Re: [alsa-devel] [PATCH v3 0/5] Beaglebone-Black HDMI audio
On 17 September 2014 06:40, Jyri Sarha wrote: > Changes since v2: > - Change compatible property from "ti,gpio-clock" to "ti,gpio-gate-clock" > - Some minor cleanups > > The code has a functional dependency to: > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg109264.html > > Without the above patch the audio card does not probe. > > The code has been rebased on top of Linux 3.17-rc5. The patches > bellow, the above dependency, and couple of commits to add BBB HDMI audio > support to omap2plus_defconfig can be pulled from: > > https://github.com/jsarha/linux.git linux-master-bbb-hdmi-audio How do you intend to get this merge, sending patchsets like this without indication to maintainers on a merge strategy is kinda messy. I'm not sure how maintained tilcdc is. Dave. > > Cheers, > Jyri > > Jyri Sarha (5): > clk: ti: add "ti,gpio-gate-clock" controlled clock > drm/tilcdc: Add I2S HDMI audio config for tda998x > ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S > bus > ASoC: davinci: HDMI audio build for AM33XX and TDA998x > ARM: dts: am335x-boneblack: Add HDMI audio support > > .../bindings/clock/ti/gpio-gate-clock.txt | 21 ++ > .../bindings/sound/davinci-evm-audio.txt |6 +- > arch/arm/boot/dts/am335x-boneblack.dts | 52 + > drivers/clk/ti/Makefile|2 +- > drivers/clk/ti/gpio.c | 202 > > drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 ++- > sound/soc/davinci/Kconfig | 12 ++ > sound/soc/davinci/davinci-evm.c| 82 +++- > 8 files changed, 395 insertions(+), 6 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt > create mode 100644 drivers/clk/ti/gpio.c > > -- > 1.7.9.5 > > ___ > Alsa-devel mailing list > alsa-de...@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: Remove unused pieces of legacy DMA API
We're moving to the dmaengine API, so let's remove the unused pieces of the omap legacy DMA code to make sure we don't get any new users for these: omap_set_dma_color_mode omap_set_dma_src_index omap_set_dma_dest_index omap_dma_unlink_lch omap_clear_dma omap_dma_running omap_dma_set_prio_lch omap_set_dma_dst_endian_type omap_set_dma_src_endian_type omap_get_dma_index omap_dma_disable_irq omap_request_dma_chain omap_free_dma_chain omap_dma_chain_a_transfer omap_start_dma_chain_transfers omap_stop_dma_chain_transfers omap_get_dma_chain_index omap_get_dma_chain_dst_pos omap_get_dma_chain_src_pos omap_modify_dma_chain_params omap_dma_chain_status Cc: Russell King Signed-off-by: Tony Lindgren --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -64,7 +64,9 @@ enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED }; static struct omap_system_dma_plat_info *p; static struct omap_dma_dev_attr *d; - +static void omap_clear_dma(int lch); +static int omap_dma_set_prio_lch(int lch, unsigned char read_prio, +unsigned char write_prio); static int enable_1510_mode; static u32 errata; @@ -284,66 +286,6 @@ void omap_set_dma_transfer_params(int lch, int data_type, int elem_count, } EXPORT_SYMBOL(omap_set_dma_transfer_params); -void omap_set_dma_color_mode(int lch, enum omap_dma_color_mode mode, u32 color) -{ - BUG_ON(omap_dma_in_1510_mode()); - - if (dma_omap1()) { - u16 w; - - w = p->dma_read(CCR2, lch); - w &= ~0x03; - - switch (mode) { - case OMAP_DMA_CONSTANT_FILL: - w |= 0x01; - break; - case OMAP_DMA_TRANSPARENT_COPY: - w |= 0x02; - break; - case OMAP_DMA_COLOR_DIS: - break; - default: - BUG(); - } - p->dma_write(w, CCR2, lch); - - w = p->dma_read(LCH_CTRL, lch); - w &= ~0x0f; - /* Default is channel type 2D */ - if (mode) { - p->dma_write(color, COLOR, lch); - w |= 1; /* Channel type G */ - } - p->dma_write(w, LCH_CTRL, lch); - } - - if (dma_omap2plus()) { - u32 val; - - val = p->dma_read(CCR, lch); - val &= ~((1 << 17) | (1 << 16)); - - switch (mode) { - case OMAP_DMA_CONSTANT_FILL: - val |= 1 << 16; - break; - case OMAP_DMA_TRANSPARENT_COPY: - val |= 1 << 17; - break; - case OMAP_DMA_COLOR_DIS: - break; - default: - BUG(); - } - p->dma_write(val, CCR, lch); - - color &= 0xff; - p->dma_write(color, COLOR, lch); - } -} -EXPORT_SYMBOL(omap_set_dma_color_mode); - void omap_set_dma_write_mode(int lch, enum omap_dma_write_mode mode) { if (dma_omap2plus()) { @@ -417,16 +359,6 @@ void omap_set_dma_params(int lch, struct omap_dma_channel_params *params) } EXPORT_SYMBOL(omap_set_dma_params); -void omap_set_dma_src_index(int lch, int eidx, int fidx) -{ - if (dma_omap2plus()) - return; - - p->dma_write(eidx, CSEI, lch); - p->dma_write(fidx, CSFI, lch); -} -EXPORT_SYMBOL(omap_set_dma_src_index); - void omap_set_dma_src_data_pack(int lch, int enable) { u32 l; @@ -510,16 +442,6 @@ void omap_set_dma_dest_params(int lch, int dest_port, int dest_amode, } EXPORT_SYMBOL(omap_set_dma_dest_params); -void omap_set_dma_dest_index(int lch, int eidx, int fidx) -{ - if (dma_omap2plus()) - return; - - p->dma_write(eidx, CDEI, lch); - p->dma_write(fidx, CDFI, lch); -} -EXPORT_SYMBOL(omap_set_dma_dest_index); - void omap_set_dma_dest_data_pack(int lch, int enable) { u32 l; @@ -843,7 +765,7 @@ EXPORT_SYMBOL(omap_dma_set_global_params); * Both of the above can be set with one of the following values : * DMA_CH_PRIO_HIGH/DMA_CH_PRIO_LOW */ -int +static int omap_dma_set_prio_lch(int lch, unsigned char read_prio, unsigned char write_prio) { @@ -864,13 +786,13 @@ omap_dma_set_prio_lch(int lch, unsigned char read_prio, return 0; } -EXPORT_SYMBOL(omap_dma_set_prio_lch); + /* * Clears any DMA state so the DMA engine is ready to restart with new buffers * through omap_start_dma(). Any buffers in flight are discarded. */ -void omap_clear_dma(int lch) +static void omap_clear_dma(int lch) { unsigned long flags; @@ -878,7 +800,6 @@ void omap_clear_dma(int lch) p->clear_dma(lch); local_irq_restore(flags); } -EXPORT_SYMBOL(omap_clear_dma); void omap_start_dma(int lch) { @@ -1167,652 +1088,6 @
[PATCH v11 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S
The omap1's debug-macro.S is similar to the generic 8250 code. Compared to the 8520 code the omap1 macro automatically determines what UART to use based on breadcrumbs left by the bootloader and automatically copes with the eccentric register layout on OMAP7XX. This patch drops both these features and relies instead on the generic 8250 macros: 1. Dropping support for the bootloader breadcrumbs is identical to the way the migration was handled for OMAP2 (see 808b7e07464d...). 2. Support for OMAP7XX still exists but it must be configured by hand (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime. Signed-off-by: Daniel Thompson Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org Cc: Tony Lindgren Cc: Arnd Bergmann Cc: linux-omap@vger.kernel.org Tested-by: Aaro Koskinen --- arch/arm/Kconfig.debug | 57 +- arch/arm/mach-omap1/include/mach/debug-macro.S | 101 - 2 files changed, 56 insertions(+), 102 deletions(-) delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 97c3058..6540036 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -471,6 +471,30 @@ choice Say Y here if you want kernel low-level debugging support on TI-NSPIRE CX models. + config DEBUG_OMAP1UART1 + bool "Kernel low-level debugging via OMAP1 UART1" + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (except OMAP730) on the UART1. + + config DEBUG_OMAP1UART2 + bool "Kernel low-level debugging via OMAP1 UART2" + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (except OMAP730) on the UART2. + + config DEBUG_OMAP1UART3 + bool "Kernel low-level debugging via OMAP1 UART3" + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (except OMAP730) on the UART3. + config DEBUG_OMAP2UART1 bool "OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 boards)" depends on ARCH_OMAP2PLUS @@ -513,6 +537,30 @@ choice depends on ARCH_OMAP2PLUS select DEBUG_OMAP2PLUS_UART + config DEBUG_OMAP7XXUART1 + bool "Kernel low-level debugging via OMAP730 UART1" + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART1. + + config DEBUG_OMAP7XXUART2 + bool "Kernel low-level debugging via OMAP730 UART2" + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART2. + + config DEBUG_OMAP7XXUART3 + bool "Kernel low-level debugging via OMAP730 UART3" + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART3. + config DEBUG_TI81XXUART1 bool "Kernel low-level debugging messages via TI81XX UART1 (ti8148evm)" depends on ARCH_OMAP2PLUS @@ -1120,6 +1168,9 @@ config DEBUG_UART_PHYS default 0xff69 if DEBUG_RK32_UART2 default 0xffc02000 if DEBUG_SOCFPGA_UART default 0xffd82340 if ARCH_IOP13XX + default 0xfffb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 + default 0xfffb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 + default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 default 0xfff36000 if DEBUG_HIGHBANK_UART default 0xf700 if ARCH_IOP33X depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \ @@ -1188,6 +1239,9 @@ config DEBUG_UART_VIRT default 0xfef0 if ARCH_IXP4XX && !CPU_BIG_ENDIAN default 0xfef3 if ARCH_IXP4XX && CPU_BIG_ENDIAN default 0xfef36000 if DEBUG_HIGHBANK_UART + default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 + default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 + default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 default 0xfefff700 if ARCH_IOP33X default 0xff003000 if DEBUG_U300_UART default DEBUG_UART_PHYS if !MMU @@ -1198,7 +1252,8 @@ confi
Re: [PATCH 2/2] mfd: twl4030-power: use 'ti,system-power-controller' as alternative way to support system power off
On Mon, 08 Sep 2014, Tony Lindgren wrote: > * Nishanth Menon [140903 12:07]: > > ti,system-power-controller is more or less the standard way of > > indicating that the PMIC is the system wide power controller and hence > > may be used to switch off the system. Almost ALL TI PMIC drivers and > > many Maxim PMIC drivers follow the same style. > > > > So support 'ti,system-power-controller' in addition to the usual > > 'ti,use_poweroff' to indicate that the PMIC instance has control for > > switching off the system. > > > > Signed-off-by: Nishanth Menon > > Acked-by: Tony Lindgren I assume you're going to resend this with the document modifications? When you do, don't forget to apply Tony's Ack, as it will ensure a faster merge. > > --- > > drivers/mfd/twl4030-power.c |3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c > > index 3bc969a..1c129ba 100644 > > --- a/drivers/mfd/twl4030-power.c > > +++ b/drivers/mfd/twl4030-power.c > > @@ -627,6 +627,9 @@ static bool twl4030_power_use_poweroff(const struct > > twl4030_power_data *pdata, > > if (pdata && pdata->use_poweroff) > > return true; > > > > + if (of_property_read_bool(node, "ti,system-power-controller")) > > + return true; > > + > > if (of_property_read_bool(node, "ti,use_poweroff")) > > return true; > > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 v10 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S
On 16/09/14 15:58, Aaro Koskinen wrote: > Hi, > > On Tue, Sep 16, 2014 at 11:46:24PM +0100, Daniel Thompson wrote: >> +config DEBUG_OMAP1UART1 >> +bool "Kernel low-level debugging via OMAP1 UART1" >> +depends on ARCH_OMAP1 >> +select DEBUG_UART_8250 >> +help >> + Say Y here if you want kernel low-level debugging support >> + on OMAP1 based platforms (expect OMAP730) on the UART1. > ^^ > >> +select DEBUG_UART_8250 >> +help >> + Say Y here if you want kernel low-level debugging support >> + on OMAP1 based platforms (expect OMAP730) on the UART2. > ^^ > >> +select DEBUG_UART_8250 >> +help >> + Say Y here if you want kernel low-level debugging support >> + on OMAP1 based platforms (expect OMAP730) on the UART3. > ^^ > > I already commented earlier, that "expect" here is probably a typo? I'm extremely sorry to have overlooked your previous comment. There's certainly no question I read your previous e-mail because because I copied your Tested-by: from it. I will fix this (and also grep all other patches in the set to make sure I haven't copied the typo anywhere else). Daniel. -- 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 v10 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S
Hi, On Tue, Sep 16, 2014 at 11:46:24PM +0100, Daniel Thompson wrote: > + config DEBUG_OMAP1UART1 > + bool "Kernel low-level debugging via OMAP1 UART1" > + depends on ARCH_OMAP1 > + select DEBUG_UART_8250 > + help > + Say Y here if you want kernel low-level debugging support > + on OMAP1 based platforms (expect OMAP730) on the UART1. ^^ > + select DEBUG_UART_8250 > + help > + Say Y here if you want kernel low-level debugging support > + on OMAP1 based platforms (expect OMAP730) on the UART2. ^^ > + select DEBUG_UART_8250 > + help > + Say Y here if you want kernel low-level debugging support > + on OMAP1 based platforms (expect OMAP730) on the UART3. ^^ I already commented earlier, that "expect" here is probably a typo? A. -- 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 v10 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S
The omap1's debug-macro.S is similar to the generic 8250 code. Compared to the 8520 code the omap1 macro automatically determines what UART to use based on breadcrumbs left by the bootloader and automatically copes with the eccentric register layout on OMAP7XX. This patch drops both these features and relies instead on the generic 8250 macros: 1. Dropping support for the bootloader breadcrumbs is identical to the way the migration was handled for OMAP2 (see 808b7e07464d...). 2. Support for OMAP7XX still exists but it must be configured by hand (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime. Signed-off-by: Daniel Thompson Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org Cc: Tony Lindgren Cc: Arnd Bergmann Cc: linux-omap@vger.kernel.org Tested-by: Aaro Koskinen --- arch/arm/Kconfig.debug | 57 +- arch/arm/mach-omap1/include/mach/debug-macro.S | 101 - 2 files changed, 56 insertions(+), 102 deletions(-) delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 97c3058..01f4ee2 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -471,6 +471,30 @@ choice Say Y here if you want kernel low-level debugging support on TI-NSPIRE CX models. + config DEBUG_OMAP1UART1 + bool "Kernel low-level debugging via OMAP1 UART1" + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART1. + + config DEBUG_OMAP1UART2 + bool "Kernel low-level debugging via OMAP1 UART2" + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART2. + + config DEBUG_OMAP1UART3 + bool "Kernel low-level debugging via OMAP1 UART3" + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (expect OMAP730) on the UART3. + config DEBUG_OMAP2UART1 bool "OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 boards)" depends on ARCH_OMAP2PLUS @@ -513,6 +537,30 @@ choice depends on ARCH_OMAP2PLUS select DEBUG_OMAP2PLUS_UART + config DEBUG_OMAP7XXUART1 + bool "Kernel low-level debugging via OMAP730 UART1" + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART1. + + config DEBUG_OMAP7XXUART2 + bool "Kernel low-level debugging via OMAP730 UART2" + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART2. + + config DEBUG_OMAP7XXUART3 + bool "Kernel low-level debugging via OMAP730 UART3" + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART3. + config DEBUG_TI81XXUART1 bool "Kernel low-level debugging messages via TI81XX UART1 (ti8148evm)" depends on ARCH_OMAP2PLUS @@ -1120,6 +1168,9 @@ config DEBUG_UART_PHYS default 0xff69 if DEBUG_RK32_UART2 default 0xffc02000 if DEBUG_SOCFPGA_UART default 0xffd82340 if ARCH_IOP13XX + default 0xfffb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 + default 0xfffb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 + default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 default 0xfff36000 if DEBUG_HIGHBANK_UART default 0xf700 if ARCH_IOP33X depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \ @@ -1188,6 +1239,9 @@ config DEBUG_UART_VIRT default 0xfef0 if ARCH_IXP4XX && !CPU_BIG_ENDIAN default 0xfef3 if ARCH_IXP4XX && CPU_BIG_ENDIAN default 0xfef36000 if DEBUG_HIGHBANK_UART + default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 + default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 + default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 default 0xfefff700 if ARCH_IOP33X default 0xff003000 if DEBUG_U300_UART default DEBUG_UART_PHYS if !MMU @@ -1198,7 +1252,8 @@ confi
Re: [PATCH 00/16 v9] omap 8250 based uart + DMA
* Tony Lindgren [140916 09:49]: > * Sebastian Andrzej Siewior [140916 05:58]: > > On 09/15/2014 01:50 PM, Sebastian Andrzej Siewior wrote: > > > I changed the restore function the fix the am335x-evm + less "freeze". > > > And now we have this. So let me search… > > > > IER was 0 by accident. It fixed in TX path. > > I pushed uart_v10_pre1 which should have it fixed aport from other > > things… > > Just verified that works for my off-idle test case thanks. > > > I am going to address the review comments, to split the DMA callbacks > > as requested and if nobody comes up with something fancy we will have a > > v10 :) > > OK Found one more issue when booting on 2420 n8x0, maybe something to do with runtime PM? Regards, Tony [4.770507] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM [4.777343] Modules linked in: [4.780487] CPU: 0 PID: 1 Comm: init Not tainted 3.17.0-rc5-00211-gc2182d0-dirty #1408 [4.788482] task: c5842b80 ti: c585 task.ti: c585 [4.793945] PC is at serial8250_start_tx+0x124/0x154 [4.798980] LR is at uart_start+0x4c/0x5c [4.803039] pc : []lr : []psr: a093 [4.803039] sp : c5851e10 ip : c5851e28 fp : c5851e24 [4.814605] r10: 0007 r9 : r8 : c134d554 [4.819885] r7 : c5cb7800 r6 : 2013 r5 : c134d554 r4 : c134d554 [4.826477] r3 : c134d690 r2 : r1 : 0001 r0 : c134d554 [4.833068] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [4.840332] Control: 00c5387d Table: 85cd8000 DAC: 0015 [4.846130] Process init (pid: 1, stack limit = 0xc5850248) [4.851776] Stack: (0xc5851e10 to 0xc5852000) [4.856201] 1e00: c5cb7800 c134d554 c5851e44 c5851e28 [4.864440] 1e20: c03d1ee4 c03d7228 c5842b80 c5b00408 c5cf3c07 c5851e7c c5851e48 [4.872711] 1e40: c03d2da0 c03d1ea4 c5851e6c a013 c03d1fe0 c5cb7800 0007 224c [4.880981] 1e60: c88cc2a0 2250 c5cf3c00 c88ca000 c5851edc c5851e80 c03b9474 c03d2cd4 [4.889251] 1e80: c5851e9c c5cb7ab4 c5cf3c00 c5cb793c c5a5ae00 c585 c0158e1c [4.897491] 1ea0: c5842b80 c007152c c5cb7ad4 c5cb7ad4 c5cb7800 e0cc 0007 c5cb7800 [4.905761] 1ec0: c585 0400 c5a5ae00 c5851f1c c5851ee0 c03b61c0 c03b92d0 [4.914031] 1ee0: 0007 0007 c5cb18c0 c03b92c4 c0b19f20 0007 e0cc [4.922271] 1f00: c5851f78 c5a5ae00 c585 e0cc c5851f44 c5851f20 c03b63c4 c03b60c0 [4.930541] 1f20: c5851f78 c5a5ae00 0007 e0cc c5851f78 0007 c5851f74 c5851f48 [4.938812] 1f40: c0168f38 c03b632c c0185718 c0185688 c5a5ae00 c5a5ae00 [4.947052] 1f60: 0007 e0cc c5851fa4 c5851f78 c0169380 c0168e90 [4.955322] 1f80: e0cc 0001 0004 c000f164 c5851fa8 [4.963592] 1fa0: c000eee0 c0169340 e0cc e0cc 0007 [4.971862] 1fc0: e0cc 0001 0004 a24c 00017504 1000 [4.980102] 1fe0: bef5aa40 bef5aa30 a474 b6e801ec 6010 [4.988372] [] (serial8250_start_tx) from [] (uart_start+0x4c/0x5c) [4.996490] [] (uart_start) from [] (uart_write+0xd8/0x100) [5.003875] [] (uart_write) from [] (n_tty_write+0x1b0/0x510) [5.011474] [] (n_tty_write) from [] (tty_write+0x10c/0x26c) [5.018951] [] (tty_write) from [] (redirected_tty_write+0xa4/0xb8) [5.027038] [] (redirected_tty_write) from [] (vfs_write+0xb4/0x1bc) [5.035217] [] (vfs_write) from [] (SyS_write+0x4c/0x98) [5.042358] [] (SyS_write) from [] (ret_fast_syscall+0x0/0x48) [5.050018] Code: e3a02000 ee072fba e3a01001 f5d3f000 (e1d30f9f) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] pstore-ram: Allow optional mapping with pgprot_noncached
* Russell King - ARM Linux [140912 16:16]: > On Fri, Sep 12, 2014 at 11:32:25AM -0700, Tony Lindgren wrote: > > On some ARMs at least the memory can be mapped pgprot_noncached() > > and still be working for atomic operations. As pointed out by > > Colin Cross , in some cases you do want to use > > pgprot_noncached() if the SoC supports it to see a debug printk > > just before a write hanging the system. > > > > On ARMs, the atomic operations on strongly ordered memory are > > implementation defined. So let's provide an optional kernel parameter > > for configuring noncached memory, and use pgprot_writecombine() by > > default. > > Can we clean up this terminology please? > > Writecombine memory is not cached - write combine memory bypasses the > caches entirely. What it doesn't bypass are store buffers, which may > combine two writes together. So, calling it "cached" is misleading. Good point. I've pretty much s/cached/memtype/ and updated the description too in the patch below. > Secondly, memory returned by ioremap() is not strongly ordered, it is > device memory. There's three main classifications of memory on ARM: > strongly ordered, device and normal memory. Normal memory has attributes > which define whether it is write combining, or cacheable in some way (and > if so, how it's cacheable.) > > Exclusives are always permitted to normal memory. The other two are > implementation defined. While an implementation may offer it on > strongly ordered, that doesn't mean that it also supports it on device > memory. > > Lastly, aliased mappings are something that ARM has always strongly > discouraged on ARMv6+ (it was plain down-right unpredictable, but it's > now "strongly discouraged") and remapping memory with different memory > type should be avoided. Yes thanks for the summary again. Maybe let's let this second patch float on the lists for a while until we have somebody actually test it on unbuffered memory. Andrew, if no comments on 1/2 in this series, can you please pick it up for fixes so we get pstore working? Here's the updated version of the second patch for reference. Regards, Tony 8< - From: Tony Lindgren Date: Thu, 11 Sep 2014 15:02:37 -0700 Subject: [PATCH] pstore-ram: Allow optional mapping with pgprot_noncached On some ARMs the memory can be mapped pgprot_noncached() and still be working for atomic operations. As pointed out by Colin Cross , in some cases you do want to use pgprot_noncached() if the SoC supports it to see a debug printk just before a write hanging the system. On ARMs, the atomic operations on strongly ordered memory are implementation defined. So let's provide an optional kernel parameter for configuring pgprot_noncached(), and use pgprot_writecombine() by default. Cc: Arnd Bergmann Cc: Rob Herring Cc: Randy Dunlap Cc: Anton Vorontsov Cc: Colin Cross Cc: Kees Cook Cc: Olof Johansson Cc: Tony Luck Cc: Russell King Signed-off-by: Tony Lindgren --- a/Documentation/ramoops.txt +++ b/Documentation/ramoops.txt @@ -14,11 +14,19 @@ survive after a restart. 1. Ramoops concepts -Ramoops uses a predefined memory area to store the dump. The start and size of -the memory area are set using two variables: +Ramoops uses a predefined memory area to store the dump. The start and size +and type of the memory area are set using three variables: * "mem_address" for the start * "mem_size" for the size. The memory size will be rounded down to a power of two. + * "mem_type" to specifiy if the memory type (default is pgprot_writecombine). + +Typically the default value of mem_type=0 should be used as that sets the pstore +mapping to pgprot_writecombine. Setting mem_type=1 attempts to use +pgprot_noncached, which only works on some platforms. This is because pstore +depends on atomic operations. At least on ARM, pgprot_noncached causes the +memory to be mapped strongly ordered, and atomic operations on strongly ordered +memory are implementation defined, and won't work on many ARMs such as omaps. The memory area is divided into "record_size" chunks (also rounded down to power of two) and each oops/panic writes a "record_size" chunk of @@ -55,6 +63,7 @@ Setting the ramoops parameters can be done in 2 different manners: static struct ramoops_platform_data ramoops_data = { .mem_size = <...>, .mem_address= <...>, +.mem_type = <...>, .record_size= <...>, .dump_oops = <...>, .ecc= <...>, --- a/fs/pstore/ram.c +++ b/fs/pstore/ram.c @@ -61,6 +61,11 @@ module_param(mem_size, ulong, 0400); MODULE_PARM_DESC(mem_size, "size of reserved RAM used to store oops/panic logs"); +static unsigned int mem_type; +module_param(mem_type, uint, 0600); +MODULE_PARM_DESC(mem_type, + "set to 1 to try to use unbuffered memory (default 0)"); + static int dump_oops = 1; module_param(dump_o
[PATCH v3 5/5] ARM: dts: am335x-boneblack: Add HDMI audio support
Adds mcasp0_pins, clk_mcasp0_fixed, clk_mcasp0, mcasp0, hdmi_audio, and sound nodes. Signed-off-by: Jyri Sarha --- arch/arm/boot/dts/am335x-boneblack.dts | 52 1 file changed, 52 insertions(+) diff --git a/arch/arm/boot/dts/am335x-boneblack.dts b/arch/arm/boot/dts/am335x-boneblack.dts index 305975d..1487f7c 100644 --- a/arch/arm/boot/dts/am335x-boneblack.dts +++ b/arch/arm/boot/dts/am335x-boneblack.dts @@ -59,12 +59,35 @@ 0x1b0 0x03 /* xdma_event_intr0, OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */ >; }; + + mcasp0_pins: mcasp0_pins { + pinctrl-single,pins = < + 0x1ac (PIN_INPUT_PULLUP | MUX_MODE0)/* mcasp0_ahclkx.mcasp0_ahclkx */ + 0x19c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* mcasp0_ahclkr.mcasp0_axr2 */ + 0x194 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* mcasp0_fsx.mcasp0_fsx */ + 0x190 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp0_aclkx.mcasp0_aclkx */ + 0x06c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_a11.GPIO1_27 */ + >; + }; }; &lcdc { status = "okay"; }; +&mcasp0{ + pinctrl-names = "default"; + pinctrl-0 = <&mcasp0_pins>; + status = "okay"; + op-mode = <0>; /* MCASP_IIS_MODE */ + tdm-slots = <2>; + serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */ + 0 0 1 0 + >; + tx-num-evt = <1>; + rx-num-evt = <1>; +}; + / { hdmi { compatible = "ti,tilcdc,slave"; @@ -74,4 +97,33 @@ pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>; status = "okay"; }; + + clk_mcasp0_fixed: clk_mcasp0_fixed { + #clock-cells = <0>; + compatible = "fixed-clock"; + clock-frequency = <24576000>; + }; + + clk_mcasp0: clk_mcasp0 { + #clock-cells = <0>; + compatible = "ti,gpio-gate-clock"; + clocks = <&clk_mcasp0_fixed>; + enable-gpios = <&gpio1 27 0>; /* BeagleBone Black Clk enable on GPIO1_27 */ + }; + + hdmi_audio: hdmi_audio@0 { + compatible = "linux,hdmi-audio"; + status = "okay"; + }; + + sound { + compatible = "ti,beaglebone-black-audio"; + ti,model = "TI BeagleBone Black"; + ti,audio-codec = <&hdmi_audio>; + ti,mcasp-controller = <&mcasp0>; + ti,audio-routing = + "HDMI Out", "TX"; + clocks = <&clk_mcasp0>; + clock-names = "mclk"; + }; }; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/5] Beaglebone-Black HDMI audio
Changes since v2: - Change compatible property from "ti,gpio-clock" to "ti,gpio-gate-clock" - Some minor cleanups The code has a functional dependency to: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg109264.html Without the above patch the audio card does not probe. The code has been rebased on top of Linux 3.17-rc5. The patches bellow, the above dependency, and couple of commits to add BBB HDMI audio support to omap2plus_defconfig can be pulled from: https://github.com/jsarha/linux.git linux-master-bbb-hdmi-audio Cheers, Jyri Jyri Sarha (5): clk: ti: add "ti,gpio-gate-clock" controlled clock drm/tilcdc: Add I2S HDMI audio config for tda998x ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus ASoC: davinci: HDMI audio build for AM33XX and TDA998x ARM: dts: am335x-boneblack: Add HDMI audio support .../bindings/clock/ti/gpio-gate-clock.txt | 21 ++ .../bindings/sound/davinci-evm-audio.txt |6 +- arch/arm/boot/dts/am335x-boneblack.dts | 52 + drivers/clk/ti/Makefile|2 +- drivers/clk/ti/gpio.c | 202 drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 ++- sound/soc/davinci/Kconfig | 12 ++ sound/soc/davinci/davinci-evm.c| 82 +++- 8 files changed, 395 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt create mode 100644 drivers/clk/ti/gpio.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/5] clk: ti: add "ti,gpio-gate-clock" controlled clock
The added ti,gpio-gate-clock is a basic clock that can be enabled and disabled trough a gpio output. The DT binding document for the clock is also added. For EPROBE_DEFER handling the registering of the clock has to be delayed until of_clk_get() call time. Signed-off-by: Jyri Sarha --- .../bindings/clock/ti/gpio-gate-clock.txt | 21 ++ drivers/clk/ti/Makefile|2 +- drivers/clk/ti/gpio.c | 202 3 files changed, 224 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt create mode 100644 drivers/clk/ti/gpio.c diff --git a/Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt b/Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt new file mode 100644 index 000..6156f82 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt @@ -0,0 +1,21 @@ +Binding for simple gpio controlled clock. + +This binding uses the common clock binding[1]. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : shall be "ti,gpio-gate-clock". +- #clock-cells : from common clock binding; shall be set to 0. +- enable-gpios : GPIO reference for enabling and disabling the clock. + +Optional properties: +- clocks: Maximum of one parent clock is supported. + +Example: + clock { + compatible = "ti,gpio-gate-clock"; + clocks = <&parentclk>; + #clock-cells = <0>; + enable-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>; + }; diff --git a/drivers/clk/ti/Makefile b/drivers/clk/ti/Makefile index ed4d0aa..88074d3 100644 --- a/drivers/clk/ti/Makefile +++ b/drivers/clk/ti/Makefile @@ -1,7 +1,7 @@ ifneq ($(CONFIG_OF),) obj-y += clk.o autoidle.o clockdomain.o clk-common = dpll.o composite.o divider.o gate.o \ - fixed-factor.o mux.o apll.o + fixed-factor.o mux.o apll.o gpio.o obj-$(CONFIG_SOC_AM33XX) += $(clk-common) clk-33xx.o obj-$(CONFIG_ARCH_OMAP2) += $(clk-common) interface.o clk-2xxx.o obj-$(CONFIG_ARCH_OMAP3) += $(clk-common) interface.o clk-3xxx.o diff --git a/drivers/clk/ti/gpio.c b/drivers/clk/ti/gpio.c new file mode 100644 index 000..b973801 --- /dev/null +++ b/drivers/clk/ti/gpio.c @@ -0,0 +1,202 @@ +/* + * Copyright (C) 2012 - 2014 Texas Instruments Incorporated - http://www.ti.com + * Author: Jyri Sarha + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * Gpio controlled clock implementation + */ + +#include +#include +#include +#include +#include +#include +#include + +struct clk_gpio { + struct clk_hw hw; + struct gpio_desc *gpiod; +}; + +/** + * DOC: basic gpio controlled clock which can be enabled and disabled + * with gpio output + * Traits of this clock: + * prepare - clk_(un)prepare only ensures parent is (un)prepared + * enable - clk_enable and clk_disable are functional & control gpio + * rate - inherits rate from parent. No clk_set_rate support + * parent - fixed parent. No clk_set_parent support + */ + +#define to_clk_gpio(_hw) container_of(_hw, struct clk_gpio, hw) + +static int clk_gpio_enable(struct clk_hw *hw) +{ + struct clk_gpio *clk = to_clk_gpio(hw); + + gpiod_set_value(clk->gpiod, 1); + + return 0; +} + +static void clk_gpio_disable(struct clk_hw *hw) +{ + struct clk_gpio *clk = to_clk_gpio(hw); + + gpiod_set_value(clk->gpiod, 0); +} + +static int clk_gpio_is_enabled(struct clk_hw *hw) +{ + struct clk_gpio *clk = to_clk_gpio(hw); + + return gpiod_get_value(clk->gpiod); +} + +static const struct clk_ops clk_gpio_ops = { + .enable = clk_gpio_enable, + .disable = clk_gpio_disable, + .is_enabled = clk_gpio_is_enabled, +}; + +/** + * clk_register_gpio - register a gpip clock with the clock framework + * @dev: device that is registering this clock + * @name: name of this clock + * @parent_name: name of this clock's parent + * @gpiod: gpio descriptor to control this clock + */ +static struct clk *clk_register_gpio(struct device *dev, const char *name, + const char *parent_name, struct gpio_desc *gpiod, + unsigned long flags) +{ + struct clk_gpio *clk_gpio = NULL; + struct clk *clk = ERR_PTR(-EINVAL); + struct clk_init_data init = { NULL }; + unsigned long gpio_flags; + int err; + + if (gpiod_is_active_low(gpiod)) + gpio_flags = GPIOF_OUT_INIT_HIGH; + else + gpio_flags = GPIOF_OUT_INIT_LOW; + + if (dev) + err = devm_gpio_request_one(dev, desc_to_gpio(gpiod), +
[PATCH v3 4/5] ASoC: davinci: HDMI audio build for AM33XX and TDA998x
Adds configuration option for HDMI audio support for AM33XX based boards with NXP TDA998x HDMI transmitter. The audio is connected to NXP TDA998x trough McASP running in i2s mode. Signed-off-by: Jyri Sarha --- sound/soc/davinci/Kconfig | 12 1 file changed, 12 insertions(+) diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig index d69510c..0c8f143 100644 --- a/sound/soc/davinci/Kconfig +++ b/sound/soc/davinci/Kconfig @@ -43,6 +43,18 @@ config SND_AM33XX_SOC_EVM AM335X-EVMSK, and BeagelBone with AudioCape boards have this setup. +config SND_AM335X_SOC_NXPTDA_EVM + tristate "HDMI Audio for the AM33XX chip based boards with TDA998x" + depends on SND_EDMA_SOC && SOC_AM33XX && DRM_I2C_NXP_TDA998X + select SND_SOC_HDMI_CODEC + select SND_DAVINCI_SOC_MCASP + select SND_DAVINCI_SOC_GENERIC_EVM + help + Say Y or M if you want to add support for HDMI SoC audio on + AM33XX boards with NXP TDA998x HDMI transmitter. For example + BeagleBoneBack. The audio is connected to NXP TDA998x trough + McASP running in i2s mode. + config SND_DAVINCI_SOC_EVM tristate "SoC Audio support for DaVinci DM6446, DM355 or DM365 EVM" depends on SND_DAVINCI_SOC && I2C -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/5] drm/tilcdc: Add I2S HDMI audio config for tda998x
The configuration is needed for HDMI audio. The "swap" and "mirr" parameters have to be correctly set in the configuration in order to have proper colors in the HDMI picture. Signed-off-by: Jyri Sarha --- drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 +++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c b/drivers/gpu/drm/tilcdc/tilcdc_slave.c index 3775fd4..5dd8d78 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c @@ -19,6 +19,7 @@ #include #include #include +#include #include "tilcdc_drv.h" @@ -111,8 +112,29 @@ static const struct drm_encoder_helper_funcs slave_encoder_helper_funcs = { .restore= drm_i2c_encoder_restore, }; +static struct tda998x_encoder_params tda998x_pdata = { + .swap_b = 0x3, + .mirr_b = 0x0, + .swap_a = 0x2, + .mirr_a = 0x0, + .swap_d = 0x1, + .mirr_d = 0x0, + .swap_c = 0x0, + .mirr_c = 0x0, + .swap_f = 0x5, + .mirr_f = 0x0, + .swap_e = 0x4, + .mirr_e = 0x0, + .audio_cfg = 0x3, /* I2S mode */ + .audio_clk_cfg = 1, /* select clock pin */ + .audio_frame[1] = 1,/* channels - 1 */ + .audio_format = AFMT_I2S, + .audio_sample_rate = 48000, +}; + static const struct i2c_board_info info = { - I2C_BOARD_INFO("tda998x", 0x70) + I2C_BOARD_INFO("tda998x", 0x70), + .platform_data = &tda998x_pdata, }; static struct drm_encoder *slave_encoder_create(struct drm_device *dev, -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/5] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
Add machine driver support for BeagleBone-Black HDMI audio. BBB has NXP TDA998X HDMI transmitter connected to McASP port in I2S mode. The 44100 Hz sample-rate and it's multiples can not be accurately produced on BBB. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE. The 8 least significant bits are ignored. Signed-off-by: Jyri Sarha --- .../bindings/sound/davinci-evm-audio.txt |6 +- sound/soc/davinci/davinci-evm.c| 82 +++- 2 files changed, 84 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt index 963e100..7560146 100644 --- a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt +++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt @@ -1,7 +1,9 @@ -* Texas Instruments SoC audio setups with TLV320AIC3X Codec +* TI SoC audio using McASP to connect to TLV320AIC3X or HDMI endcoder Required properties: -- compatible : "ti,da830-evm-audio" : forDM365/DA8xx/OMAPL1x/AM33xx +- compatible: should contain one of: +* "ti,da830-evm-audio" for DM365/DA8xx/OMAPL1x/AM33xx with TLV320AIC3X +* "ti,beaglebone-black-audio" for Beaglebone-black HDMI audio - ti,model : The user-visible name of this sound complex. - ti,audio-codec : The phandle of the TLV320AIC3x audio codec - ti,mcasp-controller : The phandle of the McASP controller diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c index a50010e..3d0acba2a 100644 --- a/sound/soc/davinci/davinci-evm.c +++ b/sound/soc/davinci/davinci-evm.c @@ -21,6 +21,7 @@ #include #include #include +#include #include #include @@ -83,12 +84,46 @@ static int evm_hw_params(struct snd_pcm_substream *substream, return 0; } +/* If changing sample format the tda998x configuration (REG_CTS_N) needs + to be changed. */ +#define TDA998X_SAMPLE_FORMAT SNDRV_PCM_FORMAT_S32_LE +static int evm_tda998x_startup(struct snd_pcm_substream *substream) +{ + struct snd_pcm_runtime *runtime = substream->runtime; + struct snd_mask *fmt = constrs_mask(&runtime->hw_constraints, + SNDRV_PCM_HW_PARAM_FORMAT); + snd_mask_none(fmt); + snd_mask_set(fmt, TDA998X_SAMPLE_FORMAT); + + return evm_startup(substream); +} + +static int evm_tda998x_hw_params(struct snd_pcm_substream *substream, +struct snd_pcm_hw_params *params) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct snd_soc_dai *cpu_dai = rtd->cpu_dai; + struct snd_soc_card *soc_card = rtd->card; + struct snd_soc_card_drvdata_davinci *drvdata = + snd_soc_card_get_drvdata(soc_card); + + return snd_soc_dai_set_sysclk(cpu_dai, 0, drvdata->sysclk, + SND_SOC_CLOCK_IN); +} + static struct snd_soc_ops evm_ops = { .startup = evm_startup, .shutdown = evm_shutdown, .hw_params = evm_hw_params, }; + +static struct snd_soc_ops evm_tda998x_ops = { + .startup = evm_tda998x_startup, + .shutdown = evm_shutdown, + .hw_params = evm_tda998x_hw_params, +}; + /* davinci-evm machine dapm widgets */ static const struct snd_soc_dapm_widget aic3x_dapm_widgets[] = { SND_SOC_DAPM_HP("Headphone Jack", NULL), @@ -149,6 +184,35 @@ static int evm_aic3x_init(struct snd_soc_pcm_runtime *rtd) return 0; } +static const struct snd_soc_dapm_widget tda998x_dapm_widgets[] = { + SND_SOC_DAPM_OUTPUT("HDMI Out"), +}; + +static int evm_tda998x_init(struct snd_soc_pcm_runtime *rtd) +{ + struct snd_soc_dai *cpu_dai = rtd->cpu_dai; + struct snd_soc_dapm_context *dapm = &rtd->codec->dapm; + struct snd_soc_card *soc_card = rtd->card; + int ret; + + ret = snd_soc_dai_set_clkdiv(cpu_dai, 0, 1); + if (ret < 0) + return ret; + + snd_soc_dapm_new_controls(dapm, tda998x_dapm_widgets, + ARRAY_SIZE(tda998x_dapm_widgets)); + + ret = snd_soc_of_parse_audio_routing(soc_card, "ti,audio-routing"); + + /* not connected */ + snd_soc_dapm_disable_pin(dapm, "RX"); + + /* always connected */ + snd_soc_dapm_enable_pin(dapm, "HDMI Out"); + + return 0; +} + /* davinci-evm digital audio interface glue - connects codec <--> CPU */ static struct snd_soc_dai_link dm6446_evm_dai = { .name = "TLV320AIC3X", @@ -334,7 +398,7 @@ static struct snd_soc_card da850_snd_soc_card = { #if defined(CONFIG_OF) /* - * The struct is used as place holder. It will be completely + * The structs are used as place holders. They will be completely * filled with data from dt node. */ static struct snd_soc_dai_link evm_dai_tlv320aic3x = { @@ -347,10 +411,24 @@ static struct snd_soc_dai_link evm_dai_tlv320aic3x = { SND_SOC_DAIFMT_IB_NF, }; +static struct sn
Re: [PATCH] arm: omap2: n8x0: move i2c devices to DT
On Tue, Sep 16, 2014 at 03:31:40PM -0500, Felipe Balbi wrote: > By moving i2c devices to DT we can clean up > i2c_board_info and fix a problem with moving > INTC to irq domain where IRQs can be renumbered > on each boot. > > Cc: Aaro Koskinen > Signed-off-by: Felipe Balbi note that this only causes problem for N8x0 because it boots in kinda of a hybrid way, where it uses DT but not all peripherals are created through DT. > --- > arch/arm/boot/dts/omap2420-n810.dts | 7 +++ > arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 6 ++ > arch/arm/mach-omap2/board-n8x0.c| 26 +++--- > arch/arm/mach-omap2/common-board-devices.h | 5 + > arch/arm/mach-omap2/pdata-quirks.c | 2 ++ > 5 files changed, 23 insertions(+), 23 deletions(-) > > diff --git a/arch/arm/boot/dts/omap2420-n810.dts > b/arch/arm/boot/dts/omap2420-n810.dts > index 21baec1..b604d26 100644 > --- a/arch/arm/boot/dts/omap2420-n810.dts > +++ b/arch/arm/boot/dts/omap2420-n810.dts > @@ -6,3 +6,10 @@ > model = "Nokia N810"; > compatible = "nokia,n810", "nokia,n8x0", "ti,omap2420", "ti,omap2"; > }; > + > +&i2c2 { > + aic3x@18 { > + compatible = "tlv320aic3x"; > + reg = <0x18>; > + }; > +}; > diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi > b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi > index 89608b2..24c50db 100644 > --- a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi > +++ b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi > @@ -27,6 +27,12 @@ > > &i2c1 { > clock-frequency = <40>; > + > + pmic@72 { > + compatible = "menelaus"; > + reg = <0x72>; > + interrupts = <7 IRQ_TYPE_EDGE_RISING>; > + }; > }; > > &i2c2 { > diff --git a/arch/arm/mach-omap2/board-n8x0.c > b/arch/arm/mach-omap2/board-n8x0.c > index aead77a..97767a2 100644 > --- a/arch/arm/mach-omap2/board-n8x0.c > +++ b/arch/arm/mach-omap2/board-n8x0.c > @@ -33,6 +33,7 @@ > #include "mmc.h" > #include "soc.h" > #include "gpmc-onenand.h" > +#include "common-board-devices.h" > > #define TUSB6010_ASYNC_CS1 > #define TUSB6010_SYNC_CS 4 > @@ -568,29 +569,14 @@ static int n8x0_menelaus_late_init(struct device *dev) > } > #endif > > -static struct menelaus_platform_data n8x0_menelaus_platform_data __initdata > = { > +struct menelaus_platform_data n8x0_menelaus_platform_data __initdata = { > .late_init = n8x0_menelaus_late_init, > }; > > -static struct i2c_board_info __initdata n8x0_i2c_board_info_1[] __initdata = > { > - { > - I2C_BOARD_INFO("menelaus", 0x72), > - .irq = 7 + OMAP_INTC_START, > - .platform_data = &n8x0_menelaus_platform_data, > - }, > -}; > - > -static struct aic3x_pdata n810_aic33_data __initdata = { > +struct aic3x_pdata n810_aic33_data __initdata = { > .gpio_reset = 118, > }; > > -static struct i2c_board_info n810_i2c_board_info_2[] __initdata = { > - { > - I2C_BOARD_INFO("tlv320aic3x", 0x18), > - .platform_data = &n810_aic33_data, > - }, > -}; > - > static int __init n8x0_late_initcall(void) > { > if (!board_caps) > @@ -612,11 +598,5 @@ void * __init n8x0_legacy_init(void) > board_check_revision(); > spi_register_board_info(n800_spi_board_info, > ARRAY_SIZE(n800_spi_board_info)); > - i2c_register_board_info(0, n8x0_i2c_board_info_1, > - ARRAY_SIZE(n8x0_i2c_board_info_1)); > - if (board_is_n810()) > - i2c_register_board_info(1, n810_i2c_board_info_2, > - ARRAY_SIZE(n810_i2c_board_info_2)); > - > return &mmc1_data; > } > diff --git a/arch/arm/mach-omap2/common-board-devices.h > b/arch/arm/mach-omap2/common-board-devices.h > index f338177..07c88ae 100644 > --- a/arch/arm/mach-omap2/common-board-devices.h > +++ b/arch/arm/mach-omap2/common-board-devices.h > @@ -1,6 +1,8 @@ > #ifndef __OMAP_COMMON_BOARD_DEVICES__ > #define __OMAP_COMMON_BOARD_DEVICES__ > > +#include > +#include > #include "twl-common.h" > > #define NAND_BLOCK_SIZE SZ_128K > @@ -12,4 +14,7 @@ void omap_ads7846_init(int bus_num, int gpio_pendown, int > gpio_debounce, > struct ads7846_platform_data *board_pdata); > void *n8x0_legacy_init(void); > > +extern struct menelaus_platform_data n8x0_menelaus_platform_data; > +extern struct aic3x_pdata n810_aic33_data; > + > #endif /* __OMAP_COMMON_BOARD_DEVICES__ */ > diff --git a/arch/arm/mach-omap2/pdata-quirks.c > b/arch/arm/mach-omap2/pdata-quirks.c > index 8695fd4..06a0ccf 100644 > --- a/arch/arm/mach-omap2/pdata-quirks.c > +++ b/arch/arm/mach-omap2/pdata-quirks.c > @@ -336,6 +336,8 @@ static struct pdata_init auxdata_quirks[] __initdata = { > struct of_dev_auxdata omap_auxdata_lookup[] __initdata = { > #ifdef CONFIG_MACH_NOKIA_N8X0 > OF_DEV_AUXDATA("ti,omap2420-mmc", 0x4809c000, "mmci-omap.0", NULL), > +
[PATCH] arm: omap2: n8x0: move i2c devices to DT
By moving i2c devices to DT we can clean up i2c_board_info and fix a problem with moving INTC to irq domain where IRQs can be renumbered on each boot. Cc: Aaro Koskinen Signed-off-by: Felipe Balbi --- arch/arm/boot/dts/omap2420-n810.dts | 7 +++ arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 6 ++ arch/arm/mach-omap2/board-n8x0.c| 26 +++--- arch/arm/mach-omap2/common-board-devices.h | 5 + arch/arm/mach-omap2/pdata-quirks.c | 2 ++ 5 files changed, 23 insertions(+), 23 deletions(-) diff --git a/arch/arm/boot/dts/omap2420-n810.dts b/arch/arm/boot/dts/omap2420-n810.dts index 21baec1..b604d26 100644 --- a/arch/arm/boot/dts/omap2420-n810.dts +++ b/arch/arm/boot/dts/omap2420-n810.dts @@ -6,3 +6,10 @@ model = "Nokia N810"; compatible = "nokia,n810", "nokia,n8x0", "ti,omap2420", "ti,omap2"; }; + +&i2c2 { + aic3x@18 { + compatible = "tlv320aic3x"; + reg = <0x18>; + }; +}; diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi index 89608b2..24c50db 100644 --- a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi +++ b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi @@ -27,6 +27,12 @@ &i2c1 { clock-frequency = <40>; + + pmic@72 { + compatible = "menelaus"; + reg = <0x72>; + interrupts = <7 IRQ_TYPE_EDGE_RISING>; + }; }; &i2c2 { diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c index aead77a..97767a2 100644 --- a/arch/arm/mach-omap2/board-n8x0.c +++ b/arch/arm/mach-omap2/board-n8x0.c @@ -33,6 +33,7 @@ #include "mmc.h" #include "soc.h" #include "gpmc-onenand.h" +#include "common-board-devices.h" #define TUSB6010_ASYNC_CS 1 #define TUSB6010_SYNC_CS 4 @@ -568,29 +569,14 @@ static int n8x0_menelaus_late_init(struct device *dev) } #endif -static struct menelaus_platform_data n8x0_menelaus_platform_data __initdata = { +struct menelaus_platform_data n8x0_menelaus_platform_data __initdata = { .late_init = n8x0_menelaus_late_init, }; -static struct i2c_board_info __initdata n8x0_i2c_board_info_1[] __initdata = { - { - I2C_BOARD_INFO("menelaus", 0x72), - .irq = 7 + OMAP_INTC_START, - .platform_data = &n8x0_menelaus_platform_data, - }, -}; - -static struct aic3x_pdata n810_aic33_data __initdata = { +struct aic3x_pdata n810_aic33_data __initdata = { .gpio_reset = 118, }; -static struct i2c_board_info n810_i2c_board_info_2[] __initdata = { - { - I2C_BOARD_INFO("tlv320aic3x", 0x18), - .platform_data = &n810_aic33_data, - }, -}; - static int __init n8x0_late_initcall(void) { if (!board_caps) @@ -612,11 +598,5 @@ void * __init n8x0_legacy_init(void) board_check_revision(); spi_register_board_info(n800_spi_board_info, ARRAY_SIZE(n800_spi_board_info)); - i2c_register_board_info(0, n8x0_i2c_board_info_1, - ARRAY_SIZE(n8x0_i2c_board_info_1)); - if (board_is_n810()) - i2c_register_board_info(1, n810_i2c_board_info_2, - ARRAY_SIZE(n810_i2c_board_info_2)); - return &mmc1_data; } diff --git a/arch/arm/mach-omap2/common-board-devices.h b/arch/arm/mach-omap2/common-board-devices.h index f338177..07c88ae 100644 --- a/arch/arm/mach-omap2/common-board-devices.h +++ b/arch/arm/mach-omap2/common-board-devices.h @@ -1,6 +1,8 @@ #ifndef __OMAP_COMMON_BOARD_DEVICES__ #define __OMAP_COMMON_BOARD_DEVICES__ +#include +#include #include "twl-common.h" #define NAND_BLOCK_SIZESZ_128K @@ -12,4 +14,7 @@ void omap_ads7846_init(int bus_num, int gpio_pendown, int gpio_debounce, struct ads7846_platform_data *board_pdata); void *n8x0_legacy_init(void); +extern struct menelaus_platform_data n8x0_menelaus_platform_data; +extern struct aic3x_pdata n810_aic33_data; + #endif /* __OMAP_COMMON_BOARD_DEVICES__ */ diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c index 8695fd4..06a0ccf 100644 --- a/arch/arm/mach-omap2/pdata-quirks.c +++ b/arch/arm/mach-omap2/pdata-quirks.c @@ -336,6 +336,8 @@ static struct pdata_init auxdata_quirks[] __initdata = { struct of_dev_auxdata omap_auxdata_lookup[] __initdata = { #ifdef CONFIG_MACH_NOKIA_N8X0 OF_DEV_AUXDATA("ti,omap2420-mmc", 0x4809c000, "mmci-omap.0", NULL), + OF_DEV_AUXDATA("menelaus", 0x72, "1-0072", &n8x0_menelaus_platform_data), + OF_DEV_AUXDATA("tlv320aic3x", 0x18, "2-0018", &n810_aic33_data), #endif #ifdef CONFIG_ARCH_OMAP3 OF_DEV_AUXDATA("ti,omap3-padconf", 0x48002030, "48002030.pinmux", &pcs_pdata), -- 2.0.1.563.g66f467c -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.or
[PATCHv2 1/2] remoteproc: use a flag to detect the presence of IOMMU
The remoteproc driver core currently relies on iommu_present() on the bus the device is on, to perform MMU management. However, this logic doesn't scale for multi-arch, especially for processors that do not have an IOMMU. Replace this logic instead by using a h/w capability flag for the presence of IOMMU in the rproc structure. This issue is seen on OMAP platforms when trying to add a remoteproc driver for a small Cortex M3 called the WkupM3 used for suspend / resume management on TI AM335/AM437x SoCs. This processor does not have an MMU. Same is the case with another processor subsystem PRU-ICSS on AM335/AM437x. All these are platform devices, and the current iommu_present check will not scale for the same kernel image to support OMAP4/OMAP5 and AM335/AM437x. The existing platform implementation drivers - OMAP remoteproc, STE Modem remoteproc and DA8xx remoteproc, are updated as well to properly configure the newly added rproc field. Cc: Robert Tivy Cc: Linus Walleij Signed-off-by: Suman Anna --- v2: - set the field explicitly in all existing remoteproc platform drivers - update patch description drivers/remoteproc/da8xx_remoteproc.c | 1 + drivers/remoteproc/omap_remoteproc.c | 5 + drivers/remoteproc/remoteproc_core.c | 15 ++- drivers/remoteproc/ste_modem_rproc.c | 1 + include/linux/remoteproc.h| 2 ++ 5 files changed, 11 insertions(+), 13 deletions(-) diff --git a/drivers/remoteproc/da8xx_remoteproc.c b/drivers/remoteproc/da8xx_remoteproc.c index 3841b98..9fdc0af 100644 --- a/drivers/remoteproc/da8xx_remoteproc.c +++ b/drivers/remoteproc/da8xx_remoteproc.c @@ -224,6 +224,7 @@ static int da8xx_rproc_probe(struct platform_device *pdev) drproc = rproc->priv; drproc->rproc = rproc; + rproc->has_iommu = false; platform_set_drvdata(pdev, rproc); diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c index 5168972..b21ce95 100644 --- a/drivers/remoteproc/omap_remoteproc.c +++ b/drivers/remoteproc/omap_remoteproc.c @@ -199,6 +199,11 @@ static int omap_rproc_probe(struct platform_device *pdev) oproc = rproc->priv; oproc->rproc = rproc; + /* +* All existing OMAP IPU and DSP processors do have an MMU, and +* are expected to use MMU, so this statement suffices. +*/ + rproc->has_iommu = true; platform_set_drvdata(pdev, rproc); diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c index 3cd85a6..11cdb11 100644 --- a/drivers/remoteproc/remoteproc_core.c +++ b/drivers/remoteproc/remoteproc_core.c @@ -94,19 +94,8 @@ static int rproc_enable_iommu(struct rproc *rproc) struct device *dev = rproc->dev.parent; int ret; - /* -* We currently use iommu_present() to decide if an IOMMU -* setup is needed. -* -* This works for simple cases, but will easily fail with -* platforms that do have an IOMMU, but not for this specific -* rproc. -* -* This will be easily solved by introducing hw capabilities -* that will be set by the remoteproc driver. -*/ - if (!iommu_present(dev->bus)) { - dev_dbg(dev, "iommu not found\n"); + if (!rproc->has_iommu) { + dev_dbg(dev, "iommu not present\n"); return 0; } diff --git a/drivers/remoteproc/ste_modem_rproc.c b/drivers/remoteproc/ste_modem_rproc.c index c4ac910..c42a32e 100644 --- a/drivers/remoteproc/ste_modem_rproc.c +++ b/drivers/remoteproc/ste_modem_rproc.c @@ -289,6 +289,7 @@ static int sproc_probe(struct platform_device *pdev) sproc = rproc->priv; sproc->mdev = mdev; sproc->rproc = rproc; + rproc->has_iommu = false; mdev->drv_data = sproc; /* Provide callback functions to modem device */ diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h index 9e7e745..78b8a9b 100644 --- a/include/linux/remoteproc.h +++ b/include/linux/remoteproc.h @@ -404,6 +404,7 @@ enum rproc_crash_type { * @table_ptr: pointer to the resource table in effect * @cached_table: copy of the resource table * @table_csum: checksum of the resource table + * @has_iommu: flag to indicate if remote processor is behind an MMU */ struct rproc { struct klist_node node; @@ -435,6 +436,7 @@ struct rproc { struct resource_table *table_ptr; struct resource_table *cached_table; u32 table_csum; + bool has_iommu; }; /* we currently support only two vrings per rvdev */ -- 2.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
[PATCHv2 2/2] remoteproc: add support to handle internal memories
A remote processor may need to load certain firmware sections into internal memories (eg: RAM at L1 or L2 levels) for performance or other reasons. Introduce a new resource type (RSC_INTMEM) and add an associated handler function to handle such memories. The handler creates a kernel mapping for the resource's 'pa' (physical address). Note that no iommu mapping is performed for this resource, as the resource is primarily used to represent physical internal memories. If the internal memory region can only be accessed through an iommu, a devmem resource entry should be used instead. Signed-off-by: Robert Tivy Signed-off-by: Suman Anna --- v2: - fixed a minor checkpatch warning drivers/remoteproc/remoteproc_core.c | 83 +++- include/linux/remoteproc.h | 43 ++- 2 files changed, 124 insertions(+), 2 deletions(-) diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c index 11cdb11..1d668e5 100644 --- a/drivers/remoteproc/remoteproc_core.c +++ b/drivers/remoteproc/remoteproc_core.c @@ -664,6 +664,82 @@ free_carv: return ret; } +/** + * rproc_handle_intmem() - handle internal memory resource entry + * @rproc: rproc handle + * @rsc: the intmem resource entry + * @offset: offset of the resource data in resource table + * @avail: size of available data (for image validation) + * + * This function will handle firmware requests for mapping a memory region + * internal to a remote processor into kernel. It neither allocates any + * physical pages, nor performs any iommu mapping, as this resource entry + * is primarily used for representing physical internal memories. If the + * internal memory region can only be accessed through an iommu, please + * use a devmem resource entry. + * + * These resource entries should be grouped near the carveout entries in + * the firmware's resource table, as other firmware entries might request + * placing other data objects inside these memory regions (e.g. data/code + * segments, trace resource entries, ...). + */ +static int rproc_handle_intmem(struct rproc *rproc, struct fw_rsc_intmem *rsc, + int offset, int avail) +{ + struct rproc_mem_entry *intmem; + struct device *dev = &rproc->dev; + void *va; + int ret; + + if (sizeof(*rsc) > avail) { + dev_err(dev, "intmem rsc is truncated\n"); + return -EINVAL; + } + + if (rsc->version != 1) { + dev_err(dev, "intmem rsc version %d is not supported\n", + rsc->version); + return -EINVAL; + } + + if (rsc->reserved) { + dev_err(dev, "intmem rsc has non zero reserved bytes\n"); + return -EINVAL; + } + + dev_dbg(dev, "intmem rsc: da 0x%x, pa 0x%x, len 0x%x\n", + rsc->da, rsc->pa, rsc->len); + + intmem = kzalloc(sizeof(*intmem), GFP_KERNEL); + if (!intmem) + return -ENOMEM; + + va = (__force void *)ioremap_nocache(rsc->pa, rsc->len); + if (!va) { + dev_err(dev, "ioremap_nocache err: %d\n", rsc->len); + ret = -ENOMEM; + goto free_intmem; + } + + dev_dbg(dev, "intmem mapped pa 0x%x of len 0x%x into kernel va %p\n", + rsc->pa, rsc->len, va); + + intmem->va = va; + intmem->len = rsc->len; + intmem->dma = rsc->pa; + intmem->da = rsc->da; + intmem->priv = (void *)1;/* prevents freeing */ + + /* reuse the rproc->carveouts list, so that loading is automatic */ + list_add_tail(&intmem->node, &rproc->carveouts); + + return 0; + +free_intmem: + kfree(intmem); + return ret; +} + static int rproc_count_vrings(struct rproc *rproc, struct fw_rsc_vdev *rsc, int offset, int avail) { @@ -681,6 +757,7 @@ static rproc_handle_resource_t rproc_loading_handlers[RSC_LAST] = { [RSC_CARVEOUT] = (rproc_handle_resource_t)rproc_handle_carveout, [RSC_DEVMEM] = (rproc_handle_resource_t)rproc_handle_devmem, [RSC_TRACE] = (rproc_handle_resource_t)rproc_handle_trace, + [RSC_INTMEM] = (rproc_handle_resource_t)rproc_handle_intmem, [RSC_VDEV] = NULL, /* VDEVs were handled upon registrarion */ }; @@ -768,7 +845,11 @@ static void rproc_resource_cleanup(struct rproc *rproc) /* clean up carveout allocations */ list_for_each_entry_safe(entry, tmp, &rproc->carveouts, node) { - dma_free_coherent(dev->parent, entry->len, entry->va, entry->dma); + if (!entry->priv) + dma_free_coherent(dev->parent, entry->len, entry->va, + entry->dma); + else + iounmap((__force void __iomem *)entry->va); list_del(&entry->node); kfree(entry); } diff --git a/include/linux/
[PATCHv2 0/2] couple of generic remoteproc enhancements
Hi Ohad, The following is an updated patchset addressing the review comments on v1. The patches are mainly developed to support the WkupM3 remote processor driver on TI AM335x/AM437x SoCs. The patches are rebased onto 3.17-rc3 (rc independent actually). I haven't made any major updates to Patch2 with respect to the ioremap vs defining a CMA region, as the latter is irrelevant for mapping these internal RAMs. Following are the main changes in v2: - Add explicit setting of the .has_iommu field in each of the existing remoteproc platform drivers (Patch 1) - Update patch description to add the usecase details for the change summary (Patch1) - Fixed a minor checkpatch warning (Patch 2). regards Suman v1: http://marc.info/?l=linux-omap&m=140483657604924&w=2 Suman Anna (2): remoteproc: use a flag to detect the presence of IOMMU remoteproc: add support to handle internal memories drivers/remoteproc/da8xx_remoteproc.c | 1 + drivers/remoteproc/omap_remoteproc.c | 5 ++ drivers/remoteproc/remoteproc_core.c | 98 ++- drivers/remoteproc/ste_modem_rproc.c | 1 + include/linux/remoteproc.h| 45 +++- 5 files changed, 135 insertions(+), 15 deletions(-) -- 2.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 v3 2/2] dmaengine: omap-dma: Restore the CLINK_CTRL in resume path
When the audio stream is paused or suspended we stop the sDMA and when it is unpaused/resumed we start the channel without reconfiguring it. The omap_dma_stop() clears the link configuration when we pause the dma, but it is not setting it back on start. This will result only one audio buffer to be played back and the DMA will stop, since the linking is disabled. We need to restore the CLINK_CTRL register in case of resume. Signed-off-by: Peter Ujfalusi Acked-by: Russell King --- drivers/dma/omap-dma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c index c01ea505ee7c..bbea8243f9e8 100644 --- a/drivers/dma/omap-dma.c +++ b/drivers/dma/omap-dma.c @@ -1019,6 +1019,9 @@ static int omap_dma_resume(struct omap_chan *c) if (c->paused) { mb(); + /* Restore channel link register */ + omap_dma_chan_write(c, CLNK_CTRL, c->desc->clnk_ctrl); + omap_dma_start(c, c->desc); c->paused = false; } -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/2] dmaengine: omap-dma: Fix cyclic suspend/resume
Hi, Changes since v2: - fix typo in patch two - Acked-by added from Russell When the audio is paused/resumed (application paused the sream or board suspend) the audio was only playing back one period worth of data and then stops because the omap_dam_stop() clears the link configuration and it is not restored in start. Also add memory barrier call to resume path since this could happen right after coming out from suspend. Regards, Peter --- Peter Ujfalusi (2): dmaengine: omap-dma: Add memory barrier to dma_resume path dmaengine: omap-dma: Restore the CLINK_CTRL in resume path drivers/dma/omap-dma.c | 5 + 1 file changed, 5 insertions(+) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] dmaengine: omap-dma: Add memory barrier to dma_resume path
Add mb() call to resume path to ensure the necessary barrier. Resume can happen after waking up from suspend for example. Signed-off-by: Peter Ujfalusi Acked-by: Russell King --- drivers/dma/omap-dma.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c index 4cf7d9a950d7..c01ea505ee7c 100644 --- a/drivers/dma/omap-dma.c +++ b/drivers/dma/omap-dma.c @@ -1017,6 +1017,8 @@ static int omap_dma_resume(struct omap_chan *c) return -EINVAL; if (c->paused) { + mb(); + omap_dma_start(c, c->desc); c->paused = false; } -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] rpmsg: compute number of buffers to allocate from vrings
The buffers to be used for communication are allocated during the rpmsg virtio driver's probe, and the total number of buffers is currently hard-coded to 512. The vring configuration can vary from one platform to another or between different remote processors. The setup of the receive buffers will throw a WARN_ON if the associated vrings are configured with less than 256 buffers (in each direction). So, adjust this hard-coded value to rely on the number of buffers the virtqueue vring is setup with, but also limit to use 256 buffers at most in each direction to avoid wacky resource tables consuming up unreasonable memory. NOTE: The number of buffers is already assumed to be symmetrical in each direction, and that logic is not unchanged. Signed-off-by: Suman Anna --- v2 changes: - add upper limit on buffers and update comments - revise patch description drivers/rpmsg/virtio_rpmsg_bus.c | 46 1 file changed, 32 insertions(+), 14 deletions(-) diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c index b6135d4..9ea6c43 100644 --- a/drivers/rpmsg/virtio_rpmsg_bus.c +++ b/drivers/rpmsg/virtio_rpmsg_bus.c @@ -41,6 +41,7 @@ * @svq: tx virtqueue * @rbufs: kernel address of rx buffers * @sbufs: kernel address of tx buffers + * @num_bufs: total number of buffers for rx and tx * @last_sbuf: index of last tx buffer used * @bufs_dma: dma base addr of the buffers * @tx_lock: protects svq, sbufs and sleepers, to allow concurrent senders. @@ -60,6 +61,7 @@ struct virtproc_info { struct virtio_device *vdev; struct virtqueue *rvq, *svq; void *rbufs, *sbufs; + unsigned int num_bufs; int last_sbuf; dma_addr_t bufs_dma; struct mutex tx_lock; @@ -86,13 +88,14 @@ struct rpmsg_channel_info { #define to_rpmsg_driver(d) container_of(d, struct rpmsg_driver, drv) /* - * We're allocating 512 buffers of 512 bytes for communications, and then - * using the first 256 buffers for RX, and the last 256 buffers for TX. + * We're allocating buffers of 512 bytes each for communications. The + * number of buffers are computed from the number of buffers supported by + * the virtqueue vring (upto a maximum of 256 buffers in each direction). * * Each buffer will have 16 bytes for the msg header and 496 bytes for * the payload. * - * This will require a total space of 256KB for the buffers. + * This will utilize a maximum total space of 256KB for the buffers. * * We might also want to add support for user-provided buffers in time. * This will allow bigger buffer size flexibility, and can also be used @@ -102,9 +105,8 @@ struct rpmsg_channel_info { * can change this without changing anything in the firmware of the remote * processor. */ -#define RPMSG_NUM_BUFS (512) +#define MAX_RPMSG_NUM_BUFS (256) #define RPMSG_BUF_SIZE (512) -#define RPMSG_TOTAL_BUF_SPACE (RPMSG_NUM_BUFS * RPMSG_BUF_SIZE) /* * Local addresses are dynamically allocated on-demand. @@ -579,7 +581,7 @@ static void *get_a_tx_buf(struct virtproc_info *vrp) * either pick the next unused tx buffer * (half of our buffers are used for sending messages) */ - if (vrp->last_sbuf < RPMSG_NUM_BUFS / 2) + if (vrp->last_sbuf < vrp->num_bufs / 2) ret = vrp->sbufs + RPMSG_BUF_SIZE * vrp->last_sbuf++; /* or recycle a used one */ else @@ -948,6 +950,7 @@ static int rpmsg_probe(struct virtio_device *vdev) struct virtproc_info *vrp; void *bufs_va; int err = 0, i; + size_t total_buf_space; vrp = kzalloc(sizeof(*vrp), GFP_KERNEL); if (!vrp) @@ -968,10 +971,24 @@ static int rpmsg_probe(struct virtio_device *vdev) vrp->rvq = vqs[0]; vrp->svq = vqs[1]; + vrp->num_bufs = MAX_RPMSG_NUM_BUFS * 2; + if (virtqueue_get_vring_size(vrp->rvq) < MAX_RPMSG_NUM_BUFS) { + /* +* Override if the virtqueues are configured with less number of +* buffers. We expect equal number of buffers for each direction +* as per current code, so throw a warning if the configuration +* doesn't match. +*/ + vrp->num_bufs = virtqueue_get_vring_size(vrp->rvq) * 2; + WARN_ON(virtqueue_get_vring_size(vrp->svq) != + (vrp->num_bufs / 2)); + } + total_buf_space = vrp->num_bufs * RPMSG_BUF_SIZE; + /* allocate coherent memory for the buffers */ bufs_va = dma_alloc_coherent(vdev->dev.parent->parent, - RPMSG_TOTAL_BUF_SPACE, - &vrp->bufs_dma, GFP_KERNEL); +total_buf_space, &vrp->bufs_dma, +GFP_KERNEL); if (!bufs_va) { err = -ENOMEM; goto vqs_del; @@ -984,10 +1001
Re: [PATCH 02/12] ARM: OMAP3: Use force-idle for UARTs because of DMA errata
* Paul Walmsley [140916 10:01]: > On Mon, 15 Sep 2014, Tony Lindgren wrote: > > > In sprz318f.pdf "Usage Note 2.7" says that UARTs cannot acknowledge > > idle requests in smartidle mode when configured for DMA operations. > > I don't have Rev. F here. But reading between the typos in Rev. E, all it > says that the UART should be placed into force-idle mode when there are no > DMA transfers scheduled, otherwise CORE won't go idle. However, this > patch does a lot more than that... OK. The errata above seems to have a bit more info on that. > > @@ -490,7 +490,9 @@ static struct omap_hwmod omap3xxx_uart1_hwmod = { > > .mpu_irqs = omap2_uart1_mpu_irqs, > > .sdma_reqs = omap2_uart1_sdma_reqs, > > .main_clk = "uart1_fck", > > - .flags = DEBUG_TI81XXUART1_FLAGS | HWMOD_SWSUP_SIDLE_ACT, > > + .flags = DEBUG_TI81XXUART1_FLAGS | > > + HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE | > > + HWMOD_FORCE_MSTANDBY | HWMOD_RECONFIG_IO_CHAIN, > > ... this patch makes four significant changes to the hwmod flags: > > 1. It changes HWMOD_SWSUP_SIDLE_ACT to HWMOD_SWSUP_SIDLE > > 2. It adds HWMOD_NO_OCP_AUTOIDLE > > 3. It adds HWMOD_FORCE_MSTANDBY > > 4. It adds HWMOD_RECONFIG_IO_CHAIN > > As far as I can tell, the only change that actually matches the erratum > usage note is #1. And even that should only be activated when the UART is > in DMA mode.. PIO mode shouldn't need it. (We used to have a DMA-specific > workaround in the driver code for this years ago, which was only enabled > when DMA was used, but it got ripped out in the rush to get rid of the > platform_data function pointers.) Indeed that's the case. Only #1 above is needed. It seems I intially just blindly copied the MUSB related changes for UART to get Sebastian's series going with DMA, then just rebased those changes blindly on the HWMOD_RECONFIG_IO_CHAIN patch. For toggling the DMA vs PIO mode, that should be done with some Linux generic API from the driver. But since we don't have that, I don't think there's much overhead for always configuring for DMA mode. Or do you see some issues with that? > So that leaves the other three flag changes. Of those three, adding > HWMOD_FORCE_MSTANDBY is definitely not correct according to the 34xx > public TRM Rev. ZV, since the UART IP blocks: > > a) have no master port, > > b) do not contain DMA controllers (they rely on the SDMA), and > > c) according to the SYSC_REG register documentation in Table 17-112 of the > above TRM, have no MIDLEMODE bit field. > > So adding HWMOD_FORCE_MSTANDBY should have zero effect and it most likely > should be dropped. OK. That's left over from blind copy-paste from MUSB related changes and not needed. > Regarding the rest: > > I'd be pretty surprised if HWMOD_RECONFIG_IO_CHAIN is needed. If that was > needed, I'd think we would have seen wakeup failures in this path a long > time ago, since the console serial port is the primary debug tool we used > for waking the chip up from deep idle states on demand. OK. Does not seem to be needed. > As far as HWMOD_NO_OCP_AUTOIDLE goes: does adding this flag have an effect > when HWMOD_SWSUP_SIDLE is used? If so then this should probably go in as > a separate patch, because it's probably a separate bug than the one > described in the commit message. That does not seem to be needed either. > So I'd suggest restricting this patch to simply change > HWMOD_SWSUP_SIDLE_ACT to HWMOD_SWSUP_SIDLE. Then if the other flags are > needed, would suggest adding them in separate patches, describing what > problems are fixed by adding them. Yes great. I've verified that's enough to make it work properly with off-idle and dma when tested against Sebastian's uart_v10_pre1 branch. Updated patch below, thanks for catching the bogus configuration. Regards, Tony 8< -- From: Tony Lindgren Date: Wed, 10 Sep 2014 16:22:31 -0700 Subject: [PATCH] ARM: OMAP3: Use manual idle for UARTs because of DMA errata In sprz318f.pdf "Usage Note 2.7" says that UARTs cannot acknowledge idle requests in smartidle mode when configured for DMA operations. This prevents L4 from going idle. So let's use manual idle mode instead. Otherwise systems using Sebastian's 8250 patches with DMA will never enter deeper idle states because of the errata above. Cc: Paul Walmsley Cc: Sebastian Andrzej Siewior Signed-off-by: Tony Lindgren --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c @@ -490,7 +490,7 @@ static struct omap_hwmod omap3xxx_uart1_hwmod = { .mpu_irqs = omap2_uart1_mpu_irqs, .sdma_reqs = omap2_uart1_sdma_reqs, .main_clk = "uart1_fck", - .flags = DEBUG_TI81XXUART1_FLAGS | HWMOD_SWSUP_SIDLE_ACT, + .flags = DEBUG_TI81XXUART1_FLAGS | HWMOD_SWSUP_SIDLE, .prcm = { .oma
OMAP baseline test results for v3.17-rc5
Here are some basic OMAP test results for Linux v3.17-rc5. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.17-rc5/20140916100200/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Boot to userspace: FAIL ( 2/17): 2430sdp, 5430es2sbct54 skip ( 1/17): 5912osk Pass (14/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3517evm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 8/12): am335xbonelt, 4430es2panda, 4460pandaes, 4460varsomom, 3530es3beagle, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 4/12): 37xxevm, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 1/ 4): 3530es3beagle Pass ( 3/ 4): 37xxevm, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 3530es3beagle Pass ( 3/ 4): 37xxevm, 3530es31beagle, 3730es12beaglexm vmlinux object size (delta in bytes from test_v3.17-rc4 (2ce7598c9a453e0acd0e07be7be3f5eb39608ebd)): text data bsstotal kernel +1980 +400+2020 omap1_defconfig +1980 -160+1964 omap1_defconfig_1510innovator_only +1980 +400+2020 omap1_defconfig_5912osk_only +1964 +720+2036 multi_v7_defconfig +1172 +160+1188 omap2plus_defconfig +1212 +160+1228 omap2plus_defconfig_2430sdp_only +1172 -480+1124 omap2plus_defconfig_am33xx_only +1236 -480+1188 omap2plus_defconfig_am43xx_only +1172 -800+1092 omap2plus_defconfig_cpupm +1172 +240+1196 omap2plus_defconfig_dra7xx_only +576 -400 +536 omap2plus_defconfig_n800_multi_omap2xxx +544 -400 +504 omap2plus_defconfig_n800_only_a +1236 -80+1228 omap2plus_defconfig_no_pm +1236 -80+1228 omap2plus_defconfig_omap2_4_only +1172 +160+1188 omap2plus_defconfig_omap3_4_only +1172 -80+1164 omap2plus_defconfig_omap5_only +516 +16 +16 +548 rmk_omap3430_ldp_allnoconfig +960 -640 +896 rmk_omap3430_ldp_oldconfig +548 +12 -16 +544 rmk_omap4430_sdp_allnoconfig +1024 -640 +960 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v3.17-rc4 (2ce7598c9a453e0acd0e07be7be3f5eb39608ebd)) avail rsrvd high freed board kconfig 4k-4k . . 2420n800 omap2plus_defconfig_n800_only_a -8k 8k . . am335xbone omap2plus_defconfig_am33xx_only -224884k -36236k . -404k am335xbonelt omap2plus_defconfig am335xbonelt has been switched to using the am335x-
Re: [PATCH 06/16] tty: serial: Add 8250-core based omap driver
On 09/11/2014 01:57 PM, Peter Hurley wrote: > Hi Sebastian, Hi Peter, > Nice work. Minor comments within. Thanks. > After this is merged, it may be worth investigating how to use Yoshihiro's > newly-added 8250-based tunable RX trigger interface for omap. We need to overwrite the FCR callback. First because we can support trigger levels 1…64 and it it split across two registers and second because a change here results also in different DMA attributes. >> +++ b/drivers/tty/serial/8250/8250_omap.c >> @@ -0,0 +1,911 @@ >> +/* >> + * 8250-core based driver for the OMAP internal UART >> + * >> + * Copyright (C) 2014 Sebastian Andrzej Siewior > > + * based on omap-serial.c, Copyright (C) 2010 Texas Instruments. > > or something like that, since this is (partly) based on omap-serial.c of course. >> + * >> + */ >> + … >> +/* >> + * Ask the core to calculate the divisor for us. >> + */ >> +baud = uart_get_baud_rate(port, termios, old, >> +port->uartclk / 16 / 0x, >> +port->uartclk / 13); >> +omap_8250_get_divisor(port, baud, priv); >> + >> +/* >> + * Ok, we're now changing the port state. Do it with >> + * interrupts disabled. >> + */ >> +pm_runtime_get_sync(port->dev); >> +spin_lock_irqsave(&port->lock, flags); >^^^ > spin_lock_irq(&port->lock); > > The serial core calls the ->set_termios() method with interrupts enabled. Okay, this could work. >> + >> +/* >> + * Update the per-port timeout. >> + */ >> +uart_update_timeout(port, termios->c_cflag, baud); >> + >> +up->port.read_status_mask = UART_LSR_OE | UART_LSR_THRE | UART_LSR_DR; >> +if (termios->c_iflag & INPCK) >> +up->port.read_status_mask |= UART_LSR_FE | UART_LSR_PE; >> +if (termios->c_iflag & (BRKINT | PARMRK)) > ^ > IGNBRK | > > Otherwise, the read_status_mask will mask out the BI condition, so > uart_insert_char() will send '\0' byte as TTY_NORMAL. > > The 8250 and omap RX path differed so the omap driver didn't need this > change, whereas the 8250 driver does. Updated. >> +up->port.read_status_mask |= UART_LSR_BI; >> + >> +/* … >> + >> +priv->efr = 0; >> +if (termios->c_cflag & CRTSCTS && up->port.flags & UPF_HARD_FLOW) { >> +/* Enable AUTORTS and AUTOCTS */ >> +priv->efr |= UART_EFR_CTS | UART_EFR_RTS; >> + >> +/* Ensure MCR RTS is asserted */ >> +up->mcr |= UART_MCR_RTS; >> +} >> + >> +if (up->port.flags & UPF_SOFT_FLOW) { > > I'm aware that this is basically from the omap driver but can someone clear > up if omap hardware can actually do UPF_HARD_FLOW and UPF_SOFT_FLOW > simultaneously? The datasheets that I've looked at say no. The one that I have here for am335x says: "The UART module can use hardware or software flow control to manage transmission and reception". So yes, you are right about this. I changed this to do UPF_HARD_FLOW if possible + else UPF_SOFT_FLOW. > Regards, > Peter Hurley Sebastian -- 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 02/12] ARM: OMAP3: Use force-idle for UARTs because of DMA errata
Hi A few comments On Mon, 15 Sep 2014, Tony Lindgren wrote: > In sprz318f.pdf "Usage Note 2.7" says that UARTs cannot acknowledge > idle requests in smartidle mode when configured for DMA operations. I don't have Rev. F here. But reading between the typos in Rev. E, all it says that the UART should be placed into force-idle mode when there are no DMA transfers scheduled, otherwise CORE won't go idle. However, this patch does a lot more than that... > This prevents L4 from going idle. So let's use force-idle mode > instead and also force reconfiguring of the IO chain wake-up events. > > Otherwise systems using Sebastian's 8250 patches with DMA will > never enter deeper idle states because of the errata above. > > Cc: Paul Walmsley > Cc: Sebastian Andrzej Siewior > Signed-off-by: Tony Lindgren > --- > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 15 +++ > 1 file changed, 11 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c > b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c > index 61cd49d..55f088c 100644 > --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c > +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c > @@ -490,7 +490,9 @@ static struct omap_hwmod omap3xxx_uart1_hwmod = { > .mpu_irqs = omap2_uart1_mpu_irqs, > .sdma_reqs = omap2_uart1_sdma_reqs, > .main_clk = "uart1_fck", > - .flags = DEBUG_TI81XXUART1_FLAGS | HWMOD_SWSUP_SIDLE_ACT, > + .flags = DEBUG_TI81XXUART1_FLAGS | > + HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE | > + HWMOD_FORCE_MSTANDBY | HWMOD_RECONFIG_IO_CHAIN, ... this patch makes four significant changes to the hwmod flags: 1. It changes HWMOD_SWSUP_SIDLE_ACT to HWMOD_SWSUP_SIDLE 2. It adds HWMOD_NO_OCP_AUTOIDLE 3. It adds HWMOD_FORCE_MSTANDBY 4. It adds HWMOD_RECONFIG_IO_CHAIN As far as I can tell, the only change that actually matches the erratum usage note is #1. And even that should only be activated when the UART is in DMA mode.. PIO mode shouldn't need it. (We used to have a DMA-specific workaround in the driver code for this years ago, which was only enabled when DMA was used, but it got ripped out in the rush to get rid of the platform_data function pointers.) So that leaves the other three flag changes. Of those three, adding HWMOD_FORCE_MSTANDBY is definitely not correct according to the 34xx public TRM Rev. ZV, since the UART IP blocks: a) have no master port, b) do not contain DMA controllers (they rely on the SDMA), and c) according to the SYSC_REG register documentation in Table 17-112 of the above TRM, have no MIDLEMODE bit field. So adding HWMOD_FORCE_MSTANDBY should have zero effect and it most likely should be dropped. Regarding the rest: I'd be pretty surprised if HWMOD_RECONFIG_IO_CHAIN is needed. If that was needed, I'd think we would have seen wakeup failures in this path a long time ago, since the console serial port is the primary debug tool we used for waking the chip up from deep idle states on demand. As far as HWMOD_NO_OCP_AUTOIDLE goes: does adding this flag have an effect when HWMOD_SWSUP_SIDLE is used? If so then this should probably go in as a separate patch, because it's probably a separate bug than the one described in the commit message. ... So I'd suggest restricting this patch to simply change HWMOD_SWSUP_SIDLE_ACT to HWMOD_SWSUP_SIDLE. Then if the other flags are needed, would suggest adding them in separate patches, describing what problems are fixed by adding them. - Paul -- 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 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx
On 09/15/2014 07:01 PM, Sebastian Andrzej Siewior wrote: > On 09/11/2014 04:35 PM, Peter Hurley wrote: >> I do need to find out if omap hardware sets UART_MSR_DCTS when auto CTS >> is on. Would you mind running the debug patch below with HW flow control on? > > I didn't forget about this. However I told minicom to use hardware flow > control (and I see the driver set the HW bit) but I haven't seen that > uart_handle_cts_change() has been invoked at all. I'm going to check > two other boards and report then. No, I don't get into this at all function. So I connected my am335x-evm with beagle board xm because both of them have an old fashion UART connector (instead those uart-to-usb). Both configured with HW-Flow and I haven't seen the function invoked but I saw "port->icount.overrun" being incremented. This shouldn't happen. So I am a little puzzled here… >> Regards, >> Peter Hurley > Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16 v9] omap 8250 based uart + DMA
* Sebastian Andrzej Siewior [140916 05:58]: > On 09/15/2014 01:50 PM, Sebastian Andrzej Siewior wrote: > > I changed the restore function the fix the am335x-evm + less "freeze". > > And now we have this. So let me search… > > IER was 0 by accident. It fixed in TX path. > I pushed uart_v10_pre1 which should have it fixed aport from other > things… Just verified that works for my off-idle test case thanks. > I am going to address the review comments, to split the DMA callbacks > as requested and if nobody comes up with something fancy we will have a > v10 :) OK Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: dts: cm-t54: add HDMI/DVI display data
On 09/16/2014 11:35 AM, Dmitry Lifshitz wrote: > Add DSS related pinmux and display data nodes required to support HDMI > and DVI video out on CM-T54. > > Signed-off-by: Dmitry Lifshitz > --- > arch/arm/boot/dts/omap5-cm-t54.dts | 158 > > 1 files changed, 158 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts > b/arch/arm/boot/dts/omap5-cm-t54.dts > index 429471a..9cb40d6 100644 > --- a/arch/arm/boot/dts/omap5-cm-t54.dts > +++ b/arch/arm/boot/dts/omap5-cm-t54.dts > @@ -66,6 +66,69 @@ > default-state = "off"; > }; > }; > + > + aliases { > + display0 = &hdmi0; > + display1 = &dvi0; > + }; Should probably maintain all the aliases in one place at the top of the dts? > + > + hdmi0: connector@0 { > + compatible = "hdmi-connector"; > + label = "hdmi"; > + > + type = "a"; > + > + pinctrl-names = "default"; > + pinctrl-0 = <&hdmi_conn_pins>; > + > + hpd-gpios = <&gpio7 1 GPIO_ACTIVE_HIGH>; /* GPIO 193, HPD */ > + > + port { > + hdmi_connector_in: endpoint { > + remote-endpoint = <&hdmi_out>; > + }; > + }; > + }; > + > + tfp410: encoder@0 { > + compatible = "ti,tfp410"; > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + > + tfp410_in: endpoint@0 { > + remote-endpoint = <&dpi_dvi_out>; > + }; > + }; > + > + port@1 { > + reg = <1>; > + > + tfp410_out: endpoint@0 { > + remote-endpoint = <&dvi_connector_in>; > + }; > + }; > + }; > + }; > + > + dvi0: connector@1 { > + compatible = "dvi-connector"; > + label = "dvi"; > + > + digital; > + > + ddc-i2c-bus = <&i2c2>; > + > + port { > + dvi_connector_in: endpoint { > + remote-endpoint = <&tfp410_out>; > + }; > + }; > + }; > }; > > &omap5_pmx_core { > @@ -88,6 +151,13 @@ > >; > }; > > + i2c2_pins: pinmux_i2c2_pins { > + pinctrl-single,pins = < > + OMAP5_IOPAD(0x01b8, PIN_INPUT | MUX_MODE0) /* i2c2_scl > */ > + OMAP5_IOPAD(0x01ba, PIN_INPUT | MUX_MODE0) /* i2c2_sda > */ > + >; > + }; > + > mmc1_pins: pinmux_mmc1_pins { > pinctrl-single,pins = < > OMAP5_IOPAD(0x01e2, PIN_INPUT_PULLUP | MUX_MODE0) /* > sdcard_clk */ > @@ -144,6 +214,53 @@ > OMAP5_IOPAD(0x00b6, PIN_OUTPUT | MUX_MODE6) /* > hsi2_acdata.gpio3_83 */ > >; > }; > + > + dss_hdmi_pins: pinmux_dss_hdmi_pins { > + pinctrl-single,pins = < > + OMAP5_IOPAD(0x013c, PIN_INPUT_PULLUP | MUX_MODE0) /* > hdmi_cec.hdmi_cec */ > + OMAP5_IOPAD(0x0140, PIN_INPUT | MUX_MODE0) /* > hdmi_ddc_scl.hdmi_ddc_scl */ > + OMAP5_IOPAD(0x0142, PIN_INPUT | MUX_MODE0) /* > hdmi_ddc_sda.hdmi_ddc_sda */ > + >; > + }; > + > + hdmi_conn_pins: pinmux_hdmi_conn_pins { > + pinctrl-single,pins = < > + OMAP5_IOPAD(0x013e, PIN_INPUT | MUX_MODE6) /* > hdmi_hpd.gpio7_193 */ > + >; > + }; > + > + dss_dpi_pins: pinmux_dss_dpi_pins { > + pinctrl-single,pins = < > + OMAP5_IOPAD(0x0104, PIN_OUTPUT | MUX_MODE3) /* > dispc_data15 */ > + OMAP5_IOPAD(0x0106, PIN_OUTPUT | MUX_MODE3) /* > dispc_data14 */ > + OMAP5_IOPAD(0x0108, PIN_OUTPUT | MUX_MODE3) /* > dispc_data13 */ > + OMAP5_IOPAD(0x010a, PIN_OUTPUT | MUX_MODE3) /* > dispc_data12 */ > + OMAP5_IOPAD(0x010c, PIN_OUTPUT | MUX_MODE3) /* > dispc_data11 */ > + OMAP5_IOPAD(0x010e, PIN_OUTPUT | MUX_MODE3) /* > dispc_data10 */ > + OMAP5_IOPAD(0x0110, PIN_OUTPUT | MUX_MODE3) /* > dispc_data9 */ > + OMAP5_IOPAD(0x0112, PIN_OUTPUT | MUX_MODE3) /* > dispc_data8 */ > + OMAP5_IOPAD(0x0114, PIN_OUTPUT | MUX_MODE3) /* > dispc_data7 */ > + OMAP5_IOPAD(0x0116, PIN_OUTPUT | MUX_MODE3) /* > dispc_data6 */ > + OMAP5_IOPAD(0x0118, PIN_OUTPUT | MUX_MODE3) /* > dispc_data5 */ > + OMAP5_IOPAD(0x011a, PIN_OUTPUT | MUX_MODE3) /* > dispc_data4 *
[PATCH 2/4] ARM: dts: cm-t54: add Startek LCD support
Add DT support for Startek KD050C LCD 800x480 panel. Signed-off-by: Dmitry Lifshitz --- arch/arm/boot/dts/omap5-cm-t54.dts | 44 1 files changed, 44 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts b/arch/arm/boot/dts/omap5-cm-t54.dts index 9cb40d6..588cc2a 100644 --- a/arch/arm/boot/dts/omap5-cm-t54.dts +++ b/arch/arm/boot/dts/omap5-cm-t54.dts @@ -70,8 +70,41 @@ aliases { display0 = &hdmi0; display1 = &dvi0; + display2 = &lcd0; }; + lcd0: display { +compatible = "startek,startek-kd050c", "panel-dpi"; +label = "lcd"; + +pinctrl-names = "default"; +pinctrl-0 = <&lcd_pins>; + +enable-gpios = <&gpio8 3 GPIO_ACTIVE_HIGH>; + +panel-timing { +clock-frequency = <3300>; +hactive = <800>; +vactive = <480>; +hfront-porch = <40>; +hback-porch = <40>; +hsync-len = <43>; +vback-porch = <29>; +vfront-porch = <13>; +vsync-len = <3>; +hsync-active = <0>; +vsync-active = <0>; +de-active = <1>; +pixelclk-active = <1>; +}; + +port { +lcd_in: endpoint { +remote-endpoint = <&dpi_lcd_out>; +}; +}; +}; + hdmi0: connector@0 { compatible = "hdmi-connector"; label = "hdmi"; @@ -223,6 +256,12 @@ >; }; + lcd_pins: pinmux_lcd_pins { + pinctrl-single,pins = < + OMAP5_IOPAD(0x0172, PIN_OUTPUT_PULLDOWN | MUX_MODE6) /* timer11_pwm_evt.gpio8_227 */ + >; + }; + hdmi_conn_pins: pinmux_hdmi_conn_pins { pinctrl-single,pins = < OMAP5_IOPAD(0x013e, PIN_INPUT | MUX_MODE6) /* hdmi_hpd.gpio7_193 */ @@ -546,6 +585,11 @@ remote-endpoint = <&tfp410_in>; data-lines = <24>; }; + + dpi_lcd_out: endpoint@1 { + remote-endpoint = <&lcd_in>; + data-lines = <24>; + }; }; }; -- 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 3/4] ARM: dts: cm-t54: add ADS7846 touchscreen support
Add ADS7846 touchscreen support. Signed-off-by: Dmitry Lifshitz --- arch/arm/boot/dts/omap5-cm-t54.dts | 61 1 files changed, 61 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts b/arch/arm/boot/dts/omap5-cm-t54.dts index 588cc2a..9cfcad5 100644 --- a/arch/arm/boot/dts/omap5-cm-t54.dts +++ b/arch/arm/boot/dts/omap5-cm-t54.dts @@ -45,6 +45,13 @@ enable-active-high; }; + ads7846reg: ads7846-reg { + compatible = "regulator-fixed"; + regulator-name = "ads7846-reg"; + regulator-min-microvolt = <330>; + regulator-max-microvolt = <330>; + }; + /* HS USB Host PHY on PORT 2 */ hsusb2_phy: hsusb2_phy { compatible = "usb-nop-xceiv"; @@ -164,6 +171,15 @@ }; }; +&omap5_pmx_wkup { + + ads7846_pins: pinmux_ads7846_pins { + pinctrl-single,pins = < + 0x02 (PIN_INPUT_PULLDOWN | MUX_MODE6) /* llib_wakereqin.gpio1_wk15 */ + >; + }; +}; + &omap5_pmx_core { pinctrl-names = "default"; pinctrl-0 = < @@ -300,6 +316,51 @@ OMAP5_IOPAD(0x013a, PIN_OUTPUT | MUX_MODE3) /* dispc_data23 */ >; }; + + mcspi2_pins: pinmux_mcspi1_pins { + pinctrl-single,pins = < + OMAP5_IOPAD(0x00fc, PIN_INPUT | MUX_MODE0) /* mcspi2_clk.mcspi2_clk */ + OMAP5_IOPAD(0x00fe, PIN_INPUT | MUX_MODE0) /* mcspi2_simo.mcspi2_simo */ + OMAP5_IOPAD(0x0100, PIN_INPUT | MUX_MODE0) /* mcspi2_somi.mcspi2_somi */ + OMAP5_IOPAD(0x0102, PIN_INPUT | MUX_MODE0) /* mcspi2_cs0.mcspi2_cs0 */ + >; + }; +}; + +&mcspi2 { + pinctrl-names = "default"; + pinctrl-0 = <&mcspi2_pins>; + + /* touch controller */ + ads7846@0 { + pinctrl-names = "default"; + pinctrl-0 = <&ads7846_pins>; + + compatible = "ti,ads7846"; + vcc-supply = <&ads7846reg>; + + reg = <0>; /* CS0 */ + spi-max-frequency = <150>; + + interrupt-parent = <&gpio1>; + interrupts = <15 0>;/* gpio1_wk15 */ + pendown-gpio = <&gpio1 15 0>; + + + ti,x-min = /bits/ 16 <0x0>; + ti,x-max = /bits/ 16 <0x0fff>; + ti,y-min = /bits/ 16 <0x0>; + ti,y-max = /bits/ 16 <0x0fff>; + + ti,x-plate-ohms = /bits/ 16 <180>; + ti,pressure-max = /bits/ 16 <255>; + + ti,debounce-max = /bits/ 16 <30>; + ti,debounce-tol = /bits/ 16 <10>; + ti,debounce-rep = /bits/ 16 <1>; + + linux,wakeup; + }; }; &mmc1 { -- 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 0/4] ARM: dts: cm-t54: enable video out, touchscreen and USB3.0
Add CM-T54 DT nodes: * enable HDMI/DVI/LCD video output support * add ADS7846 touchscreen support * enchance DWC3 setup to enable power supply for USB3.0 OTG port Dmitry Lifshitz (4): ARM: dts: cm-t54: add HDMI/DVI display data ARM: dts: cm-t54: add Startek LCD support ARM: dts: cm-t54: add ADS7846 touchscreen support ARM: dts: cm-t54: setup omap_dwc3 arch/arm/boot/dts/omap5-cm-t54.dts | 268 1 files changed, 268 insertions(+), 0 deletions(-) -- 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 1/4] ARM: dts: cm-t54: add HDMI/DVI display data
Add DSS related pinmux and display data nodes required to support HDMI and DVI video out on CM-T54. Signed-off-by: Dmitry Lifshitz --- arch/arm/boot/dts/omap5-cm-t54.dts | 158 1 files changed, 158 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts b/arch/arm/boot/dts/omap5-cm-t54.dts index 429471a..9cb40d6 100644 --- a/arch/arm/boot/dts/omap5-cm-t54.dts +++ b/arch/arm/boot/dts/omap5-cm-t54.dts @@ -66,6 +66,69 @@ default-state = "off"; }; }; + + aliases { + display0 = &hdmi0; + display1 = &dvi0; + }; + + hdmi0: connector@0 { + compatible = "hdmi-connector"; + label = "hdmi"; + + type = "a"; + + pinctrl-names = "default"; + pinctrl-0 = <&hdmi_conn_pins>; + + hpd-gpios = <&gpio7 1 GPIO_ACTIVE_HIGH>; /* GPIO 193, HPD */ + + port { + hdmi_connector_in: endpoint { + remote-endpoint = <&hdmi_out>; + }; + }; + }; + + tfp410: encoder@0 { + compatible = "ti,tfp410"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + tfp410_in: endpoint@0 { + remote-endpoint = <&dpi_dvi_out>; + }; + }; + + port@1 { + reg = <1>; + + tfp410_out: endpoint@0 { + remote-endpoint = <&dvi_connector_in>; + }; + }; + }; + }; + + dvi0: connector@1 { + compatible = "dvi-connector"; + label = "dvi"; + + digital; + + ddc-i2c-bus = <&i2c2>; + + port { + dvi_connector_in: endpoint { + remote-endpoint = <&tfp410_out>; + }; + }; + }; }; &omap5_pmx_core { @@ -88,6 +151,13 @@ >; }; + i2c2_pins: pinmux_i2c2_pins { + pinctrl-single,pins = < + OMAP5_IOPAD(0x01b8, PIN_INPUT | MUX_MODE0) /* i2c2_scl */ + OMAP5_IOPAD(0x01ba, PIN_INPUT | MUX_MODE0) /* i2c2_sda */ + >; + }; + mmc1_pins: pinmux_mmc1_pins { pinctrl-single,pins = < OMAP5_IOPAD(0x01e2, PIN_INPUT_PULLUP | MUX_MODE0) /* sdcard_clk */ @@ -144,6 +214,53 @@ OMAP5_IOPAD(0x00b6, PIN_OUTPUT | MUX_MODE6) /* hsi2_acdata.gpio3_83 */ >; }; + + dss_hdmi_pins: pinmux_dss_hdmi_pins { + pinctrl-single,pins = < + OMAP5_IOPAD(0x013c, PIN_INPUT_PULLUP | MUX_MODE0) /* hdmi_cec.hdmi_cec */ + OMAP5_IOPAD(0x0140, PIN_INPUT | MUX_MODE0) /* hdmi_ddc_scl.hdmi_ddc_scl */ + OMAP5_IOPAD(0x0142, PIN_INPUT | MUX_MODE0) /* hdmi_ddc_sda.hdmi_ddc_sda */ + >; + }; + + hdmi_conn_pins: pinmux_hdmi_conn_pins { + pinctrl-single,pins = < + OMAP5_IOPAD(0x013e, PIN_INPUT | MUX_MODE6) /* hdmi_hpd.gpio7_193 */ + >; + }; + + dss_dpi_pins: pinmux_dss_dpi_pins { + pinctrl-single,pins = < + OMAP5_IOPAD(0x0104, PIN_OUTPUT | MUX_MODE3) /* dispc_data15 */ + OMAP5_IOPAD(0x0106, PIN_OUTPUT | MUX_MODE3) /* dispc_data14 */ + OMAP5_IOPAD(0x0108, PIN_OUTPUT | MUX_MODE3) /* dispc_data13 */ + OMAP5_IOPAD(0x010a, PIN_OUTPUT | MUX_MODE3) /* dispc_data12 */ + OMAP5_IOPAD(0x010c, PIN_OUTPUT | MUX_MODE3) /* dispc_data11 */ + OMAP5_IOPAD(0x010e, PIN_OUTPUT | MUX_MODE3) /* dispc_data10 */ + OMAP5_IOPAD(0x0110, PIN_OUTPUT | MUX_MODE3) /* dispc_data9 */ + OMAP5_IOPAD(0x0112, PIN_OUTPUT | MUX_MODE3) /* dispc_data8 */ + OMAP5_IOPAD(0x0114, PIN_OUTPUT | MUX_MODE3) /* dispc_data7 */ + OMAP5_IOPAD(0x0116, PIN_OUTPUT | MUX_MODE3) /* dispc_data6 */ + OMAP5_IOPAD(0x0118, PIN_OUTPUT | MUX_MODE3) /* dispc_data5 */ + OMAP5_IOPAD(0x011a, PIN_OUTPUT | MUX_MODE3) /* dispc_data4 */ + OMAP5_IOPAD(0x011c, PIN_OUTPUT | MUX_MODE3) /* dispc_data3 */ + OMAP5_IOPAD(0x011e, PIN_OUTPUT | MUX_MODE3) /* dispc_data2 */ + OMAP5_IOPAD(0x0120, PIN_OUTPUT | MUX_MODE3) /* d
[PATCH 4/4] ARM: dts: cm-t54: setup omap_dwc3
Add "extcon" and "vbus-supply" properties of DWC3 node. Signed-off-by: Dmitry Lifshitz --- arch/arm/boot/dts/omap5-cm-t54.dts |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts b/arch/arm/boot/dts/omap5-cm-t54.dts index 9cfcad5..855cb88a 100644 --- a/arch/arm/boot/dts/omap5-cm-t54.dts +++ b/arch/arm/boot/dts/omap5-cm-t54.dts @@ -631,6 +631,11 @@ phys = <0 &hsusb2_phy &hsusb3_phy>; }; +&usb3 { + extcon = <&extcon_usb3>; + vbus-supply = <&smps10_out1_reg>; +}; + &cpu0 { cpu0-supply = <&smps123_reg>; }; -- 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
Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support
Daniel, On 09/05/2014 04:18 PM, Nishanth Menon wrote: > Daniel, > > On 13:22-20140827, Kevin Hilman wrote: >> Santosh Shilimkar writes: >> >>> On Wednesday 27 August 2014 03:35 PM, Nishanth Menon wrote: On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman wrote: > + Daniel (cpuidle maintainer) [...] >> +static int omap_enter_idle_smp(struct cpuidle_device *dev, >> +struct cpuidle_driver *drv, >> +int index) >> +{ >> + struct idle_statedata *cx = state_ptr + index; >> + unsigned long flag; >> + >> + raw_spin_lock_irqsave(&mpu_lock, flag); >> + cx->mpu_state_vote++; >> + if (cx->mpu_state_vote == num_online_cpus()) { >> + pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state); >> + omap_set_pwrdm_state(mpu_pd, cx->mpu_state); >> + } >> + raw_spin_unlock_irqrestore(&mpu_lock, flag); >> + >> + omap4_enter_lowpower(dev->cpu, cx->cpu_state); >> + >> + raw_spin_lock_irqsave(&mpu_lock, flag); >> + if (cx->mpu_state_vote == num_online_cpus()) >> + omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON); >> + cx->mpu_state_vote--; >> + raw_spin_unlock_irqrestore(&mpu_lock, flag); >> + >> + return index; >> +} > > Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM? Trying to understand benefit of MCPM here - at least without a deeper understanding of mcpm infrastructure benefits (first look seemed a little heavy for OMAP5/DRA7 needs). Neither DRA7/OMAP5 are multi-cluster, the SoCs are not targetted for "OFF" of CPU1/0, we have mercury hardware to help with context and sync issues. Being able to reuse most of existing OMAP4 infrastructure code is useful as well to leave the existing omap4 framework as being lighter in complexity -esp in a cpuidle like hot path? The spin_lock is only for the programming of MPU power domain in a consistent manner - I suppose might have been the trigger for proposing mcpm? >>> Mostly not >>> >>> I think this is coming because last time Nicolas Pitre tried to convert >>> the OMAP CPUIdle into MCPM but because of various ordering requirements, >>> OMAP wasn't suitable and then the plan was dropped later. >>> >>> Just to make clear, OMAP OMAP5/DRA7 as well the ordering requirement >>> remains the same for deeper states. Its just the mercury retention state >>> which we are able to enter without ordering requirements and hence >>> the voting scheme. >> >> Ah, OK. This is the part that I'm missing. So for deeper states you'll >> need to be using omap_enter_idle_coupled() >> >>> Hope this clarifies to you as well as Kevin just in case he missed the >>> part of the deeper C-states requirements. >> >> Yes, thanks for clarifying. >> >> That being said, I think MCPM can now do essentially what the coupled >> states code is doing. Even so, that's probably not a reason to hold up >> this patch, but Daniel gets to make that call. > > > Gentle ping.. You can find the discussion and the patch here: > https://patchwork.kernel.org/patch/4764661/ > Ping on this again.. we are pretty close to approaching v3.18 merge window and this discussion has'nt gotten further. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 10/11] ARM: OMAP2+: AM33XX: Basic suspend resume support
Hi Ohad, On 09/16/2014 10:08 AM, Ohad Ben-Cohen wrote: > On Wed, Sep 10, 2014 at 12:10 AM, Kevin Hilman wrote: >> What I think you need to do (and what I've recommended at least once in >> earlier reviews) put all the (non-rproc) wkup_m3 IPC into into one >> driver and create a well-described, well-documented API that the >> platform PM code will use. >> >> IMO, the current "split" is very difficult to read/understand, which >> means it will even more difficult to maintain. > > I strongly agree. > > A remoteproc driver should generally only register its > hardware-specific implementation of the rproc_ops via the remoteproc > framework. It is not expected to expose public API of its own - that's > why we have the generic remoteproc layer for. It makes perfect sense > not to use rpmsg for communications if it's not lightweight enough, > but exposing a new set of IPC API should take place in a separate > well-documented driver. > > In addition, the suggested remoteproc driver seems to act both as a > low-level hardware-specific driver that plugs into remoteproc (by > registering rproc_ops via the remoteproc framework), and also as a > high-level driver that utilizes the remoteproc public API (by calling > rproc_boot). This alone calls for scrutinizing the design as this is > not very intuitive. The current remoteproc infrastructure automatically calls rproc_boot only as part of the rpmsg/virtio stack (in remoteproc_virtio.c), but since the WkupM3 does not use rpmsg, there is no automatic booting of the WkupM3 processor. This is the reason why rproc_boot is called as part of the WkupM3 driver probe sequence. What are your concerns here, and if you think this is not the right place do invoke rproc_boot, where do you expect it to be called? Also do note that, there is no way at present to retrieve the struct rproc for a given remote processor, to be able to invoke the rproc_boot from a different layer. > At least for the remoteproc part: if you could provide a simple and > straight-forward remoteproc driver that just implements the rproc_ops, > this could be merged very quickly. The rest of the code most probably > belongs in a different entity, just like Kevin suggested. > Splitting this would still require some kind of notifier from remoteproc for the other layers for them to know that the WkupM3 remote processor has been loaded and booted successfully. This is also done as part of the WkupM3 driver at the moment. regards Suman -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/12] ARM: OMAP2+: Add hwmod flag for HWMOD_RECONFIG_IO_CHAIN
On Mon, 15 Sep 2014, Tony Lindgren wrote: > Commit cc824534d4fe ("ARM: OMAP2+: hwmod: Rearm wake-up interrupts > for DT when MUSB is idled") fixed issues with hung UART wake-up > events by calling _reconfigure_io_chain() when MUSB is connected > or disconnected. > > As pointed out by Paul Walmsley, we may need to also call > _reconfigure_io_chain() in other cases, so it should be a separate > flag. Let's add HWMOD_RECONFIG_IO_CHAIN as suggested by Paul. > > Cc: Paul Walmsley > Signed-off-by: Tony Lindgren Reviewed-by: Paul Walmsley Thanks for taking care of this. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 10/11] ARM: OMAP2+: AM33XX: Basic suspend resume support
On Wed, Sep 10, 2014 at 12:10 AM, Kevin Hilman wrote: > What I think you need to do (and what I've recommended at least once in > earlier reviews) put all the (non-rproc) wkup_m3 IPC into into one > driver and create a well-described, well-documented API that the > platform PM code will use. > > IMO, the current "split" is very difficult to read/understand, which > means it will even more difficult to maintain. I strongly agree. A remoteproc driver should generally only register its hardware-specific implementation of the rproc_ops via the remoteproc framework. It is not expected to expose public API of its own - that's why we have the generic remoteproc layer for. It makes perfect sense not to use rpmsg for communications if it's not lightweight enough, but exposing a new set of IPC API should take place in a separate well-documented driver. In addition, the suggested remoteproc driver seems to act both as a low-level hardware-specific driver that plugs into remoteproc (by registering rproc_ops via the remoteproc framework), and also as a high-level driver that utilizes the remoteproc public API (by calling rproc_boot). This alone calls for scrutinizing the design as this is not very intuitive. At least for the remoteproc part: if you could provide a simple and straight-forward remoteproc driver that just implements the rproc_ops, this could be merged very quickly. The rest of the code most probably belongs in a different entity, just like Kevin suggested. Thanks, Ohad. -- 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 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx
On Tue, Sep 16, 2014 at 02:42:00PM +0200, Frans Klaver wrote: > On Tue, Sep 16, 2014 at 11:05:40AM +0200, Frans Klaver wrote: > > On Mon, Sep 15, 2014 at 06:42:04PM +0200, Sebastian Andrzej Siewior wrote: > > > If there is nothing specific to the file you do less on I have no idea > > > what else it could if it is not the config. > > > > I'll test your config and go through the differences. > > So far it looks like it isn't in the config. I've tested both your and > my config on debian wheezy on a boneblack. No lock ups. No, skip that. It is in the config. I'll hunt it down. -- 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/3] can: c_can_platform: Fix c_can_hw_raminit_ti() and add timeout
On 09/09/2014 04:39 PM, Roger Quadros wrote: > On 09/09/2014 05:34 PM, Marc Kleine-Budde wrote: >> On 09/09/2014 04:31 PM, Roger Quadros wrote: >>> Pass the correct 'mask' and 'value' bits to c_can_hw_raminit_wait_ti(). >>> They seem to have been swapped in the usage instances. >> >> Can you split this fix into a seperate patch, please. > > OK. I've added this fix only to the can-tree. Thanks, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 2/2] dmaengine: omap-dma: Restore the CLINK_CTRL in resume path
On 09/16/14 15:56, Russell King - ARM Linux wrote: On Tue, Sep 16, 2014 at 04:53:49PM +0300, Peter Ujfalusi wrote: When the audio stream is paused or suspended we stop the sDMA and when it is unpaused/resumed we start the channel without reconfiguring it. The omap_dma_stop() clears the link configuration when we pause the dma, but it is not setting it back on start. This will result only one audio buffer to be played back and the DMA will stop, since the linking is disabled. We need to restore the CLINK_CTRL register in case of resume. Signed-off-by: Peter Ujfalusi Both of these patches now look good, thanks. For both: Acked-by: Russell King --- drivers/dma/omap-dma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c index c01ea505ee7c..e0990c505889 100644 --- a/drivers/dma/omap-dma.c +++ b/drivers/dma/omap-dma.c @@ -1019,6 +1019,9 @@ static int omap_dma_resume(struct omap_chan *c) if (c->paused) { mb(); + /* Restore chanel link register */ Just too bad that the comment seems to have a typo. + omap_dma_chan_write(c, CLNK_CTRL, c->desc->clnk_ctrl); + omap_dma_start(c, c->desc); c->paused = false; } -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] dmaengine: omap-dma: Restore the CLINK_CTRL in resume path
On Tue, Sep 16, 2014 at 04:53:49PM +0300, Peter Ujfalusi wrote: > When the audio stream is paused or suspended we stop the sDMA and when it > is unpaused/resumed we start the channel without reconfiguring it. > The omap_dma_stop() clears the link configuration when we pause the dma, but > it is not setting it back on start. This will result only one audio buffer > to be played back and the DMA will stop, since the linking is disabled. > We need to restore the CLINK_CTRL register in case of resume. > > Signed-off-by: Peter Ujfalusi Both of these patches now look good, thanks. For both: Acked-by: Russell King > --- > drivers/dma/omap-dma.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c > index c01ea505ee7c..e0990c505889 100644 > --- a/drivers/dma/omap-dma.c > +++ b/drivers/dma/omap-dma.c > @@ -1019,6 +1019,9 @@ static int omap_dma_resume(struct omap_chan *c) > if (c->paused) { > mb(); > > + /* Restore chanel link register */ > + omap_dma_chan_write(c, CLNK_CTRL, c->desc->clnk_ctrl); > + > omap_dma_start(c, c->desc); > c->paused = false; > } > -- > 2.1.0 > -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] dmaengine: omap-dma: Restore the CLINK_CTRL in resume path
When the audio stream is paused or suspended we stop the sDMA and when it is unpaused/resumed we start the channel without reconfiguring it. The omap_dma_stop() clears the link configuration when we pause the dma, but it is not setting it back on start. This will result only one audio buffer to be played back and the DMA will stop, since the linking is disabled. We need to restore the CLINK_CTRL register in case of resume. Signed-off-by: Peter Ujfalusi --- drivers/dma/omap-dma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c index c01ea505ee7c..e0990c505889 100644 --- a/drivers/dma/omap-dma.c +++ b/drivers/dma/omap-dma.c @@ -1019,6 +1019,9 @@ static int omap_dma_resume(struct omap_chan *c) if (c->paused) { mb(); + /* Restore chanel link register */ + omap_dma_chan_write(c, CLNK_CTRL, c->desc->clnk_ctrl); + omap_dma_start(c, c->desc); c->paused = false; } -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] dmaengine: omap-dma: Add memory barrier to dma_resume path
Add mb() call to resume path to ensure the necessary barrier. Resume can happen after waking up from suspend for example. Signed-off-by: Peter Ujfalusi --- drivers/dma/omap-dma.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c index 4cf7d9a950d7..c01ea505ee7c 100644 --- a/drivers/dma/omap-dma.c +++ b/drivers/dma/omap-dma.c @@ -1017,6 +1017,8 @@ static int omap_dma_resume(struct omap_chan *c) return -EINVAL; if (c->paused) { + mb(); + omap_dma_start(c, c->desc); c->paused = false; } -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] dmaengine: omap-dma: Fix cyclic suspend/resume
Hi, When the audio is paused/resumed (application paused the sream or board suspend) the audio was only playing back one period worth of data and then stops because the omap_dam_stop() clears the link configuration and it is not restored in start. Also add memory barrier call to resume path since this could happen right after coming out from suspend. Regards, Peter --- Peter Ujfalusi (2): dmaengine: omap-dma: Add memory barrier to dma_resume path dmaengine: omap-dma: Restore the CLINK_CTRL in resume path drivers/dma/omap-dma.c | 5 + 1 file changed, 5 insertions(+) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dmaengine: omap-dma: Fix cyclic suspend/resume
On 09/16/2014 04:22 PM, Russell King - ARM Linux wrote: > On Tue, Sep 16, 2014 at 04:06:25PM +0300, Peter Ujfalusi wrote: >> When the audio stream is paused or suspended we stop the sDMA and when it >> is unpsues/resumed we start the channel without reconfiguring it. >> The omap_dma_stop() clears the link configuration when we pause the dma, but >> it is not setting it back on start. This will result only one audio buffer >> to be played back and the DMA will stop, since the linking is disabled. >> The link need to be enabled in omap_dma_start() to make sure that cyclic >> transfer can continue. >> >> Signed-off-by: Peter Ujfalusi >> --- >> drivers/dma/omap-dma.c | 12 >> 1 file changed, 12 insertions(+) >> >> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c >> index 4cf7d9a950d7..13a02ff87f28 100644 >> --- a/drivers/dma/omap-dma.c >> +++ b/drivers/dma/omap-dma.c >> @@ -280,6 +280,7 @@ static void omap_dma_assign(struct omap_dmadev *od, >> struct omap_chan *c, >> static void omap_dma_start(struct omap_chan *c, struct omap_desc *d) >> { >> struct omap_dmadev *od = to_omap_dma_dev(c->vc.chan.device); >> +uint32_t val; >> >> if (__dma_omap15xx(od->plat->dma_attr)) >> omap_dma_chan_write(c, CPC, 0); >> @@ -288,6 +289,17 @@ static void omap_dma_start(struct omap_chan *c, struct >> omap_desc *d) >> >> omap_dma_clear_csr(c); >> >> +if (!__dma_omap15xx(od->plat->dma_attr) && c->cyclic) { >> +val = omap_dma_chan_read(c, CLNK_CTRL); >> + >> +if (dma_omap1()) >> +val &= ~(1 << 14); /* clear the STOP_LNK bit */ >> +else >> +val |= CLNK_CTRL_ENABLE_LNK; >> + >> +omap_dma_chan_write(c, CLNK_CTRL, val); >> +} >> + > > Why is this soo complicated? What's wrong with simply writing the > stored value back from the omap_desc: > > omap_dma_chan_write(c, CLNK_CTRL, d->clnk_ctrl); Oh, I have overlooked this. Thanks. > In fact, rather than loading up the above fast path with stuff which > it really doesn't need, why not do this in the resume path? The > other thing which should be placed in the resume path is a mb() call, > since calling omap_dma_start() won't have a barrier in that path. Do you want it as a separate patch (adding the mb() and to restore the CLNK_CTRL register) or is it OK if I send it as one patch? -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dmaengine: omap-dma: Fix cyclic suspend/resume
On Tue, Sep 16, 2014 at 04:06:25PM +0300, Peter Ujfalusi wrote: > When the audio stream is paused or suspended we stop the sDMA and when it > is unpsues/resumed we start the channel without reconfiguring it. > The omap_dma_stop() clears the link configuration when we pause the dma, but > it is not setting it back on start. This will result only one audio buffer > to be played back and the DMA will stop, since the linking is disabled. > The link need to be enabled in omap_dma_start() to make sure that cyclic > transfer can continue. > > Signed-off-by: Peter Ujfalusi > --- > drivers/dma/omap-dma.c | 12 > 1 file changed, 12 insertions(+) > > diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c > index 4cf7d9a950d7..13a02ff87f28 100644 > --- a/drivers/dma/omap-dma.c > +++ b/drivers/dma/omap-dma.c > @@ -280,6 +280,7 @@ static void omap_dma_assign(struct omap_dmadev *od, > struct omap_chan *c, > static void omap_dma_start(struct omap_chan *c, struct omap_desc *d) > { > struct omap_dmadev *od = to_omap_dma_dev(c->vc.chan.device); > + uint32_t val; > > if (__dma_omap15xx(od->plat->dma_attr)) > omap_dma_chan_write(c, CPC, 0); > @@ -288,6 +289,17 @@ static void omap_dma_start(struct omap_chan *c, struct > omap_desc *d) > > omap_dma_clear_csr(c); > > + if (!__dma_omap15xx(od->plat->dma_attr) && c->cyclic) { > + val = omap_dma_chan_read(c, CLNK_CTRL); > + > + if (dma_omap1()) > + val &= ~(1 << 14); /* clear the STOP_LNK bit */ > + else > + val |= CLNK_CTRL_ENABLE_LNK; > + > + omap_dma_chan_write(c, CLNK_CTRL, val); > + } > + Why is this soo complicated? What's wrong with simply writing the stored value back from the omap_desc: omap_dma_chan_write(c, CLNK_CTRL, d->clnk_ctrl); In fact, rather than loading up the above fast path with stuff which it really doesn't need, why not do this in the resume path? The other thing which should be placed in the resume path is a mb() call, since calling omap_dma_start() won't have a barrier in that path. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- 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] dmaengine: omap-dma: Fix cyclic suspend/resume
When the audio stream is paused or suspended we stop the sDMA and when it is unpsues/resumed we start the channel without reconfiguring it. The omap_dma_stop() clears the link configuration when we pause the dma, but it is not setting it back on start. This will result only one audio buffer to be played back and the DMA will stop, since the linking is disabled. The link need to be enabled in omap_dma_start() to make sure that cyclic transfer can continue. Signed-off-by: Peter Ujfalusi --- drivers/dma/omap-dma.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c index 4cf7d9a950d7..13a02ff87f28 100644 --- a/drivers/dma/omap-dma.c +++ b/drivers/dma/omap-dma.c @@ -280,6 +280,7 @@ static void omap_dma_assign(struct omap_dmadev *od, struct omap_chan *c, static void omap_dma_start(struct omap_chan *c, struct omap_desc *d) { struct omap_dmadev *od = to_omap_dma_dev(c->vc.chan.device); + uint32_t val; if (__dma_omap15xx(od->plat->dma_attr)) omap_dma_chan_write(c, CPC, 0); @@ -288,6 +289,17 @@ static void omap_dma_start(struct omap_chan *c, struct omap_desc *d) omap_dma_clear_csr(c); + if (!__dma_omap15xx(od->plat->dma_attr) && c->cyclic) { + val = omap_dma_chan_read(c, CLNK_CTRL); + + if (dma_omap1()) + val &= ~(1 << 14); /* clear the STOP_LNK bit */ + else + val |= CLNK_CTRL_ENABLE_LNK; + + omap_dma_chan_write(c, CLNK_CTRL, val); + } + /* Enable interrupts */ omap_dma_chan_write(c, CICR, d->cicr); -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16 v9] omap 8250 based uart + DMA
On 09/15/2014 01:50 PM, Sebastian Andrzej Siewior wrote: > I changed the restore function the fix the am335x-evm + less "freeze". > And now we have this. So let me search… IER was 0 by accident. It fixed in TX path. I pushed uart_v10_pre1 which should have it fixed aport from other things… I am going to address the review comments, to split the DMA callbacks as requested and if nobody comes up with something fancy we will have a v10 :) >> Regards, >> >> Tony Sebastian -- 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 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx
On Tue, Sep 16, 2014 at 11:05:40AM +0200, Frans Klaver wrote: > On Mon, Sep 15, 2014 at 06:42:04PM +0200, Sebastian Andrzej Siewior wrote: > > On 09/12/2014 12:28 PM, Frans Klaver wrote: > > > port config is 115200 8N1. I don't recall doing anything special. I > > > boot, login, less file and get a lock. > > > > So I booted my mini Debian 7.6 (basic system + openssh) on my beagle > > bone black which is: > > > > [0.00] AM335X ES2.0 (neon ) > > > > configured a console, login, invoked "less file". The file was shown, I > > hit on the space key so less shows me more of the file. No lock-up. > > I tried booting via NFS and MMC. I tried various files with less. > > > > My dot config is here > > https://breakpoint.cc/config-am335x-bb.txt.xz > > > > If there is nothing specific to the file you do less on I have no idea > > what else it could if it is not the config. > > I'll test your config and go through the differences. So far it looks like it isn't in the config. I've tested both your and my config on debian wheezy on a boneblack. No lock ups. Less doesn't fill my entire screen, so it looks a bit funky when scrolling, but I'm not sure if that's related to the driver. I'll have to look further for things we did that may have impact here. > Thanks, > Frans > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 06/15] OMAPDSS: hdmi: Add pdev pointer for audio_pdev in HDMI DRV data
This is used to store omap-hdmi-audio pdev for unregistering it. Signed-off-by: Jyri Sarha --- drivers/video/fbdev/omap2/dss/hdmi.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h index 6bf077b..a6e08ff 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi.h +++ b/drivers/video/fbdev/omap2/dss/hdmi.h @@ -368,6 +368,8 @@ struct omap_hdmi { bool core_enabled; struct omap_dss_device output; + + struct platform_device *audio_pdev; }; #endif -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 05/15] OMAPDSS: hdmi: Make hdmi structure public
Unify the private anonymous struct in hdmi4.c and hdmi5.c, name it as struct omap_hdmi, and make it public in hdmi.h. Signed-off-by: Jyri Sarha --- drivers/video/fbdev/omap2/dss/hdmi.h | 21 + drivers/video/fbdev/omap2/dss/hdmi4.c | 31 --- drivers/video/fbdev/omap2/dss/hdmi5.c | 20 ++-- 3 files changed, 31 insertions(+), 41 deletions(-) diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h index 9ba7c1a..6bf077b 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi.h +++ b/drivers/video/fbdev/omap2/dss/hdmi.h @@ -349,4 +349,25 @@ static inline bool hdmi_mode_has_audio(int mode) { return mode == HDMI_HDMI ? true : false; } + +/* HDMI DRV data */ +struct omap_hdmi { + struct mutex lock; + struct platform_device *pdev; + + struct hdmi_wp_data wp; + struct hdmi_pll_datapll; + struct hdmi_phy_dataphy; + struct hdmi_core_data core; + + struct hdmi_config cfg; + + struct clk *sys_clk; + struct regulator *vdda_reg; + + bool core_enabled; + + struct omap_dss_device output; +}; + #endif diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c b/drivers/video/fbdev/omap2/dss/hdmi4.c index 6a8550c..b98186e 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi4.c +++ b/drivers/video/fbdev/omap2/dss/hdmi4.c @@ -37,25 +37,9 @@ #include "hdmi4_core.h" #include "dss.h" #include "dss_features.h" +#include "hdmi.h" -static struct { - struct mutex lock; - struct platform_device *pdev; - - struct hdmi_wp_data wp; - struct hdmi_pll_datapll; - struct hdmi_phy_dataphy; - struct hdmi_core_data core; - - struct hdmi_config cfg; - - struct clk *sys_clk; - struct regulator *vdda_hdmi_dac_reg; - - bool core_enabled; - - struct omap_dss_device output; -} hdmi; +static struct omap_hdmi hdmi; static int hdmi_runtime_get(void) { @@ -117,7 +101,7 @@ static int hdmi_init_regulator(void) int r; struct regulator *reg; - if (hdmi.vdda_hdmi_dac_reg != NULL) + if (hdmi.vdda_reg != NULL) return 0; reg = devm_regulator_get(&hdmi.pdev->dev, "vdda"); @@ -137,7 +121,7 @@ static int hdmi_init_regulator(void) } } - hdmi.vdda_hdmi_dac_reg = reg; + hdmi.vdda_reg = reg; return 0; } @@ -146,7 +130,7 @@ static int hdmi_power_on_core(struct omap_dss_device *dssdev) { int r; - r = regulator_enable(hdmi.vdda_hdmi_dac_reg); + r = regulator_enable(hdmi.vdda_reg); if (r) return r; @@ -162,7 +146,7 @@ static int hdmi_power_on_core(struct omap_dss_device *dssdev) return 0; err_runtime_get: - regulator_disable(hdmi.vdda_hdmi_dac_reg); + regulator_disable(hdmi.vdda_reg); return r; } @@ -172,7 +156,7 @@ static void hdmi_power_off_core(struct omap_dss_device *dssdev) hdmi.core_enabled = false; hdmi_runtime_put(); - regulator_disable(hdmi.vdda_hdmi_dac_reg); + regulator_disable(hdmi.vdda_reg); } static int hdmi_power_on_full(struct omap_dss_device *dssdev) @@ -678,6 +662,7 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev) int irq; hdmi.pdev = pdev; + dev_set_drvdata(&pdev->dev, &hdmi); mutex_init(&hdmi.lock); diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c b/drivers/video/fbdev/omap2/dss/hdmi5.c index 32d02ec..90410f5 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi5.c +++ b/drivers/video/fbdev/omap2/dss/hdmi5.c @@ -43,24 +43,7 @@ #include "dss.h" #include "dss_features.h" -static struct { - struct mutex lock; - struct platform_device *pdev; - - struct hdmi_wp_data wp; - struct hdmi_pll_datapll; - struct hdmi_phy_dataphy; - struct hdmi_core_data core; - - struct hdmi_config cfg; - - struct clk *sys_clk; - struct regulator *vdda_reg; - - bool core_enabled; - - struct omap_dss_device output; -} hdmi; +static struct omap_hdmi hdmi; static int hdmi_runtime_get(void) { @@ -703,6 +686,7 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev) int irq; hdmi.pdev = pdev; + dev_set_drvdata(&pdev->dev, &hdmi); mutex_init(&hdmi.lock); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 02/15] OMAPDSS: hdmi: Remove most of OMAP[45]_DSS_HDMI_AUDIO ifdefs
It does not waste too many bytes to compile all audio related core functions always in with HDMI support. It should help readability and in keeping the audio code in working shape. Leave the options just for disabling and enabling the functionality in hdmi[45].c. Signed-off-by: Jyri Sarha --- drivers/video/fbdev/omap2/dss/hdmi.h|3 +-- drivers/video/fbdev/omap2/dss/hdmi4_core.c |5 - drivers/video/fbdev/omap2/dss/hdmi4_core.h |2 -- drivers/video/fbdev/omap2/dss/hdmi5_core.c |6 -- drivers/video/fbdev/omap2/dss/hdmi5_core.h |2 -- drivers/video/fbdev/omap2/dss/hdmi_common.c |2 -- drivers/video/fbdev/omap2/dss/hdmi_wp.c |2 -- 7 files changed, 1 insertion(+), 21 deletions(-) diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h index 1f01068..03726b5 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi.h +++ b/drivers/video/fbdev/omap2/dss/hdmi.h @@ -335,7 +335,7 @@ int hdmi_phy_parse_lanes(struct hdmi_phy_data *phy, const u32 *lanes); int hdmi_parse_lanes_of(struct platform_device *pdev, struct device_node *ep, struct hdmi_phy_data *phy); -#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) || defined(CONFIG_OMAP5_DSS_HDMI_AUDIO) +/* Audio funcs */ int hdmi_compute_acr(u32 pclk, u32 sample_freq, u32 *n, u32 *cts); int hdmi_wp_audio_enable(struct hdmi_wp_data *wp, bool enable); int hdmi_wp_audio_core_req_enable(struct hdmi_wp_data *wp, bool enable); @@ -348,4 +348,3 @@ static inline bool hdmi_mode_has_audio(int mode) return mode == HDMI_HDMI ? true : false; } #endif -#endif diff --git a/drivers/video/fbdev/omap2/dss/hdmi4_core.c b/drivers/video/fbdev/omap2/dss/hdmi4_core.c index 4ad39cf..3b448d9 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi4_core.c +++ b/drivers/video/fbdev/omap2/dss/hdmi4_core.c @@ -31,10 +31,8 @@ #include #include #include -#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) #include #include -#endif #include "hdmi4_core.h" #include "dss_features.h" @@ -530,7 +528,6 @@ void hdmi4_core_dump(struct hdmi_core_data *core, struct seq_file *s) DUMPCOREAV(HDMI_CORE_AV_CEC_ADDR_ID); } -#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) static void hdmi_core_audio_config(struct hdmi_core_data *core, struct hdmi_core_audio_config *cfg) { @@ -886,8 +883,6 @@ int hdmi4_audio_get_dma_port(u32 *offset, u32 *size) return 0; } -#endif - int hdmi4_core_init(struct platform_device *pdev, struct hdmi_core_data *core) { struct resource *res; diff --git a/drivers/video/fbdev/omap2/dss/hdmi4_core.h b/drivers/video/fbdev/omap2/dss/hdmi4_core.h index 827909e..c1959f7 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi4_core.h +++ b/drivers/video/fbdev/omap2/dss/hdmi4_core.h @@ -266,12 +266,10 @@ void hdmi4_configure(struct hdmi_core_data *core, struct hdmi_wp_data *wp, void hdmi4_core_dump(struct hdmi_core_data *core, struct seq_file *s); int hdmi4_core_init(struct platform_device *pdev, struct hdmi_core_data *core); -#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) int hdmi4_audio_start(struct hdmi_core_data *core, struct hdmi_wp_data *wp); void hdmi4_audio_stop(struct hdmi_core_data *core, struct hdmi_wp_data *wp); int hdmi4_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, struct omap_dss_audio *audio, u32 pclk); int hdmi4_audio_get_dma_port(u32 *offset, u32 *size); -#endif #endif diff --git a/drivers/video/fbdev/omap2/dss/hdmi5_core.c b/drivers/video/fbdev/omap2/dss/hdmi5_core.c index 83acbf7..8eab25b 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi5_core.c +++ b/drivers/video/fbdev/omap2/dss/hdmi5_core.c @@ -30,10 +30,8 @@ #include #include #include -#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO) #include #include -#endif #include "hdmi5_core.h" @@ -644,9 +642,6 @@ void hdmi5_configure(struct hdmi_core_data *core, struct hdmi_wp_data *wp, hdmi_core_enable_interrupts(core); } - -#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO) - static void hdmi5_core_audio_config(struct hdmi_core_data *core, struct hdmi_core_audio_config *cfg) { @@ -894,7 +889,6 @@ int hdmi5_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, return 0; } -#endif int hdmi5_core_init(struct platform_device *pdev, struct hdmi_core_data *core) { diff --git a/drivers/video/fbdev/omap2/dss/hdmi5_core.h b/drivers/video/fbdev/omap2/dss/hdmi5_core.h index ce7e9f3..f2f1022 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi5_core.h +++ b/drivers/video/fbdev/omap2/dss/hdmi5_core.h @@ -299,8 +299,6 @@ void hdmi5_configure(struct hdmi_core_data *core, struct hdmi_wp_data *wp, struct hdmi_config *cfg); int hdmi5_core_init(struct platform_device *pdev, struct hdmi_core_data *core); -#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO) int hdmi5_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, struct omap_dss_audio *audio, u32 p
[PATCH v5 11/15] OMAPDSS: hdmi5: Register ASoC platfrom device for omap hdmi audio
Implements callbacks for OMAP HDMI audio platform driver and registers it in probe function. Unregistering is done in remove function. Signed-off-by: Jyri Sarha --- drivers/video/fbdev/omap2/dss/hdmi5.c | 97 + 1 file changed, 97 insertions(+) diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c b/drivers/video/fbdev/omap2/dss/hdmi5.c index 90410f5..360b31f 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi5.c +++ b/drivers/video/fbdev/omap2/dss/hdmi5.c @@ -38,6 +38,7 @@ #include #include #include +#include #include "hdmi5_core.h" #include "dss.h" @@ -679,6 +680,91 @@ err: return r; } +/* Audio callbacks */ +static int mode_has_audio(struct device *dev) +{ + struct omap_hdmi *hd = dev_get_drvdata(dev); + int ret; + + mutex_lock(&hd->lock); + ret = hdmi_mode_has_audio(&hd->cfg); + mutex_unlock(&hd->lock); + + return ret; +} + +static int audio_enable(struct device *dev, bool enable) +{ + struct omap_hdmi *hd = dev_get_drvdata(dev); + int ret; + + mutex_lock(&hd->lock); + if (!hdmi_mode_has_audio(&hd->cfg)) + ret = -EPERM; + else + ret = hdmi_wp_audio_enable(&hd->wp, enable); + mutex_unlock(&hd->lock); + + return ret; +} + +static int audio_start(struct device *dev, bool enable) +{ + struct omap_hdmi *hd = dev_get_drvdata(dev); + + return hdmi_wp_audio_core_req_enable(&hd->wp, enable); +} + +static int audio_config(struct device *dev, struct omap_dss_audio *dss_audio) +{ + struct omap_hdmi *hd = dev_get_drvdata(dev); + int ret; + + mutex_lock(&hd->lock); + if (!hdmi_mode_has_audio(&hd->cfg)) + ret = -EPERM; + else + ret = hdmi5_audio_config(&hd->core, &hd->wp, dss_audio, +hd->cfg.timings.pixelclock); + mutex_unlock(&hd->lock); + + return ret; +} + +static int hdmi_audio_register(struct device *dev) +{ + struct omap_hdmi_audio_pdata pdata = { + .dev = dev, + .hw_version = OMAP5_HDMI, + .audio_dma_addr = hdmi_wp_get_audio_dma_addr(&hdmi.wp), + .mode_has_audio = mode_has_audio, + .audio_enable = audio_enable, + .audio_start = audio_start, + .audio_config = audio_config, + }; + struct of_phandle_args dma_spec; + int ret; + + ret = of_property_match_string(dev->of_node, "dma-names", "audio_tx"); + if (ret < 0) + return ret; + + ret = of_parse_phandle_with_args(dev->of_node, "dmas", "#dma-cells", +ret, &dma_spec); + if (ret < 0) + return ret; + + pdata.audio_dma_req = dma_spec.args[0]; + + hdmi.audio_pdev = + platform_device_register_data(dev, "omap-hdmi-audio", 0, + &pdata, sizeof(pdata)); + if (IS_ERR(hdmi.audio_pdev)) + return PTR_ERR(hdmi.audio_pdev); + + return 0; +} + /* HDMI HW IP initialisation */ static int omapdss_hdmihw_probe(struct platform_device *pdev) { @@ -736,6 +822,14 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev) hdmi_init_output(pdev); + r = hdmi_audio_register(&pdev->dev); + if (r) { + DSSERR("Registering HDMI audio failed %d\n", r); + hdmi_uninit_output(pdev); + pm_runtime_disable(&pdev->dev); + return r; + } + dss_debugfs_create_file("hdmi", hdmi_dump_regs); return 0; @@ -743,6 +837,9 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev) static int __exit omapdss_hdmihw_remove(struct platform_device *pdev) { + if (hdmi.audio_pdev) + platform_device_unregister(hdmi.audio_pdev); + hdmi_uninit_output(pdev); pm_runtime_disable(&pdev->dev); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 13/15] OMAPDSS: hdmi4: Remove callbacks for the old ASoC DAI driver
Removes the OMAP4 HDMI audio callbacks for the old external DAI driver. Signed-off-by: Jyri Sarha --- drivers/video/fbdev/omap2/dss/hdmi4.c | 113 - 1 file changed, 113 deletions(-) diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c b/drivers/video/fbdev/omap2/dss/hdmi4.c index 2e87229..47c0195 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi4.c +++ b/drivers/video/fbdev/omap2/dss/hdmi4.c @@ -469,112 +469,6 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev, return r; } -#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) -static int hdmi_audio_enable(struct omap_dss_device *dssdev) -{ - int r; - - mutex_lock(&hdmi.lock); - - if (!hdmi_mode_has_audio(hdmi.cfg.hdmi_dvi_mode)) { - r = -EPERM; - goto err; - } - - r = hdmi_wp_audio_enable(&hdmi.wp, true); - if (r) - goto err; - - mutex_unlock(&hdmi.lock); - return 0; - -err: - mutex_unlock(&hdmi.lock); - return r; -} - -static void hdmi_audio_disable(struct omap_dss_device *dssdev) -{ - hdmi_wp_audio_enable(&hdmi.wp, false); -} - -static int hdmi_audio_start(struct omap_dss_device *dssdev) -{ - return hdmi4_audio_start(&hdmi.core, &hdmi.wp); -} - -static void hdmi_audio_stop(struct omap_dss_device *dssdev) -{ - hdmi4_audio_stop(&hdmi.core, &hdmi.wp); -} - -static bool hdmi_audio_supported(struct omap_dss_device *dssdev) -{ - bool r; - - mutex_lock(&hdmi.lock); - - r = hdmi_mode_has_audio(hdmi.cfg.hdmi_dvi_mode); - - mutex_unlock(&hdmi.lock); - return r; -} - -static int hdmi_audio_config(struct omap_dss_device *dssdev, - struct omap_dss_audio *audio) -{ - int r; - u32 pclk = hdmi.cfg.timings.pixelclock; - - mutex_lock(&hdmi.lock); - - if (!hdmi_mode_has_audio(hdmi.cfg.hdmi_dvi_mode)) { - r = -EPERM; - goto err; - } - - r = hdmi4_audio_config(&hdmi.core, &hdmi.wp, audio, pclk); - if (r) - goto err; - - mutex_unlock(&hdmi.lock); - return 0; - -err: - mutex_unlock(&hdmi.lock); - return r; -} -#else -static int hdmi_audio_enable(struct omap_dss_device *dssdev) -{ - return -EPERM; -} - -static void hdmi_audio_disable(struct omap_dss_device *dssdev) -{ -} - -static int hdmi_audio_start(struct omap_dss_device *dssdev) -{ - return -EPERM; -} - -static void hdmi_audio_stop(struct omap_dss_device *dssdev) -{ -} - -static bool hdmi_audio_supported(struct omap_dss_device *dssdev) -{ - return false; -} - -static int hdmi_audio_config(struct omap_dss_device *dssdev, - struct omap_dss_audio *audio) -{ - return -EPERM; -} -#endif - static int hdmi_set_infoframe(struct omap_dss_device *dssdev, const struct hdmi_avi_infoframe *avi) { @@ -603,13 +497,6 @@ static const struct omapdss_hdmi_ops hdmi_ops = { .read_edid = hdmi_read_edid, .set_infoframe = hdmi_set_infoframe, .set_hdmi_mode = hdmi_set_hdmi_mode, - - .audio_enable = hdmi_audio_enable, - .audio_disable = hdmi_audio_disable, - .audio_start= hdmi_audio_start, - .audio_stop = hdmi_audio_stop, - .audio_supported= hdmi_audio_supported, - .audio_config = hdmi_audio_config, }; static void hdmi_init_output(struct platform_device *pdev) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 12/15] ASoC: omap: Remove obsolete HDMI audio code and Kconfig options
Removes omap-hdmi DAI driver, omap-hdmi-card driver, the related Kconfig options, and Makefile entries. The HDMI DAI drivers has been integrated directly to OMAP4+ HDMI drivers and simple-card driver is used instead of omap-hdmi-card driver. Signed-off-by: Jyri Sarha --- sound/soc/omap/Kconfig | 13 -- sound/soc/omap/Makefile |4 - sound/soc/omap/omap-hdmi-card.c | 87 -- sound/soc/omap/omap-hdmi.c | 364 --- sound/soc/omap/omap-hdmi.h | 38 5 files changed, 506 deletions(-) delete mode 100644 sound/soc/omap/omap-hdmi-card.c delete mode 100644 sound/soc/omap/omap-hdmi.c delete mode 100644 sound/soc/omap/omap-hdmi.h diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index 66eb428..5fc56a6 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -12,9 +12,6 @@ config SND_OMAP_SOC_MCBSP config SND_OMAP_SOC_MCPDM tristate -config SND_OMAP_SOC_HDMI - tristate - config SND_OMAP_SOC_HDMI_AUDIO tristate "HDMI audio support for OMAP4+ based SoCs" depends on SND_OMAP_SOC @@ -111,16 +108,6 @@ config SND_OMAP_SOC_OMAP_ABE_TWL6040 - PandaBoard (4430) - PandaBoardES (4460) -config SND_OMAP_SOC_OMAP_HDMI - tristate "SoC Audio support for Texas Instruments OMAP HDMI" - depends on SND_OMAP_SOC && OMAP4_DSS_HDMI && OMAP2_DSS - select SND_OMAP_SOC_HDMI - select SND_SOC_HDMI_CODEC - select OMAP4_DSS_HDMI_AUDIO - help - Say Y if you want to add support for SoC HDMI audio on Texas Instruments - OMAP4 chips - config SND_OMAP_SOC_OMAP3_PANDORA tristate "SoC Audio support for OMAP3 Pandora" depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP3_PANDORA diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile index 40688a6..db36fbd 100644 --- a/sound/soc/omap/Makefile +++ b/sound/soc/omap/Makefile @@ -3,14 +3,12 @@ snd-soc-omap-objs := omap-pcm.o snd-soc-omap-dmic-objs := omap-dmic.o snd-soc-omap-mcbsp-objs := omap-mcbsp.o mcbsp.o snd-soc-omap-mcpdm-objs := omap-mcpdm.o -snd-soc-omap-hdmi-objs := omap-hdmi.o snd-soc-omap-hdmi-audio-objs := omap-hdmi-audio.o obj-$(CONFIG_SND_OMAP_SOC) += snd-soc-omap.o obj-$(CONFIG_SND_OMAP_SOC_DMIC) += snd-soc-omap-dmic.o obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o obj-$(CONFIG_SND_OMAP_SOC_MCPDM) += snd-soc-omap-mcpdm.o -obj-$(CONFIG_SND_OMAP_SOC_HDMI) += snd-soc-omap-hdmi.o obj-$(CONFIG_SND_OMAP_SOC_HDMI_AUDIO) += snd-soc-omap-hdmi-audio.o # OMAP Machine Support @@ -22,7 +20,6 @@ snd-soc-am3517evm-objs := am3517evm.o snd-soc-omap-abe-twl6040-objs := omap-abe-twl6040.o snd-soc-omap-twl4030-objs := omap-twl4030.o snd-soc-omap3pandora-objs := omap3pandora.o -snd-soc-omap-hdmi-card-objs := omap-hdmi-card.o obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o obj-$(CONFIG_SND_OMAP_SOC_RX51) += snd-soc-rx51.o @@ -32,4 +29,3 @@ obj-$(CONFIG_SND_OMAP_SOC_AM3517EVM) += snd-soc-am3517evm.o obj-$(CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040) += snd-soc-omap-abe-twl6040.o obj-$(CONFIG_SND_OMAP_SOC_OMAP_TWL4030) += snd-soc-omap-twl4030.o obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += snd-soc-omap3pandora.o -obj-$(CONFIG_SND_OMAP_SOC_OMAP_HDMI) += snd-soc-omap-hdmi-card.o diff --git a/sound/soc/omap/omap-hdmi-card.c b/sound/soc/omap/omap-hdmi-card.c deleted file mode 100644 index f649fe8..000 --- a/sound/soc/omap/omap-hdmi-card.c +++ /dev/null @@ -1,87 +0,0 @@ -/* - * omap-hdmi-card.c - * - * OMAP ALSA SoC machine driver for TI OMAP HDMI - * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ - * Author: Ricardo Neri - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * version 2 as published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA - * 02110-1301 USA - * - */ - -#include -#include -#include -#include -#include - -#define DRV_NAME "omap-hdmi-audio" - -static struct snd_soc_dai_link omap_hdmi_dai = { - .name = "HDMI", - .stream_name = "HDMI", - .cpu_dai_name = "omap-hdmi-audio-dai", - .platform_name = "omap-hdmi-audio-dai", - .codec_name = "hdmi-audio-codec", - .codec_dai_name = "hdmi-hifi", -}; - -static struct snd_soc_card snd_soc_omap_hdmi = { - .name = "OMAPHDMI", - .owner = THIS_MODULE, - .dai_link = &omap_hdmi_dai, - .num_links = 1, -}; - -static int omap_hdmi_probe(struct platform_device *pdev) -{ - struct snd_soc_card *card =
[PATCH v5 10/15] OMAPDSS: hdmi4: Register ASoC platfrom device for omap hdmi audio
Implements callbacks for OMAP HDMI audio platform driver and registers it in probe function. Unregistering is done in remove function. Signed-off-by: Jyri Sarha --- drivers/video/fbdev/omap2/dss/hdmi4.c | 103 + 1 file changed, 103 insertions(+) diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c b/drivers/video/fbdev/omap2/dss/hdmi4.c index b98186e..2e87229 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi4.c +++ b/drivers/video/fbdev/omap2/dss/hdmi4.c @@ -33,6 +33,7 @@ #include #include #include +#include #include "hdmi4_core.h" #include "dss.h" @@ -655,6 +656,97 @@ err: return r; } +/* Audio callbacks */ +static int mode_has_audio(struct device *dev) +{ + struct omap_hdmi *hd = dev_get_drvdata(dev); + int ret; + + mutex_lock(&hd->lock); + ret = hdmi_mode_has_audio(&hd->cfg); + mutex_unlock(&hd->lock); + + return ret; +} + +static int audio_enable(struct device *dev, bool enable) +{ + struct omap_hdmi *hd = dev_get_drvdata(dev); + int ret; + + mutex_lock(&hd->lock); + if (!hdmi_mode_has_audio(&hd->cfg)) + ret = -EPERM; + else + ret = hdmi_wp_audio_enable(&hd->wp, enable); + mutex_unlock(&hd->lock); + + return ret; +} + +static int audio_start(struct device *dev, bool enable) +{ + struct omap_hdmi *hd = dev_get_drvdata(dev); + int ret = 0; + + if (enable) + ret = hdmi4_audio_start(&hd->core, &hd->wp); + else + hdmi4_audio_stop(&hd->core, &hd->wp); + + return ret; +} + +static int audio_config(struct device *dev, struct omap_dss_audio *dss_audio) +{ + struct omap_hdmi *hd = dev_get_drvdata(dev); + int ret; + + mutex_lock(&hd->lock); + if (!hdmi_mode_has_audio(&hd->cfg)) + ret = -EPERM; + else + ret = hdmi4_audio_config(&hd->core, &hd->wp, dss_audio, +hd->cfg.timings.pixelclock); + mutex_unlock(&hd->lock); + + return ret; +} + +static int hdmi_audio_register(struct device *dev) +{ + struct omap_hdmi_audio_pdata pdata = { + .dev = dev, + .hw_version = OMAP4_HDMI, + .audio_dma_addr = hdmi_wp_get_audio_dma_addr(&hdmi.wp), + .mode_has_audio = mode_has_audio, + .audio_enable = audio_enable, + .audio_start = audio_start, + .audio_config = audio_config, + }; + struct of_phandle_args dma_spec; + int ret; + + ret = of_property_match_string(dev->of_node, "dma-names", "audio_tx"); + if (ret < 0) + return ret; + + ret = of_parse_phandle_with_args(dev->of_node, "dmas", "#dma-cells", +ret, &dma_spec); + if (ret < 0) + return ret; + + pdata.audio_dma_req = dma_spec.args[0]; + + hdmi.audio_pdev = + platform_device_register_data(dev, "omap-hdmi-audio", 0, + &pdata, sizeof(pdata)); + if (IS_ERR(hdmi.audio_pdev)) + return PTR_ERR(hdmi.audio_pdev); + + return 0; +} + /* HDMI HW IP initialisation */ static int omapdss_hdmihw_probe(struct platform_device *pdev) { @@ -712,6 +804,14 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev) hdmi_init_output(pdev); + r = hdmi_audio_register(&pdev->dev); + if (r) { + DSSERR("Registering HDMI audio failed\n"); + hdmi_uninit_output(pdev); + pm_runtime_disable(&pdev->dev); + return r; + } + dss_debugfs_create_file("hdmi", hdmi_dump_regs); return 0; @@ -719,6 +819,9 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev) static int __exit omapdss_hdmihw_remove(struct platform_device *pdev) { + if (hdmi.audio_pdev) + platform_device_unregister(hdmi.audio_pdev); + hdmi_uninit_output(pdev); pm_runtime_disable(&pdev->dev); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 03/15] OMAPDSS: hdmi4_core: Remove unused hdmi4_audio_get_dma_port()
hdmi4_audio_get_dma_port() is unused and and broken. Signed-off-by: Jyri Sarha --- drivers/video/fbdev/omap2/dss/hdmi4_core.c |9 - drivers/video/fbdev/omap2/dss/hdmi4_core.h |2 -- 2 files changed, 11 deletions(-) diff --git a/drivers/video/fbdev/omap2/dss/hdmi4_core.c b/drivers/video/fbdev/omap2/dss/hdmi4_core.c index 3b448d9..7eafea5 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi4_core.c +++ b/drivers/video/fbdev/omap2/dss/hdmi4_core.c @@ -874,15 +874,6 @@ void hdmi4_audio_stop(struct hdmi_core_data *core, struct hdmi_wp_data *wp) hdmi_wp_audio_core_req_enable(wp, false); } -int hdmi4_audio_get_dma_port(u32 *offset, u32 *size) -{ - if (!offset || !size) - return -EINVAL; - *offset = HDMI_WP_AUDIO_DATA; - *size = 4; - return 0; -} - int hdmi4_core_init(struct platform_device *pdev, struct hdmi_core_data *core) { struct resource *res; diff --git a/drivers/video/fbdev/omap2/dss/hdmi4_core.h b/drivers/video/fbdev/omap2/dss/hdmi4_core.h index c1959f7..a069f96 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi4_core.h +++ b/drivers/video/fbdev/omap2/dss/hdmi4_core.h @@ -270,6 +270,4 @@ int hdmi4_audio_start(struct hdmi_core_data *core, struct hdmi_wp_data *wp); void hdmi4_audio_stop(struct hdmi_core_data *core, struct hdmi_wp_data *wp); int hdmi4_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, struct omap_dss_audio *audio, u32 pclk); -int hdmi4_audio_get_dma_port(u32 *offset, u32 *size); - #endif -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 09/15] OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly
Signed-off-by: Jyri Sarha --- drivers/video/fbdev/omap2/dss/hdmi.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h index a6e08ff..6d129f2 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi.h +++ b/drivers/video/fbdev/omap2/dss/hdmi.h @@ -345,9 +345,9 @@ void hdmi_wp_audio_config_format(struct hdmi_wp_data *wp, struct hdmi_audio_format *aud_fmt); void hdmi_wp_audio_config_dma(struct hdmi_wp_data *wp, struct hdmi_audio_dma *aud_dma); -static inline bool hdmi_mode_has_audio(int mode) +static inline bool hdmi_mode_has_audio(struct hdmi_config *cfg) { - return mode == HDMI_HDMI ? true : false; + return cfg->hdmi_dvi_mode == HDMI_HDMI ? true : false; } /* HDMI DRV data */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 04/15] OMAPDSS: hdmi_wp: Add function for getting audio dma address
The audio dma port is found in the hdmi_wp physical address space. Signed-off-by: Jyri Sarha --- drivers/video/fbdev/omap2/dss/hdmi.h|2 ++ drivers/video/fbdev/omap2/dss/hdmi_wp.c |6 ++ 2 files changed, 8 insertions(+) diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h index 03726b5..9ba7c1a 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi.h +++ b/drivers/video/fbdev/omap2/dss/hdmi.h @@ -250,6 +250,7 @@ struct hdmi_core_audio_config { struct hdmi_wp_data { void __iomem *base; + phys_addr_t phys_base; }; struct hdmi_pll_data { @@ -317,6 +318,7 @@ void hdmi_wp_video_config_timing(struct hdmi_wp_data *wp, void hdmi_wp_init_vid_fmt_timings(struct hdmi_video_format *video_fmt, struct omap_video_timings *timings, struct hdmi_config *param); int hdmi_wp_init(struct platform_device *pdev, struct hdmi_wp_data *wp); +phys_addr_t hdmi_wp_get_audio_dma_addr(struct hdmi_wp_data *wp); /* HDMI PLL funcs */ int hdmi_pll_enable(struct hdmi_pll_data *pll, struct hdmi_wp_data *wp); diff --git a/drivers/video/fbdev/omap2/dss/hdmi_wp.c b/drivers/video/fbdev/omap2/dss/hdmi_wp.c index f1b53de..5154120 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi_wp.c +++ b/drivers/video/fbdev/omap2/dss/hdmi_wp.c @@ -245,6 +245,7 @@ int hdmi_wp_init(struct platform_device *pdev, struct hdmi_wp_data *wp) DSSERR("can't get WP mem resource\n"); return -EINVAL; } + wp->phys_base = res->start; wp->base = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(wp->base)) { @@ -254,3 +255,8 @@ int hdmi_wp_init(struct platform_device *pdev, struct hdmi_wp_data *wp) return 0; } + +phys_addr_t hdmi_wp_get_audio_dma_addr(struct hdmi_wp_data *wp) +{ + return wp->phys_base + HDMI_WP_AUDIO_DATA; +} -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 07/15] ASoC: omap-hdmi-audio: Add platfrom device for OMAP HDMI audio support
The platform device should only be registered from OMAPDSS HDMI driver. The platfrom driver registers and unregisters all ASoC components needed for OMAP HDMI audio. The hdmi audio driver implements cpu-dai component using the callbacks provided by OMAPDSS. Omap-pcm is registered for platform component, dummy hdmi-audio-codec is registered for codec component, and asoc-simple-card is registered for machine driver. Signed-off-by: Jyri Sarha --- include/sound/omap-hdmi-audio.h | 38 sound/soc/omap/Kconfig | 11 ++ sound/soc/omap/Makefile |2 + sound/soc/omap/omap-hdmi-audio.c | 379 ++ 4 files changed, 430 insertions(+) create mode 100644 include/sound/omap-hdmi-audio.h create mode 100644 sound/soc/omap/omap-hdmi-audio.c diff --git a/include/sound/omap-hdmi-audio.h b/include/sound/omap-hdmi-audio.h new file mode 100644 index 000..6c1638c --- /dev/null +++ b/include/sound/omap-hdmi-audio.h @@ -0,0 +1,38 @@ +/* + * hdmi-audio.c -- OMAP4+ DSS HDMI audio support library + * + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com + * + * Author: Jyri Sarha + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + */ + +#include + +#ifndef __OMAP_HDMI_AUDIO_H__ +#define __OMAP_HDMI_AUDIO_H__ + +/* HDMI audio initalization data */ +struct omap_hdmi_audio_pdata { + struct device *dev; + enum { OMAP4_HDMI, OMAP5_HDMI } hw_version; + phys_addr_t audio_dma_addr; + unsigned int audio_dma_req; + + int (*mode_has_audio)(struct device *dev); + int (*audio_enable)(struct device *dev, bool enable); + int (*audio_start)(struct device *dev, bool enable); + int (*audio_config)(struct device *dev, + struct omap_dss_audio *dss_audio); +}; + +#endif /* __OMAP_HDMI_AUDIO_H__ */ diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index d44463a..66eb428 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -15,6 +15,17 @@ config SND_OMAP_SOC_MCPDM config SND_OMAP_SOC_HDMI tristate +config SND_OMAP_SOC_HDMI_AUDIO + tristate "HDMI audio support for OMAP4+ based SoCs" + depends on SND_OMAP_SOC + select SND_SOC_HDMI_CODEC + select SND_SIMPLE_CARD + help + The driver implements an integrated ASoC Digital Audio + Interface component driver and registers a dummy HDMI codec + and asoc-simple-card for full HDMI audio support. OMAPDSS + HDMI video needs to be enabled too for working HDMI audio. + config SND_OMAP_SOC_N810 tristate "SoC Audio support for Nokia N810" depends on SND_OMAP_SOC && MACH_NOKIA_N810 && I2C diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile index a725905..40688a6 100644 --- a/sound/soc/omap/Makefile +++ b/sound/soc/omap/Makefile @@ -4,12 +4,14 @@ snd-soc-omap-dmic-objs := omap-dmic.o snd-soc-omap-mcbsp-objs := omap-mcbsp.o mcbsp.o snd-soc-omap-mcpdm-objs := omap-mcpdm.o snd-soc-omap-hdmi-objs := omap-hdmi.o +snd-soc-omap-hdmi-audio-objs := omap-hdmi-audio.o obj-$(CONFIG_SND_OMAP_SOC) += snd-soc-omap.o obj-$(CONFIG_SND_OMAP_SOC_DMIC) += snd-soc-omap-dmic.o obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o obj-$(CONFIG_SND_OMAP_SOC_MCPDM) += snd-soc-omap-mcpdm.o obj-$(CONFIG_SND_OMAP_SOC_HDMI) += snd-soc-omap-hdmi.o +obj-$(CONFIG_SND_OMAP_SOC_HDMI_AUDIO) += snd-soc-omap-hdmi-audio.o # OMAP Machine Support snd-soc-n810-objs := n810.o diff --git a/sound/soc/omap/omap-hdmi-audio.c b/sound/soc/omap/omap-hdmi-audio.c new file mode 100644 index 000..4614dce --- /dev/null +++ b/sound/soc/omap/omap-hdmi-audio.c @@ -0,0 +1,379 @@ +/* + * omap-hdmi-audio.c -- OMAP4+ DSS HDMI audio support library + * + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com + * + * Author: Jyri Sarha + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define DRV_NAME "omap-hdmi-audio" + +struct hdmi_audio_data { + int (*mode_has_audio)(struct device *dev); +
[PATCH v5 08/15] OMAPDSS: Kconfig: Remove HDMI audio booleans from Kconfig
The booleans are not used anymore. Just select SND_OMAP_SOC_HDMI_AUDIO to enable OMAP HDMI audio support. Signed-off-by: Jyri Sarha --- drivers/video/fbdev/omap2/dss/Kconfig |7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/video/fbdev/omap2/dss/Kconfig b/drivers/video/fbdev/omap2/dss/Kconfig index 3d5eb6c..d1fa730 100644 --- a/drivers/video/fbdev/omap2/dss/Kconfig +++ b/drivers/video/fbdev/omap2/dss/Kconfig @@ -74,9 +74,6 @@ config OMAP4_DSS_HDMI help HDMI support for OMAP4 based SoCs. -config OMAP4_DSS_HDMI_AUDIO - bool - config OMAP5_DSS_HDMI bool "HDMI support for OMAP5" default n @@ -86,10 +83,6 @@ config OMAP5_DSS_HDMI Definition Multimedia Interface. See http://www.hdmi.org/ for HDMI specification. -config OMAP5_DSS_HDMI_AUDIO - depends on OMAP5_DSS_HDMI - bool - config OMAP2_DSS_SDI bool "SDI support" default n -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 00/15] Rework OMAP4+ HDMI audio support
The patches are based on: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git for-next The base, the patches, and couple of additional not-to-be-merged omap2plus_defconfig patches can be found here: git://git.ti.com/~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree.git omap-hdmi-audio Changes since v4: - Turn ASoC parts into a platform device driver - Some cleaning up - reorder the patches to keep bisect working Changes since v3: - Move ASoC parts into library module under sound/soc/omap - Come up with API for the library - Some cleaning up The patch set fixes OMAP4+ HDMI audio. The structure of the implementation looks a bit different than before. Instead of creating a driver specific API for a separate ASoC component driver to connect to, these patches implement a platform device driver under sound/soc/omap for ASoC side implementation. This driver should only be registered from OMAPDSS HDMI code. The ASoC side driver implements cpu-dai component using the callbacks provided by OMAPDSS. Omap-pcm is registered for platform component, dummy hdmi-audio-codec is registered for codec component, and asoc-simple-card is registered for machine driver. Big part of the HDMI audio code is still unchanged and there is a need for a cleanup there. Also there is still probably something wrong with speaker mapping of multi-channel streams. I will get back to cleaning up these issues later. Best regards, Jyri Jyri Sarha (15): OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value OMAPDSS: hdmi: Remove most of OMAP[45]_DSS_HDMI_AUDIO ifdefs OMAPDSS: hdmi4_core: Remove unused hdmi4_audio_get_dma_port() OMAPDSS: hdmi_wp: Add function for getting audio dma address OMAPDSS: hdmi: Make hdmi structure public OMAPDSS: hdmi: Add pdev pointer for audio_pdev in HDMI DRV data ASoC: omap-hdmi-audio: Add platfrom device for OMAP HDMI audio support OMAPDSS: Kconfig: Remove HDMI audio booleans from Kconfig OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedly OMAPDSS: hdmi4: Register ASoC platfrom device for omap hdmi audio OMAPDSS: hdmi5: Register ASoC platfrom device for omap hdmi audio ASoC: omap: Remove obsolete HDMI audio code and Kconfig options OMAPDSS: hdmi4: Remove callbacks for the old ASoC DAI driver OMAPDSS: hdmi5: Remove callbacks for the old ASoC DAI driver OMAPDSS: Remove all references to obsolete HDMI audio callbacks .../fbdev/omap2/displays-new/connector-hdmi.c | 99 - .../fbdev/omap2/displays-new/encoder-tpd12s015.c | 56 --- drivers/video/fbdev/omap2/dss/Kconfig |7 - drivers/video/fbdev/omap2/dss/hdmi.h | 35 +- drivers/video/fbdev/omap2/dss/hdmi4.c | 247 ++--- drivers/video/fbdev/omap2/dss/hdmi4_core.c | 14 - drivers/video/fbdev/omap2/dss/hdmi4_core.h |4 - drivers/video/fbdev/omap2/dss/hdmi5.c | 230 +--- drivers/video/fbdev/omap2/dss/hdmi5_core.c |6 - drivers/video/fbdev/omap2/dss/hdmi5_core.h |2 - drivers/video/fbdev/omap2/dss/hdmi_common.c|2 - drivers/video/fbdev/omap2/dss/hdmi_wp.c|8 +- include/sound/omap-hdmi-audio.h| 38 ++ include/video/omapdss.h| 31 -- sound/soc/omap/Kconfig | 22 +- sound/soc/omap/Makefile|6 +- sound/soc/omap/omap-hdmi-audio.c | 379 sound/soc/omap/omap-hdmi-card.c| 87 - sound/soc/omap/omap-hdmi.c | 364 --- sound/soc/omap/omap-hdmi.h | 38 -- 20 files changed, 675 insertions(+), 1000 deletions(-) create mode 100644 include/sound/omap-hdmi-audio.h create mode 100644 sound/soc/omap/omap-hdmi-audio.c delete mode 100644 sound/soc/omap/omap-hdmi-card.c delete mode 100644 sound/soc/omap/omap-hdmi.c delete mode 100644 sound/soc/omap/omap-hdmi.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 15/15] OMAPDSS: Remove all references to obsolete HDMI audio callbacks
In new model these callbacks are obsolete since the ASoC component drivers are integrated into the HDMI drivers and no callbacks are needed anymore. Signed-off-by: Jyri Sarha --- .../fbdev/omap2/displays-new/connector-hdmi.c | 99 .../fbdev/omap2/displays-new/encoder-tpd12s015.c | 56 --- include/video/omapdss.h| 31 -- 3 files changed, 186 deletions(-) diff --git a/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c b/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c index 131c6e2..dd36d71 100644 --- a/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c +++ b/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c @@ -170,98 +170,6 @@ static bool hdmic_detect(struct omap_dss_device *dssdev) return in->ops.hdmi->detect(in); } -static int hdmic_audio_enable(struct omap_dss_device *dssdev) -{ - struct panel_drv_data *ddata = to_panel_data(dssdev); - struct omap_dss_device *in = ddata->in; - int r; - - /* enable audio only if the display is active */ - if (!omapdss_device_is_enabled(dssdev)) - return -EPERM; - - r = in->ops.hdmi->audio_enable(in); - if (r) - return r; - - dssdev->audio_state = OMAP_DSS_AUDIO_ENABLED; - - return 0; -} - -static void hdmic_audio_disable(struct omap_dss_device *dssdev) -{ - struct panel_drv_data *ddata = to_panel_data(dssdev); - struct omap_dss_device *in = ddata->in; - - in->ops.hdmi->audio_disable(in); - - dssdev->audio_state = OMAP_DSS_AUDIO_DISABLED; -} - -static int hdmic_audio_start(struct omap_dss_device *dssdev) -{ - struct panel_drv_data *ddata = to_panel_data(dssdev); - struct omap_dss_device *in = ddata->in; - int r; - - /* -* No need to check the panel state. It was checked when trasitioning -* to AUDIO_ENABLED. -*/ - if (dssdev->audio_state != OMAP_DSS_AUDIO_ENABLED) - return -EPERM; - - r = in->ops.hdmi->audio_start(in); - if (r) - return r; - - dssdev->audio_state = OMAP_DSS_AUDIO_PLAYING; - - return 0; -} - -static void hdmic_audio_stop(struct omap_dss_device *dssdev) -{ - struct panel_drv_data *ddata = to_panel_data(dssdev); - struct omap_dss_device *in = ddata->in; - - in->ops.hdmi->audio_stop(in); - - dssdev->audio_state = OMAP_DSS_AUDIO_ENABLED; -} - -static bool hdmic_audio_supported(struct omap_dss_device *dssdev) -{ - struct panel_drv_data *ddata = to_panel_data(dssdev); - struct omap_dss_device *in = ddata->in; - - if (!omapdss_device_is_enabled(dssdev)) - return false; - - return in->ops.hdmi->audio_supported(in); -} - -static int hdmic_audio_config(struct omap_dss_device *dssdev, - struct omap_dss_audio *audio) -{ - struct panel_drv_data *ddata = to_panel_data(dssdev); - struct omap_dss_device *in = ddata->in; - int r; - - /* config audio only if the display is active */ - if (!omapdss_device_is_enabled(dssdev)) - return -EPERM; - - r = in->ops.hdmi->audio_config(in, audio); - if (r) - return r; - - dssdev->audio_state = OMAP_DSS_AUDIO_CONFIGURED; - - return 0; -} - static int hdmic_set_hdmi_mode(struct omap_dss_device *dssdev, bool hdmi_mode) { struct panel_drv_data *ddata = to_panel_data(dssdev); @@ -296,13 +204,6 @@ static struct omap_dss_driver hdmic_driver = { .detect = hdmic_detect, .set_hdmi_mode = hdmic_set_hdmi_mode, .set_hdmi_infoframe = hdmic_set_infoframe, - - .audio_enable = hdmic_audio_enable, - .audio_disable = hdmic_audio_disable, - .audio_start= hdmic_audio_start, - .audio_stop = hdmic_audio_stop, - .audio_supported= hdmic_audio_supported, - .audio_config = hdmic_audio_config, }; static int hdmic_probe_pdata(struct platform_device *pdev) diff --git a/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c b/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c index c891d8f..235e3d5 100644 --- a/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c +++ b/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c @@ -193,55 +193,6 @@ static bool tpd_detect(struct omap_dss_device *dssdev) return gpio_get_value_cansleep(ddata->hpd_gpio); } -static int tpd_audio_enable(struct omap_dss_device *dssdev) -{ - struct panel_drv_data *ddata = to_panel_data(dssdev); - struct omap_dss_device *in = ddata->in; - - return in->ops.hdmi->audio_enable(in); -} - -static void tpd_audio_disable(struct omap_dss_device *dssdev) -{ - struct panel_drv_data *ddata = to_panel_data(dssdev); - struct omap_dss_device *in = ddata->in; - - in->ops.hdmi->audio_disable(in); -}
[PATCH v5 14/15] OMAPDSS: hdmi5: Remove callbacks for the old ASoC DAI driver
Removes the OMAP5 HDMI audio callbacks for the old external DAI driver. Signed-off-by: Jyri Sarha --- drivers/video/fbdev/omap2/dss/hdmi5.c | 113 - 1 file changed, 113 deletions(-) diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c b/drivers/video/fbdev/omap2/dss/hdmi5.c index 360b31f..0a67c84 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi5.c +++ b/drivers/video/fbdev/omap2/dss/hdmi5.c @@ -493,112 +493,6 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev, return r; } -#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO) -static int hdmi_audio_enable(struct omap_dss_device *dssdev) -{ - int r; - - mutex_lock(&hdmi.lock); - - if (!hdmi_mode_has_audio(hdmi.cfg.hdmi_dvi_mode)) { - r = -EPERM; - goto err; - } - - r = hdmi_wp_audio_enable(&hdmi.wp, true); - if (r) - goto err; - - mutex_unlock(&hdmi.lock); - return 0; - -err: - mutex_unlock(&hdmi.lock); - return r; -} - -static void hdmi_audio_disable(struct omap_dss_device *dssdev) -{ - hdmi_wp_audio_enable(&hdmi.wp, false); -} - -static int hdmi_audio_start(struct omap_dss_device *dssdev) -{ - return hdmi_wp_audio_core_req_enable(&hdmi.wp, true); -} - -static void hdmi_audio_stop(struct omap_dss_device *dssdev) -{ - hdmi_wp_audio_core_req_enable(&hdmi.wp, false); -} - -static bool hdmi_audio_supported(struct omap_dss_device *dssdev) -{ - bool r; - - mutex_lock(&hdmi.lock); - - r = hdmi_mode_has_audio(hdmi.cfg.hdmi_dvi_mode); - - mutex_unlock(&hdmi.lock); - return r; -} - -static int hdmi_audio_config(struct omap_dss_device *dssdev, - struct omap_dss_audio *audio) -{ - int r; - u32 pclk = hdmi.cfg.timings.pixelclock; - - mutex_lock(&hdmi.lock); - - if (!hdmi_mode_has_audio(hdmi.cfg.hdmi_dvi_mode)) { - r = -EPERM; - goto err; - } - - r = hdmi5_audio_config(&hdmi.core, &hdmi.wp, audio, pclk); - if (r) - goto err; - - mutex_unlock(&hdmi.lock); - return 0; - -err: - mutex_unlock(&hdmi.lock); - return r; -} -#else -static int hdmi_audio_enable(struct omap_dss_device *dssdev) -{ - return -EPERM; -} - -static void hdmi_audio_disable(struct omap_dss_device *dssdev) -{ -} - -static int hdmi_audio_start(struct omap_dss_device *dssdev) -{ - return -EPERM; -} - -static void hdmi_audio_stop(struct omap_dss_device *dssdev) -{ -} - -static bool hdmi_audio_supported(struct omap_dss_device *dssdev) -{ - return false; -} - -static int hdmi_audio_config(struct omap_dss_device *dssdev, - struct omap_dss_audio *audio) -{ - return -EPERM; -} -#endif - static int hdmi_set_infoframe(struct omap_dss_device *dssdev, const struct hdmi_avi_infoframe *avi) { @@ -627,13 +521,6 @@ static const struct omapdss_hdmi_ops hdmi_ops = { .read_edid = hdmi_read_edid, .set_infoframe = hdmi_set_infoframe, .set_hdmi_mode = hdmi_set_hdmi_mode, - - .audio_enable = hdmi_audio_enable, - .audio_disable = hdmi_audio_disable, - .audio_start= hdmi_audio_start, - .audio_stop = hdmi_audio_stop, - .audio_supported= hdmi_audio_supported, - .audio_config = hdmi_audio_config, }; static void hdmi_init_output(struct platform_device *pdev) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 01/15] OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value
The OMAP5 HDMI audio implementation needs HDMI_AUDIO_LAYOUT_6CH in hdmi_core_audio_layout enum. I found the correct value from ti-linux 3.8 tree. Signed-off-by: Jyri Sarha --- drivers/video/fbdev/omap2/dss/hdmi.h |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h b/drivers/video/fbdev/omap2/dss/hdmi.h index 262771b..1f01068 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi.h +++ b/drivers/video/fbdev/omap2/dss/hdmi.h @@ -160,7 +160,8 @@ enum hdmi_audio_blk_strt_end_sig { enum hdmi_core_audio_layout { HDMI_AUDIO_LAYOUT_2CH = 0, - HDMI_AUDIO_LAYOUT_8CH = 1 + HDMI_AUDIO_LAYOUT_8CH = 1, + HDMI_AUDIO_LAYOUT_6CH = 2 }; enum hdmi_core_cts_mode { -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx
On Mon, Sep 15, 2014 at 06:42:04PM +0200, Sebastian Andrzej Siewior wrote: > On 09/12/2014 12:28 PM, Frans Klaver wrote: > > port config is 115200 8N1. I don't recall doing anything special. I > > boot, login, less file and get a lock. > > So I booted my mini Debian 7.6 (basic system + openssh) on my beagle > bone black which is: > > [0.00] AM335X ES2.0 (neon ) > > configured a console, login, invoked "less file". The file was shown, I > hit on the space key so less shows me more of the file. No lock-up. > I tried booting via NFS and MMC. I tried various files with less. > > My dot config is here > https://breakpoint.cc/config-am335x-bb.txt.xz > > If there is nothing specific to the file you do less on I have no idea > what else it could if it is not the config. I'll test your config and go through the differences. Thanks, Frans -- 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 3/4] tty: omap-serial: use threaded interrupt handler
On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote: > On 09/15/2014 11:39 AM, Peter Hurley wrote: > > On 09/15/2014 10:00 AM, Frans Klaver wrote: > >> At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart > >> rx buffer overflows within 30 seconds. Threading the interrupt handling > >> reduces > >> this to about 170 overflows in 10 minutes. > > > > Why is the threadirqs kernel boot option not sufficient? > > Or conversely, shouldn't this be selectable? > I wasn't aware of the threadirqs boot option. I also wouldn't know if this should be selectable. What would be a reason to favor the non-threaded irq over the threaded irq? > Also, do you see the same performance differential when you implement this > in the 8250 driver (that is, on top of Sebastian's omap->8250 conversion)? > I haven't gotten Sebastian's driver to work properly yet on the console. There was no reason for me yet to throw my omap changes on top of Sebastian's queue. > > PS - To overflow the 64 byte RX FIFO at those data rates means interrupt > > latency in excess of 250us? At 3686400 baud it should take about 174 us to fill a 64 byte buffer. I haven't done any measurements on the interrupt latency though. If you consider that we're sending about 1kB of data, 240 times a second, we're spending a lot of time reading data from the uart. I can imagine the system has other work to do as well. This doesn't mean that we're not interested in Sebastian's driver anymore though. We really want that dma support. Thanks, Frans -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] nand: omap2: Replace pr_err with dev_err
On 09/11/2014 06:02 PM, Ezequiel Garcia wrote: > Usage of pr_err is frowned upon, so replace it with dev_err. > Aditionally, the message on nand_bch_init() error is redundant, > since proper error is showed if the function fails. You could have omitted the details about nand_bch_init() in the commit message. > > Signed-off-by: Ezequiel Garcia Acked-by: Roger Quadros cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] nand: omap2: Remove horrible ifdefs to fix module probe
On 09/11/2014 06:02 PM, Ezequiel Garcia wrote: > The current code abuses ifdefs to determine if the selected ECC scheme > is supported by the running kernel. As a result the code is hard to read, > and it also fails to load as a module. > > This commit removes all the ifdefs and instead introduces a function > omap2_nand_ecc_check() to check if the ECC is supported by using > IS_ENABLED(CONFIG_xxx). > > Since IS_ENABLED() is true when a config is =y or =m, this change fixes the > module so it can be loaded with no issues. > > Signed-off-by: Ezequiel Garcia Acked-by: Roger Quadros cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] nand: omap2: Add support for flash-based bad block table
On 09/11/2014 06:02 PM, Ezequiel Garcia wrote: > This commit adds a new platform-data boolean property that enables use > of a flash-based bad block table. This can also be enabled by setting > the 'nand-on-flash-bbt' devicetree property. > > If the flash BBT is not enabled, the driver falls back to use OOB > bad block markers only, as before. If the flash BBT is enabled the > kernel will keep track of bad blocks using a BBT, in addition to > the OOB markers. > > As explained by Brian Norris the reasons for using a BBT are: > > "" > The primary reason would be that NAND datasheets specify it these days. > A better argument is that nobody guarantees that you can write a > bad block marker to a worn out block; you may just get program failures. > > This has been acknowledged by several developers over the last several > years. > > Additionally, you get a boot-time performance improvement if you only > have to read a few pages, instead of a page or two from every block on > the flash. > "" > > Signed-off-by: Ezequiel Garcia Acked-by: Roger Quadros cheers, -roger -- 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