RE: [PATCH] ARM: OMAP: hwmod: Fix error handling in functions used OMAP4 onwards
On Tue, Mar 27, 2012 at 15:28:31, Nayak, Rajendra wrote:
Some functions like _omap4_disable_module() and _omap4_wait_target_disable()
are (will be) used on all OMAPs OMAP4 and beyond which support module level
control. Fix the error checks in these functions to return if called on
any platform pre OMAP4 (i.e OMAP2 and OMAP3) instead of checking for
!cpu_is_omap44xx(). This avoids having to update the error check with a
' !cpu_is_omap54xx()' when OMAP5 is introduced and possibly similar updates
when further OMAP generations are added.
Let me add some flavor here :)
AM33xx, which has module level control, but falls under OMAP3 family of
devices. cpu_is_omap34xx() is true for AM33xx device and we have to add
check in all these functions. And I am sure we will have many of such
devices in the future.
Can we use some flag based option here, instead of cpu_is_xxx() check?
Thanks,
Vaibhav
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 8ac26f2..f2a9afa 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -808,7 +808,7 @@ static void _enable_module(struct omap_hwmod *oh)
*/
static int _omap4_wait_target_disable(struct omap_hwmod *oh)
{
- if (!cpu_is_omap44xx())
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
return 0;
if (!oh)
@@ -838,7 +838,7 @@ static int _omap4_disable_module(struct omap_hwmod *oh)
int v;
/* The module mode does not exist prior OMAP4 */
- if (!cpu_is_omap44xx())
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
return -EINVAL;
if (!oh-clkdm || !oh-prcm.omap4.modulemode)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/12] Add dummy smsc911x regulators to cm-t35.
Hi Tony, On 03/27/12 19:28, Tony Lindgren wrote: * Igor Grinberg grinb...@compulab.co.il [120327 08:56]: Hi Russ, This patch works, but can we, please use the attached patch instead? Hmm what's the difference here? Do you have some real controllable regulator for one of the smsc911x instances? Well, the difference here is that those regulators will only be present if the smsc911x controllers are present and their initialization is done along with the controllers. Also, I want to separate the cm-t35 from sb-t35 for future easier refactoring of the sb-t35 code so it can be reused also on cm-t3517. Only vddvario for smsc911x.0 is controllable - connected to VIO, but VIO will never be disabled as it also controls many other devices (DRAM is among them), so I prefer it to be dummy and keep it together with vdd33a. Anyways, I take it that you have tested that both smsc911x interfaces work now? Yes, both regulators are registered and found by the smsc911x driver. There is some kind of problem with the smsc911x.1, but it looks unrelated to the patch: smsc911x: Driver version 2008-10-21 irq 323: nobody cared (try booting with the irqpoll option) [c001ae6c] (unwind_backtrace+0x0/0xfc) from [c0088960] (__report_bad_irq+0x28/0xbc) [c0088960] (__report_bad_irq+0x28/0xbc) from [c0088bd4] (note_interrupt+0x1e0/0x230) [c0088bd4] (note_interrupt+0x1e0/0x230) from [c0086e48] (handle_irq_event_percpu+0xb0/0x1a0) [c0086e48] (handle_irq_event_percpu+0xb0/0x1a0) from [c0086f74] (handle_irq_event+0x3c/0x5c) [c0086f74] (handle_irq_event+0x3c/0x5c) from [c00895a0] (handle_level_irq+0x90/0xfc) [c00895a0] (handle_level_irq+0x90/0xfc) from [c008699c] (generic_handle_irq+0x38/0x40) [c008699c] (generic_handle_irq+0x38/0x40) from [c02635a0] (gpio_irq_handler+0x1b0/0x20c) [c02635a0] (gpio_irq_handler+0x1b0/0x20c) from [c008699c] (generic_handle_irq+0x38/0x40) [c008699c] (generic_handle_irq+0x38/0x40) from [c0015404] (handle_IRQ+0x38/0x84) [c0015404] (handle_IRQ+0x38/0x84) from [c000865c] (omap3_intc_handle_irq+0x48/0x4c) [c000865c] (omap3_intc_handle_irq+0x48/0x4c) from [c00140c4] (__irq_svc+0x44/0x78) Exception stack(0xcf02de20 to 0xcf02de68) de20: cf02c018 cf02c000 cf02de58 6013 c06739fc 0143 c06739fc de40: 6013 0508 c06739dc 00022d69 cf02de68 cf02b3c0 c04890fc de60: 2013 [c00140c4] (__irq_svc+0x44/0x78) from [c04890fc] (_raw_spin_unlock_irqrestore+0x64/0x68) [c04890fc] (_raw_spin_unlock_irqrestore+0x64/0x68) from [c0087d50] (__setup_irq+0x1b4/0x3d4) [c0087d50] (__setup_irq+0x1b4/0x3d4) from [c00881a0] (request_threaded_irq+0xdc/0x148) [c00881a0] (request_threaded_irq+0xdc/0x148) from [c0482954] (smsc911x_drv_probe+0x350/0x528) [c0482954] (smsc911x_drv_probe+0x350/0x528) from [c02d5a8c] (platform_drv_probe+0x18/0x1c) [c02d5a8c] (platform_drv_probe+0x18/0x1c) from [c02d4580] (really_probe+0x64/0x160) [c02d4580] (really_probe+0x64/0x160) from [c02d46c4] (driver_probe_device+0x48/0x60) [c02d46c4] (driver_probe_device+0x48/0x60) from [c02d4770] (__driver_attach+0x94/0x98) [c02d4770] (__driver_attach+0x94/0x98) from [c02d2ffc] (bus_for_each_dev+0x54/0x80) [c02d2ffc] (bus_for_each_dev+0x54/0x80) from [c02d3730] (bus_add_driver+0xa8/0x2a4) [c02d3730] (bus_add_driver+0xa8/0x2a4) from [c02d4d6c] (driver_register+0x78/0x184) [c02d4d6c] (driver_register+0x78/0x184) from [c0008758] (do_one_initcall+0x34/0x184) [c0008758] (do_one_initcall+0x34/0x184) from [c0613248] (do_basic_setup+0x34/0x40) [c0613248] (do_basic_setup+0x34/0x40) from [c06132b8] (kernel_init+0x64/0xec) [c06132b8] (kernel_init+0x64/0xec) from [c00154cc] (kernel_thread_exit+0x0/0x8) handlers: [c032ea98] smsc911x_irqhandler Disabling IRQ #323 I still haven't had a chance to look into this. Does anyone have a clue? -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/12] Add dummy smsc911x regulators to cm-t35.
On 03/27/12 20:32, Russ Dill wrote: No objection. 10x Russ. -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] spi/omap: Remove bus_num usage for instance index
On Mon, Mar 26, 2012 at 7:14 PM, Shubhrajyoti D shubhrajy...@ti.com wrote:
From: Benoit Cousson b-cous...@ti.com
bus_num was used to reference the mcspi controller instance in a fixed array.
Remove this array and store this information directly inside drvdata
structure.
bus_num is now just set if the pdev-id is present or with -1 for dynamic
allocation by SPI core, but the driver does not access it anymore.
Clean some bad comments format, and remove un-needed space.
Signed-off-by: Benoit Cousson b-cous...@ti.com
[Cleanup the OMAP2_MCSPI_MAX_CTRL macro as it is not needed anymore]
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c | 75 ++--
1 files changed, 34 insertions(+), 41 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index bb9274c..7785091 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -45,9 +45,6 @@
#define OMAP2_MCSPI_MAX_FREQ 4800
-/* OMAP2 has 3 SPI controllers, while OMAP3 has 4 */
-#define OMAP2_MCSPI_MAX_CTRL 4
-
#define OMAP2_MCSPI_REVISION 0x00
#define OMAP2_MCSPI_SYSSTATUS 0x14
#define OMAP2_MCSPI_IRQSTATUS 0x18
@@ -111,6 +108,16 @@ struct omap2_mcspi_dma {
#define DMA_MIN_BYTES 160
+/*
+ * Used for context save and restore, structure members to be updated
whenever
+ * corresponding registers are modified.
+ */
+struct omap2_mcspi_regs {
+ u32 modulctrl;
+ u32 wakeupenable;
+ struct list_head cs;
+};
+
struct omap2_mcspi {
struct work_struct work;
/* lock protects queue and registers */
@@ -122,8 +129,9 @@ struct omap2_mcspi {
unsigned long phys;
/* SPI1 has 4 channels, while SPI2 has 2 */
struct omap2_mcspi_dma *dma_channels;
- struct device *dev;
+ struct device *dev;
struct workqueue_struct *wq;
+ struct omap2_mcspi_regs ctx;
};
struct omap2_mcspi_cs {
@@ -135,17 +143,6 @@ struct omap2_mcspi_cs {
u32 chconf0;
};
-/* used for context save and restore, structure members to be updated
whenever
- * corresponding registers are modified.
- */
-struct omap2_mcspi_regs {
- u32 modulctrl;
- u32 wakeupenable;
- struct list_head cs;
-};
-
-static struct omap2_mcspi_regs omap2_mcspi_ctx[OMAP2_MCSPI_MAX_CTRL];
-
#define MOD_REG_BIT(val, mask, set) do { \
if (set) \
val |= mask; \
@@ -236,9 +233,12 @@ static void omap2_mcspi_force_cs(struct spi_device *spi,
int cs_active)
static void omap2_mcspi_set_master_mode(struct spi_master *master)
{
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+ struct omap2_mcspi_regs *ctx = mcspi-ctx;
u32 l;
- /* setup when switching from (reset default) slave mode
+ /*
+ * Setup when switching from (reset default) slave mode
* to single-channel master mode
*/
l = mcspi_read_reg(master, OMAP2_MCSPI_MODULCTRL);
@@ -247,24 +247,20 @@ static void omap2_mcspi_set_master_mode(struct
spi_master *master)
MOD_REG_BIT(l, OMAP2_MCSPI_MODULCTRL_SINGLE, 1);
mcspi_write_reg(master, OMAP2_MCSPI_MODULCTRL, l);
- omap2_mcspi_ctx[master-bus_num - 1].modulctrl = l;
+ ctx-modulctrl = l;
}
static void omap2_mcspi_restore_ctx(struct omap2_mcspi *mcspi)
{
- struct spi_master *spi_cntrl;
- struct omap2_mcspi_cs *cs;
- spi_cntrl = mcspi-master;
+ struct spi_master *spi_cntrl = mcspi-master;
+ struct omap2_mcspi_regs *ctx = mcspi-ctx;
+ struct omap2_mcspi_cs *cs;
/* McSPI: context restore */
- mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_MODULCTRL,
- omap2_mcspi_ctx[spi_cntrl-bus_num - 1].modulctrl);
+ mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_MODULCTRL, ctx-modulctrl);
+ mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE,
ctx-wakeupenable);
- mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE,
- omap2_mcspi_ctx[spi_cntrl-bus_num - 1].wakeupenable);
-
- list_for_each_entry(cs, omap2_mcspi_ctx[spi_cntrl-bus_num - 1].cs,
- node)
+ list_for_each_entry(cs, ctx-cs, node)
__raw_writel(cs-chconf0, cs-base + OMAP2_MCSPI_CHCONF0);
}
static void omap2_mcspi_disable_clocks(struct omap2_mcspi *mcspi)
@@ -777,7 +773,8 @@ static int omap2_mcspi_request_dma(struct spi_device *spi)
static int omap2_mcspi_setup(struct spi_device *spi)
{
int ret;
- struct omap2_mcspi *mcspi;
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(spi-master);
+ struct omap2_mcspi_regs *ctx = mcspi-ctx;
struct omap2_mcspi_dma *mcspi_dma;
struct
Re: [PATCH] ARM: OMAP: USB: fix warning on EHCI PHY reset path
On Tue, Mar 27, 2012 at 04:08:55PM +0200, Igor Grinberg wrote: When PHY reset pin is connected to a GPIO on external GPIO chip (e.g. I2C), we should not call the gpio_set_value() function, but gpio_set_value_cansleep(). Signed-off-by: Igor Grinberg grinb...@compulab.co.il Acked-by: Felipe Balbi ba...@ti.com Keshava, please give us your tested-by. Patch looks fine to me. --- This patch depends on the patch from Keshava [1]: ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue [1] http://www.spinics.net/lists/linux-omap/msg66774.html drivers/usb/host/ehci-omap.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 5c78f9e..26e9241 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -258,10 +258,10 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev) udelay(10); if (gpio_is_valid(pdata-reset_gpio_port[0])) - gpio_set_value(pdata-reset_gpio_port[0], 1); + gpio_set_value_cansleep(pdata-reset_gpio_port[0], 1); if (gpio_is_valid(pdata-reset_gpio_port[1])) - gpio_set_value(pdata-reset_gpio_port[1], 1); + gpio_set_value_cansleep(pdata-reset_gpio_port[1], 1); } return 0; -- 1.7.3.4 -- balbi signature.asc Description: Digital signature
[PATCH] ARM: OMAP3: cm-t35: add support for power off
Enable the power off feature of the TPS65930 on-board PMIC.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t35.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 8770be1..46275c6 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -499,6 +499,10 @@ static struct twl4030_gpio_platform_data cm_t35_gpio_data
= {
.setup = cm_t35_twl_gpio_setup,
};
+static struct twl4030_power_data cm_t35_power_data = {
+ .use_poweroff = true,
+};
+
static struct twl4030_platform_data cm_t35_twldata = {
/* platform_data for children goes here */
.keypad = cm_t35_kp_data,
@@ -506,6 +510,7 @@ static struct twl4030_platform_data cm_t35_twldata = {
.vmmc1 = cm_t35_vmmc1,
.vsim = cm_t35_vsim,
.vio= cm_t35_vio,
+ .power = cm_t35_power_data,
};
static void __init cm_t35_init_i2c(void)
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: USB: fix warning on EHCI PHY reset path
On Wed, Mar 28, 2012 at 2:22 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Mar 27, 2012 at 04:08:55PM +0200, Igor Grinberg wrote: When PHY reset pin is connected to a GPIO on external GPIO chip (e.g. I2C), we should not call the gpio_set_value() function, but gpio_set_value_cansleep(). Signed-off-by: Igor Grinberg grinb...@compulab.co.il Acked-by: Felipe Balbi ba...@ti.com Keshava, please give us your tested-by. Patch looks fine to me. Tried on beagle-xm where the smsc hub + smsc95xx ethernet controller relies gpio nreset sequence for initialization. Both hub + Ethernet controller get enumerated even after this patch. Tested-by: Govindraj.R govindraj.r...@ti.com --- This patch depends on the patch from Keshava [1]: ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue [1] http://www.spinics.net/lists/linux-omap/msg66774.html drivers/usb/host/ehci-omap.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 5c78f9e..26e9241 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -258,10 +258,10 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev) udelay(10); if (gpio_is_valid(pdata-reset_gpio_port[0])) - gpio_set_value(pdata-reset_gpio_port[0], 1); + gpio_set_value_cansleep(pdata-reset_gpio_port[0], 1); if (gpio_is_valid(pdata-reset_gpio_port[1])) - gpio_set_value(pdata-reset_gpio_port[1], 1); + gpio_set_value_cansleep(pdata-reset_gpio_port[1], 1); } return 0; -- 1.7.3.4 -- 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: Suspend broken on 3.3?
On Wed, Mar 28, 2012 at 3:07 AM, Kevin Hilman khil...@ti.com wrote:
Raja, Govindraj govindraj.r...@ti.com writes:
Hi Kevin,
On Tue, Mar 27, 2012 at 6:04 AM, Kevin Hilman khil...@ti.com wrote:
+Govindraj,
Joe Woodward j...@terrafix.co.uk writes:
Right, I've stepped back a bit and dug out a GUSMTIX Palo43 carrier
board on which to test the Overo OMAP3530 COM and I've found:
- Running a stock 3.3 (with absolutely no changes) does indeed suspend
correctly.
- Running the 3.3 kernel with my (minor) board modifications
(basically defining some buttons) suspends correctly as well.
Then I went back to my original board and the 3.3 still wakes up from
suspend immediately. So I had a think, and the only real differences
between my board the the GUMSTIX Palo43 board is that I am using
multiple UARTs.
Up to this point I've only wanted to wake on the console (ttyO2), and
not any other UARTs so I've stopped them waking with:
echo disabled /sys/devices/platform/omap/omap_uart.0/power/wakeup
echo disabled /sys/devices/platform/omap/omap_uart.1/power/wakeup
I wanted to check that this still worked, so tried disabling wakeup on
the console (ttyO2):
echo disabled /sys/devices/platform/omap/omap_uart.2/power/wakeup
And if I do echo mem /sys/power/state I was expecting to stay in
suspend when I typed on my keyboard... However, the kernel still woke
from suspend, which leads me to believe that the UART wakeup hasn't
been disabled?
Just to confirm: did the above work for you before v3.3?
Could you test if this is also the case your end?
Yes, I get the same behavior, which is indeed broken.
Govindraj, can you look into this?
A quick glance suggests that disabling wakeups via the sysfs file is
only disabling runtime PM, but not actually disabling wakups at the
module-level or at the IO ring.
I have started looking into this, disabling and enabling of wake-ups
from .runtime_suspend needs some changes as in here[1] with that I see pad
wakeup getting disabled and it doesn't wake up after enabling off mode
and suspending.
Thanks for looking into this.
Looks like the module wakeup event handling left to default
value during runtime clean up is causing the wakeup to happen
Here is the patch[1] to fix the same tested on 3430SDP.
--
Thanks,
Govindraj.R
[1]:
From 5a5126750d527811547a45de9546c3e0f0fac77d Mon Sep 17 00:00:00 2001
From: Govindraj.R govindraj.r...@ti.com
Date: Tue, 27 Mar 2012 18:55:00 +0530
Subject: [PATCH] OMAP2+: UART: Correct the module level wakeup enable/disable
mechanism
The commit (62f3ec5 ARM: OMAP2+: UART: Add wakeup mechanism for omap-uarts)
removed module level wakeup enable/disable mechanism and retained only
the pad wakeup handling.
On 24xx/34xx/36xx Module level wakeup events are enabled/disabled using
PM_WKEN1_CORE/PM_WKEN_PER regs. The module level wakeups are enabled by
default from bootloader, however the wakeups can be enabled/disabled
using sysfs entry
echo disabled /sys/devices/platform/omap/omap_uart.X/power/wakeup
[X=0,1,2,3]
Since module level wakeups were left enabled from bootup and when
wakeups were disabled from sysfs uart module level wakeups were
still happening as they were not getting disabled.
Adding the support to handle module level wakeups for omap2/3 socs.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 95 +-
1 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index f590afc..92ff94c 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -56,6 +56,10 @@ struct omap_uart_state {
int num;
int can_sleep;
+ void __iomem *wk_st;
+ void __iomem *wk_en;
+ u32 wk_mask;
+
struct list_head node;
struct omap_hwmod *oh;
struct platform_device *pdev;
@@ -82,17 +86,46 @@ static struct omap_uart_port_info
omap_serial_default_info[] __initdata = {
};
#ifdef CONFIG_PM
+
+static void omap_uart_disable_module_wakeup(struct omap_uart_state *uart)
+{
+ /* Clear wake-enable bit */
+ if (uart-wk_en uart-wk_mask) {
+ u32 v = __raw_readl(uart-wk_en);
+ v = ~uart-wk_mask;
+ __raw_writel(v, uart-wk_en);
+ }
+}
+
+static void omap_uart_enable_module_wakeup(struct omap_uart_state *uart)
+{
+ /* Set wake-enable bit */
+ if (uart-wk_en uart-wk_mask) {
+ u32 v = __raw_readl(uart-wk_en);
+ v |= uart-wk_mask;
+ __raw_writel(v, uart-wk_en);
+ }
+}
+
static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
{
struct omap_device *od = to_omap_device(pdev);
+ struct omap_uart_state *uart;
if (!od)
return;
- if (enable)
+ list_for_each_entry(uart, uart_list, node)
+ if (pdev-id == uart-num)
+
Re: [PATCH 1/3] OMAP2+: UART: Remove cpu checks for populating errata flags
On Wed, Mar 28, 2012 at 2:38 AM, Jon Hunter jon-hun...@ti.com wrote:
Hi Govindraj,
On 3/21/2012 5:24, Govindraj.R wrote:
From: Govindraj.Rgovindraj.r...@ti.com
Currently the errata is populated based on cpu checks this can
be removed and replaced with module version check of uart ip block.
MVR reg is provided within the uart reg map use the same
to populate the errata and thus now errata population and handling
can be managed within the driver itself.
Cc: Paul Walmsleyp...@pwsan.com
Cc: Kevin Hilmankhil...@ti.com
Signed-off-by: Felipe Balbiba...@ti.com
Signed-off-by: Govindraj.Rgovindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 8 ---
arch/arm/plat-omap/include/plat/omap-serial.h | 1 -
drivers/tty/serial/omap-serial.c | 62
-
3 files changed, 61 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index f590afc..330ee04 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -357,14 +357,6 @@ void __init omap_serial_init_port(struct
omap_board_data *bdata,
omap_up.dma_rx_poll_rate = info-dma_rx_poll_rate;
omap_up.autosuspend_timeout = info-autosuspend_timeout;
- /* Enable the MDR1 Errata i202 for OMAP2430/3xxx/44xx */
- if (!cpu_is_omap2420() !cpu_is_ti816x())
- omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS;
-
- /* Enable DMA Mode Force Idle Errata i291 for omap34xx/3630 */
- if (cpu_is_omap34xx() || cpu_is_omap3630())
- omap_up.errata |= UART_ERRATA_i291_DMA_FORCEIDLE;
-
pdata =omap_up;
pdata_size = sizeof(struct omap_uart_port_info);
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 9ff..1a52725 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -65,7 +65,6 @@ struct omap_uart_port_info {
bool dma_enabled; /* To specify DMA Mode */
unsigned int uartclk; /* UART clock rate */
upf_t flags; /* UPF_* flags */
- u32 errata;
unsigned int dma_rx_buf_size;
unsigned int dma_rx_timeout;
unsigned int autosuspend_timeout;
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index f809041..c7666d6 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -44,6 +44,13 @@
#includeplat/dmtimer.h
#includeplat/omap-serial.h
+#define UART_BUILD_REVISION(x, y) (((x) 8) | (y))
+
+#define OMAP_UART_REV_42 0x0402
+#define OMAP_UART_REV_46 0x0406
+#define OMAP_UART_REV_52 0x0502
+#define OMAP_UART_REV_63 0x0603
+
#define DEFAULT_CLK_SPEED 4800 /* 48Mhz*/
/* SCR register bitmasks */
@@ -1346,6 +1353,58 @@ static void uart_tx_dma_callback(int lch, u16
ch_status, void *data)
return;
}
+static void omap_serial_fill_features_erratas(struct uart_omap_port *up)
+{
+ u32 mvr, scheme;
+ u16 revision, major, minor;
+
+ mvr = serial_in(up, UART_OMAP_MVER);
+
+ /* Check revision register scheme */
+ scheme = mvr (0x03 30);
+ scheme= 30;
Minor nit-pick, why not ...
scheme = mvr 30;
yes will correct it.
+ switch (scheme) {
+ case 0: /* Legacy Scheme: OMAP2/3 */
+ /* MINOR_REV[0:4], MAJOR_REV[4:7] */
This scheme is also true from OMAP1 devices. Maybe we could include in the
comment.
No omap1 from $SUBJECT also reason,
mach-omap1/serial.c = 8250.c
mach-omap2/serial.c = omap-serial.c
+ major = (mvr 0xf0) 4;
+ minor = (mvr 0x0f);
+ break;
+ case 1:
+ /* New Scheme: OMAP4+ */
+ /* MINOR_REV[0:5], MAJOR_REV[8:10] */
+ major = (mvr 0x7 8) 8;
Nit-pick ...
major = (mvr 8) 0x7;
yes fine will correct this.
--
Thanks,
Govindraj.R
--
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: OMAP: USB: fix warning on EHCI PHY reset path
Hi Shubhrajyoti, On 03/28/12 12:03, Shubhrajyoti wrote: On Tuesday 27 March 2012 07:38 PM, Igor Grinberg wrote: When PHY reset pin is connected to a GPIO on external GPIO chip (e.g. I2C), we should not call the gpio_set_value() function, but gpio_set_value_cansleep(). Why so ? Whats the error otherwise ? Otherwise, we get a very confusing warnings: WARNING: at /home/grinberg/git-repo/linux-omap/drivers/gpio/gpiolib.c:1584 __gpio_set_value+0x5c/0x64() Modules linked in: [c001ae6c] (unwind_backtrace+0x0/0xfc) from [c003ba10] (warn_slowpath_common+0x54/0x64) [c003ba10] (warn_slowpath_common+0x54/0x64) from [c003ba3c] (warn_slowpath_null+0x1c/0x24) [c003ba3c] (warn_slowpath_null+0x1c/0x24) from [c0260860] (__gpio_set_value+0x5c/0x64) [c0260860] (__gpio_set_value+0x5c/0x64) from [c035fde8] (ehci_hcd_omap_probe+0x390/0x6c0) [c035fde8] (ehci_hcd_omap_probe+0x390/0x6c0) from [c02d59dc] (platform_drv_probe+0x18/0x1c) [c02d59dc] (platform_drv_probe+0x18/0x1c) from [c02d44d0] (really_probe+0x64/0x160) [c02d44d0] (really_probe+0x64/0x160) from [c02d4614] (driver_probe_device+0x48/0x60) [c02d4614] (driver_probe_device+0x48/0x60) from [c02d46c0] (__driver_attach+0x94/0x98) [c02d46c0] (__driver_attach+0x94/0x98) from [c02d2f4c] (bus_for_each_dev+0x54/0x80) [c02d2f4c] (bus_for_each_dev+0x54/0x80) from [c02d3680] (bus_add_driver+0xa8/0x2a4) [c02d3680] (bus_add_driver+0xa8/0x2a4) from [c02d4cbc] (driver_register+0x78/0x184) [c02d4cbc] (driver_register+0x78/0x184) from [c062e744] (ehci_hcd_init+0xd8/0x114) [c062e744] (ehci_hcd_init+0xd8/0x114) from [c0008758] (do_one_initcall+0x34/0x184) [c0008758] (do_one_initcall+0x34/0x184) from [c0612248] (do_basic_setup+0x34/0x40) [c0612248] (do_basic_setup+0x34/0x40) from [c06122b8] (kernel_init+0x64/0xec) [c06122b8] (kernel_init+0x64/0xec) from [c00154cc] (kernel_thread_exit+0x0/0x8) ---[ end trace 1b75b31a2719ed1e ]--- Because GPIOs can be used from atomic context, there are two versions of GPIO control functions: gpio_set|get_value() and gpio_set|get_value_cansleep(). The warning above means that the atomic context safe function has been called, but the GPIO chip is not atomic safe - requires an I2C transaction which may sleep and therefore a warning. Now, for all on SoC GPIOs, the time for the gpio_set_value_cansleep() call should not be different then the one for the gpio_set_value(). After my patch, the behavior should not change, but eliminate the warning for external GPIO chip users. Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- This patch depends on the patch from Keshava [1]: ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue [1] http://www.spinics.net/lists/linux-omap/msg66774.html drivers/usb/host/ehci-omap.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 5c78f9e..26e9241 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -258,10 +258,10 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev) udelay(10); if (gpio_is_valid(pdata-reset_gpio_port[0])) -gpio_set_value(pdata-reset_gpio_port[0], 1); +gpio_set_value_cansleep(pdata-reset_gpio_port[0], 1); if (gpio_is_valid(pdata-reset_gpio_port[1])) -gpio_set_value(pdata-reset_gpio_port[1], 1); +gpio_set_value_cansleep(pdata-reset_gpio_port[1], 1); } return 0; -- Regards, Igor. -- 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: OMAP: USB: fix warning on EHCI PHY reset path
On 03/28/12 12:53, Raja, Govindraj wrote: On Wed, Mar 28, 2012 at 2:22 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Mar 27, 2012 at 04:08:55PM +0200, Igor Grinberg wrote: When PHY reset pin is connected to a GPIO on external GPIO chip (e.g. I2C), we should not call the gpio_set_value() function, but gpio_set_value_cansleep(). Signed-off-by: Igor Grinberg grinb...@compulab.co.il Acked-by: Felipe Balbi ba...@ti.com Keshava, please give us your tested-by. Patch looks fine to me. Tried on beagle-xm where the smsc hub + smsc95xx ethernet controller relies gpio nreset sequence for initialization. Both hub + Ethernet controller get enumerated even after this patch. Tested-by: Govindraj.R govindraj.r...@ti.com Thanks Raja. -- Regards, Igor. -- 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: OMAP: USB: fix warning on EHCI PHY reset path
On Wed, Mar 28, 2012 at 4:23 PM, Raja, Govindraj govindraj.r...@ti.com wrote: On Wed, Mar 28, 2012 at 2:22 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Mar 27, 2012 at 04:08:55PM +0200, Igor Grinberg wrote: When PHY reset pin is connected to a GPIO on external GPIO chip (e.g. I2C), we should not call the gpio_set_value() function, but gpio_set_value_cansleep(). Signed-off-by: Igor Grinberg grinb...@compulab.co.il Acked-by: Felipe Balbi ba...@ti.com Keshava, please give us your tested-by. Patch looks fine to me. Tried on beagle-xm where the smsc hub + smsc95xx ethernet controller relies gpio nreset sequence for initialization. Both hub + Ethernet controller get enumerated even after this patch. Tested-by: Govindraj.R govindraj.r...@ti.com Thanks govind. --- This patch depends on the patch from Keshava [1]: ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue [1] http://www.spinics.net/lists/linux-omap/msg66774.html drivers/usb/host/ehci-omap.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 5c78f9e..26e9241 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -258,10 +258,10 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev) udelay(10); if (gpio_is_valid(pdata-reset_gpio_port[0])) - gpio_set_value(pdata-reset_gpio_port[0], 1); + gpio_set_value_cansleep(pdata-reset_gpio_port[0], 1); if (gpio_is_valid(pdata-reset_gpio_port[1])) - gpio_set_value(pdata-reset_gpio_port[1], 1); + gpio_set_value_cansleep(pdata-reset_gpio_port[1], 1); } return 0; -- 1.7.3.4 -- 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: OMAP: USB: fix warning on EHCI PHY reset path
Hi Igor, On Wed, Mar 28, 2012 at 4:43 PM, Igor Grinberg grinb...@compulab.co.il wrote: Hi Shubhrajyoti, On 03/28/12 12:03, Shubhrajyoti wrote: On Tuesday 27 March 2012 07:38 PM, Igor Grinberg wrote: When PHY reset pin is connected to a GPIO on external GPIO chip (e.g. I2C), we should not call the gpio_set_value() function, but gpio_set_value_cansleep(). Why so ? Whats the error otherwise ? Otherwise, we get a very confusing warnings: Yes I guessed so thanks for the patch. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Wed, Mar 21, 2012 at 19:30:01, Shilimkar, Santosh wrote: On Wed, Mar 21, 2012 at 5:12 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Mon, Mar 19, 2012 at 17:45:32, Shilimkar, Santosh wrote: On Monday 19 March 2012 05:14 PM, Ming Lei wrote: On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: I think you made very good point here. With the above patch, we are almost missing the capability of registering dmtimer as a clocksource for OMAP. It will always use 32k-counter, and never fall back to dmtimer. Then the only options we have here is, 1) Register both the timers, 32k-counter and dmtimer for clocksource; let Kernel pick up best rating clocksource out of these two. In case of OMAP1/2/3/4, kernel will use dmtimer, since it has better Rating. User can choose the 32k-counter clocksource via bootargs. Impact: without bootargs for clocksource selection, kernel will choose dmtimer, impacting loss of time during suspend/resume. This is the right option. The problem is gptimer clocksource doesn't work across power transitions and hence it is broken. Even for the perf, with PM enabled, dmtimer can't be used or it needs to be used with 32KHz clock which makes it no better than sync timer. So here keeping 32K sync timer is default clocksource makes sense since it is the only working and viable option. So what can be done is register both 32K and gptimer together but make gptimer clocksource registration depends on PM enabled. This should solve all the needs I guess. I am not sure this will work on all platforms, for example, AM33XX, where We do not have 32ksync timer available, but we need PM support. Also, I personally think, we should not again use compile time option here. Why not ? If 32ksync timer is not available, don't register it. Then in AM case you just have one clock-source. In case of AM33xx, what about kernel without PM support? As clocksource registration would be dependent on PM option, it won't work. I am against the idea of making gptimer as the default and asking user to choose sync32k from command-line. I understand your concern here. Btw, if you need PM, how are you going to use GPTIMER as a clocksource. Note sys-clock is generally stopped in low power states. So that leaves you option with using gptimer with 32K clock and in that case, GPTIMER is not a better clock-source compare to 32K sync timer and so shouldn't be the rating. AM33xx has GPTIMER1 in wakeup domain, so that we are already using as a Clocksource, without any issues. Thanks, Vaibhav 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 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Wed, Mar 28, 2012 at 7:46 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Wed, Mar 21, 2012 at 19:30:01, Shilimkar, Santosh wrote: On Wed, Mar 21, 2012 at 5:12 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Mon, Mar 19, 2012 at 17:45:32, Shilimkar, Santosh wrote: On Monday 19 March 2012 05:14 PM, Ming Lei wrote: On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: [...] Btw, if you need PM, how are you going to use GPTIMER as a clocksource. Note sys-clock is generally stopped in low power states. So that leaves you option with using gptimer with 32K clock and in that case, GPTIMER is not a better clock-source compare to 32K sync timer and so shouldn't be the rating. AM33xx has GPTIMER1 in wakeup domain, so that we are already using as a Clocksource, without any issues. GPTIMER1 is in wakeup domain on OMAP too but that doesn't solve the issue I am talking. Once the sysclock is stopped, GPTIMER can't tick anymore even if it is in wakeup domain. The only way it will work is using always running 32KHz clock as the clock input to GPT1. And then the end result is the accuracy of GPTIMER = sync 32K timer. So they are of same rating. Hope it is clear now. 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 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Wed, Mar 28, 2012 at 19:50:02, Shilimkar, Santosh wrote: On Wed, Mar 28, 2012 at 7:46 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Wed, Mar 21, 2012 at 19:30:01, Shilimkar, Santosh wrote: On Wed, Mar 21, 2012 at 5:12 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Mon, Mar 19, 2012 at 17:45:32, Shilimkar, Santosh wrote: On Monday 19 March 2012 05:14 PM, Ming Lei wrote: On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: [...] Btw, if you need PM, how are you going to use GPTIMER as a clocksource. Note sys-clock is generally stopped in low power states. So that leaves you option with using gptimer with 32K clock and in that case, GPTIMER is not a better clock-source compare to 32K sync timer and so shouldn't be the rating. AM33xx has GPTIMER1 in wakeup domain, so that we are already using as a Clocksource, without any issues. GPTIMER1 is in wakeup domain on OMAP too but that doesn't solve the issue I am talking. Once the sysclock is stopped, GPTIMER can't tick anymore even if it is in wakeup domain. The only way it will work is using always running 32KHz clock as the clock input to GPT1. And then the end result is the accuracy of GPTIMER = sync 32K timer. So they are of same rating. Ohh ok, sorry I should have clarified it in my last response itself. AM33xx architecture is bit different than OMAP family, and gmtimer1 is sourced from RTC32K clock, which is in wakeup domain. This means we have RTC32K clock always running across suspend/resume. 0 - SEL1: Select CLK_M_OSC clock 1 - SEL2: Select CLK_32KHZ clock 2 - SEL3: Select TCLKIN clock 3 - SEL4: Select CLK_RC32K clock 4 - SEL5: Selects the CLK_32768 from 32KHz Crystal Osc We use value 4 here, for RTC32K (always on clock). I hope this clarifies what I am trying to say here. Thanks, Vaibhav Hope it is clear now. 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 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Wed, Mar 28, 2012 at 8:07 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Wed, Mar 28, 2012 at 19:50:02, Shilimkar, Santosh wrote: On Wed, Mar 28, 2012 at 7:46 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Wed, Mar 21, 2012 at 19:30:01, Shilimkar, Santosh wrote: On Wed, Mar 21, 2012 at 5:12 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Mon, Mar 19, 2012 at 17:45:32, Shilimkar, Santosh wrote: On Monday 19 March 2012 05:14 PM, Ming Lei wrote: On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: [...] Btw, if you need PM, how are you going to use GPTIMER as a clocksource. Note sys-clock is generally stopped in low power states. So that leaves you option with using gptimer with 32K clock and in that case, GPTIMER is not a better clock-source compare to 32K sync timer and so shouldn't be the rating. AM33xx has GPTIMER1 in wakeup domain, so that we are already using as a Clocksource, without any issues. GPTIMER1 is in wakeup domain on OMAP too but that doesn't solve the issue I am talking. Once the sysclock is stopped, GPTIMER can't tick anymore even if it is in wakeup domain. The only way it will work is using always running 32KHz clock as the clock input to GPT1. And then the end result is the accuracy of GPTIMER = sync 32K timer. So they are of same rating. Ohh ok, sorry I should have clarified it in my last response itself. np. AM33xx architecture is bit different than OMAP family, and gmtimer1 is sourced from RTC32K clock, which is in wakeup domain. This means we have RTC32K clock always running across suspend/resume. 0 - SEL1: Select CLK_M_OSC clock 1 - SEL2: Select CLK_32KHZ clock 2 - SEL3: Select TCLKIN clock 3 - SEL4: Select CLK_RC32K clock 4 - SEL5: Selects the CLK_32768 from 32KHz Crystal Osc We use value 4 here, for RTC32K (always on clock). I hope this clarifies what I am trying to say here. I thought so and now if you look at last part of my comment. Rating of 32K based synctimer and 32K based GPTIMER should be same because of the precision. That's the main point why I was saying that GPTIMER is not a better clock-source( with 32k clock src) than sync timer when both are enabled together. 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: Suspend broken on 3.3?
-Original Message-
From: Raja, Govindraj govindraj.r...@ti.com
To: Kevin Hilman khil...@ti.com
Cc: Joe Woodward j...@terrafix.co.uk, linux-omap@vger.kernel.org
linux-omap@vger.kernel.org, Felipe Balbi ba...@ti.com
Date: Wed, 28 Mar 2012 16:29:53 +0530
Subject: Re: Suspend broken on 3.3?
On Wed, Mar 28, 2012 at 3:07 AM, Kevin Hilman khil...@ti.com wrote:
Raja, Govindraj govindraj.r...@ti.com writes:
Hi Kevin,
On Tue, Mar 27, 2012 at 6:04 AM, Kevin Hilman khil...@ti.com
wrote:
+Govindraj,
Joe Woodward j...@terrafix.co.uk writes:
Right, I've stepped back a bit and dug out a GUSMTIX Palo43
carrier
board on which to test the Overo OMAP3530 COM and I've found:
- Running a stock 3.3 (with absolutely no changes) does indeed
suspend correctly.
- Running the 3.3 kernel with my (minor) board modifications
(basically defining some buttons) suspends correctly as well.
Then I went back to my original board and the 3.3 still wakes up
from
suspend immediately. So I had a think, and the only real
differences
between my board the the GUMSTIX Palo43 board is that I am using
multiple UARTs.
Up to this point I've only wanted to wake on the console (ttyO2),
and
not any other UARTs so I've stopped them waking with:
echo disabled
/sys/devices/platform/omap/omap_uart.0/power/wakeup
echo disabled
/sys/devices/platform/omap/omap_uart.1/power/wakeup
I wanted to check that this still worked, so tried disabling
wakeup on
the console (ttyO2):
echo disabled
/sys/devices/platform/omap/omap_uart.2/power/wakeup
And if I do echo mem /sys/power/state I was expecting to stay
in
suspend when I typed on my keyboard... However, the kernel still
woke
from suspend, which leads me to believe that the UART wakeup
hasn't
been disabled?
Just to confirm: did the above work for you before v3.3?
Could you test if this is also the case your end?
Yes, I get the same behavior, which is indeed broken.
Govindraj, can you look into this?
A quick glance suggests that disabling wakeups via the sysfs file
is
only disabling runtime PM, but not actually disabling wakups at the
module-level or at the IO ring.
I have started looking into this, disabling and enabling of wake-ups
from .runtime_suspend needs some changes as in here[1] with that I
see pad
wakeup getting disabled and it doesn't wake up after enabling off
mode
and suspending.
Thanks for looking into this.
Looks like the module wakeup event handling left to default
value during runtime clean up is causing the wakeup to happen
Here is the patch[1] to fix the same tested on 3430SDP.
--
Thanks,
Thanks,
This patch fixes the suspend problem for me, but there is another UART issue...
Basically I've got a fairly high speed data source (in UART terms, 900KBaud)
pumping data to the OMAP (such as GPS positions).
I don't want this to wake me when suspended (which this patch fixes).
However, it seems on 3.3 that I get a lot of corruption/lost characters, which
I'm assuming is because the UART is implementing runtime-PM.
So my next question is: How do I disable runtime-PM/force-always-on for a given
UART? Can this be done via the sysfs?
Or where are the runtime-PM constraints set for the UART? I'm guessing they'll
work for 115200Baud, but my high speed UART fowls these?
Cheers,
Joe
Govindraj.R
[1]:
From 5a5126750d527811547a45de9546c3e0f0fac77d Mon Sep 17 00:00:00 2001
From: Govindraj.R govindraj.r...@ti.com
Date: Tue, 27 Mar 2012 18:55:00 +0530
Subject: [PATCH] OMAP2+: UART: Correct the module level wakeup
enable/disable
mechanism
The commit (62f3ec5 ARM: OMAP2+: UART: Add wakeup mechanism for
omap-uarts)
removed module level wakeup enable/disable mechanism and retained only
the pad wakeup handling.
On 24xx/34xx/36xx Module level wakeup events are enabled/disabled using
PM_WKEN1_CORE/PM_WKEN_PER regs. The module level wakeups are enabled by
default from bootloader, however the wakeups can be enabled/disabled
using sysfs entry
echo disabled /sys/devices/platform/omap/omap_uart.X/power/wakeup
[X=0,1,2,3]
Since module level wakeups were left enabled from bootup and when
wakeups were disabled from sysfs uart module level wakeups were
still happening as they were not getting disabled.
Adding the support to handle module level wakeups for omap2/3 socs.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 95
+-
1 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c
b/arch/arm/mach-omap2/serial.c
index f590afc..92ff94c 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -56,6 +56,10 @@ struct omap_uart_state {
int num;
int can_sleep;
+ void __iomem *wk_st;
+ void __iomem *wk_en;
+ u32 wk_mask;
+
struct list_head node;
Re: [PATCH 1/3] OMAP2+: UART: Remove cpu checks for populating errata flags
Hi Govindraj,
On 3/21/2012 5:24, Govindraj.R wrote:
From: Govindraj.Rgovindraj.r...@ti.com
Currently the errata is populated based on cpu checks this can
be removed and replaced with module version check of uart ip block.
MVR reg is provided within the uart reg map use the same
to populate the errata and thus now errata population and handling
can be managed within the driver itself.
Cc: Paul Walmsleyp...@pwsan.com
Cc: Kevin Hilmankhil...@ti.com
Signed-off-by: Felipe Balbiba...@ti.com
Signed-off-by: Govindraj.Rgovindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |8 ---
arch/arm/plat-omap/include/plat/omap-serial.h |1 -
drivers/tty/serial/omap-serial.c | 62 -
3 files changed, 61 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index f590afc..330ee04 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -357,14 +357,6 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
omap_up.dma_rx_poll_rate = info-dma_rx_poll_rate;
omap_up.autosuspend_timeout = info-autosuspend_timeout;
- /* Enable the MDR1 Errata i202 for OMAP2430/3xxx/44xx */
- if (!cpu_is_omap2420() !cpu_is_ti816x())
- omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS;
-
- /* Enable DMA Mode Force Idle Errata i291 for omap34xx/3630 */
- if (cpu_is_omap34xx() || cpu_is_omap3630())
- omap_up.errata |= UART_ERRATA_i291_DMA_FORCEIDLE;
-
pdata =omap_up;
pdata_size = sizeof(struct omap_uart_port_info);
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 9ff..1a52725 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -65,7 +65,6 @@ struct omap_uart_port_info {
booldma_enabled;/* To specify DMA Mode */
unsigned intuartclk;/* UART clock rate */
upf_t flags; /* UPF_* flags */
- u32 errata;
unsigned intdma_rx_buf_size;
unsigned intdma_rx_timeout;
unsigned intautosuspend_timeout;
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f809041..c7666d6 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -44,6 +44,13 @@
#includeplat/dmtimer.h
#includeplat/omap-serial.h
+#define UART_BUILD_REVISION(x, y) (((x) 8) | (y))
+
+#define OMAP_UART_REV_42 0x0402
+#define OMAP_UART_REV_46 0x0406
+#define OMAP_UART_REV_52 0x0502
+#define OMAP_UART_REV_63 0x0603
+
#define DEFAULT_CLK_SPEED 4800 /* 48Mhz*/
/* SCR register bitmasks */
@@ -1346,6 +1353,58 @@ static void uart_tx_dma_callback(int lch, u16 ch_status,
void *data)
return;
}
+static void omap_serial_fill_features_erratas(struct uart_omap_port *up)
+{
+ u32 mvr, scheme;
+ u16 revision, major, minor;
+
+ mvr = serial_in(up, UART_OMAP_MVER);
+
+ /* Check revision register scheme */
+ scheme = mvr (0x03 30);
+ scheme= 30;
Minor nit-pick, why not just ...
scheme = mvr 30;
+ switch (scheme) {
+ case 0: /* Legacy Scheme: OMAP2/3 */
+ /* MINOR_REV[0:4], MAJOR_REV[4:7] */
Same scheme applies to OMAP1 devices too. So maybe we should include in
the comment.
+ major = (mvr 0xf0) 4;
+ minor = (mvr 0x0f);
+ break;
+ case 1:
+ /* New Scheme: OMAP4+ */
+ /* MINOR_REV[0:5], MAJOR_REV[8:10] */
+ major = (mvr 0x7 8) 8;
Nit-pick ...
major = (mvr 8) 0x7;
+ minor = (mvr 0x3f);
+ break;
+ default:
+ dev_warn(up-pdev-dev,
+ Unknown %s revision, defaulting to highest\n,
+ up-name);
+ /* highest possible revision */
+ major = 0xff;
+ minor = 0xff;
+ }
+
+ /* normalize revision for the driver */
+ revision = UART_BUILD_REVISION(major, minor);
+
+ switch (revision) {
+ case OMAP_UART_REV_46:
+ up-errata |= (UART_ERRATA_i202_MDR1_ACCESS |
+ UART_ERRATA_i291_DMA_FORCEIDLE);
+ break;
+ case OMAP_UART_REV_52:
+ up-errata |= (UART_ERRATA_i202_MDR1_ACCESS |
+ UART_ERRATA_i291_DMA_FORCEIDLE);
+ break;
+ case OMAP_UART_REV_63:
+ up-errata |= UART_ERRATA_i202_MDR1_ACCESS;
+ break;
+ default:
+ break;
+ }
Should we also warn on an unknown revision?
+}
+
static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev)
{
struct
Re: [PATCH] ARM: OMAP: hwmod: Fix error handling in functions used OMAP4 onwards
Hi Paul,
On 3/27/2012 21:39, Paul Walmsley wrote:
Hi Jon,
On Tue, 27 Mar 2012, Jon Hunter wrote:
On 3/27/2012 4:58, Rajendra Nayak wrote:
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 8ac26f2..f2a9afa 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -808,7 +808,7 @@ static void _enable_module(struct omap_hwmod *oh)
*/
static int _omap4_wait_target_disable(struct omap_hwmod *oh)
{
- if (!cpu_is_omap44xx())
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
return 0;
What about omap36xx?
Unfortunately, cpu_is_omap34xx() also covers OMAP36xx :-(
Thanks. Is that still the case when MULTI_OMAP2 is defined? I can see if
it is not define then it will always return 1 for all OMAP3, but for
MULTI_OMAP2 it did not seem to me that it would. May be I should test ...
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] OMAP2+: UART: Remove cpu checks for populating errata flags
Hi Govindraj,
On 3/28/2012 6:09, Raja, Govindraj wrote:
On Wed, Mar 28, 2012 at 2:38 AM, Jon Hunterjon-hun...@ti.com wrote:
Hi Govindraj,
On 3/21/2012 5:24, Govindraj.R wrote:
From: Govindraj.Rgovindraj.r...@ti.com
Currently the errata is populated based on cpu checks this can
be removed and replaced with module version check of uart ip block.
MVR reg is provided within the uart reg map use the same
to populate the errata and thus now errata population and handling
can be managed within the driver itself.
Cc: Paul Walmsleyp...@pwsan.com
Cc: Kevin Hilmankhil...@ti.com
Signed-off-by: Felipe Balbiba...@ti.com
Signed-off-by: Govindraj.Rgovindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |8 ---
arch/arm/plat-omap/include/plat/omap-serial.h |1 -
drivers/tty/serial/omap-serial.c | 62
-
3 files changed, 61 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index f590afc..330ee04 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -357,14 +357,6 @@ void __init omap_serial_init_port(struct
omap_board_data *bdata,
omap_up.dma_rx_poll_rate = info-dma_rx_poll_rate;
omap_up.autosuspend_timeout = info-autosuspend_timeout;
- /* Enable the MDR1 Errata i202 for OMAP2430/3xxx/44xx */
- if (!cpu_is_omap2420()!cpu_is_ti816x())
- omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS;
-
- /* Enable DMA Mode Force Idle Errata i291 for omap34xx/3630 */
- if (cpu_is_omap34xx() || cpu_is_omap3630())
- omap_up.errata |= UART_ERRATA_i291_DMA_FORCEIDLE;
-
pdata =omap_up;
pdata_size = sizeof(struct omap_uart_port_info);
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 9ff..1a52725 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -65,7 +65,6 @@ struct omap_uart_port_info {
booldma_enabled;/* To specify DMA Mode */
unsigned intuartclk;/* UART clock rate */
upf_t flags; /* UPF_* flags */
- u32 errata;
unsigned intdma_rx_buf_size;
unsigned intdma_rx_timeout;
unsigned intautosuspend_timeout;
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index f809041..c7666d6 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -44,6 +44,13 @@
#includeplat/dmtimer.h
#includeplat/omap-serial.h
+#define UART_BUILD_REVISION(x, y) (((x)8) | (y))
+
+#define OMAP_UART_REV_42 0x0402
+#define OMAP_UART_REV_46 0x0406
+#define OMAP_UART_REV_52 0x0502
+#define OMAP_UART_REV_63 0x0603
+
#define DEFAULT_CLK_SPEED 4800 /* 48Mhz*/
/* SCR register bitmasks */
@@ -1346,6 +1353,58 @@ static void uart_tx_dma_callback(int lch, u16
ch_status, void *data)
return;
}
+static void omap_serial_fill_features_erratas(struct uart_omap_port *up)
+{
+ u32 mvr, scheme;
+ u16 revision, major, minor;
+
+ mvr = serial_in(up, UART_OMAP_MVER);
+
+ /* Check revision register scheme */
+ scheme = mvr(0x0330);
+ scheme= 30;
Minor nit-pick, why not ...
scheme = mvr 30;
yes will correct it.
Thinking some more, could be better to add some #defines for
OMAP_MVR_VERSION_MASK/SHIFT here.
+ switch (scheme) {
+ case 0: /* Legacy Scheme: OMAP2/3 */
+ /* MINOR_REV[0:4], MAJOR_REV[4:7] */
This scheme is also true from OMAP1 devices. Maybe we could include in the
comment.
No omap1 from $SUBJECT also reason,
mach-omap1/serial.c = 8250.c
mach-omap2/serial.c = omap-serial.c
Got it! Thanks.
+ major = (mvr0xf0)4;
+ minor = (mvr0x0f);
+ break;
+ case 1:
+ /* New Scheme: OMAP4+ */
+ /* MINOR_REV[0:5], MAJOR_REV[8:10] */
+ major = (mvr0x78)8;
Nit-pick ...
major = (mvr 8) 0x7;
yes fine will correct this.
May be we should add #defines here to for OMAP_UART_MVR1_MAJ_MASK/SHIFT,
OMAP_UART_MVR1_MIN_MASK/SHIFT, OMAP_UART_MVR2_MAJ_MASK/SHIFT and
OMAP_UART_MVR2_MIN_MASK/SHIFT.
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/12] Add dummy smsc911x regulators to cm-t35.
* Igor Grinberg grinb...@compulab.co.il [120327 23:36]: Hi Tony, On 03/27/12 19:28, Tony Lindgren wrote: * Igor Grinberg grinb...@compulab.co.il [120327 08:56]: Hi Russ, This patch works, but can we, please use the attached patch instead? Hmm what's the difference here? Do you have some real controllable regulator for one of the smsc911x instances? Well, the difference here is that those regulators will only be present if the smsc911x controllers are present and their initialization is done along with the controllers. Also, I want to separate the cm-t35 from sb-t35 for future easier refactoring of the sb-t35 code so it can be reused also on cm-t3517. Only vddvario for smsc911x.0 is controllable - connected to VIO, but VIO will never be disabled as it also controls many other devices (DRAM is among them), so I prefer it to be dummy and keep it together with vdd33a. OK thanks for the clarification. Anyways, I take it that you have tested that both smsc911x interfaces work now? Yes, both regulators are registered and found by the smsc911x driver. There is some kind of problem with the smsc911x.1, but it looks unrelated to the patch: OK good to hear. Regarding the following problem.. smsc911x: Driver version 2008-10-21 irq 323: nobody cared (try booting with the irqpoll option) [c001ae6c] (unwind_backtrace+0x0/0xfc) from [c0088960] (__report_bad_irq+0x28/0xbc) [c0088960] (__report_bad_irq+0x28/0xbc) from [c0088bd4] (note_interrupt+0x1e0/0x230) [c0088bd4] (note_interrupt+0x1e0/0x230) from [c0086e48] (handle_irq_event_percpu+0xb0/0x1a0) [c0086e48] (handle_irq_event_percpu+0xb0/0x1a0) from [c0086f74] (handle_irq_event+0x3c/0x5c) [c0086f74] (handle_irq_event+0x3c/0x5c) from [c00895a0] (handle_level_irq+0x90/0xfc) [c00895a0] (handle_level_irq+0x90/0xfc) from [c008699c] (generic_handle_irq+0x38/0x40) [c008699c] (generic_handle_irq+0x38/0x40) from [c02635a0] (gpio_irq_handler+0x1b0/0x20c) [c02635a0] (gpio_irq_handler+0x1b0/0x20c) from [c008699c] (generic_handle_irq+0x38/0x40) [c008699c] (generic_handle_irq+0x38/0x40) from [c0015404] (handle_IRQ+0x38/0x84) [c0015404] (handle_IRQ+0x38/0x84) from [c000865c] (omap3_intc_handle_irq+0x48/0x4c) [c000865c] (omap3_intc_handle_irq+0x48/0x4c) from [c00140c4] (__irq_svc+0x44/0x78) Exception stack(0xcf02de20 to 0xcf02de68) de20: cf02c018 cf02c000 cf02de58 6013 c06739fc 0143 c06739fc de40: 6013 0508 c06739dc 00022d69 cf02de68 cf02b3c0 c04890fc de60: 2013 [c00140c4] (__irq_svc+0x44/0x78) from [c04890fc] (_raw_spin_unlock_irqrestore+0x64/0x68) [c04890fc] (_raw_spin_unlock_irqrestore+0x64/0x68) from [c0087d50] (__setup_irq+0x1b4/0x3d4) [c0087d50] (__setup_irq+0x1b4/0x3d4) from [c00881a0] (request_threaded_irq+0xdc/0x148) [c00881a0] (request_threaded_irq+0xdc/0x148) from [c0482954] (smsc911x_drv_probe+0x350/0x528) [c0482954] (smsc911x_drv_probe+0x350/0x528) from [c02d5a8c] (platform_drv_probe+0x18/0x1c) [c02d5a8c] (platform_drv_probe+0x18/0x1c) from [c02d4580] (really_probe+0x64/0x160) [c02d4580] (really_probe+0x64/0x160) from [c02d46c4] (driver_probe_device+0x48/0x60) [c02d46c4] (driver_probe_device+0x48/0x60) from [c02d4770] (__driver_attach+0x94/0x98) [c02d4770] (__driver_attach+0x94/0x98) from [c02d2ffc] (bus_for_each_dev+0x54/0x80) [c02d2ffc] (bus_for_each_dev+0x54/0x80) from [c02d3730] (bus_add_driver+0xa8/0x2a4) [c02d3730] (bus_add_driver+0xa8/0x2a4) from [c02d4d6c] (driver_register+0x78/0x184) [c02d4d6c] (driver_register+0x78/0x184) from [c0008758] (do_one_initcall+0x34/0x184) [c0008758] (do_one_initcall+0x34/0x184) from [c0613248] (do_basic_setup+0x34/0x40) [c0613248] (do_basic_setup+0x34/0x40) from [c06132b8] (kernel_init+0x64/0xec) [c06132b8] (kernel_init+0x64/0xec) from [c00154cc] (kernel_thread_exit+0x0/0x8) handlers: [c032ea98] smsc911x_irqhandler Disabling IRQ #323 I still haven't had a chance to look into this. Does anyone have a clue? ..care to see if you have OMAP_GPIO_IRQ entry for your board? If so, we're still waiting for the cleanup-fixes branch to get merged that changes things to use gpio_to_irq() instead. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suspend broken on 3.3?
+Paul, NeilBrown who both have worked on/around recent UART breakage since v3.2 Joe Woodward j...@terrafix.co.uk writes: [...] This patch fixes the suspend problem for me, but there is another UART issue... Basically I've got a fairly high speed data source (in UART terms, 900KBaud) pumping data to the OMAP (such as GPS positions). I don't want this to wake me when suspended (which this patch fixes). However, it seems on 3.3 that I get a lot of corruption/lost characters, which I'm assuming is because the UART is implementing runtime-PM. So my next question is: How do I disable runtime-PM/force-always-on for a given UART? Can this be done via the sysfs? Yes, but the boot-time default for this is that the UARTs have runtime PM disabled since the default autosuspend timeout is set to -1. You must be setting an autosuspend timeout 0 if you're seeing runtime PM kick in. That being said, even with an autosuspend timeout enabled, you can disable runtime PM by setting the /sys/devices/.../power/control knob to 'on' (instead of auto, which means it's controle by runtime PM): echo on /sys/devices/platform/omap/omap_uart.2/power/control That will disable runtime PM and leave the UARTs always clocked. Or where are the runtime-PM constraints set for the UART? Look for this in the driver: /* calculate wakeup latency constraint */ up-calc_latency = (USEC_PER_SEC * up-port.fifosize) / (baud / 8); I'm guessing they'll work for 115200Baud, but my high speed UART fowls these? The constraint calculations take into account baud rate, but are known to be somewhat broken currently. You might want to experiment with Paul's work on fixing up the QoS contstraint calculation[1] to see if it helps as well. That is available here Kevin [1] git://git.pwsan.com/linux-2.6 omap_serial_fix_pm_qos_formula_devel_3.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] mtd: plat_nand: Add default partition parser and use it
This patch series adds cmdlinepart as the default partition parser for the plat_nand driver and updates all the arch setup code to use it. Arch setup code that requires other partition parsers can still pass that information as chip.part_probe_types. Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com mtd: plat_nand: Add default partition parser to driver arm: Use the plat_nand default partition parser blackfin: Use the plat_nand default partition parser mips: Use the plat_nand default partition parser sh: Use the plat_nand default partition parser arch/arm/mach-ep93xx/snappercl15.c|3 --- arch/arm/mach-ep93xx/ts72xx.c |3 --- arch/arm/mach-ixp4xx/ixdp425-setup.c |3 --- arch/arm/mach-omap1/board-fsample.c |3 --- arch/arm/mach-omap1/board-h2.c|3 --- arch/arm/mach-omap1/board-h3.c|3 --- arch/arm/mach-omap1/board-perseus2.c |3 --- arch/arm/mach-orion5x/ts78xx-setup.c |3 --- arch/arm/mach-pxa/balloon3.c |3 --- arch/arm/mach-pxa/em-x270.c |3 --- arch/arm/mach-pxa/palmtx.c|3 --- arch/blackfin/mach-bf561/boards/acvilon.c |3 --- arch/mips/alchemy/devboards/db1200.c |3 --- arch/mips/alchemy/devboards/db1300.c |3 --- arch/mips/alchemy/devboards/db1550.c |3 --- arch/mips/pnx833x/common/platform.c |6 -- arch/sh/boards/mach-migor/setup.c |1 - drivers/mtd/nand/plat_nand.c |8 ++-- 18 files changed, 6 insertions(+), 54 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] arm: Use the plat_nand default partition parser
Use the default partition parser, cmdlinepart, provided by the plat_nand driver.
Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com
Cc: Ryan Mallon rmal...@gmail.com
Cc: Imre Kaloz ka...@openwrt.org
Cc: Krzysztof Halasa k...@pm.waw.pl
Cc: Tony Lindgren t...@atomide.com
Cc: Alexander Clouter a...@digriz.org.uk
Cc: Nicolas Pitre n...@fluxnic.net
Cc: Eric Miao eric.y.m...@gmail.com
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Marek Vasut marek.va...@gmail.com
---
diff --git a/arch/arm/mach-ep93xx/snappercl15.c
b/arch/arm/mach-ep93xx/snappercl15.c
index 0c00852..5df9092 100644
--- a/arch/arm/mach-ep93xx/snappercl15.c
+++ b/arch/arm/mach-ep93xx/snappercl15.c
@@ -82,8 +82,6 @@ static int snappercl15_nand_dev_ready(struct mtd_info *mtd)
return !!(__raw_readw(NAND_CTRL_ADDR(chip)) SNAPPERCL15_NAND_RDY);
}
-static const char *snappercl15_nand_part_probes[] = {cmdlinepart, NULL};
-
static struct mtd_partition snappercl15_nand_parts[] = {
{
.name = Kernel,
@@ -100,7 +98,6 @@ static struct mtd_partition snappercl15_nand_parts[] = {
static struct platform_nand_data snappercl15_nand_data = {
.chip = {
.nr_chips = 1,
- .part_probe_types = snappercl15_nand_part_probes,
.partitions = snappercl15_nand_parts,
.nr_partitions = ARRAY_SIZE(snappercl15_nand_parts),
.options= NAND_NO_AUTOINCR,
diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index 5ea7909..14d7121 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -105,8 +105,6 @@ static int ts72xx_nand_device_ready(struct mtd_info *mtd)
return !!(__raw_readb(addr) 0x20);
}
-static const char *ts72xx_nand_part_probes[] = { cmdlinepart, NULL };
-
#define TS72XX_BOOTROM_PART_SIZE (SZ_16K)
#define TS72XX_REDBOOT_PART_SIZE (SZ_2M + SZ_1M)
@@ -134,7 +132,6 @@ static struct platform_nand_data ts72xx_nand_data = {
.nr_chips = 1,
.chip_offset= 0,
.chip_delay = 15,
- .part_probe_types = ts72xx_nand_part_probes,
.partitions = ts72xx_nand_parts,
.nr_partitions = ARRAY_SIZE(ts72xx_nand_parts),
},
diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c
b/arch/arm/mach-ixp4xx/ixdp425-setup.c
index 3d742ae..fccfc73 100644
--- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
+++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
@@ -60,8 +60,6 @@ static struct platform_device ixdp425_flash = {
#if defined(CONFIG_MTD_NAND_PLATFORM) || \
defined(CONFIG_MTD_NAND_PLATFORM_MODULE)
-const char *part_probes[] = { cmdlinepart, NULL };
-
static struct mtd_partition ixdp425_partitions[] = {
{
.name = ixp400 NAND FS 0,
@@ -101,7 +99,6 @@ static struct platform_nand_data ixdp425_flash_nand_data = {
.nr_chips = 1,
.chip_delay = 30,
.options= NAND_NO_AUTOINCR,
- .part_probe_types = part_probes,
.partitions = ixdp425_partitions,
.nr_partitions = ARRAY_SIZE(ixdp425_partitions),
},
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index 80bd43c..62a1e11 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -206,14 +206,11 @@ static int nand_dev_ready(struct mtd_info *mtd)
return gpio_get_value(FSAMPLE_NAND_RB_GPIO_PIN);
}
-static const char *part_probes[] = { cmdlinepart, NULL };
-
static struct platform_nand_data nand_data = {
.chip = {
.nr_chips = 1,
.chip_offset= 0,
.options= NAND_SAMSUNG_LP_OPTIONS,
- .part_probe_types = part_probes,
},
.ctrl = {
.cmd_ctrl = nand_cmd_ctl,
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index c306862..a914a7d 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -200,8 +200,6 @@ static int h2_nand_dev_ready(struct mtd_info *mtd)
return gpio_get_value(H2_NAND_RB_GPIO_PIN);
}
-static const char *h2_part_probes[] = { cmdlinepart, NULL };
-
static struct platform_nand_data h2_nand_platdata = {
.chip = {
.nr_chips = 1,
@@ -209,7 +207,6 @@ static struct platform_nand_data h2_nand_platdata = {
.nr_partitions = ARRAY_SIZE(h2_nand_partitions),
.partitions = h2_nand_partitions,
.options= NAND_SAMSUNG_LP_OPTIONS,
- .part_probe_types = h2_part_probes,
},
.ctrl = {
.cmd_ctrl = h2_nand_cmd_ctl,
diff --git
Re: [PATCH 2/5] arm: Use the plat_nand default partition parser
Dear H Hartley Sweeten,
Use the default partition parser, cmdlinepart, provided by the plat_nand
driver.
Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com
Cc: Ryan Mallon rmal...@gmail.com
Cc: Imre Kaloz ka...@openwrt.org
Cc: Krzysztof Halasa k...@pm.waw.pl
Cc: Tony Lindgren t...@atomide.com
Cc: Alexander Clouter a...@digriz.org.uk
Cc: Nicolas Pitre n...@fluxnic.net
Cc: Eric Miao eric.y.m...@gmail.com
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Marek Vasut marek.va...@gmail.com
Acked-by: Marek Vasut marek.va...@gmail.com
---
diff --git a/arch/arm/mach-ep93xx/snappercl15.c
b/arch/arm/mach-ep93xx/snappercl15.c index 0c00852..5df9092 100644
--- a/arch/arm/mach-ep93xx/snappercl15.c
+++ b/arch/arm/mach-ep93xx/snappercl15.c
@@ -82,8 +82,6 @@ static int snappercl15_nand_dev_ready(struct mtd_info
*mtd) return !!(__raw_readw(NAND_CTRL_ADDR(chip)) SNAPPERCL15_NAND_RDY);
}
-static const char *snappercl15_nand_part_probes[] = {cmdlinepart, NULL};
-
static struct mtd_partition snappercl15_nand_parts[] = {
{
.name = Kernel,
@@ -100,7 +98,6 @@ static struct mtd_partition snappercl15_nand_parts[] = {
static struct platform_nand_data snappercl15_nand_data = {
.chip = {
.nr_chips = 1,
- .part_probe_types = snappercl15_nand_part_probes,
.partitions = snappercl15_nand_parts,
.nr_partitions = ARRAY_SIZE(snappercl15_nand_parts),
.options= NAND_NO_AUTOINCR,
diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index 5ea7909..14d7121 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -105,8 +105,6 @@ static int ts72xx_nand_device_ready(struct mtd_info
*mtd) return !!(__raw_readb(addr) 0x20);
}
-static const char *ts72xx_nand_part_probes[] = { cmdlinepart, NULL };
-
#define TS72XX_BOOTROM_PART_SIZE (SZ_16K)
#define TS72XX_REDBOOT_PART_SIZE (SZ_2M + SZ_1M)
@@ -134,7 +132,6 @@ static struct platform_nand_data ts72xx_nand_data = {
.nr_chips = 1,
.chip_offset= 0,
.chip_delay = 15,
- .part_probe_types = ts72xx_nand_part_probes,
.partitions = ts72xx_nand_parts,
.nr_partitions = ARRAY_SIZE(ts72xx_nand_parts),
},
diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c
b/arch/arm/mach-ixp4xx/ixdp425-setup.c index 3d742ae..fccfc73 100644
--- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
+++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
@@ -60,8 +60,6 @@ static struct platform_device ixdp425_flash = {
#if defined(CONFIG_MTD_NAND_PLATFORM) || \
defined(CONFIG_MTD_NAND_PLATFORM_MODULE)
-const char *part_probes[] = { cmdlinepart, NULL };
-
static struct mtd_partition ixdp425_partitions[] = {
{
.name = ixp400 NAND FS 0,
@@ -101,7 +99,6 @@ static struct platform_nand_data ixdp425_flash_nand_data
= { .nr_chips = 1,
.chip_delay = 30,
.options= NAND_NO_AUTOINCR,
- .part_probe_types = part_probes,
.partitions = ixdp425_partitions,
.nr_partitions = ARRAY_SIZE(ixdp425_partitions),
},
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c index 80bd43c..62a1e11 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -206,14 +206,11 @@ static int nand_dev_ready(struct mtd_info *mtd)
return gpio_get_value(FSAMPLE_NAND_RB_GPIO_PIN);
}
-static const char *part_probes[] = { cmdlinepart, NULL };
-
static struct platform_nand_data nand_data = {
.chip = {
.nr_chips = 1,
.chip_offset= 0,
.options= NAND_SAMSUNG_LP_OPTIONS,
- .part_probe_types = part_probes,
},
.ctrl = {
.cmd_ctrl = nand_cmd_ctl,
diff --git a/arch/arm/mach-omap1/board-h2.c
b/arch/arm/mach-omap1/board-h2.c index c306862..a914a7d 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -200,8 +200,6 @@ static int h2_nand_dev_ready(struct mtd_info *mtd)
return gpio_get_value(H2_NAND_RB_GPIO_PIN);
}
-static const char *h2_part_probes[] = { cmdlinepart, NULL };
-
static struct platform_nand_data h2_nand_platdata = {
.chip = {
.nr_chips = 1,
@@ -209,7 +207,6 @@ static struct platform_nand_data h2_nand_platdata = {
.nr_partitions = ARRAY_SIZE(h2_nand_partitions),
.partitions = h2_nand_partitions,
.options= NAND_SAMSUNG_LP_OPTIONS,
- .part_probe_types = h2_part_probes,
},
.ctrl = {
[PATCH] RTC: twl6030: correct usage of static register while reading time
From: Konstantin Shlyakhovoy x0155...@ti.com
RTC stores time and date in several registers. Due to the fact that
these registers can't be read instantaneously, there is a chance
that reading from counting registers gives an error of one minute,
one hour, one day, etc.
To address this issue, the RTC has hardware support to copy the
RTC counting registers to static shadowed registers.
The current implementation does not use this feature, and in a
stress test, we can reproduce this error at a rate of around
two times per 30 readings.
Fix the implementation to ensure that the right snapshot of time
is captured.
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: Benoit Cousson b-cous...@ti.com
Cc: linux-omap linux-omap@vger.kernel.org
Acked-by: Mykola Oleksiienko x0174...@ti.com
Acked-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com
Acked-by: Graeme Gregory g...@slimlogic.co.uk
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Konstantin Shlyakhovoy x0155...@ti.com
---
drivers/rtc/rtc-twl.c | 43 ++-
1 files changed, 38 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index 4c2c6df..258abea 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -112,6 +112,7 @@ static const u8 twl6030_rtc_reg_map[] = {
#define BIT_RTC_CTRL_REG_TEST_MODE_M 0x10
#define BIT_RTC_CTRL_REG_SET_32_COUNTER_M0x20
#define BIT_RTC_CTRL_REG_GET_TIME_M 0x40
+#define BIT_RTC_CTRL_REG_RTC_V_OPT 0x80
/* RTC_STATUS_REG bitfields */
#define BIT_RTC_STATUS_REG_RUN_M 0x02
@@ -235,25 +236,57 @@ static int twl_rtc_read_time(struct device *dev, struct
rtc_time *tm)
unsigned char rtc_data[ALL_TIME_REGS + 1];
int ret;
u8 save_control;
+ u8 rtc_control;
ret = twl_rtc_read_u8(save_control, REG_RTC_CTRL_REG);
- if (ret 0)
+ if (ret 0) {
+ dev_err(dev, %s: reading CTRL_REG, error %d\n, __func__, ret);
return ret;
+ }
+ /* for twl6030/32 make sure BIT_RTC_CTRL_REG_GET_TIME_M is clear */
+ if (twl_class_is_6030()) {
+ if (save_control BIT_RTC_CTRL_REG_GET_TIME_M) {
+ save_control = ~BIT_RTC_CTRL_REG_GET_TIME_M;
+ ret = twl_rtc_write_u8(save_control, REG_RTC_CTRL_REG);
+ if (ret 0) {
+ dev_err(dev, %s clr GET_TIME, error %d\n,
+ __func__, ret);
+ return ret;
+ }
+ }
+ }
- save_control |= BIT_RTC_CTRL_REG_GET_TIME_M;
+ /* Copy RTC counting registers to static registers or latches */
+ rtc_control = save_control | BIT_RTC_CTRL_REG_GET_TIME_M;
- ret = twl_rtc_write_u8(save_control, REG_RTC_CTRL_REG);
- if (ret 0)
+ /* for twl6030/32 enable read access to static shadowed registers */
+ if (twl_class_is_6030())
+ rtc_control |= BIT_RTC_CTRL_REG_RTC_V_OPT;
+
+ ret = twl_rtc_write_u8(rtc_control, REG_RTC_CTRL_REG);
+ if (ret 0) {
+ dev_err(dev, %s: writing CTRL_REG, error %d\n, __func__, ret);
return ret;
+ }
ret = twl_i2c_read(TWL_MODULE_RTC, rtc_data,
(rtc_reg_map[REG_SECONDS_REG]), ALL_TIME_REGS);
if (ret 0) {
- dev_err(dev, rtc_read_time error %d\n, ret);
+ dev_err(dev, %s: reading data, error %d\n, __func__, ret);
return ret;
}
+ /* for twl6030 restore original state of rtc control register */
+ if (twl_class_is_6030()) {
+ ret = twl_rtc_write_u8(save_control, REG_RTC_CTRL_REG);
+ if (ret 0) {
+ dev_err(dev, %s: restore CTRL_REG, error %d\n,
+ __func__, ret);
+ return ret;
+ }
+ }
+
tm-tm_sec = bcd2bin(rtc_data[0]);
tm-tm_min = bcd2bin(rtc_data[1]);
tm-tm_hour = bcd2bin(rtc_data[2]);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAPDSS: Provide interface for audio support in DSS
There exist several display technologies and standards that support audio as
well. Hence, it is relevant to update the DSS device driver to provide an audio
interface that may be used by an audio or any other driver interested in the
functionality.
The DSS audio functions are intended to be used as follows:
The audio_enable function is intended to prepare the relevant IP for playback
(e.g., enabling an audio FIFO, taking out of reset some IP, etc).
While the display may support audio, it is possible that for certain
configurations audio is not supported (e.g., an HDMI display using a VESA video
timing). The audio_detect function is intended to query whether the current
configuration of the display supports audio.
The audio_config function is intended to configure all the relevant audio
parameters of the display. In order to make the function independent of any DSS
device driver or IP, it takes an IEC-60958 channel status word struct as well
as a CEA-861 audio infoframe struct. At the moment, this should be enough to
support HDMI and DisplayPort, as both are based on CEA-861 and IEC-60958.
The audio_start function is intended to effectively start/stop audio playback
after the configuration has taken place.
Please note that asound.h is #included only to pass the relevant data
structures to the DSS device driver. The DSS device driver should
not link to any ALSA function as DSS and ALSA are built in separate modules.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
Documentation/arm/OMAP/DSS | 28
include/video/omapdss.h| 12
2 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS
index 888ae7b..b303a5c 100644
--- a/Documentation/arm/OMAP/DSS
+++ b/Documentation/arm/OMAP/DSS
@@ -47,6 +47,34 @@ flexible way to enable non-common multi-display
configuration. In addition to
modelling the hardware overlays, omapdss supports virtual overlays and overlay
managers. These can be used when updating a display with CPU or system DMA.
+omapdss driver support for audio
+
+There exist several display technologies and standards that support audio as
+well. Hence, it is relevant to update the DSS device driver to provide an audio
+interface that may be used by an audio or any other driver interested in the
+functionality.
+
+The audio_enable function is intended to prepare the relevant IP for playback
+(e.g., enabling an audio FIFO, taking out of reset some IP, etc).
+
+While the display may support audio, it is possible that for certain
+configurations audio is not supported (e.g., an HDMI display using a VESA video
+timing). The audio_detect function is intended to query whether the current
+configuration of the display supports audio.
+
+The audio_config function is intended to configure all the relevant audio
+parameters of the display. In order to make the function independent of DSS
+any device driver, it takes a IEC-60958 channel status word as well
+as a CEA-861 audio infoframe. At the moment, this should be enough to support
+HDMI and DisplayPort, as both are based on CEA-861 and IEC-60958.
+
+The audio_start function is intended to effectively start/stop audio playback
+after the configuration has taken place.
+
+Please note that asound.h is #included only to pass the relevant data
+structures to the DSS device driver. The DSS device driver should
+not link to any ALSA function as DSS and ALSA are built in separate modules.
+
Panel and controller drivers
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 483f67c..e35ae96 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -21,6 +21,7 @@
#include linux/list.h
#include linux/kobject.h
#include linux/device.h
+#include sound/asound.h
#define DISPC_IRQ_FRAMEDONE(1 0)
#define DISPC_IRQ_VSYNC(1 1)
@@ -642,6 +643,17 @@ struct omap_dss_driver {
int (*read_edid)(struct omap_dss_device *dssdev, u8 *buf, int len);
bool (*detect)(struct omap_dss_device *dssdev);
+
+ /*
+* For display drivers that support audio. This encompasses
+* HDMI and DisplayPort at the moment.
+*/
+ int (*audio_enable)(struct omap_dss_device *dssdev, bool enable);
+ int (*audio_start)(struct omap_dss_device *dssdev, bool start);
+ bool (*audio_detect)(struct omap_dss_device *dssdev);
+ int (*audio_config)(struct omap_dss_device *dssdev,
+ struct snd_aes_iec958 *iec, struct snd_cea_861_aud_if *aud_if);
+
};
int omap_dss_register_driver(struct omap_dss_driver *);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAPDSS: Provide interface for audio support in DSS
Hi, This patch is proposed as a result of a previous discussion related to include audio support in the DSS device driver (http://www.spinics.net/lists/linux-omap/msg64748.html) As discussed in the description of the patch, this is intended to cover audio implementation based on CEA-861 and IEC-60958, such as HDMI and DisplayPort. This patch #includes definitions from asound.h that are not yet present, I will be sending the patch shortly to alsa-devel. BR, Ricardo Ricardo Neri (1): OMAPDSS: Provide interface for audio support in DSS Documentation/arm/OMAP/DSS | 28 include/video/omapdss.h| 12 2 files changed, 40 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] arm: Use the plat_nand default partition parser
* H Hartley Sweeten hartl...@visionengravers.com [2012-03-28 11:13:09-0700]: Use the default partition parser, cmdlinepart, provided by the plat_nand driver. Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com Cc: Ryan Mallon rmal...@gmail.com Cc: Imre Kaloz ka...@openwrt.org Cc: Krzysztof Halasa k...@pm.waw.pl Cc: Tony Lindgren t...@atomide.com Cc: Alexander Clouter a...@digriz.org.uk Cc: Nicolas Pitre n...@fluxnic.net Cc: Eric Miao eric.y.m...@gmail.com Cc: Haojian Zhuang haojian.zhu...@gmail.com Cc: Marek Vasut marek.va...@gmail.com Acked-by: Alexander Clouter a...@digriz.org.uk Thanks -- Alexander Clouter .sigmonster says: The only rose without thorns is friendship. -- 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 01/10] OMAPDSS: HDMI: Remove ASoC codec
Instead of having an ASoC codec embedded into DSS code, use the generic DSS
device driverinterface for audio support. This allows to any potential user,
including an ASoC driver, take advantage of the HDMI audio functionality.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 236
1 files changed, 0 insertions(+), 236 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 9c12337..27d4fba 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -33,12 +33,6 @@
#include linux/pm_runtime.h
#include linux/clk.h
#include video/omapdss.h
-#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
- defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
-#include sound/soc.h
-#include sound/pcm_params.h
-#include ti_hdmi_4xxx_ip.h
-#endif
#include ti_hdmi.h
#include dss.h
@@ -583,220 +577,6 @@ void omapdss_hdmi_display_disable(struct omap_dss_device
*dssdev)
mutex_unlock(hdmi.lock);
}
-#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
- defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
-
-static int hdmi_audio_trigger(struct snd_pcm_substream *substream, int cmd,
- struct snd_soc_dai *dai)
-{
- struct snd_soc_pcm_runtime *rtd = substream-private_data;
- struct snd_soc_codec *codec = rtd-codec;
- struct platform_device *pdev = to_platform_device(codec-dev);
- struct hdmi_ip_data *ip_data = snd_soc_codec_get_drvdata(codec);
- int err = 0;
-
- if (!(ip_data-ops) !(ip_data-ops-audio_enable)) {
- dev_err(pdev-dev, Cannot enable/disable audio\n);
- return -ENODEV;
- }
-
- switch (cmd) {
- case SNDRV_PCM_TRIGGER_START:
- case SNDRV_PCM_TRIGGER_RESUME:
- case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
- ip_data-ops-audio_enable(ip_data, true);
- break;
- case SNDRV_PCM_TRIGGER_STOP:
- case SNDRV_PCM_TRIGGER_SUSPEND:
- case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
- ip_data-ops-audio_enable(ip_data, false);
- break;
- default:
- err = -EINVAL;
- }
- return err;
-}
-
-static int hdmi_audio_hw_params(struct snd_pcm_substream *substream,
- struct snd_pcm_hw_params *params,
- struct snd_soc_dai *dai)
-{
- struct snd_soc_pcm_runtime *rtd = substream-private_data;
- struct snd_soc_codec *codec = rtd-codec;
- struct hdmi_ip_data *ip_data = snd_soc_codec_get_drvdata(codec);
- struct hdmi_audio_format audio_format;
- struct hdmi_audio_dma audio_dma;
- struct hdmi_core_audio_config core_cfg;
- struct hdmi_core_infoframe_audio aud_if_cfg;
- int err, n, cts;
- enum hdmi_core_audio_sample_freq sample_freq;
-
- switch (params_format(params)) {
- case SNDRV_PCM_FORMAT_S16_LE:
- core_cfg.i2s_cfg.word_max_length =
- HDMI_AUDIO_I2S_MAX_WORD_20BITS;
- core_cfg.i2s_cfg.word_length = HDMI_AUDIO_I2S_CHST_WORD_16_BITS;
- core_cfg.i2s_cfg.in_length_bits =
- HDMI_AUDIO_I2S_INPUT_LENGTH_16;
- core_cfg.i2s_cfg.justification = HDMI_AUDIO_JUSTIFY_LEFT;
- audio_format.samples_per_word = HDMI_AUDIO_ONEWORD_TWOSAMPLES;
- audio_format.sample_size = HDMI_AUDIO_SAMPLE_16BITS;
- audio_format.justification = HDMI_AUDIO_JUSTIFY_LEFT;
- audio_dma.transfer_size = 0x10;
- break;
- case SNDRV_PCM_FORMAT_S24_LE:
- core_cfg.i2s_cfg.word_max_length =
- HDMI_AUDIO_I2S_MAX_WORD_24BITS;
- core_cfg.i2s_cfg.word_length = HDMI_AUDIO_I2S_CHST_WORD_24_BITS;
- core_cfg.i2s_cfg.in_length_bits =
- HDMI_AUDIO_I2S_INPUT_LENGTH_24;
- audio_format.samples_per_word = HDMI_AUDIO_ONEWORD_ONESAMPLE;
- audio_format.sample_size = HDMI_AUDIO_SAMPLE_24BITS;
- audio_format.justification = HDMI_AUDIO_JUSTIFY_RIGHT;
- core_cfg.i2s_cfg.justification = HDMI_AUDIO_JUSTIFY_RIGHT;
- audio_dma.transfer_size = 0x20;
- break;
- default:
- return -EINVAL;
- }
-
- switch (params_rate(params)) {
- case 32000:
- sample_freq = HDMI_AUDIO_FS_32000;
- break;
- case 44100:
- sample_freq = HDMI_AUDIO_FS_44100;
- break;
- case 48000:
- sample_freq = HDMI_AUDIO_FS_48000;
- break;
- default:
- return -EINVAL;
- }
-
- err = hdmi_config_audio_acr(ip_data, params_rate(params), n, cts);
- if (err 0)
- return err;
-
- /* Audio wrapper config */
- audio_format.stereo_channels =
[PATCH 03/10] OMAPDSS: HDMI: OMAP4: Correcty typo in I2S definitions
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index d6b49b6..9fa5cb1 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -350,7 +350,7 @@ enum hdmi_audio_blk_strt_end_sig {
enum hdmi_audio_i2s_config {
HDMI_AUDIO_I2S_WS_POLARITY_LOW_IS_LEFT = 0,
- HDMI_AUDIO_I2S_WS_POLARIT_YLOW_IS_RIGHT = 1,
+ HDMI_AUDIO_I2S_WS_POLARITY_LOW_IS_RIGHT = 1,
HDMI_AUDIO_I2S_MSB_SHIFTED_FIRST = 0,
HDMI_AUDIO_I2S_LSB_SHIFTED_FIRST = 1,
HDMI_AUDIO_I2S_MAX_WORD_20BITS = 0,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/10] OMAPDSS: HDMI: OMAP4: Remove CEA-861 audio infoframe and IEC-60958 enums
In order to avoid duplication of definitions. Use the definitions provided
by asoundef.h. Furthermore, as CEA-861 and IEC-60958 are used by both
DisplayPort and HDMI, this helps to make the code more generic.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 15 +++---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 80 ++---
2 files changed, 12 insertions(+), 83 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 4740e64..4ab3b19 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -29,7 +29,6 @@
#include linux/string.h
#include linux/seq_file.h
#include linux/gpio.h
-
#include ti_hdmi_4xxx_ip.h
#include dss.h
@@ -1156,7 +1155,7 @@ void hdmi_core_audio_config(struct hdmi_ip_data *ip_data,
}
void hdmi_core_audio_infoframe_config(struct hdmi_ip_data *ip_data,
- struct hdmi_core_infoframe_audio *info_aud)
+ struct snd_cea_861_aud_if *info_aud)
{
u8 val;
u8 sum = 0, checksum = 0;
@@ -1172,22 +1171,24 @@ void hdmi_core_audio_infoframe_config(struct
hdmi_ip_data *ip_data,
hdmi_write_reg(av_base, HDMI_CORE_AV_AUDIO_LEN, 0x0a);
sum += 0x84 + 0x001 + 0x00a;
- val = (info_aud-db1_coding_type 4)
- | (info_aud-db1_channel_count - 1);
+ val = (info_aud-coding_type CEA861_AUDIO_INFOFRAME_DB1CT_SHIFT)
+ | (info_aud-channel_count - 1);
hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(0), val);
sum += val;
- val = (info_aud-db2_sample_freq 2) | info_aud-db2_sample_size;
+ val = (info_aud-sample_freq CEA861_AUDIO_INFOFRAME_DB2SF_SHIFT)
+ | (info_aud-sample_size);
hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(1), val);
sum += val;
hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(2), 0x00);
- val = info_aud-db4_channel_alloc;
+ val = info_aud-channel_alloc;
hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(3), val);
sum += val;
- val = (info_aud-db5_downmix_inh 7) | (info_aud-db5_lsv 3);
+ val = (info_aud-st_downmix CEA861_AUDIO_INFOFRAME_DB5_DM_INH_SHIFT)
+ | (info_aud-lsv CEA861_AUDIO_INFOFRAME_DB5_LSV_SHIFT);
hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(4), val);
sum += val;
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index a442998..d6b49b6 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -28,6 +28,8 @@
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
#include sound/soc.h
#include sound/pcm_params.h
+#include sound/asound.h
+#include sound/asoundef.h
#endif
/* HDMI Wrapper */
@@ -284,35 +286,6 @@ enum hdmi_core_infoframe {
HDMI_INFOFRAME_AVI_DB5PR_8 = 7,
HDMI_INFOFRAME_AVI_DB5PR_9 = 8,
HDMI_INFOFRAME_AVI_DB5PR_10 = 9,
- HDMI_INFOFRAME_AUDIO_DB1CT_FROM_STREAM = 0,
- HDMI_INFOFRAME_AUDIO_DB1CT_IEC60958 = 1,
- HDMI_INFOFRAME_AUDIO_DB1CT_AC3 = 2,
- HDMI_INFOFRAME_AUDIO_DB1CT_MPEG1 = 3,
- HDMI_INFOFRAME_AUDIO_DB1CT_MP3 = 4,
- HDMI_INFOFRAME_AUDIO_DB1CT_MPEG2_MULTICH = 5,
- HDMI_INFOFRAME_AUDIO_DB1CT_AAC = 6,
- HDMI_INFOFRAME_AUDIO_DB1CT_DTS = 7,
- HDMI_INFOFRAME_AUDIO_DB1CT_ATRAC = 8,
- HDMI_INFOFRAME_AUDIO_DB1CT_ONEBIT = 9,
- HDMI_INFOFRAME_AUDIO_DB1CT_DOLBY_DIGITAL_PLUS = 10,
- HDMI_INFOFRAME_AUDIO_DB1CT_DTS_HD = 11,
- HDMI_INFOFRAME_AUDIO_DB1CT_MAT = 12,
- HDMI_INFOFRAME_AUDIO_DB1CT_DST = 13,
- HDMI_INFOFRAME_AUDIO_DB1CT_WMA_PRO = 14,
- HDMI_INFOFRAME_AUDIO_DB2SF_FROM_STREAM = 0,
- HDMI_INFOFRAME_AUDIO_DB2SF_32000 = 1,
- HDMI_INFOFRAME_AUDIO_DB2SF_44100 = 2,
- HDMI_INFOFRAME_AUDIO_DB2SF_48000 = 3,
- HDMI_INFOFRAME_AUDIO_DB2SF_88200 = 4,
- HDMI_INFOFRAME_AUDIO_DB2SF_96000 = 5,
- HDMI_INFOFRAME_AUDIO_DB2SF_176400 = 6,
- HDMI_INFOFRAME_AUDIO_DB2SF_192000 = 7,
- HDMI_INFOFRAME_AUDIO_DB2SS_FROM_STREAM = 0,
- HDMI_INFOFRAME_AUDIO_DB2SS_16BIT = 1,
- HDMI_INFOFRAME_AUDIO_DB2SS_20BIT = 2,
- HDMI_INFOFRAME_AUDIO_DB2SS_24BIT = 3,
- HDMI_INFOFRAME_AUDIO_DB5_DM_INH_PERMITTED = 0,
- HDMI_INFOFRAME_AUDIO_DB5_DM_INH_PROHIBITED = 1
};
enum hdmi_packing_mode {
@@ -322,17 +295,6 @@ enum hdmi_packing_mode {
HDMI_PACK_ALREADYPACKED = 7
};
-enum hdmi_core_audio_sample_freq {
- HDMI_AUDIO_FS_32000 = 0x3,
- HDMI_AUDIO_FS_44100 = 0x0,
- HDMI_AUDIO_FS_48000 = 0x2,
- HDMI_AUDIO_FS_88200 = 0x8,
- HDMI_AUDIO_FS_96000 = 0xA,
- HDMI_AUDIO_FS_176400 = 0xC,
- HDMI_AUDIO_FS_192000 = 0xE,
- HDMI_AUDIO_FS_NOT_INDICATED = 0x1
-};
-
enum hdmi_core_audio_layout {
HDMI_AUDIO_LAYOUT_2CH = 0,
[PATCH 06/10] OMAPDSS: HDMI: OMAP4: Expand configuration for IEC-60958 audio
Provide more configuration parameters for the IEC-60958 channel status word.
For this, a new structure containing the relevant parameters is created. Some
of the parameters previously located in the I2S structure are moved
to the new IEC-60958 struct to improve the logical organization of the code.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 39 +---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 23 ++---
2 files changed, 48 insertions(+), 14 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index e06139a..da2806c 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -1119,12 +1119,37 @@ void hdmi_core_audio_config(struct hdmi_ip_data
*ip_data,
REG_FLD_MOD(av_base, HDMI_CORE_AV_SPDIF_CTRL,
cfg-fs_override, 1, 1);
- /* I2S parameters */
- REG_FLD_MOD(av_base, HDMI_CORE_AV_I2S_CHST4,
- cfg-freq_sample, 3, 0);
+ /* I2S and IEC60958 parameters */
+
+ r = hdmi_read_reg(av_base, HDMI_CORE_AV_I2S_CHST0);
+ r = FLD_MOD(r, cfg-iec60958_cfg.professional, 0, 0);
+ r = FLD_MOD(r, cfg-iec60958_cfg.for_lpcm_aud, 1, 1);
+ r = FLD_MOD(r, cfg-iec60958_cfg.copyright, 2, 2);
+ r = FLD_MOD(r, cfg-iec60958_cfg.emphasis, 5, 3);
+ r = FLD_MOD(r, cfg-iec60958_cfg.mode, 7, 6);
+ hdmi_write_reg(av_base, HDMI_CORE_AV_I2S_CHST0, r);
+
+ hdmi_write_reg(av_base, HDMI_CORE_AV_I2S_CHST1,
+ cfg-iec60958_cfg.category);
+
+ r = hdmi_read_reg(av_base, HDMI_CORE_AV_I2S_CHST2);
+ r = FLD_MOD(r, cfg-iec60958_cfg.source_nr, 3, 0);
+ r = FLD_MOD(r, cfg-iec60958_cfg.channel_nr, 7, 4);
+ hdmi_write_reg(av_base, HDMI_CORE_AV_I2S_CHST2, r);
+
+ r = hdmi_read_reg(av_base, HDMI_CORE_AV_I2S_CHST4);
+ r = FLD_MOD(r, cfg-iec60958_cfg.freq_sample, 3, 0);
+ r = FLD_MOD(r, cfg-iec60958_cfg.clock_accuracy, 7, 4);
+ hdmi_write_reg(av_base, HDMI_CORE_AV_I2S_CHST4, r);
+
+ r = hdmi_read_reg(av_base, HDMI_CORE_AV_I2S_CHST5);
+ r = FLD_MOD(r, cfg-iec60958_cfg.freq_sample, 7, 4);
+ r = FLD_MOD(r, cfg-iec60958_cfg.word_length, 3, 1);
+ r = FLD_MOD(r, cfg-iec60958_cfg.word_max_length, 0, 0);
+ hdmi_write_reg(av_base, HDMI_CORE_AV_I2S_CHST5, r);
r = hdmi_read_reg(av_base, HDMI_CORE_AV_I2S_IN_CTRL);
- r = FLD_MOD(r, cfg-i2s_cfg.en_high_bitrate_aud, 7, 7);
+ r = FLD_MOD(r, cfg-en_high_bitrate_aud, 7, 7);
r = FLD_MOD(r, cfg-i2s_cfg.sck_edge_mode, 6, 6);
r = FLD_MOD(r, cfg-i2s_cfg.cbit_order, 5, 5);
r = FLD_MOD(r, cfg-i2s_cfg.vbit, 4, 4);
@@ -1134,12 +1159,6 @@ void hdmi_core_audio_config(struct hdmi_ip_data *ip_data,
r = FLD_MOD(r, cfg-i2s_cfg.shift, 0, 0);
hdmi_write_reg(av_base, HDMI_CORE_AV_I2S_IN_CTRL, r);
- r = hdmi_read_reg(av_base, HDMI_CORE_AV_I2S_CHST5);
- r = FLD_MOD(r, cfg-freq_sample, 7, 4);
- r = FLD_MOD(r, cfg-i2s_cfg.word_length, 3, 1);
- r = FLD_MOD(r, cfg-i2s_cfg.word_max_length, 0, 0);
- hdmi_write_reg(av_base, HDMI_CORE_AV_I2S_CHST5, r);
-
REG_FLD_MOD(av_base, HDMI_CORE_AV_I2S_IN_LEN,
cfg-i2s_cfg.in_length_bits, 3, 0);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index 222cc16..4359001 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -469,11 +469,8 @@ struct hdmi_audio_dma {
};
struct hdmi_core_audio_i2s_config {
- u8 word_max_length;
- u8 word_length;
u8 in_length_bits;
u8 justification;
- u8 en_high_bitrate_aud;
u8 sck_edge_mode;
u8 cbit_order;
u8 vbit;
@@ -483,9 +480,26 @@ struct hdmi_core_audio_i2s_config {
u8 active_sds;
};
+/* TODO: Consider if having this is better than parsing the audio word
+ * directly from the status word */
+struct hdmi_core_audio_iec60958_config {
+ bool professional;
+ bool for_lpcm_aud;
+ bool copyright;
+ u8 emphasis;
+ u8 mode;
+ u8 category;
+ u8 source_nr;
+ u8 channel_nr;
+ u8 freq_sample;
+ u8 clock_accuracy;
+ u8 word_max_length;
+ u8 word_length;
+};
+
struct hdmi_core_audio_config {
struct hdmi_core_audio_i2s_config i2s_cfg;
- u32 freq_sample;
+ struct hdmi_core_audio_iec60958_config iec60958_cfg;
boolfs_override;
u32 n;
u32 cts;
@@ -498,6 +512,7 @@ struct hdmi_core_audio_config {
boolen_dsd_audio;
bool
[PATCH 00/10] OMAPDSS: HDMI: Prepare for OMAP5 and DSS dev driver audio support
Hi, This set of patches is inteded to prepare the HDMI driver to implement the DSS device driver interface for audio proposed here: http://www.spinics.net/lists/linux-omap/msg67303.html In preparation for that, it removes the current ASoC HDMI codec driver and decouples HDMI audio build configuration from ASoC. Instead, a config option may be selected by the parties interested in the HDMI audio functionality. The last patch effectively implements the DSS audio interface. Also, this set prepares the HDMI driver for the introduction of the OMAP5 HDMI audio functionality by further abstracting the portions of code that are generic to all HDMI implementations (e.g, N/CTS params calculation). Also, an IP-dependent audio configuration function is introduced as an HDMI IP operation; this function takes IP-independent parameters and is intended to be implemented for each individual IP. For the specific case of OMAP4, the configuration of the IEC-60958 channel status word is expanded to provide more flexibility. Also, some duplicated IEC-60958 definitions are removed to, instead, reuse the definitions provided in asound.h The CEA-861 definitions are not yet added to asound.h. I will send a patch for that to alsa-devel. The changes for OMAP4 configuration expand the current support to cover more audio sample rates: 32, 44.1, 48, 88.2, 176.4 and 192 kHz. Audio sample world length of 16 through 24 bits as well as up to 8 audio channels. These changes are based on the 3.3 Linux kernel plus the patches for the audio MCLK selection (http://www.spinics.net/lists/linux-omap/msg64302.html). Validation was performed using Onkyo TX-SR508 and Yamaha RX-V367 AV receivers. BR, Ricardo Ricardo Neri (10): OMAPDSS: HDMI: Remove ASoC codec OMAPDSS: HDMI: OMAP4: Remove CEA-861 audio infoframe and IEC-60958 enums OMAPDSS: HDMI: OMAP4: Correcty typo in I2S definitions OMAPDSS: HDMI: OMAP4: Decouple wrapper enable and audio start OMAPDSS: HDMI: Decouple HDMI audio from ASoC OMAPDSS: HDMI: OMAP4: Expand configuration for IEC-60958 audio OMAPDSS: HDMI: Relocate N/CTS calculation OMAPDSS: HDMI: Add support for more audio sample rates in N/CTS calculation OMAPDSS: HDMI: OMAP4: Add an audio configuration function OMAPDSS: HDMI: Implement DSS driver interface for audio drivers/video/omap2/dss/Kconfig |4 + drivers/video/omap2/dss/dss.h |7 + drivers/video/omap2/dss/dss_features.c|5 +- drivers/video/omap2/dss/hdmi.c| 339 ++--- drivers/video/omap2/dss/hdmi_panel.c | 76 +++ drivers/video/omap2/dss/ti_hdmi.h | 17 +- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 304 +- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 116 ++ 8 files changed, 488 insertions(+), 380 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/10] OMAPDSS: HDMI: Decouple HDMI audio from ASoC
Instead of having OMAPDSS HDMI audio functionality depending on the
ASoC HDMI audio driver, use a new config option so that
potential users, including ASoC, may select if needed.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
drivers/video/omap2/dss/Kconfig |4
drivers/video/omap2/dss/dss_features.c|3 +--
drivers/video/omap2/dss/ti_hdmi.h |6 ++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |3 +--
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |5 +
5 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index 7be7c06..b492001 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -68,6 +68,10 @@ config OMAP4_DSS_HDMI
HDMI Interface. This adds the High Definition Multimedia Interface.
See http://www.hdmi.org/ for HDMI specification.
+config OMAP4_DSS_HDMI_AUDIO
+ bool
+ depends on OMAP4_DSS_HDMI
+
config OMAP2_DSS_SDI
bool SDI support
depends on ARCH_OMAP3
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index c1839e2..399a28a 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -497,8 +497,7 @@ static const struct ti_hdmi_ip_ops omap4_hdmi_functions = {
.dump_core = ti_hdmi_4xxx_core_dump,
.dump_pll = ti_hdmi_4xxx_pll_dump,
.dump_phy = ti_hdmi_4xxx_phy_dump,
-#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
- defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
.audio_enable = ti_hdmi_4xxx_wp_audio_enable,
.audio_start= ti_hdmi_4xxx_audio_start,
#endif
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index 529e227..211da6f 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -110,8 +110,7 @@ struct ti_hdmi_ip_ops {
void (*dump_phy)(struct hdmi_ip_data *ip_data, struct seq_file *s);
-#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
- defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
void (*audio_enable)(struct hdmi_ip_data *ip_data, bool start);
void (*audio_start)(struct hdmi_ip_data *ip_data, bool start);
@@ -145,8 +144,7 @@ void ti_hdmi_4xxx_wp_dump(struct hdmi_ip_data *ip_data,
struct seq_file *s);
void ti_hdmi_4xxx_pll_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
-#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
- defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
void ti_hdmi_4xxx_wp_audio_enable(struct hdmi_ip_data *ip_data, bool enable);
void ti_hdmi_4xxx_audio_start(struct hdmi_ip_data *ip_data, bool enable);
#endif
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index e6fa61d..e06139a 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -1030,8 +1030,7 @@ void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data,
struct seq_file *s)
DUMPPHY(HDMI_TXPHY_PAD_CFG_CTRL);
}
-#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
- defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
void hdmi_wp_audio_config_format(struct hdmi_ip_data *ip_data,
struct hdmi_audio_format *aud_fmt)
{
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index 9fa5cb1..222cc16 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -26,8 +26,6 @@
#include ti_hdmi.h
#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
-#include sound/soc.h
-#include sound/pcm_params.h
#include sound/asound.h
#include sound/asoundef.h
#endif
@@ -502,8 +500,7 @@ struct hdmi_core_audio_config {
boolen_spdif;
};
-#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
- defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
int hdmi_config_audio_acr(struct hdmi_ip_data *ip_data,
u32 sample_freq, u32 *n, u32 *cts);
void hdmi_core_audio_infoframe_config(struct hdmi_ip_data *ip_data,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/10] OMAPDSS: HDMI: Implement DSS driver interface for audio
Implement the DSS device driver audio support interface in the HDMI
panel driver and generic driver. The implementation relies on the
IP-specific functions that are defined at DSS probe time.
A HW-safe spinlock is used to protect the audio functions. This is because
the audio functions may be called while holding a lock; in such case,
the panel's driver mutex is not suitable. Functions should be used
to set registers and should not wait for any other event.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
drivers/video/omap2/dss/dss.h|7 +++
drivers/video/omap2/dss/hdmi.c | 33 +++
drivers/video/omap2/dss/hdmi_panel.c | 76 ++
3 files changed, 116 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 32ff69f..fca4490 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -520,6 +520,13 @@ int omapdss_hdmi_read_edid(u8 *buf, int len);
bool omapdss_hdmi_detect(void);
int hdmi_panel_init(void);
void hdmi_panel_exit(void);
+#ifdef CONFIG_OMAP4_DSS_HDMI_AUDIO
+int hdmi_audio_enable(bool enable);
+int hdmi_audio_start(bool start);
+bool hdmi_mode_has_audio(void);
+int hdmi_audio_config(struct snd_aes_iec958 *iec,
+ struct snd_cea_861_aud_if *aud_if);
+#endif
/* RFBI */
#ifdef CONFIG_OMAP2_DSS_RFBI
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index bd44891..880509d 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -698,6 +698,39 @@ int hdmi_compute_acr(u32 sample_freq, u32 *n, u32 *cts)
return 0;
}
+
+int hdmi_audio_enable(bool enable)
+{
+ DSSDBG(audio_enable\n);
+
+ hdmi.ip_data.ops-audio_enable(hdmi.ip_data, enable);
+
+ return 0;
+}
+
+int hdmi_audio_start(bool start)
+{
+ DSSDBG(audio_enable\n);
+
+ hdmi.ip_data.ops-audio_start(hdmi.ip_data, start);
+
+ return 0;
+}
+
+bool hdmi_mode_has_audio(void)
+{
+ if (hdmi.ip_data.cfg.cm.mode == HDMI_HDMI)
+ return true;
+ else
+ return false;
+}
+
+int hdmi_audio_config(struct snd_aes_iec958 *iec,
+ struct snd_cea_861_aud_if *aud_if)
+{
+ return hdmi.ip_data.ops-audio_config(hdmi.ip_data, iec, aud_if);
+}
+
#endif
/* HDMI HW IP initialisation */
diff --git a/drivers/video/omap2/dss/hdmi_panel.c
b/drivers/video/omap2/dss/hdmi_panel.c
index 533d5dc..dac1ac2 100644
--- a/drivers/video/omap2/dss/hdmi_panel.c
+++ b/drivers/video/omap2/dss/hdmi_panel.c
@@ -31,6 +31,10 @@
static struct {
struct mutex hdmi_lock;
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+ /* protects calls to HDMI driver audio functionality */
+ spinlock_t hdmi_sp_lock;
+#endif
} hdmi;
@@ -222,6 +226,68 @@ err:
return r;
}
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+static int hdmi_panel_audio_enable(struct omap_dss_device *dssdev, bool enable)
+{
+ unsigned long flags;
+ int r;
+
+ spin_lock_irqsave(hdmi.hdmi_sp_lock, flags);
+
+ r = hdmi_audio_enable(enable);
+
+ spin_unlock_irqrestore(hdmi.hdmi_sp_lock, flags);
+ return r;
+}
+
+static int hdmi_panel_audio_start(struct omap_dss_device *dssdev, bool start)
+{
+ unsigned long flags;
+ int r;
+
+ spin_lock_irqsave(hdmi.hdmi_sp_lock, flags);
+
+ r = hdmi_audio_start(start);
+
+ spin_unlock_irqrestore(hdmi.hdmi_sp_lock, flags);
+ return r;
+}
+
+static bool hdmi_panel_audio_detect(struct omap_dss_device *dssdev)
+{
+ unsigned long flags;
+ bool r = false;
+
+ spin_lock_irqsave(hdmi.hdmi_sp_lock, flags);
+
+ if (dssdev-state != OMAP_DSS_DISPLAY_ACTIVE)
+ goto err;
+
+ if (!hdmi_mode_has_audio())
+ goto err;
+
+ r = true;
+err:
+ spin_unlock_irqrestore(hdmi.hdmi_sp_lock, flags);
+ return r;
+}
+
+static int hdmi_panel_audio_config(struct omap_dss_device *dssdev,
+ struct snd_aes_iec958 *iec, struct snd_cea_861_aud_if *aud_if)
+{
+ unsigned long flags;
+ int r;
+
+ spin_lock_irqsave(hdmi.hdmi_sp_lock, flags);
+
+ r = hdmi_audio_config(iec, aud_if);
+
+ spin_unlock_irqrestore(hdmi.hdmi_sp_lock, flags);
+ return r;
+}
+
+#endif
+
static struct omap_dss_driver hdmi_driver = {
.probe = hdmi_panel_probe,
.remove = hdmi_panel_remove,
@@ -234,6 +300,12 @@ static struct omap_dss_driver hdmi_driver = {
.check_timings = hdmi_check_timings,
.read_edid = hdmi_read_edid,
.detect = hdmi_detect,
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+ .audio_enable = hdmi_panel_audio_enable,
+ .audio_start= hdmi_panel_audio_start,
+ .audio_detect = hdmi_panel_audio_detect,
+ .audio_config = hdmi_panel_audio_config,
+#endif
.driver = {
.name = hdmi_panel,
[PATCH 09/10] OMAPDSS: HDMI: OMAP4: Add an audio configuration function
The generic HDMI driver does not need to know about the specific
settings of a given IP. Hence, it just passes the audio configuration
and the IP library parses such configuration and sets the IP
accordingly. This patch introduces an IP-specific audio configuration
function. Also the DMA, format and core config functions are no longer
exposed to the generic HDMI driver as they are IP-specific.
The audio configuration functions caters for 16-bit through 24-bit
audio samples with sample rates from 32kHz and up to 192kHz as well
as up to 8 audio channels.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
drivers/video/omap2/dss/dss_features.c|1 +
drivers/video/omap2/dss/ti_hdmi.h |7 +
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 226 -
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 10 --
4 files changed, 230 insertions(+), 14 deletions(-)
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index 399a28a..9ed112a 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -500,6 +500,7 @@ static const struct ti_hdmi_ip_ops omap4_hdmi_functions = {
#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
.audio_enable = ti_hdmi_4xxx_wp_audio_enable,
.audio_start= ti_hdmi_4xxx_audio_start,
+ .audio_config = ti_hdmi_4xxx_audio_config,
#endif
};
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index db22a02..9864484 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -22,6 +22,8 @@
#define _TI_HDMI_H
struct hdmi_ip_data;
+struct snd_aes_iec958;
+struct snd_cea_861_aud_if;
enum hdmi_pll_pwr {
HDMI_PLLPWRCMD_ALLOFF = 0,
@@ -114,6 +116,9 @@ struct ti_hdmi_ip_ops {
void (*audio_enable)(struct hdmi_ip_data *ip_data, bool start);
void (*audio_start)(struct hdmi_ip_data *ip_data, bool start);
+
+ int (*audio_config)(struct hdmi_ip_data *ip_data,
+ struct snd_aes_iec958 *iec, struct snd_cea_861_aud_if *aud_if);
#endif
};
@@ -148,5 +153,7 @@ void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data,
struct seq_file *s);
int hdmi_compute_acr(u32 sample_freq, u32 *n, u32 *cts);
void ti_hdmi_4xxx_wp_audio_enable(struct hdmi_ip_data *ip_data, bool enable);
void ti_hdmi_4xxx_audio_start(struct hdmi_ip_data *ip_data, bool enable);
+int ti_hdmi_4xxx_audio_config(struct hdmi_ip_data *ip_data,
+ struct snd_aes_iec958 *iec, struct snd_cea_861_aud_if *aud_if);
#endif
#endif
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index d587b20..ef96524 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -31,6 +31,7 @@
#include linux/gpio.h
#include ti_hdmi_4xxx_ip.h
#include dss.h
+#include dss_features.h
static inline void hdmi_write_reg(void __iomem *base_addr,
const u16 idx, u32 val)
@@ -1031,7 +1032,7 @@ void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data,
struct seq_file *s)
}
#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
-void hdmi_wp_audio_config_format(struct hdmi_ip_data *ip_data,
+static void ti_hdmi_4xxx_wp_audio_config_format(struct hdmi_ip_data *ip_data,
struct hdmi_audio_format *aud_fmt)
{
u32 r;
@@ -1050,7 +1051,7 @@ void hdmi_wp_audio_config_format(struct hdmi_ip_data
*ip_data,
hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_AUDIO_CFG, r);
}
-void hdmi_wp_audio_config_dma(struct hdmi_ip_data *ip_data,
+static void ti_hdmi_4xxx_wp_audio_config_dma(struct hdmi_ip_data *ip_data,
struct hdmi_audio_dma *aud_dma)
{
u32 r;
@@ -1068,7 +1069,7 @@ void hdmi_wp_audio_config_dma(struct hdmi_ip_data
*ip_data,
hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_AUDIO_CTRL, r);
}
-void hdmi_core_audio_config(struct hdmi_ip_data *ip_data,
+static void ti_hdmi_4xxx_core_audio_config(struct hdmi_ip_data *ip_data,
struct hdmi_core_audio_config *cfg)
{
u32 r;
@@ -1172,7 +1173,7 @@ void hdmi_core_audio_config(struct hdmi_ip_data *ip_data,
hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_MODE, r);
}
-void hdmi_core_audio_infoframe_config(struct hdmi_ip_data *ip_data,
+static void ti_hdmi_4xxx_core_audio_infoframe_cfg(struct hdmi_ip_data *ip_data,
struct snd_cea_861_aud_if *info_aud)
{
u8 val;
@@ -1226,6 +1227,223 @@ void hdmi_core_audio_infoframe_config(struct
hdmi_ip_data *ip_data,
*/
}
+int ti_hdmi_4xxx_audio_config(struct hdmi_ip_data *ip_data,
+ struct snd_aes_iec958 *iec, struct snd_cea_861_aud_if *aud_if)
+{
+ struct hdmi_audio_format audio_format;
+ struct hdmi_audio_dma audio_dma;
+ struct hdmi_core_audio_config core;
+
[PATCH 08/10] OMAPDSS: HDMI: Add support for more audio sample rates in N/CTS calculation
Add support for more sample rates when calculating N and CTS. This
covers all the audio sample rates that an HDMI source is allowed
to transmit according to the HDMI 1.4a specification.
Also, reorganize the logic for the calculation when using deep color.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 88 +--
1 files changed, 74 insertions(+), 14 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 7fcc22f..bd44891 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -602,6 +602,7 @@ static void hdmi_put_clocks(void)
int hdmi_compute_acr(u32 sample_freq, u32 *n, u32 *cts)
{
u32 deep_color;
+ bool deep_color_correct = false;
u32 pclk = hdmi.ip_data.cfg.timings.timings.pixel_clock;
if (n == NULL || cts == NULL)
@@ -610,29 +611,88 @@ int hdmi_compute_acr(u32 sample_freq, u32 *n, u32 *cts)
/* TODO: When implemented, query deep color mode here. */
deep_color = 100;
+ /*
+* When using deep color, the default N value (as in the HDMI
+* specification) yields to an non-integer CTS. Hence, we
+* modify it while keeping the restrictions described in
+* section 7.2.1 of the HDMI 1.4a specification.
+*/
switch (sample_freq) {
case 32000:
- if ((deep_color == 125) ((pclk == 54054)
- || (pclk == 74250)))
- *n = 8192;
- else
- *n = 4096;
+ case 48000:
+ case 96000:
+ case 192000:
+ if (deep_color == 125)
+ if (pclk == 27027 || pclk == 74250)
+ deep_color_correct = true;
+ if (deep_color == 150)
+ if (pclk == 27027)
+ deep_color_correct = true;
break;
case 44100:
- *n = 6272;
- break;
- case 48000:
- if ((deep_color == 125) ((pclk == 54054)
- || (pclk == 74250)))
- *n = 8192;
- else
- *n = 6144;
+ case 88200:
+ case 176400:
+ if (deep_color == 125)
+ if (pclk == 27027)
+ deep_color_correct = true;
break;
default:
- *n = 0;
return -EINVAL;
}
+ if (deep_color_correct) {
+ switch (sample_freq) {
+ case 32000:
+ *n = 8192;
+ break;
+ case 44100:
+ *n = 12544;
+ break;
+ case 48000:
+ *n = 8192;
+ break;
+ case 88200:
+ *n = 25088;
+ break;
+ case 96000:
+ *n = 16384;
+ break;
+ case 176400:
+ *n = 50176;
+ break;
+ case 192000:
+ *n = 32768;
+ break;
+ default:
+ return -EINVAL;
+ }
+ } else {
+ switch (sample_freq) {
+ case 32000:
+ *n = 4096;
+ break;
+ case 44100:
+ *n = 6272;
+ break;
+ case 48000:
+ *n = 6144;
+ break;
+ case 88200:
+ *n = 12544;
+ break;
+ case 96000:
+ *n = 12288;
+ break;
+ case 176400:
+ *n = 25088;
+ break;
+ case 192000:
+ *n = 24576;
+ break;
+ default:
+ return -EINVAL;
+ }
+ }
/* Calculate CTS. See HDMI 1.3a or 1.4a specifications */
*cts = pclk * (*n / 128) * deep_color / (sample_freq / 10);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/10] OMAPDSS: HDMI: Relocate N/CTS calculation
The N and CTS parameters are relevant to all HDMI implmentations and
not specific to a given IP. Hence, the calculation is relocated
into the generic HDMI driver.
Also, deep color is not queried but it is still considered in the
calculation of N. This is to be changed when deep color functionality is
implemented in the driver.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
drivers/video/omap2/dss/hdmi.c| 42 +
drivers/video/omap2/dss/ti_hdmi.h |1 +
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 57 -
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |2 -
4 files changed, 43 insertions(+), 59 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 27d4fba..7fcc22f 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -598,6 +598,48 @@ static void hdmi_put_clocks(void)
clk_put(hdmi.sys_clk);
}
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+int hdmi_compute_acr(u32 sample_freq, u32 *n, u32 *cts)
+{
+ u32 deep_color;
+ u32 pclk = hdmi.ip_data.cfg.timings.timings.pixel_clock;
+
+ if (n == NULL || cts == NULL)
+ return -EINVAL;
+
+ /* TODO: When implemented, query deep color mode here. */
+ deep_color = 100;
+
+ switch (sample_freq) {
+ case 32000:
+ if ((deep_color == 125) ((pclk == 54054)
+ || (pclk == 74250)))
+ *n = 8192;
+ else
+ *n = 4096;
+ break;
+ case 44100:
+ *n = 6272;
+ break;
+ case 48000:
+ if ((deep_color == 125) ((pclk == 54054)
+ || (pclk == 74250)))
+ *n = 8192;
+ else
+ *n = 6144;
+ break;
+ default:
+ *n = 0;
+ return -EINVAL;
+ }
+
+ /* Calculate CTS. See HDMI 1.3a or 1.4a specifications */
+ *cts = pclk * (*n / 128) * deep_color / (sample_freq / 10);
+
+ return 0;
+}
+#endif
+
/* HDMI HW IP initialisation */
static int omapdss_hdmihw_probe(struct platform_device *pdev)
{
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index 211da6f..db22a02 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -145,6 +145,7 @@ void ti_hdmi_4xxx_pll_dump(struct hdmi_ip_data *ip_data,
struct seq_file *s);
void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+int hdmi_compute_acr(u32 sample_freq, u32 *n, u32 *cts);
void ti_hdmi_4xxx_wp_audio_enable(struct hdmi_ip_data *ip_data, bool enable);
void ti_hdmi_4xxx_audio_start(struct hdmi_ip_data *ip_data, bool enable);
#endif
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index da2806c..d587b20 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -1226,63 +1226,6 @@ void hdmi_core_audio_infoframe_config(struct
hdmi_ip_data *ip_data,
*/
}
-int hdmi_config_audio_acr(struct hdmi_ip_data *ip_data,
- u32 sample_freq, u32 *n, u32 *cts)
-{
- u32 r;
- u32 deep_color = 0;
- u32 pclk = ip_data-cfg.timings.timings.pixel_clock;
-
- if (n == NULL || cts == NULL)
- return -EINVAL;
- /*
-* Obtain current deep color configuration. This needed
-* to calculate the TMDS clock based on the pixel clock.
-*/
- r = REG_GET(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG, 1, 0);
- switch (r) {
- case 1: /* No deep color selected */
- deep_color = 100;
- break;
- case 2: /* 10-bit deep color selected */
- deep_color = 125;
- break;
- case 3: /* 12-bit deep color selected */
- deep_color = 150;
- break;
- default:
- return -EINVAL;
- }
-
- switch (sample_freq) {
- case 32000:
- if ((deep_color == 125) ((pclk == 54054)
- || (pclk == 74250)))
- *n = 8192;
- else
- *n = 4096;
- break;
- case 44100:
- *n = 6272;
- break;
- case 48000:
- if ((deep_color == 125) ((pclk == 54054)
- || (pclk == 74250)))
- *n = 8192;
- else
- *n = 6144;
- break;
- default:
- *n = 0;
- return -EINVAL;
- }
-
- /* Calculate CTS. See HDMI 1.3a or 1.4a specifications */
- *cts =
[PATCH 04/10] OMAPDSS: HDMI: OMAP4: Decouple wrapper enable and audio start
Decouple the enablement of the HDMI audio wrapper from audio start.
Otherwise, an audio FIFO underflow may occur. The audio wrapper
enablement must be done after configuration and before audio playback
is started.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
drivers/video/omap2/dss/dss_features.c|1 +
drivers/video/omap2/dss/ti_hdmi.h |3 +++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |8 ++--
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index 162c9a9..c1839e2 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -500,6 +500,7 @@ static const struct ti_hdmi_ip_ops omap4_hdmi_functions = {
#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
.audio_enable = ti_hdmi_4xxx_wp_audio_enable,
+ .audio_start= ti_hdmi_4xxx_audio_start,
#endif
};
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index 50dadba..529e227 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -113,6 +113,8 @@ struct ti_hdmi_ip_ops {
#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
void (*audio_enable)(struct hdmi_ip_data *ip_data, bool start);
+
+ void (*audio_start)(struct hdmi_ip_data *ip_data, bool start);
#endif
};
@@ -146,5 +148,6 @@ void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data,
struct seq_file *s);
#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
void ti_hdmi_4xxx_wp_audio_enable(struct hdmi_ip_data *ip_data, bool enable);
+void ti_hdmi_4xxx_audio_start(struct hdmi_ip_data *ip_data, bool enable);
#endif
#endif
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 4ab3b19..e6fa61d 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -1267,10 +1267,14 @@ int hdmi_config_audio_acr(struct hdmi_ip_data *ip_data,
void ti_hdmi_4xxx_wp_audio_enable(struct hdmi_ip_data *ip_data, bool enable)
{
- REG_FLD_MOD(hdmi_av_base(ip_data),
- HDMI_CORE_AV_AUD_MODE, enable, 0, 0);
REG_FLD_MOD(hdmi_wp_base(ip_data),
HDMI_WP_AUDIO_CTRL, enable, 31, 31);
+}
+
+void ti_hdmi_4xxx_audio_start(struct hdmi_ip_data *ip_data, bool enable)
+{
+ REG_FLD_MOD(hdmi_av_base(ip_data),
+ HDMI_CORE_AV_AUD_MODE, enable, 0, 0);
REG_FLD_MOD(hdmi_wp_base(ip_data),
HDMI_WP_AUDIO_CTRL, enable, 30, 30);
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAPDSS: VENC: allow switching venc type at runtime
VENC type (composite/svideo) doesn't have to be fixed by board wiring,
it is possible to provide both connectors, which is what pandora does.
Having to recompile the kernel for users who have TV connector types
that's don't match default board setting is very inconvenient, especially
for users of a consumer device, so add support for switching VENC type
at runtime over a new sysfs file venc_type.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
Documentation/arm/OMAP/DSS |1 +
drivers/video/omap2/dss/venc.c | 55 +++-
2 files changed, 55 insertions(+), 1 deletions(-)
diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS
index 888ae7b..18e2214 100644
--- a/Documentation/arm/OMAP/DSS
+++ b/Documentation/arm/OMAP/DSS
@@ -156,6 +156,7 @@ timings Display timings
(pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw)
pal and ntsc
panel_name
tear_elim Tearing elimination 0=off, 1=on
+venc_type Output type (video encoder only): composite or svideo
There are also some debugfs files at debugfs/omapdss/ which show information
about clocks and registers.
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 9c3daf7..aa2e74a 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -485,16 +485,69 @@ unsigned long venc_get_pixel_clock(void)
return 1350;
}
+static ssize_t display_venc_type_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct omap_dss_device *dssdev = to_dss_device(dev);
+ const char *ret;
+
+ switch (dssdev-phy.venc.type) {
+ case OMAP_DSS_VENC_TYPE_COMPOSITE:
+ ret = composite;
+ break;
+ case OMAP_DSS_VENC_TYPE_SVIDEO:
+ ret = svideo;
+ break;
+ default:
+ ret = unknown;
+ break;
+ }
+
+ return snprintf(buf, PAGE_SIZE, %s\n, ret);
+}
+
+static ssize_t display_venc_type_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t size)
+{
+ struct omap_dss_device *dssdev = to_dss_device(dev);
+ enum omap_dss_venc_type new_type;
+
+ if (strncmp(composite, buf, 9) == 0)
+ new_type = OMAP_DSS_VENC_TYPE_COMPOSITE;
+ else if (strncmp(svideo, buf, 6) == 0)
+ new_type = OMAP_DSS_VENC_TYPE_SVIDEO;
+ else
+ return -EINVAL;
+
+ mutex_lock(venc.venc_lock);
+
+ if (dssdev-phy.venc.type != new_type) {
+ dssdev-phy.venc.type = new_type;
+ if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE) {
+ venc_power_off(dssdev);
+ venc_power_on(dssdev);
+ }
+ }
+
+ mutex_unlock(venc.venc_lock);
+
+ return size;
+}
+
+static DEVICE_ATTR(venc_type, S_IRUGO | S_IWUSR,
+ display_venc_type_show, display_venc_type_store);
+
/* driver */
static int venc_panel_probe(struct omap_dss_device *dssdev)
{
dssdev-panel.timings = omap_dss_pal_timings;
- return 0;
+ return device_create_file(dssdev-dev, dev_attr_venc_type);
}
static void venc_panel_remove(struct omap_dss_device *dssdev)
{
+ device_remove_file(dssdev-dev, dev_attr_venc_type);
}
static int venc_panel_enable(struct omap_dss_device *dssdev)
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ARM: OMAP1: boards: Fix OMAP_GPIO_IRQ usage with gpio_to_irq()
Hi,
Sorry for the slow reply, I noticed this when dealing with merge
conflicts pulling in this patch and others from Tony.
On Mon, Mar 19, 2012 at 5:06 AM, Tarun Kanti DebBarma
tarun.ka...@ti.com wrote:
With dynamic allocation of IRQ the usage of OMAP_GPIO_IRQ
is no longer valid. We should be using gpio_to_irq() instead.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/mach-omap1/board-h2.c | 8
arch/arm/mach-omap1/board-h3.c | 9 -
arch/arm/mach-omap1/board-htcherald.c | 6 +++---
arch/arm/mach-omap1/board-innovator.c | 4 ++--
arch/arm/mach-omap1/board-nokia770.c | 2 +-
arch/arm/mach-omap1/board-osk.c | 12 ++--
arch/arm/mach-omap1/board-palmte.c | 2 +-
arch/arm/mach-omap1/board-palmtt.c | 2 +-
arch/arm/mach-omap1/board-palmz71.c | 2 +-
arch/arm/mach-omap1/board-voiceblue.c | 16 +++-
10 files changed, 30 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 00ad6b2..ad0eece 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -244,8 +244,6 @@ static struct resource h2_smc91x_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = OMAP_GPIO_IRQ(0),
- .end = OMAP_GPIO_IRQ(0),
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWEDGE,
},
};
@@ -364,11 +362,9 @@ static struct tps65010_board tps_board = {
static struct i2c_board_info __initdata h2_i2c_board_info[] = {
{
I2C_BOARD_INFO(tps65010, 0x48),
- .irq = OMAP_GPIO_IRQ(58),
.platform_data = tps_board,
}, {
I2C_BOARD_INFO(isp1301_omap, 0x2d),
- .irq = OMAP_GPIO_IRQ(2),
},
};
@@ -437,10 +433,14 @@ static void __init h2_init(void)
omap_cfg_reg(E19_1610_KBR4);
omap_cfg_reg(N19_1610_KBR5);
+ h2_devices[2]-resource[1].start = gpio_to_irq(0);
+ h2_devices[2]-resource[1].end = gpio_to_irq(0);
Never, ever, ever do this. What happens here when someone else adds
another device to the h2_devices array before the smc91x one? Booom.
Extremely fragile code.
There's already a named resource struct you can use for this
(h2_smc91x_resources). Use it.
Same comments go for the other locations in this file as well as the
other OMAP2+ patch, where appropriate.
-Olof
--
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: [GIT PULL] omap fixes for merge window
Hi Tony, On Wed, Mar 21, 2012 at 11:05 AM, Tony Lindgren t...@atomide.com wrote: Hi Arnd Olof, Here's a set of fixes that would be nice to get merged during the merge window before the GPIO changes get merged to avoid boot issues on many omap boards. The changes queued in the GPIO tree require getting rid of OMAP_GPIO_IRQ and use gpio_to_irq() instead. This is needed for dynamically allocated GPIO interrupt ranges. Sorry for the slow response on this, we've been focused on getting the main pulls going in. I'm about to start a fixes branch now and looked at this pull request. I replied to one of the original patches in this branch, they need to be fixed before they can go in: http://marc.info/?l=linux-omapm=133299716528617w=2 Also, that way we can get a clean branch based on current mainline without merge conflicts. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] ARM: OMAP1: boards: Fix OMAP_GPIO_IRQ usage with gpio_to_irq()
On Thu, Mar 29, 2012 at 10:28 AM, Olof Johansson o...@lixom.net wrote:
Hi,
Sorry for the slow reply, I noticed this when dealing with merge
conflicts pulling in this patch and others from Tony.
On Mon, Mar 19, 2012 at 5:06 AM, Tarun Kanti DebBarma
tarun.ka...@ti.com wrote:
With dynamic allocation of IRQ the usage of OMAP_GPIO_IRQ
is no longer valid. We should be using gpio_to_irq() instead.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/mach-omap1/board-h2.c | 8
arch/arm/mach-omap1/board-h3.c | 9 -
arch/arm/mach-omap1/board-htcherald.c | 6 +++---
arch/arm/mach-omap1/board-innovator.c | 4 ++--
arch/arm/mach-omap1/board-nokia770.c | 2 +-
arch/arm/mach-omap1/board-osk.c | 12 ++--
arch/arm/mach-omap1/board-palmte.c | 2 +-
arch/arm/mach-omap1/board-palmtt.c | 2 +-
arch/arm/mach-omap1/board-palmz71.c | 2 +-
arch/arm/mach-omap1/board-voiceblue.c | 16 +++-
10 files changed, 30 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 00ad6b2..ad0eece 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -244,8 +244,6 @@ static struct resource h2_smc91x_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = OMAP_GPIO_IRQ(0),
- .end = OMAP_GPIO_IRQ(0),
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWEDGE,
},
};
@@ -364,11 +362,9 @@ static struct tps65010_board tps_board = {
static struct i2c_board_info __initdata h2_i2c_board_info[] = {
{
I2C_BOARD_INFO(tps65010, 0x48),
- .irq = OMAP_GPIO_IRQ(58),
.platform_data = tps_board,
}, {
I2C_BOARD_INFO(isp1301_omap, 0x2d),
- .irq = OMAP_GPIO_IRQ(2),
},
};
@@ -437,10 +433,14 @@ static void __init h2_init(void)
omap_cfg_reg(E19_1610_KBR4);
omap_cfg_reg(N19_1610_KBR5);
+ h2_devices[2]-resource[1].start = gpio_to_irq(0);
+ h2_devices[2]-resource[1].end = gpio_to_irq(0);
Never, ever, ever do this. What happens here when someone else adds
another device to the h2_devices array before the smc91x one? Booom.
Extremely fragile code.
Ok.
There's already a named resource struct you can use for this
(h2_smc91x_resources). Use it.
Sure, I will use this one.
Same comments go for the other locations in this file as well as the
other OMAP2+ patch, where appropriate.
Alright, I will make appropriate changes. Thanks.
--
Tarun
-Olof
--
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
