Re: [PATCH 5/5] tty: serial: Add 8250-core based omap driver
* Sebastian Andrzej Siewior bige...@linutronix.de [140716 07:47]: This patch provides a 8250-core based UART driver for the internal OMAP UART. The longterm goal is to provide the same functionality as the current OMAP uart driver and hopefully DMA support which could borrowed from the 8250-core. It has been only tested as console UART on am335x-evm and dra7-evm. The device name is ttyS based instead of ttyO. If a ttyO based node name is required please ask udev for it. If both driver are activated (this and omap-serial) then this serial driver will take control over the device due to the link order v3…v4: - drop RS485 support - wire up -throttle / -unthrottle v2…v3: - wire up startup shutdown for wakeup-irq handling. - RS485 handling (well the core does). v1…v2: - added runtime PM. Could somebody could plese double check this? - added omap_8250_set_termios() Seems to boot a bit further now with output from serial console initially, then I'm getting the following error again that's probably related to clocks not enabled when the registers are accessed: [1.050231] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [1.068664] 4806a000.serial: ttyS0 at MMIO 0x4806a000 (irq = 88, base_baud = 300) is a OMAP [1.074676] 4806c000.serial: ttyS1 at MMIO 0x4806c000 (irq = 89, base_baud = 300) is a OMAP [1.078613] console [ttyS2] disabled [1.079193] 4902.serial: ttyS2 at MMIO 0x4902 (irq = 90, base_baud = 300) is a OMAP [1.938110] console [ttyS2] enabled [1.946533] 49042000.serial: ttyS3 at MMIO 0x49042000 (irq = 96, base_baud = 300) is a OMAP ... [5.538421] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfb02 [5.546142] Internal error: : 1028 [#1] SMP ARM [5.550720] Modules linked in: [5.553802] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-rc5-00070-g1f95851 #129 [5.561584] task: ce058b00 ti: ce05a000 task.ti: ce05a000 [5.567016] PC is at mem32_serial_in+0xc/0x1c [5.571411] LR is at serial8250_do_startup+0xc8/0x89c [5.576507] pc : [c034731c]lr : [c034a988]psr: 6113 [5.576507] sp : ce05bcf0 ip : c0a008e8 fp : ce46c400 [5.588043] r10: r9 : cda7a680 r8 : ce46c68c [5.593292] r7 : ce46c400 r6 : r5 : ce548e10 r4 : c10abf34 [5.599853] r3 : fb02 r2 : 0002 r1 : fb02 r0 : c10abf34 [5.606414] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [5.613769] Control: 10c5387d Table: 80004019 DAC: 0015 [5.619537] Process swapper/0 (pid: 1, stack limit = 0xce05a248) ... [5.835601] [c034731c] (mem32_serial_in) from [c034a988] (serial8250_do_startup+0xc8/0x89c) [5.844360] [c034a988] (serial8250_do_startup) from [c034c58c] (omap_8250_startup+0x5c/0xdc) [5.853179] [c034c58c] (omap_8250_startup) from [c034b170] (serial8250_startup+0x14/0x20) [5.861755] [c034b170] (serial8250_startup) from [c0346584] (uart_startup.part.3+0x7c/0x1dc) [5.870605] [c0346584] (uart_startup.part.3) from [c03470f4] (uart_open+0xe4/0x124) [5.878662] [c03470f4] (uart_open) from [c032c528] (tty_open+0x130/0x58c) [5.885864] [c032c528] (tty_open) from [c01216ec] (chrdev_open+0x9c/0x174) [5.893127] [c01216ec] (chrdev_open) from [c011b8cc] (do_dentry_open+0x1d0/0x310) [5.901000] [c011b8cc] (do_dentry_open) from [c011bd90] (finish_open+0x34/0x4c) [5.908721] [c011bd90] (finish_open) from [c012a8f0] (do_last.isra.27+0x5a4/0xb98) [5.916687] [c012a8f0] (do_last.isra.27) from [c012af98] (path_openat+0xb4/0x5e4) [5.924560] [c012af98] (path_openat) from [c012b7d4] (do_filp_open+0x2c/0x80) [5.932098] [c012b7d4] (do_filp_open) from [c011cd0c] (do_sys_open+0x100/0x1d0) [5.939788] [c011cd0c] (do_sys_open) from [c07b6ce0] (kernel_init_freeable+0x124/0x1c8) [5.948211] [c07b6ce0] (kernel_init_freeable) from [c054ed28] (kernel_init+0x8/0xe4) [5.956359] [c054ed28] (kernel_init) from [c000e868] (ret_from_fork+0x14/0x2c) ... [5.974792] In-band Error seen by MPU at address 0 [5.979675] [ cut here ] [5.984344] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:162 omap3_l3_app_irq+0xcc/0x124() ... 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 00/10] ARM: OMAP2+: PRCM cleanup series for 3.17
* Tero Kristo t-kri...@ti.com [140704 07:12]: Hi, Here's a small PRCM cleanup series against 3.16-rc1, meant for 3.17 if at all possible. Basically some cleanup to remove the direct CM/PRM register accesses outside PRCM drivers. This set is touching the OMAP2/ OMAP3 code only. This series is part of the ongoing work to make PRCM a separate driver. Testing done: - omap2430-sdp : boot - omap3-beagle : boot, suspend/resume (ret), suspend/resume (off) Working branch: - tree: https://github.com/t-kristo/linux-pm.git - branch: for-v3.17/cm-prm-cleanup Great seems to work for me for my omap3 off-idle test cases, so pulling this into omap-for-v3.17/soc. 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 5/5] tty: serial: Add 8250-core based omap driver
* Tony Lindgren | 2014-07-17 00:09:00 [-0700]:
Seems to boot a bit further now with output from serial console
initially, then I'm getting the following error again that's probably
related to clocks not enabled when the registers are accessed:
It is (mostly) the same thing as before. We have additionally
omap_8250_startup() in the backtrace but it is the same thing.
So you say I miss a clock? Looking through serial8250_do_startup() I see:
- pm_runtime_get_sync(port-dev); which should get the clocks up
- serial8250_clear_fifos() which does a write at address + 8. Seems to
work.
- serial_port_in(port, UART_LSR); does a read at address + 0x14, seems
to work.
- serial_port_in(port, UART_RX); does a read at address + 0. This is
probably the bad one.
Now comparing with omap-serial I noticed that I do a 32bit access
instead a 16bit.
Could you please try the following hack:
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 2e4a93b..94af5a3 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -420,13 +420,13 @@ static void mem_serial_out(struct uart_port *p, int
offset, int value)
static void mem32_serial_out(struct uart_port *p, int offset, int value)
{
offset = offset p-regshift;
- writel(value, p-membase + offset);
+ writew(value, p-membase + offset);
}
static unsigned int mem32_serial_in(struct uart_port *p, int offset)
{
offset = offset p-regshift;
- return readl(p-membase + offset);
+ return readw(p-membase + offset);
}
static unsigned int io_serial_in(struct uart_port *p, int offset)
besides that, I don't see what could be different.
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: [Re-send PATCH 1/1] arm: dra7xx: Add hwmod data for MDIO and CPSW
* Mugunthan V N mugunthan...@ti.com [140708 06:18]:
Adding hwmod data for CPSW and MDIO which is present in DRA7xx SoC
Cc: Rajendra Nayak rna...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
This patch was already send twice on 2013-10-18 and 2014-05-13. Adding
more people in Cc to review the patch.
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 65
+++
1 file changed, 65 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 20b4398..45b5113 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -273,6 +273,56 @@ static struct omap_hwmod dra7xx_ctrl_module_wkup_hwmod =
{
};
/*
+ * 'gmac' class
+ * cpsw/gmac sub system
+ */
+static struct omap_hwmod_class_sysconfig dra7xx_gmac_sysc = {
+ .rev_offs = 0x0,
+ .sysc_offs = 0x8,
+ .syss_offs = 0x4,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
+SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | MSTANDBY_FORCE |
+MSTANDBY_NO),
+ .sysc_fields= omap_hwmod_sysc_type3,
+};
We seem to have this layout WR_SOFT_RESET and WR_CONTROL in the TRM:
WR_SOFT_RESET
[0] SOFT_RESET
WR_CONTROL
[3:2] MMR_STDBYMODE 0 = force-idle, 1 = no-standby
[1:0] MMR_IDLEMODE0 = force-idle, 1 = no-idle
And so it seems to match what am33xx also has for am33xx_cpgmac_sysc
and am33xx TRM for 14.5.9 CONTROL register. So as far as I'm concerned:
Acked-by: Tony Lindgren t...@atomide.com
--
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: [Re-send PATCH 1/1] arm: dra7xx: Add hwmod data for MDIO and CPSW
* Paul Walmsley p...@pwsan.com [140716 11:59]: On Wed, 16 Jul 2014, Sebastian Andrzej Siewior wrote: On 2014-07-15 20:21:21 [+], Paul Walmsley wrote: Acked-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc This is basically what Tony hasked me to do: No IRQ numbers iomem. Sorry - I'm a bit confused - Sebastian, did you test this one? If so, is it okay to add a Tested-by from you? Tested-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc Thanks Sebastian. Mugunthan, next step would be for you to get a Reviewed-by: by someone who has access to the (non-public) DRA7xx TRM, and can review for SoC integration. Since Rajendra is no longer at TI, the right person is probably Tony. Then this patch should be mergeable. Yeah took a look at it and acked it. 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 5/5] tty: serial: Add 8250-core based omap driver
* Sebastian Andrzej Siewior bige...@linutronix.de [140717 00:44]: * Tony Lindgren | 2014-07-17 00:09:00 [-0700]: Seems to boot a bit further now with output from serial console initially, then I'm getting the following error again that's probably related to clocks not enabled when the registers are accessed: It is (mostly) the same thing as before. We have additionally omap_8250_startup() in the backtrace but it is the same thing. So you say I miss a clock? Looking through serial8250_do_startup() I see: - pm_runtime_get_sync(port-dev); which should get the clocks up - serial8250_clear_fifos() which does a write at address + 8. Seems to work. - serial_port_in(port, UART_LSR); does a read at address + 0x14, seems to work. - serial_port_in(port, UART_RX); does a read at address + 0. This is probably the bad one. Hmm it could be that it works for a while because the clocks are on from the bootloader and pm_runtime calls won't do anything. This could happen if the interconnect data based on the ti,hwmods entry is not getting matched to the new driver. This gets initialized when the device entry gets created in omap_device_build_from_dt(). Or maybe something now affects the clock aliases? It seems that we are still missing the clocks entries in the .dtsi files, see the mappings with $ git grep uart drivers/clk/ti/ Now comparing with omap-serial I noticed that I do a 32bit access instead a 16bit. Could you please try the following hack: No change with that :) 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 v4 03/11] ARM: OMAP2+: timer: Add suspend-resume callbacks for clkevent device
* Dave Gerlach d-gerl...@ti.com [140716 13:19]: On 07/15/2014 01:48 AM, Tony Lindgren wrote: It's best to register these kind of functions as platform_data in pdata-quirks.c auxdata. That way when this moves to live in drivers/clocksource the driver does not need to know anything about the interconnect specific registers. Perhaps I spoke too soon on this, I can't use pdata-quirks right now to pass the idle/unidle functions. The clockevent source is special and reads the dt node itself and then marks it as disabled so nothing else can touch it. No device is created and no auxdata matched. I will gladly fix it up once the driver is ready to move but right now I can't use any existing functionality to do it. OK. So maybe just initialize the function pointers during init and use appropriate naming so the function pointers will stay usable later on too once it's a driver. 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 5/5] tty: serial: Add 8250-core based omap driver
On 07/17/2014 10:12 AM, Tony Lindgren wrote:
Hmm it could be that it works for a while because the clocks are on
from the bootloader and pm_runtime calls won't do anything. This
could happen if the interconnect data based on the ti,hwmods entry
is not getting matched to the new driver. This gets initialized when
the device entry gets created in omap_device_build_from_dt().
Or maybe something now affects the clock aliases? It seems that we
are still missing the clocks entries in the .dtsi files, see the
mappings with $ git grep uart drivers/clk/ti/
I've been looking for something completely different while I noticed
this:
in drivers/tty/serial/omap-serial.c
| static struct platform_driver serial_omap_driver = {
| .driver = {
| .name = DRIVER_NAME,
| },
| };
|
and DRIVER_NAME should come from include/linux/platform_data/serial-omap.h
Looking further, I've found arch/arm/mach-omap2/serial.c:
| void __init omap_serial_init_port(struct omap_board_data *bdata,
| struct omap_uart_port_info *info)
| {
| char *name
…
| name = DRIVER_NAME;
…
| pdev = omap_device_build(name, uart-num, oh, pdata, pdata_size);
…
|
Would this explain it?
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
[PATCH CFT] 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 is configured at compile time rather than runtime. Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: Arnd Bergmann arnd.bergm...@linaro.org Cc: linux-omap@vger.kernel.org --- 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 6f9664a..0881853 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -463,6 +463,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 !ARCH_OMAP730 + 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 !ARCH_OMAP730 + 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 !ARCH_OMAP730 + 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 @@ -505,6 +529,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 @@ -1106,6 +1154,9 @@ config DEBUG_UART_PHYS default 0xfe80 if ARCH_IOP32X 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 || \ @@ -1173,6 +1224,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 @@ -1183,7 +1237,8 @@
[PATCH] iommu/omap: Remove virtual memory manager
The OMAP3 ISP driver was the only user of the OMAP IOVMM API. Now that
is has been ported to the DMA API, remove the unused virtual memory
manager.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Joerg, could you please pick this patch up for v3.17 if possible ?
drivers/iommu/Kconfig| 10 +-
drivers/iommu/Makefile | 1 -
drivers/iommu/omap-iommu-debug.c | 114 --
drivers/iommu/omap-iommu.c | 2 -
drivers/iommu/omap-iommu.h | 6 +-
drivers/iommu/omap-iovmm.c | 791 ---
include/linux/omap-iommu.h | 37 +-
7 files changed, 8 insertions(+), 953 deletions(-)
delete mode 100644 drivers/iommu/omap-iovmm.c
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index d260605..a1f0fad 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -143,16 +143,12 @@ config OMAP_IOMMU
depends on ARCH_OMAP2PLUS
select IOMMU_API
-config OMAP_IOVMM
- tristate OMAP IO Virtual Memory Manager Support
- depends on OMAP_IOMMU
-
config OMAP_IOMMU_DEBUG
- tristate Export OMAP IOMMU/IOVMM internals in DebugFS
- depends on OMAP_IOVMM DEBUG_FS
+ tristate Export OMAP IOMMU internals in DebugFS
+ depends on DEBUG_FS
help
Select this to see extensive information about
- the internal state of OMAP IOMMU/IOVMM in debugfs.
+ the internal state of OMAP IOMMU in debugfs.
Say N unless you know you need this.
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 8893bad..6a4a00e 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -11,7 +11,6 @@ obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o
obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o irq_remapping.o
obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
obj-$(CONFIG_OMAP_IOMMU) += omap-iommu2.o
-obj-$(CONFIG_OMAP_IOVMM) += omap-iovmm.o
obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o
obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o
diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
index 80fffba..531658d 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -213,116 +213,6 @@ static ssize_t debug_read_pagetable(struct file *file,
char __user *userbuf,
return bytes;
}
-static ssize_t debug_read_mmap(struct file *file, char __user *userbuf,
- size_t count, loff_t *ppos)
-{
- struct device *dev = file-private_data;
- struct omap_iommu *obj = dev_to_omap_iommu(dev);
- char *p, *buf;
- struct iovm_struct *tmp;
- int uninitialized_var(i);
- ssize_t bytes;
-
- buf = (char *)__get_free_page(GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
- p = buf;
-
- p += sprintf(p, %-3s %-8s %-8s %6s %8s\n,
-No, start, end, size, flags);
- p += sprintf(p, -\n);
-
- mutex_lock(iommu_debug_lock);
-
- list_for_each_entry(tmp, obj-mmap, list) {
- size_t len;
- const char *str = %3d %08x-%08x %6x %8x\n;
- const int maxcol = 39;
-
- len = tmp-da_end - tmp-da_start;
- p += snprintf(p, maxcol, str,
- i, tmp-da_start, tmp-da_end, len, tmp-flags);
-
- if (PAGE_SIZE - (p - buf) maxcol)
- break;
- i++;
- }
-
- bytes = simple_read_from_buffer(userbuf, count, ppos, buf, p - buf);
-
- mutex_unlock(iommu_debug_lock);
- free_page((unsigned long)buf);
-
- return bytes;
-}
-
-static ssize_t debug_read_mem(struct file *file, char __user *userbuf,
- size_t count, loff_t *ppos)
-{
- struct device *dev = file-private_data;
- char *p, *buf;
- struct iovm_struct *area;
- ssize_t bytes;
-
- count = min_t(ssize_t, count, PAGE_SIZE);
-
- buf = (char *)__get_free_page(GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
- p = buf;
-
- mutex_lock(iommu_debug_lock);
-
- area = omap_find_iovm_area(dev, (u32)ppos);
- if (!area) {
- bytes = -EINVAL;
- goto err_out;
- }
- memcpy(p, area-va, count);
- p += count;
-
- bytes = simple_read_from_buffer(userbuf, count, ppos, buf, p - buf);
-err_out:
- mutex_unlock(iommu_debug_lock);
- free_page((unsigned long)buf);
-
- return bytes;
-}
-
-static ssize_t debug_write_mem(struct file *file, const char __user *userbuf,
- size_t count, loff_t *ppos)
-{
- struct device *dev = file-private_data;
- struct iovm_struct *area;
- char *p, *buf;
-
- count = min_t(size_t, count, PAGE_SIZE);
-
- buf = (char *)__get_free_page(GFP_KERNEL);
- if (!buf)
-
Re: [PATCH] media:platform: OMAP3 camera support needs VIDEOBUF2_DMA_CONTIG
Hi Peter, Thank you for the patch. On Friday 04 July 2014 09:51:47 Peter Meerwald wrote: drivers/built-in.o: In function `isp_video_open': /src/linux/drivers/media/platform/omap3isp/ispvideo.c:1253: undefined reference to `vb2_dma_contig_memops' drivers/built-in.o: In function `omap3isp_video_init': /src/linux/drivers/media/platform/omap3isp/ispvideo.c:1344: undefined reference to `vb2_dma_contig_init_ctx' /src/linux/drivers/media/platform/omap3isp/ispvideo.c:1350: undefined reference to `vb2_dma_contig_cleanup_ctx' drivers/built-in.o: In function `omap3isp_video_cleanup': /src/linux/drivers/media/platform/omap3isp/ispvideo.c:1381: undefined reference to `vb2_dma_contig_cleanup_ctx' make: *** [vmlinux] Error 1 Signed-off-by: Peter Meerwald pme...@pmeerw.net Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com and applied to my tree, with the select VIDEOBUF2_DMA_CONTIG and select OMAP_IOMMU lines swapped below to keep them alphabetically sorted. --- not sure if this is the right way to fix, at least my kernel compiles drivers/media/platform/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 8108c69..e1ff228 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -95,6 +95,7 @@ config VIDEO_OMAP3 tristate OMAP 3 Camera support depends on VIDEO_V4L2 I2C VIDEO_V4L2_SUBDEV_API ARCH_OMAP3 select ARM_DMA_USE_IOMMU + select VIDEOBUF2_DMA_CONTIG select OMAP_IOMMU ---help--- Driver for an OMAP 3 camera controller. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/5] Add Video Processing Front End Support
On Tue, Jul 15, 2014 at 6:56 PM, Felipe Balbi ba...@ti.com wrote: Hi all, the following patches add suport for AM43xx's Video Processing Front End (VPFE). Full documentation is available at [1] chapter 14. This driver has been tested with linux-next from yesterday, plus my (already queued) am437x starter kit patches, plus these patches, plus the sensor driver which, saddly enough, we're not allowed to release :-( This driver has almost full v4l2-compliance with only 2 failures (I'll take hints on how to properly fix them) as below: fail: v4l2-compliance.cpp(419): !doioctl(node2, VIDIOC_S_PRIORITY, prio) test VIDIOC_G/S_PRIORITY: FAIL fail: v4l2-test-formats.cpp(319): pixelformat != V4L2_PIX_FMT_JPEG colorspace == V4L2_COLORSPACE_JPEG fail: v4l2-test-formats.cpp(418): testColorspace(pix.pixelformat, pix.colorspace) test VIDIOC_G_FMT: FAIL I have also tested with gst-launch using fbdevsink and I can see my ugly mug just fine. Please give this a thorough review and let me know of any problems which need to be sorted out and I'll try to help out as time allows. cheers [1] http://www.ti.com/lit/pdf/spruhl7 Benoit Parrot (4): Media: platform: Add ti-vpfe driver for AM437x device arm: omap: hwmod: add hwmod entries for AM437x VPFE arm: boot: dts: am4372: add vpfe DTS entries arm: dts: am43x-epos: Add VPFE DTS entries Darren Etheridge (1): ARM: dts: am437x-sk-evm: add vpfe support and ov2659 sensor arch/arm/boot/dts/am4372.dtsi | 16 + arch/arm/boot/dts/am437x-sk-evm.dts | 63 + arch/arm/boot/dts/am43x-epos-evm.dts | 54 + arch/arm/mach-omap2/omap_hwmod_43xx_data.c| 56 + arch/arm/mach-omap2/prcm43xx.h|3 +- drivers/media/platform/Kconfig|1 + drivers/media/platform/Makefile |2 + drivers/media/platform/ti-vpfe/Kconfig| 12 + drivers/media/platform/ti-vpfe/Makefile |2 + drivers/media/platform/ti-vpfe/am437x_isif.c | 1053 + drivers/media/platform/ti-vpfe/am437x_isif.h | 355 +++ drivers/media/platform/ti-vpfe/am437x_isif_regs.h | 144 ++ drivers/media/platform/ti-vpfe/vpfe_capture.c | 2478 + drivers/media/platform/ti-vpfe/vpfe_capture.h | 263 +++ 14 files changed, 4501 insertions(+), 1 deletion(-) Missing documentation for DT ? Thanks, --Prabhakar Lad create mode 100644 drivers/media/platform/ti-vpfe/Kconfig create mode 100644 drivers/media/platform/ti-vpfe/Makefile create mode 100644 drivers/media/platform/ti-vpfe/am437x_isif.c create mode 100644 drivers/media/platform/ti-vpfe/am437x_isif.h create mode 100644 drivers/media/platform/ti-vpfe/am437x_isif_regs.h create mode 100644 drivers/media/platform/ti-vpfe/vpfe_capture.c create mode 100644 drivers/media/platform/ti-vpfe/vpfe_capture.h -- 2.0.0.390.gcb682f8 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] tty: serial: Add 8250-core based omap driver
Hi,
On Wed, Jul 16, 2014 at 04:45:03PM +0200, Sebastian Andrzej Siewior wrote:
+static int omap_8250_startup(struct uart_port *port)
+{
+ struct uart_8250_port *up =
+ container_of(port, struct uart_8250_port, port);
+ struct omap8250_priv *priv = port-private_data;
+
+ int ret;
+
+ if (priv-wakeirq) {
+ ret = request_irq(priv-wakeirq, omap_wake_irq,
+ port-irqflags, wakeup irq, port);
+ if (ret)
+ return ret;
+ disable_irq(priv-wakeirq);
+ }
+
+ ret = serial8250_do_startup(port);
+ if (ret)
+ goto err;
+
+ pm_runtime_get_sync(port-dev);
should this pm_runtime_get_sync() be placed above
serial8250_do_startup() call ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 5/5] tty: serial: Add 8250-core based omap driver
On 07/17/2014 04:54 PM, Felipe Balbi wrote:
Hi,
On Wed, Jul 16, 2014 at 04:45:03PM +0200, Sebastian Andrzej Siewior wrote:
+static int omap_8250_startup(struct uart_port *port)
+{
+struct uart_8250_port *up =
+container_of(port, struct uart_8250_port, port);
+struct omap8250_priv *priv = port-private_data;
+
+int ret;
+
+if (priv-wakeirq) {
+ret = request_irq(priv-wakeirq, omap_wake_irq,
+port-irqflags, wakeup irq, port);
+if (ret)
+return ret;
+disable_irq(priv-wakeirq);
+}
+
+ret = serial8250_do_startup(port);
+if (ret)
+goto err;
+
+pm_runtime_get_sync(port-dev);
should this pm_runtime_get_sync() be placed above
serial8250_do_startup() call ?
I don't think it matters since serial8250_do_startup() has its own
pm_runtime_get_sync().
-startup(), -shutdown() are called via omap callbacks so we could
spare in the 8250-core if we do it in the omap code before invoking the
function. The same goes for serial8250_set_termios() which is not used
by omap but has those runtime-pm stuff, too.
It would be wrong if someone would use the serial8250_do_startup()
without his own runtime-pm get but it is omap only which does this
things.
So it is not used by anyone else (right now) and if you want to keep it
to a minimum I could remove them from those places.
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 4/5] tty: serial: 8250 core: add runtime pm
* Peter Hurley | 2014-07-17 11:31:59 [-0400]:
On 07/16/2014 12:06 PM, Felipe Balbi wrote:
On Wed, Jul 16, 2014 at 05:54:56PM +0200, Sebastian Andrzej Siewior wrote:
On 07/16/2014 05:16 PM, Felipe Balbi wrote:
I wonder if you should get_sync() on start_tx() and only
put_autosuspend() at stop_tx(). I guess the outcome would be
largely the same, no ?
I just opened minicom on ttyS0 and gave a try. start_tx() was invoked
each time I pressed a key (sent a character). I haven't seen stop_tx()
even after after I closed minicom. I guess stop_tx() is invoked if you
switch half-duplex communication.
that's bad, I expected stop to be called also after each character.
The 8250 core auto-stops tx when the tx ring buffer is empty (except
in the case of dma, where stopping tx isn't necessary).
This is correct. So this is what I have now for the non-dma case:
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 2e4a93b..480a1c0 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1283,6 +1283,9 @@ static inline void __stop_tx(struct uart_8250_port *p)
if (p-ier UART_IER_THRI) {
p-ier = ~UART_IER_THRI;
serial_out(p, UART_IER, p-ier);
+
+ pm_runtime_mark_last_busy(p-port.dev);
+ pm_runtime_put_autosuspend(p-port.dev);
}
}
@@ -1310,12 +1313,12 @@ static void serial8250_start_tx(struct uart_port *port)
struct uart_8250_port *up =
container_of(port, struct uart_8250_port, port);
- pm_runtime_get_sync(port-dev);
if (up-dma !serial8250_tx_dma(up)) {
goto out;
} else if (!(up-ier UART_IER_THRI)) {
up-ier |= UART_IER_THRI;
+ pm_runtime_get_sync(port-dev);
serial_port_out(port, UART_IER, up-ier);
if (up-bugs UART_BUG_TXEN) {
unsigned char lsr;
@@ -1500,9 +1503,10 @@ void serial8250_tx_chars(struct uart_8250_port *up)
uart_write_wakeup(port);
DEBUG_INTR(THRE...);
-
+#if 0
if (uart_circ_empty(xmit))
__stop_tx(up);
+#endif
}
EXPORT_SYMBOL_GPL(serial8250_tx_chars);
and now I need to come up with something that is not if (port != omap)
for that #if 0 block. The code disables the TX FIFO empty interrupt once
the transfer is complete. I want to call __stop_tx() once the tx fifo is
empty.
Felipe, Would a check for dev-power.use_autosuspend be the right thing
to do?
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] iommu/omap: Remove virtual memory manager
Hi Laurent,
On 07/17/2014 06:09 AM, Laurent Pinchart wrote:
The OMAP3 ISP driver was the only user of the OMAP IOVMM API. Now that
is has been ported to the DMA API, remove the unused virtual memory
manager.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Joerg, could you please pick this patch up for v3.17 if possible ?
Need one minor change as below, otherwise patch is good.
drivers/iommu/Kconfig| 10 +-
drivers/iommu/Makefile | 1 -
drivers/iommu/omap-iommu-debug.c | 114 --
drivers/iommu/omap-iommu.c | 2 -
drivers/iommu/omap-iommu.h | 6 +-
drivers/iommu/omap-iovmm.c | 791
---
include/linux/omap-iommu.h | 37 +-
7 files changed, 8 insertions(+), 953 deletions(-)
delete mode 100644 drivers/iommu/omap-iovmm.c
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index d260605..a1f0fad 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -143,16 +143,12 @@ config OMAP_IOMMU
depends on ARCH_OMAP2PLUS
select IOMMU_API
-config OMAP_IOVMM
- tristate OMAP IO Virtual Memory Manager Support
- depends on OMAP_IOMMU
-
config OMAP_IOMMU_DEBUG
- tristate Export OMAP IOMMU/IOVMM internals in DebugFS
- depends on OMAP_IOVMM DEBUG_FS
+ tristate Export OMAP IOMMU internals in DebugFS
+ depends on DEBUG_FS
This module is relevant only when OMAP_IOMMU is enabled, so this should
be depends on OMAP_IOMMU DEBUG_FS. The dependency is inherent before
through OMAP_IOVMM. Otherwise, this module can be built by itself and
results in some build errors.
help
Select this to see extensive information about
- the internal state of OMAP IOMMU/IOVMM in debugfs.
+ the internal state of OMAP IOMMU in debugfs.
Say N unless you know you need this.
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 8893bad..6a4a00e 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -11,7 +11,6 @@ obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o
obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o irq_remapping.o
obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
obj-$(CONFIG_OMAP_IOMMU) += omap-iommu2.o
-obj-$(CONFIG_OMAP_IOVMM) += omap-iovmm.o
obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o
obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o
diff --git a/drivers/iommu/omap-iommu-debug.c
b/drivers/iommu/omap-iommu-debug.c
index 80fffba..531658d 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -213,116 +213,6 @@ static ssize_t debug_read_pagetable(struct file *file,
char __user *userbuf,
return bytes;
}
-static ssize_t debug_read_mmap(struct file *file, char __user *userbuf,
-size_t count, loff_t *ppos)
-{
- struct device *dev = file-private_data;
- struct omap_iommu *obj = dev_to_omap_iommu(dev);
- char *p, *buf;
- struct iovm_struct *tmp;
- int uninitialized_var(i);
- ssize_t bytes;
-
- buf = (char *)__get_free_page(GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
- p = buf;
-
- p += sprintf(p, %-3s %-8s %-8s %6s %8s\n,
- No, start, end, size, flags);
- p += sprintf(p, -\n);
-
- mutex_lock(iommu_debug_lock);
-
- list_for_each_entry(tmp, obj-mmap, list) {
- size_t len;
- const char *str = %3d %08x-%08x %6x %8x\n;
- const int maxcol = 39;
-
- len = tmp-da_end - tmp-da_start;
- p += snprintf(p, maxcol, str,
- i, tmp-da_start, tmp-da_end, len, tmp-flags);
-
- if (PAGE_SIZE - (p - buf) maxcol)
- break;
- i++;
- }
-
- bytes = simple_read_from_buffer(userbuf, count, ppos, buf, p - buf);
-
- mutex_unlock(iommu_debug_lock);
- free_page((unsigned long)buf);
-
- return bytes;
-}
-
-static ssize_t debug_read_mem(struct file *file, char __user *userbuf,
- size_t count, loff_t *ppos)
-{
- struct device *dev = file-private_data;
- char *p, *buf;
- struct iovm_struct *area;
- ssize_t bytes;
-
- count = min_t(ssize_t, count, PAGE_SIZE);
-
- buf = (char *)__get_free_page(GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
- p = buf;
-
- mutex_lock(iommu_debug_lock);
-
- area = omap_find_iovm_area(dev, (u32)ppos);
- if (!area) {
- bytes = -EINVAL;
- goto err_out;
- }
- memcpy(p, area-va, count);
- p += count;
-
- bytes = simple_read_from_buffer(userbuf, count, ppos, buf, p - buf);
-err_out:
- mutex_unlock(iommu_debug_lock);
- free_page((unsigned long)buf);
-
- return
Re: [PATCH 4/5] tty: serial: 8250 core: add runtime pm
Hi,
On Thu, Jul 17, 2014 at 05:43:00PM +0200, Sebastian Andrzej Siewior wrote:
* Peter Hurley | 2014-07-17 11:31:59 [-0400]:
On 07/16/2014 12:06 PM, Felipe Balbi wrote:
On Wed, Jul 16, 2014 at 05:54:56PM +0200, Sebastian Andrzej Siewior wrote:
On 07/16/2014 05:16 PM, Felipe Balbi wrote:
I wonder if you should get_sync() on start_tx() and only
put_autosuspend() at stop_tx(). I guess the outcome would be
largely the same, no ?
I just opened minicom on ttyS0 and gave a try. start_tx() was invoked
each time I pressed a key (sent a character). I haven't seen stop_tx()
even after after I closed minicom. I guess stop_tx() is invoked if you
switch half-duplex communication.
that's bad, I expected stop to be called also after each character.
The 8250 core auto-stops tx when the tx ring buffer is empty (except
in the case of dma, where stopping tx isn't necessary).
This is correct. So this is what I have now for the non-dma case:
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 2e4a93b..480a1c0 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1283,6 +1283,9 @@ static inline void __stop_tx(struct uart_8250_port *p)
if (p-ier UART_IER_THRI) {
p-ier = ~UART_IER_THRI;
serial_out(p, UART_IER, p-ier);
+
+ pm_runtime_mark_last_busy(p-port.dev);
+ pm_runtime_put_autosuspend(p-port.dev);
}
}
@@ -1310,12 +1313,12 @@ static void serial8250_start_tx(struct uart_port
*port)
struct uart_8250_port *up =
container_of(port, struct uart_8250_port, port);
- pm_runtime_get_sync(port-dev);
if (up-dma !serial8250_tx_dma(up)) {
goto out;
} else if (!(up-ier UART_IER_THRI)) {
up-ier |= UART_IER_THRI;
+ pm_runtime_get_sync(port-dev);
serial_port_out(port, UART_IER, up-ier);
if (up-bugs UART_BUG_TXEN) {
unsigned char lsr;
this looks better. So we get on start_tx() and put on stop_tx().
@@ -1500,9 +1503,10 @@ void serial8250_tx_chars(struct uart_8250_port *up)
uart_write_wakeup(port);
DEBUG_INTR(THRE...);
-
+#if 0
if (uart_circ_empty(xmit))
__stop_tx(up);
+#endif
}
EXPORT_SYMBOL_GPL(serial8250_tx_chars);
is it so that start_tx() gets called one and stop_tx() might be called N
times ? That looks unbalanced to me. If the calls are balanced, then you
shouldn't need to care because pm_runtime will handle reference counting
for you, right?
and now I need to come up with something that is not if (port != omap)
for that #if 0 block. The code disables the TX FIFO empty interrupt once
the transfer is complete. I want to call __stop_tx() once the tx fifo is
empty.
Felipe, Would a check for dev-power.use_autosuspend be the right thing
to do?
probably not, as that's internal to the pm_runtime code. But I wonder if
start/stop tx calls are balanced, if they are then we're good. Unless
I'm missing something else.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 5/5] tty: serial: Add 8250-core based omap driver
On Thu, Jul 17, 2014 at 05:11:58PM +0200, Sebastian Andrzej Siewior wrote:
On 07/17/2014 04:54 PM, Felipe Balbi wrote:
Hi,
On Wed, Jul 16, 2014 at 04:45:03PM +0200, Sebastian Andrzej Siewior wrote:
+static int omap_8250_startup(struct uart_port *port)
+{
+ struct uart_8250_port *up =
+ container_of(port, struct uart_8250_port, port);
+ struct omap8250_priv *priv = port-private_data;
+
+ int ret;
+
+ if (priv-wakeirq) {
+ ret = request_irq(priv-wakeirq, omap_wake_irq,
+ port-irqflags, wakeup irq, port);
+ if (ret)
+ return ret;
+ disable_irq(priv-wakeirq);
+ }
+
+ ret = serial8250_do_startup(port);
+ if (ret)
+ goto err;
+
+ pm_runtime_get_sync(port-dev);
should this pm_runtime_get_sync() be placed above
serial8250_do_startup() call ?
I don't think it matters since serial8250_do_startup() has its own
pm_runtime_get_sync().
oh right, saw that now.
-startup(), -shutdown() are called via omap callbacks so we could
spare in the 8250-core if we do it in the omap code before invoking the
function. The same goes for serial8250_set_termios() which is not used
by omap but has those runtime-pm stuff, too.
It would be wrong if someone would use the serial8250_do_startup()
without his own runtime-pm get but it is omap only which does this
things.
So it is not used by anyone else (right now) and if you want to keep it
to a minimum I could remove them from those places.
I don't think it matters as long as the calls are balanced.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 4/5] tty: serial: 8250 core: add runtime pm
On 07/17/2014 06:02 PM, Felipe Balbi wrote:
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c index 2e4a93b..480a1c0
100644 --- a/drivers/tty/serial/8250/8250_core.c +++
b/drivers/tty/serial/8250/8250_core.c @@ -1283,6 +1283,9 @@
static inline void __stop_tx(struct uart_8250_port *p) if (p-ier
UART_IER_THRI) { p-ier = ~UART_IER_THRI; serial_out(p,
UART_IER, p-ier); + + pm_runtime_mark_last_busy(p-port.dev);
+
pm_runtime_put_autosuspend(p-port.dev); } }
@@ -1310,12 +1313,12 @@ static void serial8250_start_tx(struct
uart_port *port) struct uart_8250_port *up = container_of(port,
struct uart_8250_port, port);
-pm_runtime_get_sync(port-dev); if (up-dma
!serial8250_tx_dma(up)) { goto out; } else if (!(up-ier
UART_IER_THRI)) { up-ier |= UART_IER_THRI; +
pm_runtime_get_sync(port-dev); serial_port_out(port, UART_IER,
up-ier);
if (up-bugs UART_BUG_TXEN) { unsigned char lsr;
this looks better. So we get on start_tx() and put on stop_tx().
@@ -1500,9 +1503,10 @@ void serial8250_tx_chars(struct
uart_8250_port *up) uart_write_wakeup(port);
DEBUG_INTR(THRE...); - +#if 0 if (uart_circ_empty(xmit))
__stop_tx(up); +#endif } EXPORT_SYMBOL_GPL(serial8250_tx_chars);
is it so that start_tx() gets called one and stop_tx() might be
called N times ? That looks unbalanced to me. If the calls are
balanced, then you shouldn't need to care because pm_runtime will
handle reference counting for you, right?
No, this is okay. If you look, it checks for up-ier
UART_IER_THRI. On the second invocation it will see that this bit is
already set and therefore won't call get_sync() for the second time.
That bit is removed in the _stop_tx() path.
and now I need to come up with something that is not if (port !=
omap) for that #if 0 block. The code disables the TX FIFO empty
interrupt once the transfer is complete. I want to call
__stop_tx() once the tx fifo is empty. Felipe, Would a check for
dev-power.use_autosuspend be the right thing to do?
probably not, as that's internal to the pm_runtime code. But I
wonder if start/stop tx calls are balanced, if they are then we're
good. Unless I'm missing something else.
Do you have other ideas? It doesn't look like this is exported at all.
If we call _stop_tx() right away, then we have 64 bytes in the TX fifo
in the worst case. They should be gone soon but the HW-flow control
may delay it (in theory for a long time)).
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 4/5] tty: serial: 8250 core: add runtime pm
Hi,
On Thu, Jul 17, 2014 at 06:06:59PM +0200, Sebastian Andrzej Siewior wrote:
On 07/17/2014 06:02 PM, Felipe Balbi wrote:
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c index 2e4a93b..480a1c0
100644 --- a/drivers/tty/serial/8250/8250_core.c +++
b/drivers/tty/serial/8250/8250_core.c @@ -1283,6 +1283,9 @@
static inline void __stop_tx(struct uart_8250_port *p) if (p-ier
UART_IER_THRI) { p-ier = ~UART_IER_THRI; serial_out(p,
UART_IER, p-ier); + + pm_runtime_mark_last_busy(p-port.dev);
+
pm_runtime_put_autosuspend(p-port.dev); } }
@@ -1310,12 +1313,12 @@ static void serial8250_start_tx(struct
uart_port *port) struct uart_8250_port *up = container_of(port,
struct uart_8250_port, port);
- pm_runtime_get_sync(port-dev); if (up-dma
!serial8250_tx_dma(up)) { goto out; } else if (!(up-ier
UART_IER_THRI)) { up-ier |= UART_IER_THRI; +
pm_runtime_get_sync(port-dev); serial_port_out(port, UART_IER,
up-ier);
if (up-bugs UART_BUG_TXEN) { unsigned char lsr;
this looks better. So we get on start_tx() and put on stop_tx().
@@ -1500,9 +1503,10 @@ void serial8250_tx_chars(struct
uart_8250_port *up) uart_write_wakeup(port);
DEBUG_INTR(THRE...); - +#if 0 if (uart_circ_empty(xmit))
__stop_tx(up); +#endif } EXPORT_SYMBOL_GPL(serial8250_tx_chars);
is it so that start_tx() gets called one and stop_tx() might be
called N times ? That looks unbalanced to me. If the calls are
balanced, then you shouldn't need to care because pm_runtime will
handle reference counting for you, right?
No, this is okay. If you look, it checks for up-ier
UART_IER_THRI. On the second invocation it will see that this bit is
already set and therefore won't call get_sync() for the second time.
That bit is removed in the _stop_tx() path.
oh, right. But that's actually unnecessary. Calling pm_runtime_get()
multiple times will just increment the usage counter multiple times,
which means you can call __stop_tx() multiple times too and everything
gets balanced, right ?
and now I need to come up with something that is not if (port !=
omap) for that #if 0 block. The code disables the TX FIFO empty
interrupt once the transfer is complete. I want to call
__stop_tx() once the tx fifo is empty. Felipe, Would a check for
dev-power.use_autosuspend be the right thing to do?
probably not, as that's internal to the pm_runtime code. But I
wonder if start/stop tx calls are balanced, if they are then we're
good. Unless I'm missing something else.
Do you have other ideas? It doesn't look like this is exported at all.
If we call _stop_tx() right away, then we have 64 bytes in the TX fifo
in the worst case. They should be gone soon but the HW-flow control
may delay it (in theory for a long time)).
this can be problematic, specially for OMAP which can go into OFF while
idle. Whatever is in the FIFO would get lost. It seems like omap-serial
solved this within transmit_chars().
See how transmit_chars() is called from within IRQ handler with clocks
enabled then it conditionally calls serial_omap_stop_tx() which will
pm_runtime_get_sync() - do_the_harlem_shake() -
pm_runtime_put_autosuspend(). That leaves one unbalanced
pm_runtime_get() which is balanced when we're exitting the IRQ handler.
This seems work fine and dandy without DMA, but for DMA work, I think we
need to make sure this IP stays powered until we get DMA completion
callback. But that's future, I guess.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 4/5] tty: serial: 8250 core: add runtime pm
On 07/16/2014 12:06 PM, Felipe Balbi wrote: On Wed, Jul 16, 2014 at 05:54:56PM +0200, Sebastian Andrzej Siewior wrote: On 07/16/2014 05:16 PM, Felipe Balbi wrote: I wonder if you should get_sync() on start_tx() and only put_autosuspend() at stop_tx(). I guess the outcome would be largely the same, no ? I just opened minicom on ttyS0 and gave a try. start_tx() was invoked each time I pressed a key (sent a character). I haven't seen stop_tx() even after after I closed minicom. I guess stop_tx() is invoked if you switch half-duplex communication. that's bad, I expected stop to be called also after each character. The 8250 core auto-stops tx when the tx ring buffer is empty (except in the case of dma, where stopping tx isn't necessary). Regards, Peter Hurley -- 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/7] Enable L2 cache support on Exynos4210/4x12 SoCs
This series intends to add support for L2 cache on Exynos4 SoCs on boards
running under secure firmware, which requires certain initialization steps
to be done with help of firmware, as selected registers are writable only
from secure mode.
First four patches extend existing support for secure write in L2C driver
to account for design of secure firmware running on Exynos. Namely:
1) direct read access to certain registers is needed on Exynos, because
secure firmware calls set several registers at once,
2) not all boards are running secure firmware, so .write_sec callback
needs to be installed in Exynos firmware ops initialization code,
3) write access to {DATA,TAG}_LATENCY_CTRL registers fron non-secure world
is not allowed and so must use l2c_write_sec as well,
4) on certain boards, default value of prefetch register is incorrect
and must be overridden at L2C initialization.
For boards running with firmware that provides access to individual
L2C registers this series should introduce no functional changes. However
since the driver is widely used on other platforms I'd like to kindly ask
any interested people for testing.
Further two patches add impelmentation of .write_sec for Exynos secure
firmware and necessary DT nodes to enable L2 cache.
Tested on Exynos4210-based Universal C210 and Trats (both without secure
firmware) and Exynos4412-based TRATS2 and ODROID-U3 boards (both with secure
firmware).
Depends on:
- [PATCH] ARM: make it easier to check the CPU part number correctly
(http://thread.gmane.org/gmane.linux.ports.arm.kernel/335126
already in linux-next)
- [PATCH v2 0/2] Firmware-assisted suspend/resume of Exynos SoCs
(https://lkml.org/lkml/2014/7/17/431)
Changes since v2:
(https://lkml.org/lkml/2014/6/25/416)
- refactored L2C driver to use commit-like interface and make it no longer
depend on availability of writes to individual registers,
- moved L2C resume to assembly code, because doing it later makes some
systems unstable - this is also needed for deeper cpuidle modes,
- dropped unnecessary patch hacking around the .write_sec interface,
- dropped patch making the driver use l2c_write_sec() for LATENCY_CTRL
registers as Exynos is no longer affected and I'm not aware of any
reports that this is also needed on other platforms (can be applied
separately if it turns out to be so),
- rebased onto next-20140717 tag of linux-next tree.
Changes since v1:
(https://www.mail-archive.com/linux-omap@vger.kernel.org/msg106323.html)
- rebased onto for-next branch of linux-samsung tree,
- changed argument order of outer_cache.write_sec() callback to match
l2c_write_sec() function in cache-l2x0.c,
- added support of overriding of prefetch settings to work around incorrect
default settings on certain Exynos4x12-based boards,
- added call to firmware to invalidate whole L2 cache before setting enable
bit in L2C control register (required by Exynos secure firmware).
Tomasz Figa (7):
ARM: l2c: Refactor the driver to use commit-like interface
ARM: l2c: Add interface to ask hypervisor to configure L2C
ARM: l2c: Get outer cache .write_sec callback from mach_desc only if
not NULL
ARM: l2c: Add support for overriding prefetch settings
ARM: EXYNOS: Add .write_sec outer cache callback for L2C-310
ARM: EXYNOS: Add support for non-secure L2X0 resume
ARM: dts: exynos4: Add nodes for L2 cache controller
Documentation/devicetree/bindings/arm/l2cc.txt | 10 +
arch/arm/boot/dts/exynos4210.dtsi | 9 +
arch/arm/boot/dts/exynos4x12.dtsi | 14 ++
arch/arm/include/asm/outercache.h | 3 +
arch/arm/kernel/irq.c | 3 +-
arch/arm/mach-exynos/common.h | 1 +
arch/arm/mach-exynos/firmware.c| 40
arch/arm/mach-exynos/sleep.S | 41 +
arch/arm/mm/cache-l2x0.c | 245 -
9 files changed, 274 insertions(+), 92 deletions(-)
--
1.9.3
--
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 6/7] ARM: EXYNOS: Add support for non-secure L2X0 resume
On Exynos SoCs it is necessary to resume operation of L2C early in assembly code, because otherwise certain systems will crash. This patch adds necessary code to non-secure resume handler. Signed-off-by: Tomasz Figa t.f...@samsung.com --- arch/arm/mach-exynos/common.h | 1 + arch/arm/mach-exynos/firmware.c | 2 ++ arch/arm/mach-exynos/sleep.S| 41 + 3 files changed, 44 insertions(+) diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h index a3f3061..2540827 100644 --- a/arch/arm/mach-exynos/common.h +++ b/arch/arm/mach-exynos/common.h @@ -113,6 +113,7 @@ IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID, EXYNOS5_SOC_MASK) extern u32 cp15_save_diag; extern u32 cp15_save_power; +extern unsigned long l2x0_regs_phys; extern void __iomem *sysram_ns_base_addr; extern void __iomem *sysram_base_addr; diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c index 554b350..09131d3 100644 --- a/arch/arm/mach-exynos/firmware.c +++ b/arch/arm/mach-exynos/firmware.c @@ -103,6 +103,8 @@ static int exynos_suspend(void) writel(virt_to_phys(exynos_cpu_resume_ns), sysram_ns_base_addr + EXYNOS_BOOT_ADDR); + l2x0_regs_phys = virt_to_phys(l2x0_saved_regs); + return cpu_suspend(0, exynos_cpu_suspend); } diff --git a/arch/arm/mach-exynos/sleep.S b/arch/arm/mach-exynos/sleep.S index e3c3730..b8ce8f0 100644 --- a/arch/arm/mach-exynos/sleep.S +++ b/arch/arm/mach-exynos/sleep.S @@ -16,6 +16,8 @@ */ #include linux/linkage.h +#include asm/asm-offsets.h +#include asm/hardware/cache-l2x0.h #include smc.h #define CPU_MASK 0xff00 @@ -74,6 +76,40 @@ ENTRY(exynos_cpu_resume_ns) mov r0, #SMC_CMD_C15RESUME dsb smc #0 +#ifdef CONFIG_CACHE_L2X0 + adr r0, l2x0_regs_phys + ldr r0, [r0] + cmp r0, #0 + beq skip_l2x0 + + ldr r1, [r0, #L2X0_R_PHY_BASE] + ldr r2, [r1, #L2X0_CTRL] + tst r2, #0x1 + bne skip_l2x0 + + ldr r1, [r0, #L2X0_R_TAG_LATENCY] + ldr r2, [r0, #L2X0_R_DATA_LATENCY] + ldr r3, [r0, #L2X0_R_PREFETCH_CTRL] + mov r0, #SMC_CMD_L2X0SETUP1 + smc #0 + + /* Reload saved regs pointer because smc corrupts registers. */ + adr r0, l2x0_regs_phys + ldr r0, [r0] + + ldr r1, [r0, #L2X0_R_PWR_CTRL] + ldr r2, [r0, #L2X0_R_AUX_CTRL] + mov r0, #SMC_CMD_L2X0SETUP2 + smc #0 + + mov r0, #SMC_CMD_L2X0INVALL + smc #0 + + mov r1, #1 + mov r0, #SMC_CMD_L2X0CTRL + smc #0 +skip_l2x0: +#endif /* CONFIG_CACHE_L2X0 */ skip_cp15: b cpu_resume ENDPROC(exynos_cpu_resume_ns) @@ -83,3 +119,8 @@ cp15_save_diag: .globl cp15_save_power cp15_save_power: .long 0 @ cp15 power control +#ifdef CONFIG_CACHE_L2X0 + .globl l2x0_regs_phys +l2x0_regs_phys: + .long 0 @ phys address of l2x0 save struct +#endif /* CONFIG_CACHE_L2X0 */ -- 1.9.3 -- 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 7/7] ARM: dts: exynos4: Add nodes for L2 cache controller
This patch adds device tree nodes for L2 cache controller present on
Exynos4 SoCs.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/boot/dts/exynos4210.dtsi | 9 +
arch/arm/boot/dts/exynos4x12.dtsi | 14 ++
2 files changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index ee3001f..99970ab 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -54,6 +54,15 @@
reg = 0x10023CA0 0x20;
};
+ l2c: l2-cache-controller@10502000 {
+ compatible = arm,pl310-cache;
+ reg = 0x10502000 0x1000;
+ cache-unified;
+ cache-level = 2;
+ arm,tag-latency = 2 2 1;
+ arm,data-latency = 2 2 1;
+ };
+
gic: interrupt-controller@1049 {
cpu-offset = 0x8000;
};
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index c5a943d..ddffefe 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -60,6 +60,20 @@
reg = 0x10023CA0 0x20;
};
+ l2c: l2-cache-controller@10502000 {
+ compatible = arm,pl310-cache;
+ reg = 0x10502000 0x1000;
+ cache-unified;
+ cache-level = 2;
+ arm,tag-latency = 2 2 1;
+ arm,data-latency = 3 2 1;
+ arm,double-linefill = 1;
+ arm,double-linefill-incr = 0;
+ arm,double-linefill-wrap = 1;
+ arm,prefetch-drop = 1;
+ arm,prefetch-offset = 7;
+ };
+
clock: clock-controller@1003 {
compatible = samsung,exynos4412-clock;
reg = 0x1003 0x2;
--
1.9.3
--
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/7] ARM: l2c: Refactor the driver to use commit-like interface
Certain implementations of secure hypervisors (namely the one found on
Samsung Exynos-based boards) do not provide access to individual L2C
registers. This makes the .write_sec()-based interface insufficient and
provoking ugly hacks.
This patch is first step to make the driver not rely on availability of
writes to individual registers. This is achieved by refactoring the
driver to use a commit-like operation scheme: all register values are
prepared first and stored in an instance of l2x0_regs struct and then a
single callback is responsible to flush those values to the hardware.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mm/cache-l2x0.c | 201 ++-
1 file changed, 110 insertions(+), 91 deletions(-)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 5f2c988..385c047 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -40,12 +40,14 @@ struct l2c_init_data {
void (*enable)(void __iomem *, u32, unsigned);
void (*fixup)(void __iomem *, u32, struct outer_cache_fns *);
void (*save)(void __iomem *);
+ void (*configure)(void __iomem *);
struct outer_cache_fns outer_cache;
};
#define CACHE_LINE_SIZE32
static void __iomem *l2x0_base;
+static const struct l2c_init_data *l2x0_data;
static DEFINE_RAW_SPINLOCK(l2x0_lock);
static u32 l2x0_way_mask; /* Bitmask of active ways */
static u32 l2x0_size;
@@ -105,6 +107,14 @@ static inline void l2c_unlock(void __iomem *base, unsigned
num)
}
}
+static void l2c_configure(void __iomem *base)
+{
+ if (l2x0_data-configure)
+ l2x0_data-configure(base);
+
+ l2c_write_sec(l2x0_saved_regs.aux_ctrl, base, L2X0_AUX_CTRL);
+}
+
/*
* Enable the L2 cache controller. This function must only be
* called when the cache controller is known to be disabled.
@@ -113,7 +123,12 @@ static void l2c_enable(void __iomem *base, u32 aux,
unsigned num_lock)
{
unsigned long flags;
- l2c_write_sec(aux, base, L2X0_AUX_CTRL);
+ /* Do not touch the controller if already enabled. */
+ if (readl_relaxed(base + L2X0_CTRL) L2X0_CTRL_EN)
+ return;
+
+ l2x0_saved_regs.aux_ctrl = aux;
+ l2c_configure(base);
l2c_unlock(base, num_lock);
@@ -207,6 +222,12 @@ static void l2c_save(void __iomem *base)
l2x0_saved_regs.aux_ctrl = readl_relaxed(l2x0_base + L2X0_AUX_CTRL);
}
+static void l2c_resume(void)
+{
+ l2x0_data-enable(l2x0_base, l2x0_saved_regs.aux_ctrl,
+ l2x0_data-num_lock);
+}
+
/*
* L2C-210 specific code.
*
@@ -287,14 +308,6 @@ static void l2c210_sync(void)
__l2c210_cache_sync(l2x0_base);
}
-static void l2c210_resume(void)
-{
- void __iomem *base = l2x0_base;
-
- if (!(readl_relaxed(base + L2X0_CTRL) L2X0_CTRL_EN))
- l2c_enable(base, l2x0_saved_regs.aux_ctrl, 1);
-}
-
static const struct l2c_init_data l2c210_data __initconst = {
.type = L2C-210,
.way_size_0 = SZ_8K,
@@ -308,7 +321,7 @@ static const struct l2c_init_data l2c210_data __initconst =
{
.flush_all = l2c210_flush_all,
.disable = l2c_disable,
.sync = l2c210_sync,
- .resume = l2c210_resume,
+ .resume = l2c_resume,
},
};
@@ -465,7 +478,7 @@ static const struct l2c_init_data l2c220_data = {
.flush_all = l2c220_flush_all,
.disable = l2c_disable,
.sync = l2c220_sync,
- .resume = l2c210_resume,
+ .resume = l2c_resume,
},
};
@@ -614,39 +627,29 @@ static void __init l2c310_save(void __iomem *base)
L310_POWER_CTRL);
}
-static void l2c310_resume(void)
+static void l2c310_configure(void __iomem *base)
{
- void __iomem *base = l2x0_base;
+ unsigned revision;
- if (!(readl_relaxed(base + L2X0_CTRL) L2X0_CTRL_EN)) {
- unsigned revision;
-
- /* restore pl310 setup */
- writel_relaxed(l2x0_saved_regs.tag_latency,
- base + L310_TAG_LATENCY_CTRL);
- writel_relaxed(l2x0_saved_regs.data_latency,
- base + L310_DATA_LATENCY_CTRL);
- writel_relaxed(l2x0_saved_regs.filter_end,
- base + L310_ADDR_FILTER_END);
- writel_relaxed(l2x0_saved_regs.filter_start,
- base + L310_ADDR_FILTER_START);
-
- revision = readl_relaxed(base + L2X0_CACHE_ID)
- L2X0_CACHE_ID_RTL_MASK;
-
- if (revision = L310_CACHE_ID_RTL_R2P0)
- l2c_write_sec(l2x0_saved_regs.prefetch_ctrl, base,
- L310_PREFETCH_CTRL);
- if (revision = L310_CACHE_ID_RTL_R3P0)
-
[PATCH v3 4/7] ARM: l2c: Add support for overriding prefetch settings
Firmware on certain boards (e.g. ODROID-U3) can leave incorrect L2C prefetch
settings configured in registers leading to crashes if L2C is enabled
without overriding them. This patch introduces bindings to enable
prefetch settings to be specified from DT and necessary support in the
driver.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
Documentation/devicetree/bindings/arm/l2cc.txt | 10 +++
arch/arm/mm/cache-l2x0.c | 39 ++
2 files changed, 49 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt
b/Documentation/devicetree/bindings/arm/l2cc.txt
index af527ee..3443d2d 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -47,6 +47,16 @@ Optional properties:
- cache-id-part: cache id part number to be used if it is not present
on hardware
- wt-override: If present then L2 is forced to Write through mode
+- arm,double-linefill : Override double linefill enable setting. Enable if
+ non-zero, disable if zero.
+- arm,double-linefill-incr : Override double linefill on INCR read. Enable
+ if non-zero, disable if zero.
+- arm,double-linefill-wrap : Override double linefill on WRAP read. Enable
+ if non-zero, disable if zero.
+- arm,prefetch-drop : Override prefetch drop enable setting. Enable if
non-zero,
+ disable if zero.
+- arm,prefetch-offset : Override prefetch offset value. Valid values are
+ 0-7, 15, 23, and 31.
Example:
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 21a625a0..6274803 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1055,6 +1055,8 @@ static void __init l2c310_of_parse(const struct
device_node *np,
u32 data[3] = { 0, 0, 0 };
u32 tag[3] = { 0, 0, 0 };
u32 filter[2] = { 0, 0 };
+ u32 prefetch;
+ u32 val;
of_property_read_u32_array(np, arm,tag-latency, tag, ARRAY_SIZE(tag));
if (tag[0] tag[1] tag[2])
@@ -1079,6 +1081,43 @@ static void __init l2c310_of_parse(const struct
device_node *np,
l2x0_saved_regs.filter_start = (filter[0] ~(SZ_1M - 1))
| L310_ADDR_FILTER_EN;
}
+
+ prefetch = l2x0_saved_regs.prefetch_ctrl;
+
+ if (!of_property_read_u32(np, arm,double-linefill, val)) {
+ if (val)
+ prefetch |= L310_PREFETCH_CTRL_DBL_LINEFILL;
+ else
+ prefetch = ~L310_PREFETCH_CTRL_DBL_LINEFILL;
+ }
+
+ if (!of_property_read_u32(np, arm,double-linefill-incr, val)) {
+ if (val)
+ prefetch |= L310_PREFETCH_CTRL_DBL_LINEFILL_INCR;
+ else
+ prefetch = ~L310_PREFETCH_CTRL_DBL_LINEFILL_INCR;
+ }
+
+ if (!of_property_read_u32(np, arm,double-linefill-wrap, val)) {
+ if (!val)
+ prefetch |= L310_PREFETCH_CTRL_DBL_LINEFILL_WRAP;
+ else
+ prefetch = ~L310_PREFETCH_CTRL_DBL_LINEFILL_WRAP;
+ }
+
+ if (!of_property_read_u32(np, arm,prefetch-drop, val)) {
+ if (val)
+ prefetch |= L310_PREFETCH_CTRL_PREFETCH_DROP;
+ else
+ prefetch = ~L310_PREFETCH_CTRL_PREFETCH_DROP;
+ }
+
+ if (!of_property_read_u32(np, arm,prefetch-offset, val)) {
+ prefetch = ~L310_PREFETCH_CTRL_OFFSET_MASK;
+ prefetch |= val L310_PREFETCH_CTRL_OFFSET_MASK;
+ }
+
+ l2x0_saved_regs.prefetch_ctrl = prefetch;
}
static const struct l2c_init_data of_l2c310_data __initconst = {
--
1.9.3
--
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 5/7] ARM: EXYNOS: Add .write_sec outer cache callback for L2C-310
Exynos4 SoCs equipped with an L2C-310 cache controller and running under
secure firmware require certain registers of aforementioned IP to be
accessed only from secure mode. This means that SMC calls are required
for certain register writes. To handle this, an implementation of
.write_sec and .configure callbacks is provided by this patch.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-exynos/firmware.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index f5e626d..554b350 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -17,6 +17,7 @@
#include asm/cacheflush.h
#include asm/cputype.h
#include asm/firmware.h
+#include asm/hardware/cache-l2x0.h
#include asm/suspend.h
#include mach/map.h
@@ -120,6 +121,31 @@ static const struct firmware_ops exynos_firmware_ops = {
.resume = exynos_resume,
};
+static void exynos_l2_write_sec(unsigned long val, unsigned reg)
+{
+ switch (reg) {
+ case L2X0_CTRL:
+ if (val L2X0_CTRL_EN)
+ exynos_smc(SMC_CMD_L2X0INVALL, 0, 0, 0);
+ exynos_smc(SMC_CMD_L2X0CTRL, val, 0, 0);
+ break;
+
+ case L2X0_DEBUG_CTRL:
+ exynos_smc(SMC_CMD_L2X0DEBUG, val, 0, 0);
+ break;
+
+ default:
+ WARN_ONCE(1, %s: ignoring write to reg 0x%x\n, __func__, reg);
+ }
+}
+
+static void exynos_l2_configure(const struct l2x0_regs *regs)
+{
+ exynos_smc(SMC_CMD_L2X0SETUP1, regs-tag_latency, regs-data_latency,
+ regs-prefetch_ctrl);
+ exynos_smc(SMC_CMD_L2X0SETUP2, regs-pwr_ctrl, regs-aux_ctrl, 0);
+}
+
void __init exynos_firmware_init(void)
{
struct device_node *nd;
@@ -139,4 +165,16 @@ void __init exynos_firmware_init(void)
pr_info(Running under secure firmware.\n);
register_firmware_ops(exynos_firmware_ops);
+
+ /*
+* Exynos 4 SoCs (based on Cortex A9 and equipped with L2C-310),
+* running under secure firmware, require certain registers of L2
+* cache controller to be written in secure mode. Here .write_sec
+* callback is provided to perform necessary SMC calls.
+*/
+ if (IS_ENABLED(CONFIG_CACHE_L2X0)
+read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
+ outer_cache.write_sec = exynos_l2_write_sec;
+ outer_cache.configure = exynos_l2_configure;
+ }
}
--
1.9.3
--
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/7] ARM: l2c: Add interface to ask hypervisor to configure L2C
Because certain secure hypervisor do not allow writes to individual L2C
registers, but rather expect set of parameters to be passed as argument
to secure monitor calls, there is a need to provide an interface for the
L2C driver to ask the firmware to configure the hardware according to
specified parameters. This patch adds such.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/include/asm/outercache.h | 3 +++
arch/arm/mm/cache-l2x0.c | 5 +
2 files changed, 8 insertions(+)
diff --git a/arch/arm/include/asm/outercache.h
b/arch/arm/include/asm/outercache.h
index 891a56b..563b92f 100644
--- a/arch/arm/include/asm/outercache.h
+++ b/arch/arm/include/asm/outercache.h
@@ -23,6 +23,8 @@
#include linux/types.h
+struct l2x0_regs;
+
struct outer_cache_fns {
void (*inv_range)(unsigned long, unsigned long);
void (*clean_range)(unsigned long, unsigned long);
@@ -36,6 +38,7 @@ struct outer_cache_fns {
/* This is an ARM L2C thing */
void (*write_sec)(unsigned long, unsigned);
+ void (*configure)(const struct l2x0_regs *);
};
extern struct outer_cache_fns outer_cache;
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 385c047..21a625a0 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -109,6 +109,11 @@ static inline void l2c_unlock(void __iomem *base, unsigned
num)
static void l2c_configure(void __iomem *base)
{
+ if (outer_cache.configure) {
+ outer_cache.configure(l2x0_saved_regs);
+ return;
+ }
+
if (l2x0_data-configure)
l2x0_data-configure(base);
--
1.9.3
--
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/7] ARM: l2c: Get outer cache .write_sec callback from mach_desc only if not NULL
Certain platforms (i.e. Exynos) might need to set .write_sec callback
from firmware initialization which is happenning in .init_early callback
of machine descriptor. However current code will overwrite the pointer
with whatever is present in machine descriptor, even though it can be
already set earlier. This patch fixes this by making the assignment
conditional, depending on whether current .write_sec callback is NULL.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/kernel/irq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 2c42576..e7383b9 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -125,7 +125,8 @@ void __init init_IRQ(void)
if (IS_ENABLED(CONFIG_OF) IS_ENABLED(CONFIG_CACHE_L2X0)
(machine_desc-l2c_aux_mask || machine_desc-l2c_aux_val)) {
- outer_cache.write_sec = machine_desc-l2c_write_sec;
+ if (!outer_cache.write_sec)
+ outer_cache.write_sec = machine_desc-l2c_write_sec;
ret = l2x0_of_init(machine_desc-l2c_aux_val,
machine_desc-l2c_aux_mask);
if (ret)
--
1.9.3
--
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
[v3 PATCH 5/6] ARM: dts: dra7: Add prm_resets node
Add the prcm_resets node to the prm parent node.
Add the draxx_resets file to define the
dra7xx reset lines that are handled by this reset
framework.
Signed-off-by: Dan Murphy dmur...@ti.com
---
v3 - No changes
arch/arm/boot/dts/dra7.dtsi |7 +++
arch/arm/boot/dts/dra7xx-resets.dtsi | 82 ++
2 files changed, 89 insertions(+)
create mode 100644 arch/arm/boot/dts/dra7xx-resets.dtsi
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 8012763..f3a8819 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -93,6 +93,12 @@
prm_clockdomains: clockdomains {
};
+
+ prm_resets: resets {
+ #address-cells = 1;
+ #size-cells = 1;
+ #reset-cells = 1;
+ };
};
cm_core_aon: cm_core_aon@4a005000 {
@@ -998,3 +1004,4 @@
};
/include/ dra7xx-clocks.dtsi
+/include/ dra7xx-resets.dtsi
diff --git a/arch/arm/boot/dts/dra7xx-resets.dtsi
b/arch/arm/boot/dts/dra7xx-resets.dtsi
new file mode 100644
index 000..4c4966d
--- /dev/null
+++ b/arch/arm/boot/dts/dra7xx-resets.dtsi
@@ -0,0 +1,82 @@
+/*
+ * Device Tree Source for DRA7XX reset data
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * 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.
+ */
+
+prm_resets {
+ dsp_rstctrl {
+ reg = 0x410,
+ 0x414;
+
+ dsp_reset: dsp_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+
+ dsp_mmu_reset: dsp_mmu_reset {
+ control-bit = 0x02;
+ status-bit = 0x02;
+ };
+ };
+
+ ipu_rstctrl {
+ reg = 0x510,
+ 0x514;
+
+ ipu_cpu0_reset: ipu_cpu0_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+
+ ipu_cpu1_reset: ipu_cpu1_reset {
+ control-bit = 0x02;
+ status-bit = 0x02;
+ };
+
+ ipu_mmu_reset: ipu_mmu_reset {
+ control-bit = 0x04;
+ status-bit = 0x04;
+ };
+ };
+
+ iva_rstctrl {
+ reg = 0xf10,
+ 0xf14;
+
+ iva_reset: iva_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+
+ pcie_rstctrl {
+ reg = 0x1310,
+ 0x1314;
+
+ pcie1_reset: pcie1_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+
+ pcie2_reset: pcie2_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+
+ device_rstctrl {
+ reg = 0x1D00,
+ 0x1D04;
+
+ device_reset: device_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+
+};
--
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
[v3 PATCH 3/6] ARM: dts: am33xx: Add prcm_resets node
Add the prcm_resets node to the prcm parent node.
Add the am33xx_resets file to define the
am33xx reset lines that are handled by this reset
framework.
Signed-off-by: Dan Murphy dmur...@ti.com
---
v3 - No changes
arch/arm/boot/dts/am33xx-resets.dtsi | 42 ++
arch/arm/boot/dts/am33xx.dtsi|7 ++
2 files changed, 49 insertions(+)
create mode 100644 arch/arm/boot/dts/am33xx-resets.dtsi
diff --git a/arch/arm/boot/dts/am33xx-resets.dtsi
b/arch/arm/boot/dts/am33xx-resets.dtsi
new file mode 100644
index 000..9260626
--- /dev/null
+++ b/arch/arm/boot/dts/am33xx-resets.dtsi
@@ -0,0 +1,42 @@
+/*
+ * Device Tree Source for AM33XX reset data
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * 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.
+ */
+
+prcm_resets {
+ gfx_rstctrl {
+ reg = 0x1104,
+ 0x1114;
+
+ gfx_reset: gfx_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+
+ per_rstctrl {
+ reg = 0xD00,
+ 0xD0C;
+
+ iva_reset: iva_reset {
+ control-bit = 0x04;
+ status-bit = 0x10;
+ };
+ };
+
+ device_rstctrl {
+ reg = 0xf00,
+ 0xf08;
+
+ device_reset: device_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 4a4e02d..5cdc8f0 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -117,6 +117,12 @@
prcm_clockdomains: clockdomains {
};
+
+ prcm_resets: resets {
+ #address-cells = 1;
+ #size-cells = 1;
+ #reset-cells = 1;
+ };
};
scrm: scrm@44e1 {
@@ -834,3 +840,4 @@
};
/include/ am33xx-clocks.dtsi
+/include/ am33xx-resets.dtsi
--
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
[v3 PATCH 6/6] ARM: dts: omap5: Add prm_resets node
Add the prm_resets node to the prm parent node.
Add the omap54xx_resets file to define the
omap5 reset lines that are handled by this reset
framework.
Signed-off-by: Dan Murphy dmur...@ti.com
---
v3 - No changes
arch/arm/boot/dts/omap5.dtsi |7
arch/arm/boot/dts/omap54xx-resets.dtsi | 66
2 files changed, 73 insertions(+)
create mode 100644 arch/arm/boot/dts/omap54xx-resets.dtsi
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a4ed549..97bfef5 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -139,6 +139,12 @@
prm_clockdomains: clockdomains {
};
+
+ prm_resets: resets {
+ #address-cells = 1;
+ #size-cells = 1;
+ #reset-cells = 1;
+ };
};
cm_core_aon: cm_core_aon@4a004000 {
@@ -989,3 +995,4 @@
};
/include/ omap54xx-clocks.dtsi
+/include/ omap54xx-resets.dtsi
diff --git a/arch/arm/boot/dts/omap54xx-resets.dtsi
b/arch/arm/boot/dts/omap54xx-resets.dtsi
new file mode 100644
index 000..cba6f52
--- /dev/null
+++ b/arch/arm/boot/dts/omap54xx-resets.dtsi
@@ -0,0 +1,66 @@
+/*
+ * Device Tree Source for OMAP5 reset data
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * 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.
+ */
+
+prm_resets {
+ dsp_rstctrl {
+ reg = 0x1c00,
+ 0x1c04;
+
+ dsp_reset: dsp_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+
+ dsp_mmu_reset: dsp_mmu_reset {
+ control-bit = 0x02;
+ status-bit = 0x02;
+ };
+ };
+
+ ipu_rstctrl {
+ reg = 0x910,
+ 0x914;
+
+ ipu_cpu0_reset: ipu_cpu0_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+
+ ipu_cpu1_reset: ipu_cpu1_reset {
+ control-bit = 0x02;
+ status-bit = 0x02;
+ };
+
+ ipu_mmu_reset: ipu_mmu_reset {
+ control-bit = 0x04;
+ status-bit = 0x04;
+ };
+ };
+
+ iva_rstctrl {
+ reg = 0x1210,
+ 0x1214;
+
+ iva_reset: iva_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+
+ device_rstctrl {
+ reg = 0x1c00,
+ 0x1c04;
+
+ device_reset: device_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+};
--
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
[v3 PATCH 1/6] drivers: reset: TI: SoC reset controller support.
The TI SoC reset controller support utilizes the
reset controller framework to give device drivers or
function drivers a common set of APIs to call to reset
a module.
The reset-ti is a common interface to the reset framework.
The register data is retrieved during initialization
of the reset driver through the reset-ti-data
file. The array of data is associated with the compatible from the
respective DT entry.
Once the data is available then this is derefenced within the common
interface.
The device driver has the ability to assert, deassert or perform a
complete reset.
This code was derived from previous work by Rajendra Nayak and Afzal Mohammed.
The code was changed to adopt to the reset core and abstract away the SoC
information.
Signed-off-by: Dan Murphy dmur...@ti.com
---
v3 - Resolved comments from v2. To many to call out here -
https://patchwork.kernel.org/patch/4116941/
drivers/reset/Kconfig|9 ++
drivers/reset/Makefile |1 +
drivers/reset/reset-ti.c | 373 ++
3 files changed, 383 insertions(+)
create mode 100644 drivers/reset/reset-ti.c
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 0615f50..31a5a79 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -12,4 +12,13 @@ menuconfig RESET_CONTROLLER
If unsure, say no.
+config RESET_TI
+ depends on RESET_CONTROLLER ARCH_OMAP || COMPILE_TEST
+ bool TI reset controller
+ help
+ Reset controller support for TI SoC's
+
+ Reset controller found in TI's AM series of SoC's like
+ AM335x and AM43x and OMAP SoC's like OMAP5 and DRA7
+
source drivers/reset/sti/Kconfig
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 60fed3d..a5986b9 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_RESET_CONTROLLER) += core.o
obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
+obj-$(CONFIG_RESET_TI) += reset-ti.o
obj-$(CONFIG_ARCH_STI) += sti/
diff --git a/drivers/reset/reset-ti.c b/drivers/reset/reset-ti.c
new file mode 100644
index 000..e9d4039
--- /dev/null
+++ b/drivers/reset/reset-ti.c
@@ -0,0 +1,373 @@
+/*
+ * reset-ti.c - PRCM reset driver for TI SoC's
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Dan Murphy dmur...@ti.com
+ *
+ * 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.
+ */
+
+#include linux/delay.h
+#include linux/device.h
+#include linux/err.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/reset.h
+#include linux/reset-controller.h
+#include linux/slab.h
+#include linux/spinlock.h
+
+#define DRIVER_NAME prcm_reset_ti
+#define MAX_RESET_SIGNALS 255
+
+/**
+ * struct ti_reset_reg_data - Structure of the reset register information
+ * for a particular SoC.
+ * @rstctrl_offs: This is the reset control offset value from
+ * from the parent reset node.
+ * @rstst_offs: This is the reset status offset value from
+ * from the parent reset node.
+ * @rstctrl_bit: This is the reset control bit for the module.
+ * @rstst_bit: This is the reset status bit for the module.
+ *
+ * Longer description of this structure.
+ */
+struct ti_reset_reg_data {
+ phandle handle;
+ u32 rstctrl_offs;
+ u32 rstst_offs;
+ u32 rstctrl_bit;
+ u32 rstst_bit;
+};
+
+/**
+ * struct ti_reset_data - Structure that contains the reset register data
+ * as well as the total number of resets for a particular SoC.
+ * @ti_data: Pointer to this structure to be dereferenced
+ * @reg_data: Pointer to the register data structure.
+ * @rcdev: Reset controller device instance
+ * @dev: Pointer to the devive structure
+ * @ti_reg_data: Array of register data. Only reset signal with valid
+ * phandles will be stored in this array.
+ * @reg_base: Parent register base address
+ * @lock: Spinlock for accessing the registers
+ * @nr_resets: Total number of resets for the SoC in the reset array.
+ *
+ * This structure contains a pointer to the register data and the modules
+ * register base. The number of resets and reset controller device data is
+ * stored within this structure.
+ *
+ */
+struct ti_reset_data {
+ struct ti_reset_data *ti_data;
+ struct ti_reset_reg_data *reg_data;
+ struct reset_controller_dev rcdev;
+ struct device *dev;
+ struct ti_reset_reg_data ti_reg_data[MAX_RESET_SIGNALS];
+ void __iomem *reg_base;
+ spinlock_t lock;
+ int nr_resets;
+};
+
+static int ti_reset_wait_on_reset(struct reset_controller_dev *rcdev,
[v3 PATCH 2/6] dt: TI: Describe the ti reset DT entries
Describe the TI reset DT entries for TI SoC's.
Signed-off-by: Dan Murphy dmur...@ti.com
---
v3 - Changed Headline no other changes
.../devicetree/bindings/reset/ti,reset.txt | 103
1 file changed, 103 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/ti,reset.txt
diff --git a/Documentation/devicetree/bindings/reset/ti,reset.txt
b/Documentation/devicetree/bindings/reset/ti,reset.txt
new file mode 100644
index 000..9d5c29c
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/ti,reset.txt
@@ -0,0 +1,103 @@
+Texas Instruments Reset Controller
+==
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Specifying the reset entries for the IP module
+==
+Parent module:
+This is the module node that contains the reset registers and bits.
+
+example:
+ prcm_resets: resets {
+ compatible = ti,dra7-resets;
+ #reset-cells = 1;
+ };
+
+Required parent properties:
+- compatible : Should be one of,
+ ti,omap4-prm for OMAP4 PRM instances
+ ti,omap5-prm for OMAP5 PRM instances
+ ti,dra7-prm for DRA7xx PRM instances
+ ti,am4-prcm for AM43xx PRCM instances
+ ti,am3-prcm for AM33xx PRCM instances
+
+Required child reset property:
+- compatible : Should be
+ resets for All TI SoCs
+
+example:
+ prm: prm@4ae06000 {
+ compatible = ti,omap5-prm;
+ reg = 0x4ae06000 0x3000;
+
+ prm_resets: resets {
+ #address-cells = 1;
+ #size-cells = 1;
+ #reset-cells = 1;
+ };
+ };
+
+
+Reset node declaration
+==
+The reset node is declared in a parent child relationship. The main parent
+is the PRCM module which contains the base address. The first child within
+the reset parent declares the target modules reset name. This is followed by
+the control and status offsets.
+
+Within the first reset child node is a secondary child node which declares the
+reset signal of interest. Under this node the control and status bits
+are declared. These bits declare the bit mask for the target reset.
+
+
+Required properties:
+reg - This is the register offset from the PRCM parent.
+ This must be declared as:
+
+ reg = control register offset,
+ status register offset;
+
+control-bit - This is the bit within the register which controls the reset
+ of the target module. This is declared as a bit mask for the register.
+status-bit - This is the bit within the register which contains the status of
+ the reset of the target module.
+ This is declared as a bit mask for the register.
+
+example:
+prm_resets {
+ dsp_rstctrl {
+ reg = 0x1c00,
+ 0x1c04;
+
+ dsp_reset: dsp_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+};
+
+
+
+Client Node Declaration
+==
+This is the consumer of the parent node to declare what resets this
+particular module is interested in.
+
+example:
+ src: src@55082000 {
+ resets = reset_src phandle;
+ reset-names = reset_name;
+ };
+
+Required Properties:
+reset_src - This is the parent DT entry for the reset controller
+phandle - This is the phandle of the specific reset to be used by the clien
+ driver.
+reset-names - This is the reset name of module that the device driver
+ needs to be able to reset. This value must correspond to a value within
+ the reset controller array.
+
+example:
+resets = prm_resets dsp_mmu_reset;
+reset-names = dsp_mmu_reset;
--
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
[v3 PATCH 4/6] ARM: dts: am4372: Add prcm_resets node
Add the prcm_resets node to the prcm parent node.
Add the am34xx_resets file to define the
am34xx reset lines that are handled by this reset
framework.
Signed-off-by: Dan Murphy dmur...@ti.com
---
v3 - No changes
arch/arm/boot/dts/am4372.dtsi|7 +
arch/arm/boot/dts/am43xx-resets.dtsi | 52 ++
2 files changed, 59 insertions(+)
create mode 100644 arch/arm/boot/dts/am43xx-resets.dtsi
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 49fa596..d0aa9c9 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -88,6 +88,12 @@
prcm_clockdomains: clockdomains {
};
+
+ prcm_resets: resets {
+ #address-cells = 1;
+ #size-cells = 1;
+ #reset-cells = 1;
+ };
};
scrm: scrm@44e1 {
@@ -892,3 +898,4 @@
};
/include/ am43xx-clocks.dtsi
+/include/ am43xx-resets.dtsi
diff --git a/arch/arm/boot/dts/am43xx-resets.dtsi
b/arch/arm/boot/dts/am43xx-resets.dtsi
new file mode 100644
index 000..ef338ba
--- /dev/null
+++ b/arch/arm/boot/dts/am43xx-resets.dtsi
@@ -0,0 +1,52 @@
+/*
+ * Device Tree Source for AM43XX reset data
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * 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.
+ */
+
+prcm_resets {
+ icss_rstctrl {
+ reg = 0x810,
+ 0x814;
+
+ icss_reset: icss_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+
+ gfx_rstctrl {
+ reg = 0x410,
+ 0x414;
+
+ gfx_reset: gfx_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+
+ per_rstctrl {
+ reg = 0x2010,
+ 0x2014;
+
+ iva_reset: iva_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+
+ device_rstctrl {
+ reg = 0x4000,
+ 0x4004;
+
+ device_reset: device_reset {
+ control-bit = 0x01;
+ status-bit = 0x01;
+ };
+ };
+
+};
--
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 CFT] arm: omap1: Migrate debug_ll macros to use 8250.S
Hi, On Thu, Jul 17, 2014 at 11:54:04AM +0100, Daniel Thompson wrote: 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. [...] + config DEBUG_OMAP1UART1 + bool Kernel low-level debugging via OMAP1 UART1 + depends on ARCH_OMAP1 !ARCH_OMAP730 Did you try this with omap1_defconfig and then running menuconfig to see how it looks like? The patch allows to select only OMAP730 ports, but the kernel should be bootable on all core types... 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
[GIT PULL] ARM: OMAP2+: clock cleanup for 3.17
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony, The following changes since commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee: Linux 3.16-rc2 (2014-06-21 19:02:54 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.17/omap-clock-a for you to fetch changes up to acd052bb8119dd9117e0af48ff0ac6e56e61b6b4: ARM: OMAP2+: clock/interface: remove some headers from clkt_iclk.c file (2014-07-15 14:09:24 -0600) - An OMAP clock cleanup series for 3.17 from Tero Kristo. This is in preparation for moving this code into drivers/clk/ti. Basic build, boot, and PM test logs are here: http://www.pwsan.com/omap/testlogs/clock-a-v3.17/20140717034329/ - Tero Kristo (12): ARM: OMAP4+: clock: remove DEFINE_CLK_OMAP_HSDIVIDER macro ARM: OMAP4+: dpll: remove cpu_is_omap44xx checks ARM: OMAP4+: dpll44xx: remove cm-regbits-44xx.h and clock44xx.h includes ARM: OMAP2+: clock: introduce ti_clk_features flags ARM: OMAP2+: clock: add fint values to the ti_clk_features struct ARM: OMAP2+: clock/dpll: add private API for checking if DPLL is in bypass ARM: OMAP2+: clock/dpll: convert bypass check to use clk_features ARM: OMAP2+: clock/dpll: add jitter correction behind clk_features ARM: OMAP2+: clock/interface: add a clk_features definition for idlest value ARM: OMAP2+: clock/dpll: remove unused header includes from clkt_dpll.c ARM: OMAP2+: clock/dpll: remove unused header includes from dpll3xxx.c ARM: OMAP2+: clock/interface: remove some headers from clkt_iclk.c file arch/arm/mach-omap2/clkt_dpll.c | 98 +++-- arch/arm/mach-omap2/clkt_iclk.c | 8 ++-- arch/arm/mach-omap2/clock.c | 76 +--- arch/arm/mach-omap2/clock.h | 44 -- arch/arm/mach-omap2/dpll3xxx.c | 7 +-- arch/arm/mach-omap2/dpll44xx.c | 19 +--- arch/arm/mach-omap2/io.c| 2 + 7 files changed, 154 insertions(+), 100 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJTyBMxAAoJEMePsQ0LvSpLiIAQAJl7wHt44ZVVOwdeabNQppl3 PjqUjgQaT60Kpz4utPg0lOd6pJzzmLQ2cHtbV39U4ZCyMnTFi7wArmOR5htir0gh zBDSBEXNJh4ZFyBBNTdlxhJcVjRnO+ar3HuuqdtQLEP19795IxY8Rk9X3ric+35W 1oeFj9EcCs9Reet4l8FnY5GKcLJvL5KiKD8BIsBa8U1AlHu3Cw8RtfpdQX6zdNMO 1THNKFsIt5PdTmbTuWA9c161DciNeN0QuXQVdqWYzepyOP1rS3zwKyZDEC3mE5Bl TEOuANaJy2IqLJVTSal0hounMPmOUOp/wXr06s2chZ/bGLKZ/riTZm746cSFUTuZ d8sGMxVJ2X9D2MexBzlO/3blg6503WCT1slIZwhEoiqQoDiWG6E/29ZrP752rFWy c/Sa5Ro10pL0wAmjaU4hNxIE7ekksJKXROiqcOiqNeI0egTRu5wn/dNArPAewj25 K6T5sVes9getq98LfgCFdI+9QVr75gGkP7tWjuLhMnp+DSSdVfWlp3XPdazDFPdO qkN7LByiHPTQUsbM7yCUfnlRVPpZdPUDkTJ3VHmbw/VhzCs90kirMywtheXJMWwT carzv/FzdkZAhy1gfnH+GR/JaTm2JizUvA3xEb+V43JvPvgIzxiNhCM4eTYi7ElE svIdX6E2JPB4JeP3DTwo =z9Eq -END PGP SIGNATURE- -- 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
OMAP baseline test results for v3.16-rc5
Here are some basic OMAP test results for Linux v3.16-rc5. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.16-rc5/20140716140950/ Test summary Build: zImage: Pass (16/16): multi_v7_defconfig, omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_am43xx_only, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_dra7xx_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig, rmk_omap4430_sdp_oldconfig Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (10/10): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap5-uevm Boot to userspace: FAIL ( 1/14): 2430sdp skip ( 1/14): 5912osk Pass (12/14): 2420n800, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, am335xbonelt, cmt3517, 4460varsomom, 5430es2uevm PM: chip retention via suspend: FAIL ( 3/ 7): 2430sdp, 4430es2panda, 4460varsomom Pass ( 4/ 7): 3530es3beagle, 3730beaglexm, 37xxevm, 4460pandaes PM: chip retention via dynamic idle: FAIL ( 7/ 7): 2430sdp, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: FAIL ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 4/ 5): 3530es3beagle, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 37xxevm PM: chip off via dynamic idle: FAIL ( 5/ 5): 3530es3beagle, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom vmlinux object size (delta in bytes from test_v3.16-rc4 (cd3de83f147601356395b57a8673e9c5ff1e59d1)): text data bsstotal kernel +16000 +160 omap1_defconfig +19200 +192 omap1_defconfig_1510innovator_only +16000 +160 omap1_defconfig_5912osk_only +1044 -1600 +884 multi_v7_defconfig +284 +160 +300 omap2plus_defconfig +284 +80 +292 omap2plus_defconfig_2430sdp_only +284 +80 +292 omap2plus_defconfig_am33xx_only +524 +1920 +716 omap2plus_defconfig_am43xx_only +348 -160 +332 omap2plus_defconfig_cpupm +284 +80 +292 omap2plus_defconfig_dra7xx_only +17200 +172 omap2plus_defconfig_n800_multi_omap2xxx +140 -80 +132 omap2plus_defconfig_n800_only_a +348 +160 +364 omap2plus_defconfig_no_pm +348 -160 +332 omap2plus_defconfig_omap2_4_only +348 +160 +364 omap2plus_defconfig_omap3_4_only +284 +160 +300 omap2plus_defconfig_omap5_only +2160 -16 +200 rmk_omap3430_ldp_allnoconfig +16000 +160 rmk_omap3430_ldp_oldconfig +1840 -16 +168 rmk_omap4430_sdp_allnoconfig +168 -80 +160 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v3.16-rc4 (cd3de83f147601356395b57a8673e9c5ff1e59d1)) avail rsrvd high freed board kconfig (no differences) Two bugs were fixed in the PM testing scripts for this test. One of them prevented UART wakeups from being enabled. The other caused off-mode test results to not be reported if retention test results failed. (Thanks to Tony for prompting me to closely review the test scripts here and fix them.) After fixing these, suspend/resume power management, including both retention and off-idle, now appears to be working for OMAP37xx-series chips. Dynamic PM idle entry still appears broken, as does PM for OMAP35xx-series chips and OMAP4 chips. -- 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
AM3517 fails to boot 3.16-rc5 device tree kernel
I am in the process of porting a device tree compatible version of the linux kernel to a AM3517 based device. First I tried 3.10.x and the device tree port appeared to be incomplete. Neither the LCD or Ethernet were supported. Next I tried 3.14.x and the Ethernet driver appeared to work but still no LCD support. Lastly I tried 3.16-rc5 and found that the kernel hangs in early boot without any messages from the serial COM. I was using the omap2plus_defconfig and the am3517-evm.dtb from each kernel build. Is there any reason why the kernel would start hanging with the newest release? Are there any versions where the LCD output works? Looking at the 3.16-rc5 test results just posted it is supposed to be working but I have not been able to replicate this. Any suggestions would be greatly appreciated. -- 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
