Re: [GIT PULL] omap fixes against v3.16-rc4
* Olof Johansson o...@lixom.net [140710 14:37]: On Wed, Jul 09, 2014 at 08:35:52AM -0700, Tony Lindgren wrote: The following changes since commit cd3de83f147601356395b57a8673e9c5ff1e59d1: Linux 3.16-rc4 (2014-07-06 12:37:51 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.16/fixes-rc4 for you to fetch changes up to 1d29a0722f6c38f79785c9ffb911730598de84e2: ARM: OMAP2+: Remove non working OMAP HDMI audio initialization (2014-07-08 01:08:44 -0700) Fixes for omaps for the -rc series. It's mostly fixes for clock rates, restart handling and phy regulators and SATA interconnect data. It's a little surprising to see a SATA fix about a week after enablement went in during -rc -- enabling it that late should ideally have been better tested than this. Yes sorry we are having a bit hard time getting things coordinated with driver + dts + hwmod changes. Ideally the hwmod changes for the interconnect would be all done when adding support for a new SoC instead of adding them one driver at a time. And those should be eventually just device tree properties. Also few build fixes related to the DSP driver in staging, and trivial stuff like removal of broken and soon to be unused platform data init for HDMI audio that would be good to get into the -rc series if not too late. Thanks, merged. Definitely time for regressions only from here on out though. Yes agreed. So far I'm not aware of any major regressions for the first time for a few merge cycles. 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 6/6] tty: serial: Add 8250-core based omap driver
* Sebastian Andrzej Siewior bige...@linutronix.de [140710 08:50]: On 07/10/2014 09:09 AM, Tony Lindgren wrote: You can test this pretty easily on beagleboard xm for example using v3.16-r4: I tried this with am335x-evm, dra7-evm and beaglebone (omap5-uevm and am335x-evmsk didn't want to boot a kernel and omap4-blaze didn't even want to show MLO/U-boot) with the same result. None of these SoCs support off-idle with mainline kernel so testing with those is not enough :) Best to use some omap3 based device for testing this. So far I have verified that beagleboard xm, n900, and omap3730-evm all hit off-idle with v3.16-rc4. 1. Compile the kernel using omap2plus_defconfig and enable your driver. USB EHCI needs to be disabled and OTG port should not have a USB cable connected. EHCI was already disabled in the config. OTG was not connected. OK 2. Boot with init=/bin/sh to keep user space timers to minimum at least until you have verified to hit off-idle I had network up and configured. Was that okay? I also tried ifconfig eth0 down; sleep 10; ifconfig eth0 up to see if it works. That's fine for GPMC connected devices, devices with Ethernet on EHCI won't idle properly AFAIK. 3. Enable UART timeouts with something like this. You may need to update it for ttyS, I just changed ttyO to ttyS here: #!/bin/bash uarts=$(find /sys/class/tty/ttyS*/device/power/ -type d) for uart in $uarts; do echo 3000 $uart/autosuspend_delay_ms done uarts=$(find /sys/class/tty/ttyS*/power/ -type d) for uart in $uarts; do echo enabled $uart/wakeup echo auto $uart/control done echo 1 /sys/kernel/debug/pm_debug/enable_off_mode 4. Wait for UART to time out and verify you hit off-idle by looking at the debugfs entry: # cat /sys/kernel/debug/pm_debug/count ... core_pwrdm (ON),OFF:6,RET:0,INA:0,ON:7,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 That core_pwrdm shows only up on dra7. However with both drivers (mine and the current omap serial) the UART went down after three secs (as expected) and didn't accept any characters while writing on the console. If I wrote something on it via network (like echo a /dev/ttyO0) it came back and was working as long as I kept it busy. The thing is that RX does not wake it up. Any idea? If the RX pin does not wake it up, you need to configure the pinctrl-single entry for it, and configure that pin as a wake-up interrupt. See the interrupts-extended entry in omap3-beagle-xm.dts. Also, while it was I checked the core_pwrdm and I had ON:1 and OFF:0. So something is not right. Since Dra7 has some things missing I tried it on am335x with the same behavior. Should it work here? Yes only omap3 currently has the pieces needed for off-idle in the mainline kernel. I just tried testing this, but did not get far on my omap3 evm: [5.445953] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfb02 [5.453674] Internal error: : 1028 [#1] SMP ARM [5.458221] Modules linked in: [5.461334] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-rc4-6-gaab2c6a #98 [5.469024] task: ce058b00 ti: ce05a000 task.ti: ce05a000 [5.474456] PC is at mem32_serial_in+0xc/0x1c [5.478851] LR is at serial8250_do_startup+0xc8/0x89c [5.483917] pc : [c0346f90]lr : [c034ab2c]psr: 6113 [5.483917] sp : ce05bd10 ip : c0a0aba8 fp : ce275400 [5.495452] r10: r9 : cda7a680 r8 : ce27568c [5.500701] r7 : ce275400 r6 : r5 : ce280408 r4 : c10b6234 [5.507263] r3 : fb02 r2 : 0002 r1 : fb02 r0 : c10b6234 [5.513854] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [5.521179] Control: 10c5387d Table: 80004019 DAC: 0015 [5.526977] Process swapper/0 (pid: 1, stack limit = 0xce05a248) [5.532989] Stack: (0xce05bd10 to 0xce05c000) ... [5.734771] [c0346f90] (mem32_serial_in) from [c034ab2c] (serial8250_do_startup+0xc8/0x89c) [5.743530] [c034ab2c] (serial8250_do_startup) from [c03461f8] (uart_startup.part.3+0x7c/0x1dc) [5.752624] [c03461f8] (uart_startup.part.3) from [c0346d68] (uart_open+0xe4/0x124) [5.760681] [c0346d68] (uart_open) from [c032c19c] (tty_open+0x130/0x58c) [5.767852] [c032c19c] (tty_open) from [c01216f4] (chrdev_open+0x9c/0x174) [5.775115] [c01216f4] (chrdev_open) from [c011b8d4] (do_dentry_open+0x1d0/0x310) [5.783020] [c011b8d4] (do_dentry_open) from [c011bd98] (finish_open+0x34/0x4c) [5.790710] [c011bd98] (finish_open) from [c012a8f8] (do_last.isra.27+0x5a4/0xb98) [5.798675] [c012a8f8] (do_last.isra.27) from [c012afa0] (path_openat+0xb4/0x5e4) [5.806549] [c012afa0] (path_openat) from [c012b7dc] (do_filp_open+0x2c/0x80) [5.814086] [c012b7dc] (do_filp_open) from [c011cd14]
Re: [RFC PATCH 00/10] OMAP: GPMC: NAND: Introduce GPMC APIs for OMAP NAND
* Roger Quadros rog...@ti.com [140709 05:39]: Hi, The following hardware modules/registers are meant for NAND controller driver usage: - NAND I/O control (NAND address, data, command registers) - Prefetch/Write-post engine - ECC/BCH engine However, these registers sit in the GPMC controller's register space and there need to be some sane way to access them from the OMAP NAND controller driver. Till now the GPMC driver was populating a data structure (struct gpmc_nand_regs) with the register addresses and passing it to the OMAP NAND driver via platform data. This mechanism cannot be used for true Device tree support as custom platform data passing mechanism doesn't seem to work. Moreover, direct access to these registers must be limited to the GPMC driver. This calls for a few custom OMAP GPMC specific APIs that the OMAP NAND driver can use to access these GPMC space registers. This series attempts to add the following new APIs and gets rid of 'struct gpmc_nand_regs' and 'gpmc_update_nand_regs()'. -For NAND I/O control registers u32 omap_gpmc_read_reg(int cs, enum omap_gpmc_reg reg); void omap_gpmc_write_reg(int cs, enum omap_gpmc_reg reg, u32 val); -For Prefetch engine int omap_gpmc_prefetch_start(int cs, int fifo_th, bool dma, u32 count, int is_write); int omap_gpmc_prefetch_stop(int cs); u32 omap_gpmc_get_prefetch_count(void); u32 omap_gpmc_get_prefetch_fifo_count(void); -For ECC/BCH engine void omap_gpmc_ecc_disable(void); void omap_gpmc_ecc_configure_enable(int cs, bool ecc16, u8 ecc_size0, u8 ecc_size1, bool use_bch, enum omap_gpmc_bch_type bch_type, u8 bch_sectors, u8 bch_wrap_mode); void omap_gpmc_ecc_get_result(int length, u32 *result); void omap_gpmc_ecc_get_bch_result(int length, u8 sector, u32 *result); These seem fine to me. At least I don't have any better ideas to expose these GPMC registers to the NAND driver(s). These APIs don't implement any logic to serialize access to the NAND/Prefetch/ECC registers. It is upto the NAND controller driver to ensure that. As these modules can only handle one NAND controller context at a time, we set the nand_chip-hwcontrol to point to a single controller instance even if there are multiple NAND chips on different Chip select spaces. The NAND base driver then takes care of serializing access to the NAND controller (and ECC) through nandchip-hwcontrol-lock. NOTE: Patches are still untested and only meant for review. 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: [RFC PATCH 00/10] OMAP: GPMC: NAND: Introduce GPMC APIs for OMAP NAND
Hi Roger, From: Tony Lindgren [mailto:t...@atomide.com] * Roger Quadros rog...@ti.com [140709 05:39]: Hi, The following hardware modules/registers are meant for NAND controller driver usage: - NAND I/O control (NAND address, data, command registers) - Prefetch/Write-post engine - ECC/BCH engine However, these registers sit in the GPMC controller's register space and there need to be some sane way to access them from the OMAP NAND controller driver. Till now the GPMC driver was populating a data structure (struct gpmc_nand_regs) with the register addresses and passing it to the OMAP NAND driver via platform data. This mechanism cannot be used for true Device tree support as custom platform data passing mechanism doesn't seem to work. Moreover, direct access to these registers must be limited to the GPMC driver. This calls for a few custom OMAP GPMC specific APIs that the OMAP NAND driver can use to access these GPMC space registers. This series attempts to add the following new APIs and gets rid of 'struct gpmc_nand_regs' and 'gpmc_update_nand_regs()'. -For NAND I/O control registers u32 omap_gpmc_read_reg(int cs, enum omap_gpmc_reg reg); void omap_gpmc_write_reg(int cs, enum omap_gpmc_reg reg, u32 val); -For Prefetch engine int omap_gpmc_prefetch_start(int cs, int fifo_th, bool dma, u32 count, int is_write); int omap_gpmc_prefetch_stop(int cs); u32 omap_gpmc_get_prefetch_count(void); u32 omap_gpmc_get_prefetch_fifo_count(void); -For ECC/BCH engine void omap_gpmc_ecc_disable(void); void omap_gpmc_ecc_configure_enable(int cs, bool ecc16, u8 ecc_size0, u8 ecc_size1, bool use_bch, enum omap_gpmc_bch_type bch_type, u8 bch_sectors, u8 bch_wrap_mode); I think this one has too big argument list. And also this interface will become inconsistent when you will expand the NAND driver to support devices with larger page-size(like 8K NAND devices) Why can't we just use omap_gpmc_write_reg(int cs, enum omap_gpmc_reg reg); as already defined above? This is one-time configuration per read/write cycle so using 'omap_gpmc_write_reg()' shouldn't be much of issue. And this will automatically plugin to current chip-ecc.hwctl() calls. void omap_gpmc_ecc_get_result(int length, u32 *result); Can you please rename it to omap_gpmc_ecc_get_hamming_result() Just to keep it consistent with omap_gpmc_ecc_get_bch_result() void omap_gpmc_ecc_get_bch_result(int length, u8 sector, u32 *result); This one looks good, but you should also take in int 'ecc-scheme'. Actually you can just move omap_calculate_ecc_bch(...) out of NAND driver into GPMC driver and rename it, because support of ECC scheme is property of hardware controller not NAND driver. What ecc-schemes GPMC controller supports should be inside GPMC driver, and NAND driver should just attach them to appropriate interfaces. Right ? Same way just think of moving chip-ecc.hwctl() callbacks implementations out of NAND driver into GPMC driver. Then you would _not_ need to export any GPMC registers into NAND driver. with regards, pekon These seem fine to me. At least I don't have any better ideas to expose these GPMC registers to the NAND driver(s). These APIs don't implement any logic to serialize access to the NAND/Prefetch/ECC registers. It is upto the NAND controller driver to ensure that. As these modules can only handle one NAND controller context at a time, we set the nand_chip-hwcontrol to point to a single controller instance even if there are multiple NAND chips on different Chip select spaces. The NAND base driver then takes care of serializing access to the NAND controller (and ECC) through nandchip-hwcontrol-lock. NOTE: Patches are still untested and only meant for review. 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: [RFC PATCH 02/10] mtd: nand: omap: Always use chip-ecc.steps for BCH sector count
From: Quadros, Roger
Instead of hardcoding use the pre-calculated chip-ecc.steps for
configuring number of sectors to process with the BCH algorithm.
This also avoids unnecessary access to the ECC_CONFIG register in
omap_calculate_ecc_bch().
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mtd/nand/omap2.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5b8739c..6f3d7cd 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1066,10 +1066,10 @@ static void __maybe_unused
omap_enable_hwecc_bch(struct mtd_info
*mtd, int mode)
unsigned int ecc_size1, ecc_size0;
/* GPMC configurations for calculating ECC */
+ nsectors = chip-ecc.steps;
switch (ecc_opt) {
case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW:
bch_type = 0;
- nsectors = 1;
if (mode == NAND_ECC_READ) {
wr_mode = BCH_WRAPMODE_6;
ecc_size0 = BCH_ECC_SIZE0;
@@ -1082,7 +1082,6 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
mtd_info
*mtd, int mode)
break;
case OMAP_ECC_BCH4_CODE_HW:
bch_type = 0;
- nsectors = chip-ecc.steps;
if (mode == NAND_ECC_READ) {
wr_mode = BCH_WRAPMODE_1;
ecc_size0 = BCH4R_ECC_SIZE0;
@@ -1095,7 +1094,6 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
mtd_info
*mtd, int mode)
break;
case OMAP_ECC_BCH8_CODE_HW_DETECTION_SW:
bch_type = 1;
- nsectors = 1;
if (mode == NAND_ECC_READ) {
wr_mode = BCH_WRAPMODE_6;
ecc_size0 = BCH_ECC_SIZE0;
@@ -1108,7 +1106,6 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
mtd_info
*mtd, int mode)
break;
case OMAP_ECC_BCH8_CODE_HW:
bch_type = 1;
- nsectors = chip-ecc.steps;
if (mode == NAND_ECC_READ) {
wr_mode = BCH_WRAPMODE_1;
ecc_size0 = BCH8R_ECC_SIZE0;
@@ -1121,7 +1118,6 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
mtd_info
*mtd, int mode)
break;
case OMAP_ECC_BCH16_CODE_HW:
bch_type = 0x2;
- nsectors = chip-ecc.steps;
if (mode == NAND_ECC_READ) {
wr_mode = 0x01;
ecc_size0 = 52; /* ECC bits in nibbles per sector */
@@ -1176,6 +1172,7 @@ static int __maybe_unused omap_calculate_ecc_bch(struct
mtd_info *mtd,
{
struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
mtd);
+ struct nand_chip *chip = mtd-priv;
int eccbytes= info-nand.ecc.bytes;
struct gpmc_nand_regs *gpmc_regs = info-reg;
u8 *ecc_code;
@@ -1183,7 +1180,7 @@ static int __maybe_unused omap_calculate_ecc_bch(struct
mtd_info *mtd,
u32 val;
int i, j;
- nsectors = ((readl(info-reg.gpmc_ecc_config) 4) 0x7) + 1;
+ nsectors = chip-ecc.steps;
Sorry NAK.. I'm sure you are breaking something here :-)
NAND driver supports multiple ECC schemes like;
OMAP_ECC_CODE_HAM1_HW (support for legacy reasons)
OMAP_ECC_CODE_BCH4_HW_DETECTION_SW (needed for OMAP3 and AM35xx)
OMAP_ECC_CODE_BCH4_HW
OMAP_ECC_CODE_BCH8_HW
OMAP_ECC_CODE_BCH8_HW_DETECTION_SW (needed for OMAP3 and AM35xx)
OMAP_ECC_CODE_BCH16_HW
IIRC ..
- software based ecc-schemes OMAP_ECC_CODE_BCHx_HW_DETECTION_SW
Reads/Write in per-sector granularity. (here nsector != chip-ecc.steps)
- hardware based ecc-schemes OMAP_ECC_CODE_BCHx_HW, perform
Reads/Write in per-page granularity (or something like this).
Therefore you have custom implementation of
chip-ecc.read_page = omap_read_page_bch()
Also if you change the configurations here, it will break the compatibility
with
u-boot, so images flashed via u-boot will stop to boot in kernel and
vice-versa.
I suggest, please refrain from these tweaks for now..
All these optimizations have been tested on multiple scenario so please test
all ecc-schemes before doing anything, otherwise you will end-up in
a bad loop of breaking and fixing NAND driver :-).
with regards, pekon
--
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 07/10] OMAP: GPMC: Introduce APIs for Configuring ECC Engine
Hi Roger, From: Quadros, Roger Even though the ECC/BCH engine is meant for exclusive use by the OMAP NAND controller, the ECC/BCH registers belong to the GPMC controller's register space Add omap_gpmc_ecc_configure_enable() and omap_gpmc_ecc_disable() to manage the ECC engine. OMAP NAND driver must use these APIs instead of directly accessing the ECC Engine registers. Signed-off-by: Roger Quadros rog...@ti.com --- As suggested in http://lists.infradead.org/pipermail/linux-mtd/2014-July/054595.html Please try to move chip-ecc.calculate() implementations like - omap_calculate_ecc_bch() - omap_calculate_ecc() From NAND driver To GPMC driver, as that should be easy, And solve most of your work (no need to export GPMC registers). - You may rename them appropriately and change the argument list if needed. - And NAND driver can just have some wrapper functions to match the MTD interface arguments. with regards, pekon -- 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 09/10] mtd: nand: omap: Use GPMC APIs for accessing ECC/BCH engine
Roger,
From: Quadros, Roger
Don't access the ECC/BCH engine registers directly as they belong
to the GPMC controller's register space. Use the relevant
GPMC APIs instead.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mtd/nand/omap2.c | 191 +++
1 file changed, 76 insertions(+), 115 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 420ef0b..6b0f953 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1123,71 +1088,67 @@ static int __maybe_unused
omap_calculate_ecc_bch(struct mtd_info
*mtd,
switch (info-ecc_opt) {
case OMAP_ECC_BCH8_CODE_HW_DETECTION_SW:
case OMAP_ECC_BCH8_CODE_HW:
- bch_val1 = readl(gpmc_regs-gpmc_bch_result0[i]);
- bch_val2 = readl(gpmc_regs-gpmc_bch_result1[i]);
- bch_val3 = readl(gpmc_regs-gpmc_bch_result2[i]);
- bch_val4 = readl(gpmc_regs-gpmc_bch_result3[i]);
- *ecc_code++ = (bch_val4 0xFF);
- *ecc_code++ = ((bch_val3 24) 0xFF);
- *ecc_code++ = ((bch_val3 16) 0xFF);
- *ecc_code++ = ((bch_val3 8) 0xFF);
- *ecc_code++ = (bch_val3 0xFF);
- *ecc_code++ = ((bch_val2 24) 0xFF);
- *ecc_code++ = ((bch_val2 16) 0xFF);
- *ecc_code++ = ((bch_val2 8) 0xFF);
- *ecc_code++ = (bch_val2 0xFF);
- *ecc_code++ = ((bch_val1 24) 0xFF);
- *ecc_code++ = ((bch_val1 16) 0xFF);
- *ecc_code++ = ((bch_val1 8) 0xFF);
- *ecc_code++ = (bch_val1 0xFF);
+ omap_gpmc_ecc_get_bch_result(4, i, bch_val);
+ *ecc_code++ = (bch_val[3] 0xFF);
+ *ecc_code++ = ((bch_val[2] 24) 0xFF);
+ *ecc_code++ = ((bch_val[2] 16) 0xFF);
+ *ecc_code++ = ((bch_val[2] 8) 0xFF);
+ *ecc_code++ = (bch_val[2] 0xFF);
+ *ecc_code++ = ((bch_val[1] 24) 0xFF);
+ *ecc_code++ = ((bch_val[1] 16) 0xFF);
+ *ecc_code++ = ((bch_val[1] 8) 0xFF);
+ *ecc_code++ = (bch_val[1] 0xFF);
+ *ecc_code++ = ((bch_val[0] 24) 0xFF);
+ *ecc_code++ = ((bch_val[0] 16) 0xFF);
+ *ecc_code++ = ((bch_val[0] 8) 0xFF);
+ *ecc_code++ = (bch_val[0] 0xFF);
break;
case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW:
case OMAP_ECC_BCH4_CODE_HW:
- bch_val1 = readl(gpmc_regs-gpmc_bch_result0[i]);
- bch_val2 = readl(gpmc_regs-gpmc_bch_result1[i]);
- *ecc_code++ = ((bch_val2 12) 0xFF);
- *ecc_code++ = ((bch_val2 4) 0xFF);
- *ecc_code++ = ((bch_val2 0xF) 4) |
- ((bch_val1 28) 0xF);
- *ecc_code++ = ((bch_val1 20) 0xFF);
- *ecc_code++ = ((bch_val1 12) 0xFF);
- *ecc_code++ = ((bch_val1 4) 0xFF);
- *ecc_code++ = ((bch_val1 0xF) 4);
+ omap_gpmc_ecc_get_bch_result(2, i, bch_val);
+ *ecc_code++ = ((bch_val[1] 12) 0xFF);
+ *ecc_code++ = ((bch_val[1] 4) 0xFF);
+ *ecc_code++ = ((bch_val[1] 0xF) 4) |
+ ((bch_val[0] 28) 0xF);
+ *ecc_code++ = ((bch_val[0] 20) 0xFF);
+ *ecc_code++ = ((bch_val[0] 12) 0xFF);
+ *ecc_code++ = ((bch_val[0] 4) 0xFF);
+ *ecc_code++ = ((bch_val[0] 0xF) 4);
break;
case OMAP_ECC_BCH16_CODE_HW:
- val = readl(gpmc_regs-gpmc_bch_result6[i]);
- ecc_code[0] = ((val 8) 0xFF);
- ecc_code[1] = ((val 0) 0xFF);
- val = readl(gpmc_regs-gpmc_bch_result5[i]);
- ecc_code[2] = ((val 24) 0xFF);
- ecc_code[3] = ((val 16) 0xFF);
- ecc_code[4] = ((val 8) 0xFF);
- ecc_code[5] = ((val 0) 0xFF);
- val = readl(gpmc_regs-gpmc_bch_result4[i]);
- ecc_code[6] = ((val 24) 0xFF);
- ecc_code[7] = ((val 16) 0xFF);
- ecc_code[8] = ((val 8) 0xFF);
- ecc_code[9] = ((val 0) 0xFF);
- val = readl(gpmc_regs-gpmc_bch_result3[i]);
- ecc_code[10] = ((val 24) 0xFF);
- ecc_code[11] = ((val 16) 0xFF);
-
Re: [PATCH v4 00/11] ARM: OMAP2+: AM33XX: Add suspend-resume support
On 07/11/2014 04:55 AM, Dave Gerlach wrote: This series adds suspend/resume support for am335x. Version 3 of this series can be found at [1]. I apologize for the large delay between this and the previous revision. This code has been heavily refined since the last version based on the various comments received for v3. The major change from previous version is moving all wkup_m3 code into a remoteproc based driver. The new driver handles all IPC and fw loading and exposes a small API to be used by PM code to achieve low power states. Thanks a lot for this new series, Dave! I've given it a quick test on a custom AM335x board and can confirm success. Tested with both DDR2 and DDR3 versions, both work fine, and power consumption drops to a reasonable level. I'd be very happy if these patches made it in for 3.17, but I haven't followed the discussion on the patches this set depends on. Best regards, Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 00/10] OMAP: GPMC: NAND: Introduce GPMC APIs for OMAP NAND
Hi Pekon, On 07/11/2014 10:27 AM, Gupta, Pekon wrote: Hi Roger, From: Tony Lindgren [mailto:t...@atomide.com] * Roger Quadros rog...@ti.com [140709 05:39]: Hi, The following hardware modules/registers are meant for NAND controller driver usage: - NAND I/O control (NAND address, data, command registers) - Prefetch/Write-post engine - ECC/BCH engine However, these registers sit in the GPMC controller's register space and there need to be some sane way to access them from the OMAP NAND controller driver. Till now the GPMC driver was populating a data structure (struct gpmc_nand_regs) with the register addresses and passing it to the OMAP NAND driver via platform data. This mechanism cannot be used for true Device tree support as custom platform data passing mechanism doesn't seem to work. Moreover, direct access to these registers must be limited to the GPMC driver. This calls for a few custom OMAP GPMC specific APIs that the OMAP NAND driver can use to access these GPMC space registers. This series attempts to add the following new APIs and gets rid of 'struct gpmc_nand_regs' and 'gpmc_update_nand_regs()'. -For NAND I/O control registers u32 omap_gpmc_read_reg(int cs, enum omap_gpmc_reg reg); void omap_gpmc_write_reg(int cs, enum omap_gpmc_reg reg, u32 val); -For Prefetch engine int omap_gpmc_prefetch_start(int cs, int fifo_th, bool dma, u32 count, int is_write); int omap_gpmc_prefetch_stop(int cs); u32 omap_gpmc_get_prefetch_count(void); u32 omap_gpmc_get_prefetch_fifo_count(void); -For ECC/BCH engine void omap_gpmc_ecc_disable(void); void omap_gpmc_ecc_configure_enable(int cs, bool ecc16, u8 ecc_size0, u8 ecc_size1, bool use_bch, enum omap_gpmc_bch_type bch_type, u8 bch_sectors, u8 bch_wrap_mode); I think this one has too big argument list. And also this interface will become inconsistent when you will expand the NAND driver to support devices with larger page-size(like 8K NAND devices) Why can't we just use omap_gpmc_write_reg(int cs, enum omap_gpmc_reg reg); as already defined above? omap_gpmc_write_reg will not be optimal for reading larger result blocks and does not create enough abstraction between the clearly separate blocks i.e. prefetch engine and ecc engine. This is one-time configuration per read/write cycle so using 'omap_gpmc_write_reg()' shouldn't be much of issue. And this will automatically plugin to current chip-ecc.hwctl() calls. hwctl() doesn't take care of ECC. Those are done by chip-ecc.correct() and chip-ecc.calculate(). void omap_gpmc_ecc_get_result(int length, u32 *result); Can you please rename it to omap_gpmc_ecc_get_hamming_result() Just to keep it consistent with omap_gpmc_ecc_get_bch_result() OK. Sounds reasonable. void omap_gpmc_ecc_get_bch_result(int length, u8 sector, u32 *result); This one looks good, but you should also take in int 'ecc-scheme'. Could you please explain why? Actually you can just move omap_calculate_ecc_bch(...) out of NAND driver into GPMC driver and rename it, because support of ECC scheme is property of hardware controller not NAND driver. What ecc-schemes GPMC controller supports should be inside GPMC driver, and NAND driver should just attach them to appropriate interfaces. Right ? Same way just think of moving chip-ecc.hwctl() callbacks implementations out of NAND driver into GPMC driver. Then you would _not_ need to export any GPMC registers into NAND driver. I don't agree with moving anything nand_chip related (i.e. ecc.hwctl(), ecc.calculate() or ecc.correct()) to GMPC driver because they are supposed to be implemented by the NAND driver. ECC is a functionality of NAND controller not of GPMC controller. It is just a IP design mistake that they smudged the ECC registers so badly in the GPMC register space. Could you please explain your view point as to why you want me to move these ecc.*() to GPMC driver other than being extensively tested? We can extensively test the new changes before merging any code to mainline as well. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 00/10] OMAP: GPMC: NAND: Introduce GPMC APIs for OMAP NAND
From: Quadros, Roger On 07/11/2014 10:27 AM, Gupta, Pekon wrote: From: Tony Lindgren [mailto:t...@atomide.com] * Roger Quadros rog...@ti.com [140709 05:39]: Hi, The following hardware modules/registers are meant for NAND controller driver usage: - NAND I/O control (NAND address, data, command registers) - Prefetch/Write-post engine - ECC/BCH engine However, these registers sit in the GPMC controller's register space and there need to be some sane way to access them from the OMAP NAND controller driver. Till now the GPMC driver was populating a data structure (struct gpmc_nand_regs) with the register addresses and passing it to the OMAP NAND driver via platform data. This mechanism cannot be used for true Device tree support as custom platform data passing mechanism doesn't seem to work. Moreover, direct access to these registers must be limited to the GPMC driver. This calls for a few custom OMAP GPMC specific APIs that the OMAP NAND driver can use to access these GPMC space registers. This series attempts to add the following new APIs and gets rid of 'struct gpmc_nand_regs' and 'gpmc_update_nand_regs()'. -For NAND I/O control registers u32 omap_gpmc_read_reg(int cs, enum omap_gpmc_reg reg); void omap_gpmc_write_reg(int cs, enum omap_gpmc_reg reg, u32 val); -For Prefetch engine int omap_gpmc_prefetch_start(int cs, int fifo_th, bool dma, u32 count, int is_write); int omap_gpmc_prefetch_stop(int cs); u32 omap_gpmc_get_prefetch_count(void); u32 omap_gpmc_get_prefetch_fifo_count(void); -For ECC/BCH engine void omap_gpmc_ecc_disable(void); void omap_gpmc_ecc_configure_enable(int cs, bool ecc16, u8 ecc_size0, u8 ecc_size1, bool use_bch, enum omap_gpmc_bch_type bch_type, u8 bch_sectors, u8 bch_wrap_mode); I think this one has too big argument list. And also this interface will become inconsistent when you will expand the NAND driver to support devices with larger page-size(like 8K NAND devices) Why can't we just use omap_gpmc_write_reg(int cs, enum omap_gpmc_reg reg); as already defined above? omap_gpmc_write_reg will not be optimal for reading larger result blocks and does not create enough abstraction between the clearly separate blocks i.e. prefetch engine and ecc engine. This is one-time configuration per read/write cycle so using 'omap_gpmc_write_reg()' shouldn't be much of issue. And this will automatically plugin to current chip-ecc.hwctl() calls. hwctl() doesn't take care of ECC. Those are done by chip-ecc.correct() and chip-ecc.calculate(). Incorrect assumption :-). chip-ecc.hwctl() is used to configure ecc_size0 and ecc_size1, which in-turn depend on ecc-scheme selected. Also, ecc_wrap_mode differs from ecc-scheme for software and hardware implementations. void omap_gpmc_ecc_get_result(int length, u32 *result); Can you please rename it to omap_gpmc_ecc_get_hamming_result() Just to keep it consistent with omap_gpmc_ecc_get_bch_result() OK. Sounds reasonable. void omap_gpmc_ecc_get_bch_result(int length, u8 sector, u32 *result); This one looks good, but you should also take in int 'ecc-scheme'. Could you please explain why? Actually you can just move omap_calculate_ecc_bch(...) out of NAND driver into GPMC driver and rename it, because support of ECC scheme is property of hardware controller not NAND driver. What ecc-schemes GPMC controller supports should be inside GPMC driver, and NAND driver should just attach them to appropriate interfaces. Right ? Same way just think of moving chip-ecc.hwctl() callbacks implementations out of NAND driver into GPMC driver. Then you would _not_ need to export any GPMC registers into NAND driver. I don't agree with moving anything nand_chip related (i.e. ecc.hwctl(), ecc.calculate() or ecc.correct()) to GMPC driver because they are supposed to be implemented by the NAND driver. ECC is a functionality of NAND controller not of GPMC controller. It is just a IP design mistake that they smudged the ECC registers so badly in the GPMC register space. Not really, I don't think that's a problem. That's TI's way of looking at controller architecture. If you read discussion of GPMI (freescale's NAND controller) and NAND controllers from other vendors, there are other complexities. Anyways that's not the discussion here, so converging back :-) .. And, yes, you should _not_ touch chip-ecc.correct() or any other such Implementations because those are NAND framework specific. But below code isn't related to NAND framework, all NAND needs is how you calcaluate the ECC, whether you do by - reading GPMC registers or - by using software bch library, or - mixed of both. Therefore, I suggest you to move following code from NAND driver to GPMC driver, nothing other than. And this exported function does not need any NAND framework information, except number_of_sectors.
Re: [RFC PATCH 00/10] OMAP: GPMC: NAND: Introduce GPMC APIs for OMAP NAND
On 07/11/2014 12:42 PM, Gupta, Pekon wrote: From: Quadros, Roger On 07/11/2014 10:27 AM, Gupta, Pekon wrote: From: Tony Lindgren [mailto:t...@atomide.com] * Roger Quadros rog...@ti.com [140709 05:39]: Hi, The following hardware modules/registers are meant for NAND controller driver usage: - NAND I/O control (NAND address, data, command registers) - Prefetch/Write-post engine - ECC/BCH engine However, these registers sit in the GPMC controller's register space and there need to be some sane way to access them from the OMAP NAND controller driver. Till now the GPMC driver was populating a data structure (struct gpmc_nand_regs) with the register addresses and passing it to the OMAP NAND driver via platform data. This mechanism cannot be used for true Device tree support as custom platform data passing mechanism doesn't seem to work. Moreover, direct access to these registers must be limited to the GPMC driver. This calls for a few custom OMAP GPMC specific APIs that the OMAP NAND driver can use to access these GPMC space registers. This series attempts to add the following new APIs and gets rid of 'struct gpmc_nand_regs' and 'gpmc_update_nand_regs()'. -For NAND I/O control registers u32 omap_gpmc_read_reg(int cs, enum omap_gpmc_reg reg); void omap_gpmc_write_reg(int cs, enum omap_gpmc_reg reg, u32 val); -For Prefetch engine int omap_gpmc_prefetch_start(int cs, int fifo_th, bool dma, u32 count, int is_write); int omap_gpmc_prefetch_stop(int cs); u32 omap_gpmc_get_prefetch_count(void); u32 omap_gpmc_get_prefetch_fifo_count(void); -For ECC/BCH engine void omap_gpmc_ecc_disable(void); void omap_gpmc_ecc_configure_enable(int cs, bool ecc16, u8 ecc_size0, u8 ecc_size1, bool use_bch, enum omap_gpmc_bch_type bch_type, u8 bch_sectors, u8 bch_wrap_mode); I think this one has too big argument list. And also this interface will become inconsistent when you will expand the NAND driver to support devices with larger page-size(like 8K NAND devices) Why can't we just use omap_gpmc_write_reg(int cs, enum omap_gpmc_reg reg); as already defined above? omap_gpmc_write_reg will not be optimal for reading larger result blocks and does not create enough abstraction between the clearly separate blocks i.e. prefetch engine and ecc engine. This is one-time configuration per read/write cycle so using 'omap_gpmc_write_reg()' shouldn't be much of issue. And this will automatically plugin to current chip-ecc.hwctl() calls. hwctl() doesn't take care of ECC. Those are done by chip-ecc.correct() and chip-ecc.calculate(). Incorrect assumption :-). chip-ecc.hwctl() is used to configure ecc_size0 and ecc_size1, which in-turn depend on ecc-scheme selected. Also, ecc_wrap_mode differs from ecc-scheme for software and hardware implementations. Right. so hwctl(), calculate() and correct() go hand in hand and must be implemented by the NAND controller driver. void omap_gpmc_ecc_get_result(int length, u32 *result); Can you please rename it to omap_gpmc_ecc_get_hamming_result() Just to keep it consistent with omap_gpmc_ecc_get_bch_result() OK. Sounds reasonable. void omap_gpmc_ecc_get_bch_result(int length, u8 sector, u32 *result); This one looks good, but you should also take in int 'ecc-scheme'. Could you please explain why? Actually you can just move omap_calculate_ecc_bch(...) out of NAND driver into GPMC driver and rename it, because support of ECC scheme is property of hardware controller not NAND driver. What ecc-schemes GPMC controller supports should be inside GPMC driver, and NAND driver should just attach them to appropriate interfaces. Right ? Same way just think of moving chip-ecc.hwctl() callbacks implementations out of NAND driver into GPMC driver. Then you would _not_ need to export any GPMC registers into NAND driver. I don't agree with moving anything nand_chip related (i.e. ecc.hwctl(), ecc.calculate() or ecc.correct()) to GMPC driver because they are supposed to be implemented by the NAND driver. ECC is a functionality of NAND controller not of GPMC controller. It is just a IP design mistake that they smudged the ECC registers so badly in the GPMC register space. Not really, I don't think that's a problem. That's TI's way of looking at Moreover, that is TI's legacy stuff coming right from OMAP2/3 days. controller architecture. If you read discussion of GPMI (freescale's NAND controller) and NAND controllers from other vendors, there are other complexities. Anyways that's not the discussion here, so converging back :-) .. And, yes, you should _not_ touch chip-ecc.correct() or any other such Implementations because those are NAND framework specific. But below code isn't related to NAND framework, all NAND needs is how you calcaluate the ECC, whether you do by - reading GPMC
Re: [RFC PATCH 02/10] mtd: nand: omap: Always use chip-ecc.steps for BCH sector count
On 07/11/2014 10:43 AM, Gupta, Pekon wrote:
From: Quadros, Roger
Instead of hardcoding use the pre-calculated chip-ecc.steps for
configuring number of sectors to process with the BCH algorithm.
This also avoids unnecessary access to the ECC_CONFIG register in
omap_calculate_ecc_bch().
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mtd/nand/omap2.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5b8739c..6f3d7cd 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1066,10 +1066,10 @@ static void __maybe_unused
omap_enable_hwecc_bch(struct mtd_info
*mtd, int mode)
unsigned int ecc_size1, ecc_size0;
/* GPMC configurations for calculating ECC */
+nsectors = chip-ecc.steps;
switch (ecc_opt) {
case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW:
bch_type = 0;
-nsectors = 1;
if (mode == NAND_ECC_READ) {
wr_mode = BCH_WRAPMODE_6;
ecc_size0 = BCH_ECC_SIZE0;
@@ -1082,7 +1082,6 @@ static void __maybe_unused
omap_enable_hwecc_bch(struct mtd_info
*mtd, int mode)
break;
case OMAP_ECC_BCH4_CODE_HW:
bch_type = 0;
-nsectors = chip-ecc.steps;
if (mode == NAND_ECC_READ) {
wr_mode = BCH_WRAPMODE_1;
ecc_size0 = BCH4R_ECC_SIZE0;
@@ -1095,7 +1094,6 @@ static void __maybe_unused
omap_enable_hwecc_bch(struct mtd_info
*mtd, int mode)
break;
case OMAP_ECC_BCH8_CODE_HW_DETECTION_SW:
bch_type = 1;
-nsectors = 1;
if (mode == NAND_ECC_READ) {
wr_mode = BCH_WRAPMODE_6;
ecc_size0 = BCH_ECC_SIZE0;
@@ -1108,7 +1106,6 @@ static void __maybe_unused
omap_enable_hwecc_bch(struct mtd_info
*mtd, int mode)
break;
case OMAP_ECC_BCH8_CODE_HW:
bch_type = 1;
-nsectors = chip-ecc.steps;
if (mode == NAND_ECC_READ) {
wr_mode = BCH_WRAPMODE_1;
ecc_size0 = BCH8R_ECC_SIZE0;
@@ -1121,7 +1118,6 @@ static void __maybe_unused
omap_enable_hwecc_bch(struct mtd_info
*mtd, int mode)
break;
case OMAP_ECC_BCH16_CODE_HW:
bch_type = 0x2;
-nsectors = chip-ecc.steps;
if (mode == NAND_ECC_READ) {
wr_mode = 0x01;
ecc_size0 = 52; /* ECC bits in nibbles per sector */
@@ -1176,6 +1172,7 @@ static int __maybe_unused
omap_calculate_ecc_bch(struct mtd_info *mtd,
{
struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
mtd);
+struct nand_chip *chip = mtd-priv;
int eccbytes= info-nand.ecc.bytes;
struct gpmc_nand_regs *gpmc_regs = info-reg;
u8 *ecc_code;
@@ -1183,7 +1180,7 @@ static int __maybe_unused
omap_calculate_ecc_bch(struct mtd_info *mtd,
u32 val;
int i, j;
-nsectors = ((readl(info-reg.gpmc_ecc_config) 4) 0x7) + 1;
+nsectors = chip-ecc.steps;
Sorry NAK.. I'm sure you are breaking something here :-)
NAND driver supports multiple ECC schemes like;
OMAP_ECC_CODE_HAM1_HW (support for legacy reasons)
OMAP_ECC_CODE_BCH4_HW_DETECTION_SW (needed for OMAP3 and AM35xx)
OMAP_ECC_CODE_BCH4_HW
OMAP_ECC_CODE_BCH8_HW
OMAP_ECC_CODE_BCH8_HW_DETECTION_SW (needed for OMAP3 and AM35xx)
OMAP_ECC_CODE_BCH16_HW
IIRC ..
- software based ecc-schemes OMAP_ECC_CODE_BCHx_HW_DETECTION_SW
Reads/Write in per-sector granularity. (here nsector != chip-ecc.steps)
OK. I still don't have a full understanding about the ECC schemes so to ensure
we
don't break anything I can just leave nsectors as it is and probably just store
a
copy of it in omap_nand_info to avoid reading it back from gpmc_ecc_config.
I still have a few questions to clarify my understanding.
The only difference between OMAP_ECC_CODE_BCHx_HW_DETECTION_SW and
OMAP_ECC_CODE_BCHx_HW is that in the former the _correction_ is done by software
and in the latter the _correction_ is done by hardware (i.e. ELM module).
In both cases the _detection_ is done by the same hardware IP via
ecc.calculate(),
i.e. omap_calculate_ecc_bch().
so why should nsector be different for both in the _detection_ stage?
An I right that ecc_steps is nothing but number of sub-blocks ECC calculation
and correction
needs to be done for larger pages. This is a function of ECC hw capability
(chip-ecc.size)
and NAND flash capability (mtd-writesize). i.e. ecc_steps = mtd-writesize /
chip-ecc.size
We hardcode chip-ecc.size to 512 for all the ECC schemes in omap_nand_probe()
so
calculate and correct will always be called for 512 byte sized blocks. So when
does
the usecase for nsector 1 come in?
cheers,
-roger
--
To unsubscribe from this list: send
RE: [RFC PATCH 02/10] mtd: nand: omap: Always use chip-ecc.steps for BCH sector count
From: Quadros, Roger
On 07/11/2014 10:43 AM, Gupta, Pekon wrote:
From: Quadros, Roger
[...]
@@ -1176,6 +1172,7 @@ static int __maybe_unused
omap_calculate_ecc_bch(struct mtd_info
*mtd,
{
struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
mtd);
+ struct nand_chip *chip = mtd-priv;
int eccbytes= info-nand.ecc.bytes;
struct gpmc_nand_regs *gpmc_regs = info-reg;
u8 *ecc_code;
@@ -1183,7 +1180,7 @@ static int __maybe_unused
omap_calculate_ecc_bch(struct mtd_info
*mtd,
u32 val;
int i, j;
- nsectors = ((readl(info-reg.gpmc_ecc_config) 4) 0x7) + 1;
+ nsectors = chip-ecc.steps;
Sorry NAK.. I'm sure you are breaking something here :-)
NAND driver supports multiple ECC schemes like;
OMAP_ECC_CODE_HAM1_HW (support for legacy reasons)
OMAP_ECC_CODE_BCH4_HW_DETECTION_SW (needed for OMAP3 and AM35xx)
OMAP_ECC_CODE_BCH4_HW
OMAP_ECC_CODE_BCH8_HW
OMAP_ECC_CODE_BCH8_HW_DETECTION_SW (needed for OMAP3 and AM35xx)
OMAP_ECC_CODE_BCH16_HW
IIRC ..
- software based ecc-schemes OMAP_ECC_CODE_BCHx_HW_DETECTION_SW
Reads/Write in per-sector granularity. (here nsector != chip-ecc.steps)
OK. I still don't have a full understanding about the ECC schemes so to ensure
we
don't break anything I can just leave nsectors as it is and probably just
store a
copy of it in omap_nand_info to avoid reading it back from gpmc_ecc_config.
I still have a few questions to clarify my understanding.
The only difference between OMAP_ECC_CODE_BCHx_HW_DETECTION_SW and
OMAP_ECC_CODE_BCHx_HW is that in the former the _correction_ is done by
software
and in the latter the _correction_ is done by hardware (i.e. ELM module).
In both cases the _detection_ is done by the same hardware IP via
ecc.calculate(),
i.e. omap_calculate_ecc_bch().
so why should nsector be different for both in the _detection_ stage?
Again IIRC, That is because of ELM driver.
ELM hardware engine has 8 channels with each of them having 512Bytes capacity.
Now, there can be two approaches:
(1) SECTOR_MODE: Process only one sector of 512 bytes at a time, and iterate
chip-ecc.steps times.
(2) PAGE_MODE: Process complete page at a time, enabling multiple channels
simultaneously. This improves some throughput, especially for large-page
NAND devices and MLC NAND where bit-flips are common.
As ELM uses (2)nd approach, so the GPMC also has to calculate and store
ECC for complete page at a time. That is why trace NAND driver you will find
- OMAP_ECC_CODE_BCHx_HW_DETECTION_SW use generic implementation
chip-ecc.read_page= nand_read_page_hwecc() defined in nand_base.c
whereas,
- OMAP_ECC_CODE_BCHx_HW use custom implementation
chip-ecc.read_page= omap_read_page_bch() defined in omap.c
An I right that ecc_steps is nothing but number of sub-blocks ECC calculation
and correction
needs to be done for larger pages. This is a function of ECC hw capability
(chip-ecc.size)
and NAND flash capability (mtd-writesize). i.e. ecc_steps = mtd-writesize /
chip-ecc.size
We hardcode chip-ecc.size to 512 for all the ECC schemes in omap_nand_probe()
so
calculate and correct will always be called for 512 byte sized blocks. So when
does
the usecase for nsector 1 come in?
Ok.. I'll try to explain above details again in probably simplified version
- OMAP_ECC_CODE_BCHx_HW_DETECTION_SW
uses lib/bch.c (via nand_bch.c) to correct ECC. And is generic implementation
so here each sector (data chunk of ecc_size) is corrected independently.
So nsector = 1;
- OMAP_ECC_CODE_BCHx_HW
Uses ELM to correct ECC. But the way ELM driver is written today. It corrects
the whole page in single go. Not individual sectors (ecc_size chunks).
So, its doable to make it same like OMAP_ECC_CODE_BCHx_HW_DETECTION_SW
But then you _may_ have performance penalty for new technology NAND and MLC
NAND on which bit-flips are very common.
So to keep ELM driver as it is (performance tweaked), we use different
configurations in GPMC to read complete page in single go. This is where
nsector = chip-ecc.steps;
Hope that clarifies the implementation..
Good to document this detail somewhere for OMAP drivers both (u-boot and
kernel).
Any thoughts ?
with regards, pekon
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 02/10] mtd: nand: omap: Always use chip-ecc.steps for BCH sector count
On 07/11/2014 02:27 PM, Gupta, Pekon wrote:
From: Quadros, Roger
On 07/11/2014 10:43 AM, Gupta, Pekon wrote:
From: Quadros, Roger
[...]
@@ -1176,6 +1172,7 @@ static int __maybe_unused
omap_calculate_ecc_bch(struct mtd_info
*mtd,
{
struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
mtd);
+ struct nand_chip *chip = mtd-priv;
int eccbytes= info-nand.ecc.bytes;
struct gpmc_nand_regs *gpmc_regs = info-reg;
u8 *ecc_code;
@@ -1183,7 +1180,7 @@ static int __maybe_unused
omap_calculate_ecc_bch(struct mtd_info
*mtd,
u32 val;
int i, j;
- nsectors = ((readl(info-reg.gpmc_ecc_config) 4) 0x7) + 1;
+ nsectors = chip-ecc.steps;
Sorry NAK.. I'm sure you are breaking something here :-)
NAND driver supports multiple ECC schemes like;
OMAP_ECC_CODE_HAM1_HW (support for legacy reasons)
OMAP_ECC_CODE_BCH4_HW_DETECTION_SW (needed for OMAP3 and AM35xx)
OMAP_ECC_CODE_BCH4_HW
OMAP_ECC_CODE_BCH8_HW
OMAP_ECC_CODE_BCH8_HW_DETECTION_SW (needed for OMAP3 and AM35xx)
OMAP_ECC_CODE_BCH16_HW
IIRC ..
- software based ecc-schemes OMAP_ECC_CODE_BCHx_HW_DETECTION_SW
Reads/Write in per-sector granularity. (here nsector != chip-ecc.steps)
OK. I still don't have a full understanding about the ECC schemes so to
ensure we
don't break anything I can just leave nsectors as it is and probably just
store a
copy of it in omap_nand_info to avoid reading it back from gpmc_ecc_config.
I still have a few questions to clarify my understanding.
The only difference between OMAP_ECC_CODE_BCHx_HW_DETECTION_SW and
OMAP_ECC_CODE_BCHx_HW is that in the former the _correction_ is done by
software
and in the latter the _correction_ is done by hardware (i.e. ELM module).
In both cases the _detection_ is done by the same hardware IP via
ecc.calculate(),
i.e. omap_calculate_ecc_bch().
so why should nsector be different for both in the _detection_ stage?
Again IIRC, That is because of ELM driver.
ELM hardware engine has 8 channels with each of them having 512Bytes capacity.
Now, there can be two approaches:
(1) SECTOR_MODE: Process only one sector of 512 bytes at a time, and iterate
chip-ecc.steps times.
(2) PAGE_MODE: Process complete page at a time, enabling multiple channels
simultaneously. This improves some throughput, especially for large-page
NAND devices and MLC NAND where bit-flips are common.
As ELM uses (2)nd approach, so the GPMC also has to calculate and store
ECC for complete page at a time. That is why trace NAND driver you will find
- OMAP_ECC_CODE_BCHx_HW_DETECTION_SW use generic implementation
chip-ecc.read_page= nand_read_page_hwecc() defined in nand_base.c
whereas,
- OMAP_ECC_CODE_BCHx_HW use custom implementation
chip-ecc.read_page= omap_read_page_bch() defined in omap.c
An I right that ecc_steps is nothing but number of sub-blocks ECC
calculation and correction
needs to be done for larger pages. This is a function of ECC hw capability
(chip-ecc.size)
and NAND flash capability (mtd-writesize). i.e. ecc_steps = mtd-writesize
/ chip-ecc.size
We hardcode chip-ecc.size to 512 for all the ECC schemes in
omap_nand_probe() so
calculate and correct will always be called for 512 byte sized blocks. So
when does
the usecase for nsector 1 come in?
Ok.. I'll try to explain above details again in probably simplified version
- OMAP_ECC_CODE_BCHx_HW_DETECTION_SW
uses lib/bch.c (via nand_bch.c) to correct ECC. And is generic
implementation
so here each sector (data chunk of ecc_size) is corrected independently.
So nsector = 1;
- OMAP_ECC_CODE_BCHx_HW
Uses ELM to correct ECC. But the way ELM driver is written today. It
corrects
the whole page in single go. Not individual sectors (ecc_size chunks).
Then shouldn't chip-ecc.size be equal page size and chip-ecc.steps be equal
to 1 for upto 4KB pages?
For larger pages it can be a multiple of 4KB page size. i.e. 2 for 8KB, 4 for
16KB and so on.
So nsectors is not necessarily equal to ecc.steps but equal to how many 512
byte blocks are there in
one step. i.e. [min(4096, page_size) / 512]. And it must be local to omap NAND
driver.
So, its doable to make it same like OMAP_ECC_CODE_BCHx_HW_DETECTION_SW
But then you _may_ have performance penalty for new technology NAND and MLC
NAND on which bit-flips are very common.
So to keep ELM driver as it is (performance tweaked), we use different
configurations in GPMC to read complete page in single go. This is where
nsector = chip-ecc.steps;
Hope that clarifies the implementation..
Good to document this detail somewhere for OMAP drivers both (u-boot and
kernel).
Any thoughts ?
Sure. we have the processors wiki. That should be a good place.
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
Re: [PATCH] ARM: omap2+: gpmc-nand: Use dynamic platform_device_alloc()
On 07/09/2014 03:49 PM, Roger Quadros wrote:
Hi Rostislav,
On 06/04/2014 05:24 PM, Rostislav Lisovy wrote:
GPMC controller supports up to 8 memory devices connected to it.
Since there is one statically allocated struct platform_device
gpmc_nand_device it is not possible to configure the system to
use more than one NAND device connected to the GPMC. This
modification makes it possible to use up to 8 NAND devices
connected to the GPMC controller.
Signed-off-by: Rostislav Lisovy lis...@merica.cz
---
Tested on custom AM335x board with two different NAND chips
(128 + 256 MiB) using GPMC configuration in FDT -- behaves
correctly.
arch/arm/mach-omap2/gpmc-nand.c | 79
+++--
1 file changed, 37 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c
b/arch/arm/mach-omap2/gpmc-nand.c
index 4349e82..c5481a8 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -24,25 +24,6 @@
/* minimum size for IO mapping */
#define NAND_IO_SIZE4
-static struct resource gpmc_nand_resource[] = {
-{
-.flags = IORESOURCE_MEM,
-},
-{
-.flags = IORESOURCE_IRQ,
-},
-{
-.flags = IORESOURCE_IRQ,
-},
-};
-
-static struct platform_device gpmc_nand_device = {
-.name = omap2-nand,
-.id = 0,
-.num_resources = ARRAY_SIZE(gpmc_nand_resource),
-.resource = gpmc_nand_resource,
-};
-
static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
{
/* platforms which support all ECC schemes */
@@ -93,43 +74,41 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
{
int err = 0;
struct gpmc_settings s;
-struct device *dev = gpmc_nand_device.dev;
-
-memset(s, 0, sizeof(struct gpmc_settings));
+struct platform_device *pdev;
+struct resource gpmc_nand_res[] = {
+{ .flags = IORESOURCE_MEM, },
+{ .flags = IORESOURCE_IRQ, },
+{ .flags = IORESOURCE_IRQ, },
+};
-gpmc_nand_device.dev.platform_data = gpmc_nand_data;
+BUG_ON(gpmc_nand_data-cs = GPMC_CS_NUM);
err = gpmc_cs_request(gpmc_nand_data-cs, NAND_IO_SIZE,
-(unsigned long *)gpmc_nand_resource[0].start);
+ (unsigned long *)gpmc_nand_res[0].start);
if (err 0) {
-dev_err(dev, Cannot request GPMC CS %d, error %d\n,
-gpmc_nand_data-cs, err);
+pr_err(omap2-gpmc: Cannot request GPMC CS %d, error %d\n,
+ gpmc_nand_data-cs, err);
return err;
}
-
-gpmc_nand_resource[0].end = gpmc_nand_resource[0].start +
-NAND_IO_SIZE - 1;
-
-gpmc_nand_resource[1].start =
-gpmc_get_client_irq(GPMC_IRQ_FIFOEVENTENABLE);
-gpmc_nand_resource[2].start =
-gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
+gpmc_nand_res[0].end = gpmc_nand_res[0].start + NAND_IO_SIZE - 1;
+gpmc_nand_res[1].start = gpmc_get_client_irq(GPMC_IRQ_FIFOEVENTENABLE);
+gpmc_nand_res[2].start = gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
if (gpmc_t) {
err = gpmc_cs_set_timings(gpmc_nand_data-cs, gpmc_t);
if (err 0) {
-dev_err(dev, Unable to set gpmc timings: %d\n, err);
+pr_err(omap2-gpmc: Unable to set gpmc timings: %d\n,
err);
return err;
}
}
+memset(s, 0, sizeof(struct gpmc_settings));
if (gpmc_nand_data-of_node)
gpmc_read_settings_dt(gpmc_nand_data-of_node, s);
else
gpmc_set_legacy(gpmc_nand_data, s);
s.device_nand = true;
-
err = gpmc_cs_program_settings(gpmc_nand_data-cs, s);
if (err 0)
goto out_free_cs;
@@ -141,18 +120,34 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
gpmc_update_nand_reg(gpmc_nand_data-reg, gpmc_nand_data-cs);
if (!gpmc_hwecc_bch_capable(gpmc_nand_data-ecc_opt)) {
-dev_err(dev, Unsupported NAND ECC scheme selected\n);
-return -EINVAL;
+pr_err(omap2-nand: Unsupported NAND ECC scheme selected\n);
+err = -EINVAL;
+goto out_free_cs;
}
-err = platform_device_register(gpmc_nand_device);
-if (err 0) {
-dev_err(dev, Unable to register NAND device\n);
-goto out_free_cs;
+
+pdev = platform_device_alloc(omap2-nand, gpmc_nand_data-cs);
+if (pdev) {
+err = platform_device_add_resources(pdev, gpmc_nand_res,
+ARRAY_SIZE(gpmc_nand_res));
+if (!err)
+pdev-dev.platform_data = gpmc_nand_data;
+} else {
+
Re: [PATCH] ARM: omap2+: gpmc-nand: Use dynamic platform_device_alloc()
On 06/04/2014 05:24 PM, Rostislav Lisovy wrote:
GPMC controller supports up to 8 memory devices connected to it.
Since there is one statically allocated struct platform_device
gpmc_nand_device it is not possible to configure the system to
use more than one NAND device connected to the GPMC. This
modification makes it possible to use up to 8 NAND devices
connected to the GPMC controller.
Signed-off-by: Rostislav Lisovy lis...@merica.cz
pushed to g...@github.com:rogerq/linux.git for-v3.17/gpmc-omap
Tony,
You can please pull all omap-gpmc patches for 3.17 from there. Thanks.
cheers,
-roger
---
Tested on custom AM335x board with two different NAND chips
(128 + 256 MiB) using GPMC configuration in FDT -- behaves
correctly.
arch/arm/mach-omap2/gpmc-nand.c | 79
+++--
1 file changed, 37 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 4349e82..c5481a8 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -24,25 +24,6 @@
/* minimum size for IO mapping */
#define NAND_IO_SIZE4
-static struct resource gpmc_nand_resource[] = {
- {
- .flags = IORESOURCE_MEM,
- },
- {
- .flags = IORESOURCE_IRQ,
- },
- {
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct platform_device gpmc_nand_device = {
- .name = omap2-nand,
- .id = 0,
- .num_resources = ARRAY_SIZE(gpmc_nand_resource),
- .resource = gpmc_nand_resource,
-};
-
static bool gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
{
/* platforms which support all ECC schemes */
@@ -93,43 +74,41 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
{
int err = 0;
struct gpmc_settings s;
- struct device *dev = gpmc_nand_device.dev;
-
- memset(s, 0, sizeof(struct gpmc_settings));
+ struct platform_device *pdev;
+ struct resource gpmc_nand_res[] = {
+ { .flags = IORESOURCE_MEM, },
+ { .flags = IORESOURCE_IRQ, },
+ { .flags = IORESOURCE_IRQ, },
+ };
- gpmc_nand_device.dev.platform_data = gpmc_nand_data;
+ BUG_ON(gpmc_nand_data-cs = GPMC_CS_NUM);
err = gpmc_cs_request(gpmc_nand_data-cs, NAND_IO_SIZE,
- (unsigned long *)gpmc_nand_resource[0].start);
+ (unsigned long *)gpmc_nand_res[0].start);
if (err 0) {
- dev_err(dev, Cannot request GPMC CS %d, error %d\n,
- gpmc_nand_data-cs, err);
+ pr_err(omap2-gpmc: Cannot request GPMC CS %d, error %d\n,
+gpmc_nand_data-cs, err);
return err;
}
-
- gpmc_nand_resource[0].end = gpmc_nand_resource[0].start +
- NAND_IO_SIZE - 1;
-
- gpmc_nand_resource[1].start =
- gpmc_get_client_irq(GPMC_IRQ_FIFOEVENTENABLE);
- gpmc_nand_resource[2].start =
- gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
+ gpmc_nand_res[0].end = gpmc_nand_res[0].start + NAND_IO_SIZE - 1;
+ gpmc_nand_res[1].start = gpmc_get_client_irq(GPMC_IRQ_FIFOEVENTENABLE);
+ gpmc_nand_res[2].start = gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
if (gpmc_t) {
err = gpmc_cs_set_timings(gpmc_nand_data-cs, gpmc_t);
if (err 0) {
- dev_err(dev, Unable to set gpmc timings: %d\n, err);
+ pr_err(omap2-gpmc: Unable to set gpmc timings: %d\n,
err);
return err;
}
}
+ memset(s, 0, sizeof(struct gpmc_settings));
if (gpmc_nand_data-of_node)
gpmc_read_settings_dt(gpmc_nand_data-of_node, s);
else
gpmc_set_legacy(gpmc_nand_data, s);
s.device_nand = true;
-
err = gpmc_cs_program_settings(gpmc_nand_data-cs, s);
if (err 0)
goto out_free_cs;
@@ -141,18 +120,34 @@ int gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data,
gpmc_update_nand_reg(gpmc_nand_data-reg, gpmc_nand_data-cs);
if (!gpmc_hwecc_bch_capable(gpmc_nand_data-ecc_opt)) {
- dev_err(dev, Unsupported NAND ECC scheme selected\n);
- return -EINVAL;
+ pr_err(omap2-nand: Unsupported NAND ECC scheme selected\n);
+ err = -EINVAL;
+ goto out_free_cs;
}
- err = platform_device_register(gpmc_nand_device);
- if (err 0) {
- dev_err(dev, Unable to register NAND device\n);
- goto out_free_cs;
+
+ pdev = platform_device_alloc(omap2-nand, gpmc_nand_data-cs);
+ if (pdev) {
+ err = platform_device_add_resources(pdev, gpmc_nand_res,
+
Re: [PATCH v4 00/11] ARM: OMAP2+: AM33XX: Add suspend-resume support
Hi Dave, On Thu, Jul 10, 2014 at 09:55:38PM -0500, Dave Gerlach wrote: Hello, This series adds suspend/resume support for am335x. Version 3 of this series can be found at [1]. I apologize for the large delay between this and the previous revision. This code has been heavily refined since the last version based on the various comments received for v3. The major change from previous version is moving all wkup_m3 code into a remoteproc based driver. The new driver handles all IPC and fw loading and exposes a small API to be used by PM code to achieve low power states. Firmware that can be used for testing this can be found at [2] on branch pm-remote-proc-v3, using am335x-pm-firmware.elf found in bin directory. Please note this has changed from all previous versions and is no longer the .bin file. Firmware can be built into kernel or placed in /lib/firmware in rootfs for automatic loading during boot. This series has several dependencies. The wkup_m3_rproc utilizes a mailbox to communicate with the cm3 and depends on Suman's series for omap mbox support [3], which has several dependencies of it's own, listed in the cover letter. Also, a few changes to remoteproc itself were needed and have been provided by Suman here [4]. The edma patch included in this series was previously submitted by Daniel Mack and after discussion with him we agreed to include an updated version with this series as resume has a direct dependency on it due to hangs in mmc without it. Because of the high number of dependencies I have pushed a branch for testing here [6] if anyone desires to try it out on branch pm-ds0-v3.16. As is this series will only suspend and resume one time and then fail to resume afterwards due to the removal of direct PM code control of hwmods that do not properly assert their MSTANDBY signal after a context loss, discussed here [7]. In particular it is due to the usb_otg_hs hwmod that currently has no driver controlling it in the kernel. The main cause of the issue is that the SYSCONFIG register present within the IP must be reprogrammed after every suspend cycle and this only happens at boot if no driver is present. Work is in progress to allow suspend to function with or without drivers for the troublesome hwmods (cpgmac, usb_otg_hs, and tptc1-3) and will be provided in a separate future patch. The previous suggestion of allowing omap_device to handle it proved to be too invasive into both omap_device and omap_hwmod and the approach of allowing the firmware to handle it is not possible due to the inability of the CM3 to access the IPs causing the issue. I'd be happy to discuss this at length if anybody is interested. I gave this a quick spin on boneblack, and it works for me, thanks! Tested with echo mem /sys/power/state and uart0 input to resume. Contradictionary to the limits you mention, multiple suspend/resume cycles do work for me. Maybe because of the enabled drivers in my .config, or maybe something was messed up, but at first glance it looked fine. It fails to compile with CONFIG_THUMB2_KERNEL though: arch/arm/mach-omap2/sleep33xx.S:61: Error: cannot use register index with PC-relative addressing -- `str r1,emif_addr_virt' Then I noticed freeze in /sys/power/state, when triggered then crashes with a null pointer dereference in suspend_devices_and_enter(). That might be expected or even stupid though ;) Thanks, Andre -- 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 00/11] ARM: OMAP2+: AM33XX: Add suspend-resume support
On 07/11/2014 02:59 AM, Daniel Mack wrote: On 07/11/2014 04:55 AM, Dave Gerlach wrote: This series adds suspend/resume support for am335x. Version 3 of this series can be found at [1]. I apologize for the large delay between this and the previous revision. This code has been heavily refined since the last version based on the various comments received for v3. The major change from previous version is moving all wkup_m3 code into a remoteproc based driver. The new driver handles all IPC and fw loading and exposes a small API to be used by PM code to achieve low power states. Thanks a lot for this new series, Dave! I've given it a quick test on a custom AM335x board and can confirm success. Tested with both DDR2 and DDR3 versions, both work fine, and power consumption drops to a reasonable level. I appreciate you trying it out! Regards, Dave I'd be very happy if these patches made it in for 3.17, but I haven't followed the discussion on the patches this set depends on. Best regards, Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/11] ARM: OMAP2+: AM33XX: Add suspend-resume support
Andre, On 07/11/2014 10:30 AM, Andre Heider wrote: Hi Dave, On Thu, Jul 10, 2014 at 09:55:38PM -0500, Dave Gerlach wrote: Hello, This series adds suspend/resume support for am335x. Version 3 of this series can be found at [1]. I apologize for the large delay between this and the previous revision. This code has been heavily refined since the last version based on the various comments received for v3. The major change from previous version is moving all wkup_m3 code into a remoteproc based driver. The new driver handles all IPC and fw loading and exposes a small API to be used by PM code to achieve low power states. Firmware that can be used for testing this can be found at [2] on branch pm-remote-proc-v3, using am335x-pm-firmware.elf found in bin directory. Please note this has changed from all previous versions and is no longer the .bin file. Firmware can be built into kernel or placed in /lib/firmware in rootfs for automatic loading during boot. This series has several dependencies. The wkup_m3_rproc utilizes a mailbox to communicate with the cm3 and depends on Suman's series for omap mbox support [3], which has several dependencies of it's own, listed in the cover letter. Also, a few changes to remoteproc itself were needed and have been provided by Suman here [4]. The edma patch included in this series was previously submitted by Daniel Mack and after discussion with him we agreed to include an updated version with this series as resume has a direct dependency on it due to hangs in mmc without it. Because of the high number of dependencies I have pushed a branch for testing here [6] if anyone desires to try it out on branch pm-ds0-v3.16. As is this series will only suspend and resume one time and then fail to resume afterwards due to the removal of direct PM code control of hwmods that do not properly assert their MSTANDBY signal after a context loss, discussed here [7]. In particular it is due to the usb_otg_hs hwmod that currently has no driver controlling it in the kernel. The main cause of the issue is that the SYSCONFIG register present within the IP must be reprogrammed after every suspend cycle and this only happens at boot if no driver is present. Work is in progress to allow suspend to function with or without drivers for the troublesome hwmods (cpgmac, usb_otg_hs, and tptc1-3) and will be provided in a separate future patch. The previous suggestion of allowing omap_device to handle it proved to be too invasive into both omap_device and omap_hwmod and the approach of allowing the firmware to handle it is not possible due to the inability of the CM3 to access the IPs causing the issue. I'd be happy to discuss this at length if anybody is interested. I gave this a quick spin on boneblack, and it works for me, thanks! Tested with echo mem /sys/power/state and uart0 input to resume. Thanks for trying it out! Contradictionary to the limits you mention, multiple suspend/resume cycles do work for me. Maybe because of the enabled drivers in my .config, or maybe something was messed up, but at first glance it looked fine. Yes, if you have USB enabled and the driver is present, the usb hwmod is properly handled and SYSCONFIG properly restored, it is only when there is no driver as is the case with the defconfig that we run in to issues. Looking back I was not clear about that, sorry. It fails to compile with CONFIG_THUMB2_KERNEL though: arch/arm/mach-omap2/sleep33xx.S:61: Error: cannot use register index with PC-relative addressing -- `str r1,emif_addr_virt' Hmm, interestingly enough I can not reproduce this build error. Can you share your config and compiler version? Then I noticed freeze in /sys/power/state, when triggered then crashes with a null pointer dereference in suspend_devices_and_enter(). That might be expected or even stupid though ;) This is present before my patches are applied, this series adds support for PM_SUSPEND_MEM, that's something else I probably should have been a bit more clear about in my cover letter. Regards, Dave Thanks, Andre -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 04/10] ARM: dts: AM4372: Correct mailbox node data
The mailbox DT node for AM4372 is enabled and is corrected to
remove some properties that have crept in by mistake.
Fixes: 9e3269b (ARM: dts: AM4372: Add L2, EDMA, mailbox, MMC and SHAM nodes)
Cc: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 49fa596..c9aee0e 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -168,9 +168,6 @@
ti,hwmods = mailbox;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 8;
- ti,mbox-names = wkup_m3;
- ti,mbox-data = 0 0 0 0;
- status = disabled;
};
timer1: timer@44e31000 {
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 07/10] ARM: OMAP2+: Avoid mailbox legacy device creation for DT-boot
The legacy platform device for mailbox should not be created for
a DT boot, so adjust the platform device initialization logic
appropriately.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/devices.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 592ba0a..708eb7d 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -460,9 +460,9 @@ static int __init omap2_init_devices(void)
omap_init_audio();
omap_init_camera();
omap_init_hdmi_audio();
- omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
+ omap_init_mbox();
omap_init_mcspi();
omap_init_sham();
omap_init_aes();
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 08/10] ARM: OMAP2: hwmod_data: Remove legacy mailbox data and addrs
OMAP2 devices are devicetree boot only, and the legacy mode
of mailbox device creation should no longer be used, so remove
the mailbox attribute data and the hwmod addr space used for
creating mailboxes in legacy mode.
Acked-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 14 --
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 13 -
.../mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c| 9 -
arch/arm/mach-omap2/omap_hwmod_common_data.h | 1 -
4 files changed, 37 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 2f15979..65b1647 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -16,7 +16,6 @@
#include linux/i2c-omap.h
#include linux/platform_data/spi-omap2-mcspi.h
#include linux/omap-dma.h
-#include linux/platform_data/mailbox-omap.h
#include plat/dmtimer.h
#include omap_hwmod.h
@@ -163,18 +162,6 @@ static struct omap_hwmod omap2420_dma_system_hwmod = {
};
/* mailbox */
-static struct omap_mbox_dev_info omap2420_mailbox_info[] = {
- { .name = dsp, .tx_id = 0, .rx_id = 1, .irq_id = 0, .usr_id = 0 },
- { .name = iva, .tx_id = 2, .rx_id = 3, .irq_id = 1, .usr_id = 3 },
-};
-
-static struct omap_mbox_pdata omap2420_mailbox_attrs = {
- .num_users = 4,
- .num_fifos = 6,
- .info_cnt = ARRAY_SIZE(omap2420_mailbox_info),
- .info = omap2420_mailbox_info,
-};
-
static struct omap_hwmod omap2420_mailbox_hwmod = {
.name = mailbox,
.class = omap2xxx_mailbox_hwmod_class,
@@ -188,7 +175,6 @@ static struct omap_hwmod omap2420_mailbox_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_MAILBOXES_SHIFT,
},
},
- .dev_attr = omap2420_mailbox_attrs,
};
/*
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 6d1b609..c2555cb 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -17,7 +17,6 @@
#include linux/platform_data/asoc-ti-mcbsp.h
#include linux/platform_data/spi-omap2-mcspi.h
#include linux/omap-dma.h
-#include linux/platform_data/mailbox-omap.h
#include plat/dmtimer.h
#include omap_hwmod.h
@@ -161,17 +160,6 @@ static struct omap_hwmod omap2430_dma_system_hwmod = {
};
/* mailbox */
-static struct omap_mbox_dev_info omap2430_mailbox_info[] = {
- { .name = dsp, .tx_id = 0, .rx_id = 1 },
-};
-
-static struct omap_mbox_pdata omap2430_mailbox_attrs = {
- .num_users = 4,
- .num_fifos = 6,
- .info_cnt = ARRAY_SIZE(omap2430_mailbox_info),
- .info = omap2430_mailbox_info,
-};
-
static struct omap_hwmod omap2430_mailbox_hwmod = {
.name = mailbox,
.class = omap2xxx_mailbox_hwmod_class,
@@ -185,7 +173,6 @@ static struct omap_hwmod omap2430_mailbox_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_MAILBOXES_SHIFT,
},
},
- .dev_attr = omap2430_mailbox_attrs,
};
/* mcspi3 */
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c
index 0413dab..c1e98d5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_interconnect_data.c
@@ -152,15 +152,6 @@ struct omap_hwmod_addr_space omap2_dma_system_addrs[] = {
{ }
};
-struct omap_hwmod_addr_space omap2_mailbox_addrs[] = {
- {
- .pa_start = 0x48094000,
- .pa_end = 0x48094000 + SZ_512 - 1,
- .flags = ADDR_TYPE_RT,
- },
- { }
-};
-
struct omap_hwmod_addr_space omap2_mcbsp1_addrs[] = {
{
.name = mpu,
diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.h
b/arch/arm/mach-omap2/omap_hwmod_common_data.h
index 2c38c6b..11ed5a1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_common_data.h
+++ b/arch/arm/mach-omap2/omap_hwmod_common_data.h
@@ -33,7 +33,6 @@ extern struct omap_hwmod_addr_space omap2_mcspi1_addr_space[];
extern struct omap_hwmod_addr_space omap2_mcspi2_addr_space[];
extern struct omap_hwmod_addr_space omap2430_mcspi3_addr_space[];
extern struct omap_hwmod_addr_space omap2_dma_system_addrs[];
-extern struct omap_hwmod_addr_space omap2_mailbox_addrs[];
extern struct omap_hwmod_addr_space omap2_mcbsp1_addrs[];
extern struct omap_hwmod_addr_space omap2_hdq1w_addr_space[];
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 03/10] ARM: dts: AM33xx: Add mailbox node
The mailbox DT node data has been added for AM33xx device.
The mailbox IP in AM33xx is similar to the version found in
OMAP4+ devices.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 4a4e02d..3a0a161 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -347,6 +347,15 @@
status = disabled;
};
+ mailbox: mailbox@480C8000 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x480C8000 0x200;
+ interrupts = 77;
+ ti,hwmods = mailbox;
+ ti,mbox-num-users = 4;
+ ti,mbox-num-fifos = 8;
+ };
+
timer1: timer@44e31000 {
compatible = ti,am335x-timer-1ms;
reg = 0x44e31000 0x400;
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 02/10] ARM: dts: OMAP4: Add mailbox node
The mailbox DT node data has been added for OMAP44xx
devices.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 7e26d22..69408b5 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -649,6 +649,15 @@
};
};
+ mailbox: mailbox@4a0f4000 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x4a0f4000 0x200;
+ interrupts = GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = mailbox;
+ ti,mbox-num-users = 3;
+ ti,mbox-num-fifos = 8;
+ };
+
timer1: timer@4a318000 {
compatible = ti,omap3430-timer;
reg = 0x4a318000 0x80;
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 10/10] ARM: AM33xx: hwmod_data: Remove legacy mailbox addrs
The legacy-style definition of the hwmod addr space is no longer
required as AM33xx/AM43xx are DT-boot only, and the minimal mailbox
DT nodes have been added, so clean up this data.
Acked-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
index e2db378..8f5989d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
@@ -317,21 +317,11 @@ struct omap_hwmod_ocp_if am33xx_l4_per__i2c3 = {
.user = OCP_USER_MPU,
};
-static struct omap_hwmod_addr_space am33xx_mailbox_addrs[] = {
- {
- .pa_start = 0x480C8000,
- .pa_end = 0x480C8000 + (SZ_4K - 1),
- .flags = ADDR_TYPE_RT
- },
- { }
-};
-
/* l4 ls - mailbox */
struct omap_hwmod_ocp_if am33xx_l4_per__mailbox = {
.master = am33xx_l4_ls_hwmod,
.slave = am33xx_mailbox_hwmod,
.clk= l4ls_gclk,
- .addr = am33xx_mailbox_addrs,
.user = OCP_USER_MPU,
};
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 00/10] OMAP Mailbox DT node/hwmod cleanup
Hi Tony, This is a refresh of the OMAP Mailbox DT node/hwmod cleanup series [1], addressing the review comments [2] from Pavel Machek about the Mailbox IP design parameters. The changes are limited to only the DTS patches, and mainly bring back the DT properties that were dropped in the previous series. The hwmod patches in the series are identical to v1 (I added the Acked-by responses from Paul Walmsley on 2 patches). I will refresh the OMAP Mailbox framework adoption and DT conversion series [3] as well, which builds on top of this cleanup series. Changes in v2: - Add a new patch that adds the new DT properties: ti,mbox-num-users and ti,mbox-num-fifos to existing DT nodes as of 3.16-rc2 - Updated the other DTS patches from v1 to include the new DT properties - Updated the compatible properties on AM33xx and DRA7 to use the same compatible string as OMAP4. The following shows the boot logs on various OMAP platforms with just these patches on top of 3.16-rc2: OMAP3 (BeagleXM) : http://slexy.org/view/s21MEzZ4bU OMAP4 (PandaBoard): http://slexy.org/view/s2S5sxIjYw OMAP5 (OMAP5 uEVM): http://slexy.org/view/s21siI3Vi2 DRA7 (DRA7 EVM) : http://slexy.org/view/s21RVgqBeT AM33xx (BeagleBone Black) : http://slexy.org/view/s20fcQqcOd AM43xx (AM437x GP EVM): http://slexy.org/view/s2k3GzeZK1 [1] http://marc.info/?l=linux-omapm=140365833121612w=2 [2] https://patchwork.kernel.org/patch/4415881/ [3] http://marc.info/?l=linux-omapm=140366093024233w=2 Suman Anna (10): ARM: dts: OMAP2+: Add mailbox fifo and user information ARM: dts: OMAP4: Add mailbox node ARM: dts: AM33xx: Add mailbox node ARM: dts: AM4372: Correct mailbox node data ARM: dts: DRA7: Add mailbox nodes ARM: DRA7: hwmod_data: Add mailbox hwmod data ARM: OMAP2+: Avoid mailbox legacy device creation for DT-boot ARM: OMAP2: hwmod_data: Remove legacy mailbox data and addrs ARM: OMAP4: hwmod_data: Remove legacy mailbox addrs ARM: AM33xx: hwmod_data: Remove legacy mailbox addrs arch/arm/boot/dts/am33xx.dtsi | 9 + arch/arm/boot/dts/am4372.dtsi | 3 - arch/arm/boot/dts/dra7.dtsi| 117 arch/arm/boot/dts/omap2420.dtsi| 2 + arch/arm/boot/dts/omap2430.dtsi| 2 + arch/arm/boot/dts/omap3.dtsi | 2 + arch/arm/boot/dts/omap4.dtsi | 9 + arch/arm/boot/dts/omap5.dtsi | 2 + arch/arm/mach-omap2/devices.c | 2 +- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 14 - arch/arm/mach-omap2/omap_hwmod_2430_data.c | 13 - .../omap_hwmod_2xxx_3xxx_interconnect_data.c | 9 - .../omap_hwmod_33xx_43xx_interconnect_data.c | 10 - arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 - arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 305 + arch/arm/mach-omap2/omap_hwmod_common_data.h | 1 - 16 files changed, 449 insertions(+), 61 deletions(-) -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 01/10] ARM: dts: OMAP2+: Add mailbox fifo and user information
The number of mailbox fifos and users (IP interrupts) are added
to the Mailbox DT nodes on OMAP2420, OMAP2430, OMAP3, and OMAP5
family of SoCs through the DT properties ti,mbox-num-fifos and
ti,mbox-num-users properties. This data represents the same data
that used to be represented in hwmod attribute data through the
.num_fifos and .num_users fields previously.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap2420.dtsi | 2 ++
arch/arm/boot/dts/omap2430.dtsi | 2 ++
arch/arm/boot/dts/omap3.dtsi| 2 ++
arch/arm/boot/dts/omap5.dtsi| 2 ++
4 files changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index e83b046..6d21994 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -157,6 +157,8 @@
interrupts = 26, 34;
interrupt-names = dsp, iva;
ti,hwmods = mailbox;
+ ti,mbox-num-users = 4;
+ ti,mbox-num-fifos = 6;
};
timer1: timer@48028000 {
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index c4e8013..aa6a354 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -247,6 +247,8 @@
reg = 0x48094000 0x200;
interrupts = 26;
ti,hwmods = mailbox;
+ ti,mbox-num-users = 4;
+ ti,mbox-num-fifos = 6;
};
timer1: timer@49018000 {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index b2891a9..575a49b 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -332,6 +332,8 @@
ti,hwmods = mailbox;
reg = 0x48094000 0x200;
interrupts = 26;
+ ti,mbox-num-users = 2;
+ ti,mbox-num-fifos = 2;
};
mcspi1: spi@48098000 {
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 3bfda16..0e8336e 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -641,6 +641,8 @@
reg = 0x4a0f4000 0x200;
interrupts = GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox;
+ ti,mbox-num-users = 3;
+ ti,mbox-num-fifos = 8;
};
timer1: timer@4ae18000 {
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 06/10] ARM: DRA7: hwmod_data: Add mailbox hwmod data
Add the hwmod data for the 13 instances of the system mailbox
IP in DRA7 SoC. The patch is needed for performing a soft-reset
while configuring the respective mailbox instance, otherwise is
a non-essential change for functionality. The modules are smart
idled on reset, and the IP module mode is hardware controlled.
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 305 ++
1 file changed, 305 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..e35f5b1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -939,6 +939,194 @@ static struct omap_hwmod dra7xx_i2c5_hwmod = {
};
/*
+ * 'mailbox' class
+ *
+ */
+
+static struct omap_hwmod_class_sysconfig dra7xx_mailbox_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class dra7xx_mailbox_hwmod_class = {
+ .name = mailbox,
+ .sysc = dra7xx_mailbox_sysc,
+};
+
+/* mailbox1 */
+static struct omap_hwmod dra7xx_mailbox1_hwmod = {
+ .name = mailbox1,
+ .class = dra7xx_mailbox_hwmod_class,
+ .clkdm_name = l4cfg_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX1_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4CFG_MAILBOX1_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* mailbox2 */
+static struct omap_hwmod dra7xx_mailbox2_hwmod = {
+ .name = mailbox2,
+ .class = dra7xx_mailbox_hwmod_class,
+ .clkdm_name = l4cfg_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX2_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4CFG_MAILBOX2_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* mailbox3 */
+static struct omap_hwmod dra7xx_mailbox3_hwmod = {
+ .name = mailbox3,
+ .class = dra7xx_mailbox_hwmod_class,
+ .clkdm_name = l4cfg_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX3_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4CFG_MAILBOX3_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* mailbox4 */
+static struct omap_hwmod dra7xx_mailbox4_hwmod = {
+ .name = mailbox4,
+ .class = dra7xx_mailbox_hwmod_class,
+ .clkdm_name = l4cfg_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX4_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4CFG_MAILBOX4_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* mailbox5 */
+static struct omap_hwmod dra7xx_mailbox5_hwmod = {
+ .name = mailbox5,
+ .class = dra7xx_mailbox_hwmod_class,
+ .clkdm_name = l4cfg_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX5_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4CFG_MAILBOX5_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* mailbox6 */
+static struct omap_hwmod dra7xx_mailbox6_hwmod = {
+ .name = mailbox6,
+ .class = dra7xx_mailbox_hwmod_class,
+ .clkdm_name = l4cfg_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX6_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4CFG_MAILBOX6_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* mailbox7 */
+static struct omap_hwmod dra7xx_mailbox7_hwmod = {
+ .name = mailbox7,
+ .class = dra7xx_mailbox_hwmod_class,
+ .clkdm_name = l4cfg_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX7_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4CFG_MAILBOX7_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* mailbox8 */
+static struct omap_hwmod dra7xx_mailbox8_hwmod = {
+ .name = mailbox8,
+ .class = dra7xx_mailbox_hwmod_class,
+ .clkdm_name = l4cfg_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_L4CFG_MAILBOX8_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_L4CFG_MAILBOX8_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/* mailbox9 */
+static struct omap_hwmod dra7xx_mailbox9_hwmod = {
+ .name
[PATCHv2 05/10] ARM: dts: DRA7: Add mailbox nodes
DRA7xx has 13 system mailboxes, and is present on both the
DRA72x and DRA74x family of SoCs. Add the DT nodes for all
these 13 mailboxes. Except for mailbox 1, all other mailboxes
do not have interrupts mapped into the MPU GIC by default.
All the mailboxes have been disabled and the interrupts
property information is left out intentionally for now,
because of the dependencies against the crossbar driver.
These mailboxes can be enabled when a usecase arises
and the crossbar driver dependencies are met.
NOTE: The mailbox 1 has different number of mailbox fifos
and IP interrupts compared to the remaining 12 mailboxes.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 117
1 file changed, 117 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index c29945e..99c40d4 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -338,6 +338,123 @@
status = disabled;
};
+ mailbox1: mailbox@4a0f4000 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x4a0f4000 0x200;
+ ti,hwmods = mailbox1;
+ ti,mbox-num-users = 3;
+ ti,mbox-num-fifos = 8;
+ status = disabled;
+ };
+
+ mailbox2: mailbox@4883a000 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x4883a000 0x200;
+ ti,hwmods = mailbox2;
+ ti,mbox-num-users = 4;
+ ti,mbox-num-fifos = 12;
+ status = disabled;
+ };
+
+ mailbox3: mailbox@4883c000 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x4883c000 0x200;
+ ti,hwmods = mailbox3;
+ ti,mbox-num-users = 4;
+ ti,mbox-num-fifos = 12;
+ status = disabled;
+ };
+
+ mailbox4: mailbox@4883e000 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x4883e000 0x200;
+ ti,hwmods = mailbox4;
+ ti,mbox-num-users = 4;
+ ti,mbox-num-fifos = 12;
+ status = disabled;
+ };
+
+ mailbox5: mailbox@4884 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x4884 0x200;
+ ti,hwmods = mailbox5;
+ ti,mbox-num-users = 4;
+ ti,mbox-num-fifos = 12;
+ status = disabled;
+ };
+
+ mailbox6: mailbox@48842000 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x48842000 0x200;
+ ti,hwmods = mailbox6;
+ ti,mbox-num-users = 4;
+ ti,mbox-num-fifos = 12;
+ status = disabled;
+ };
+
+ mailbox7: mailbox@48844000 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x48844000 0x200;
+ ti,hwmods = mailbox7;
+ ti,mbox-num-users = 4;
+ ti,mbox-num-fifos = 12;
+ status = disabled;
+ };
+
+ mailbox8: mailbox@48846000 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x48846000 0x200;
+ ti,hwmods = mailbox8;
+ ti,mbox-num-users = 4;
+ ti,mbox-num-fifos = 12;
+ status = disabled;
+ };
+
+ mailbox9: mailbox@4885e000 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x4885e000 0x200;
+ ti,hwmods = mailbox9;
+ ti,mbox-num-users = 4;
+ ti,mbox-num-fifos = 12;
+ status = disabled;
+ };
+
+ mailbox10: mailbox@4886 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x4886 0x200;
+ ti,hwmods = mailbox10;
+ ti,mbox-num-users = 4;
+ ti,mbox-num-fifos = 12;
+ status = disabled;
+ };
+
+ mailbox11: mailbox@48862000 {
+ compatible = ti,omap4-mailbox;
+ reg = 0x48862000 0x200;
+ ti,hwmods = mailbox11;
+ ti,mbox-num-users = 4;
+ ti,mbox-num-fifos = 12;
+ status = disabled;
+ };
+
+ mailbox12: mailbox@48864000 {
+
[PATCHv2 09/10] ARM: OMAP4: hwmod_data: Remove legacy mailbox addrs
The legacy-style definition of the hwmod addr space is no longer
required after the addition of the OMAP4 mailbox DT node, so
clean up this data.
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson bcous...@baylibre.com
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 41e54f7..5e61b8c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4142,21 +4142,11 @@ static struct omap_hwmod_ocp_if omap44xx_l4_wkup__kbd =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
-static struct omap_hwmod_addr_space omap44xx_mailbox_addrs[] = {
- {
- .pa_start = 0x4a0f4000,
- .pa_end = 0x4a0f41ff,
- .flags = ADDR_TYPE_RT
- },
- { }
-};
-
/* l4_cfg - mailbox */
static struct omap_hwmod_ocp_if omap44xx_l4_cfg__mailbox = {
.master = omap44xx_l4_cfg_hwmod,
.slave = omap44xx_mailbox_hwmod,
.clk= l4_div_ck,
- .addr = omap44xx_mailbox_addrs,
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 0/5] OMAP Mailbox framework adoption DT support
Hi, This is a refresh of the OMAP Mailbox framework adoption DT support series [1], to work with the revised OMAP mailbox DT/hwmod cleanup series [2]. The series has one less patch than the previous series, with the patch mailbox/omap: add a custom of_xlate function squashed into the OMAP mailbox framework adaptation patch. The first 3 patches deal with the OMAP DT bindings and parse support like previous series, and the last 2 patches deal with the mailbox framework adaptation. The testing is also done with the updated v8 version of mailbox framework [3] from Jassi Brar, no changes are required for the v7 to v8 update. The AM335 PM suspend series [4] which relies on this series also does not require any changes. Changes in v2: - Updated the OMAP DT bindings document for the added back DT properties: ti,mbox-num-users and ti,mbox-num-fifos. Also added information regarding #mbox-cells and DT client usage. - Updated the OMAP DT adaptation patch to parse the added back DT properties and clean up the previous match data structure. - Squashed custom xlate patch into the framework adaptation patch. - Tested against v8 of mailbox framework. v1: - Tested against v7 of mailbox framework - See [1] for additional details The series depends on the OMAP mailbox cleanup series [5] and the refreshed OMAP mailbox DT/hwmod cleanup series [2]. The following shows the boot/validation logs on various OMAP platforms: OMAP3 (BeagleXM) : http://slexy.org/view/s23mLEA46B OMAP4 (PandaBoard): http://slexy.org/view/s215xfwEo3 OMAP5 (OMAP5 uEVM): http://slexy.org/view/s2peigexO0 DRA7 (DRA7 EVM) : http://slexy.org/view/s21huoN7Q4 AM33xx (BeagleBone Black) : http://slexy.org/view/s21KQ0gMN8 AM43xx (AM437x GP EVM): http://slexy.org/view/s2KGKGeFre [1] http://www.spinics.net/lists/linux-omap/msg108595.html [2] http://marc.info/?l=linux-omapm=140511512208519w=2 [3] https://lkml.org/lkml/2014/7/11/174 [4] http://www.spinics.net/lists/linux-omap/msg109331.html [5] http://www.spinics.net/lists/linux-omap/msg108574.html Suman Anna (5): Documentation: dt: add omap mailbox bindings mailbox/omap: add support for parsing dt devices ARM: dts: OMAP2+: Add sub mailboxes device node information mailbox/omap: adapt to the new mailbox framework ARM: dts: OMAP2+: Add #mbox-cells property to all mailbox nodes .../devicetree/bindings/mailbox/omap-mailbox.txt | 135 ++ arch/arm/boot/dts/am33xx.dtsi | 5 + arch/arm/boot/dts/am4372.dtsi | 5 + arch/arm/boot/dts/dra7.dtsi| 13 + arch/arm/boot/dts/omap2420.dtsi| 9 + arch/arm/boot/dts/omap2430.dtsi| 5 + arch/arm/boot/dts/omap3.dtsi | 5 + arch/arm/boot/dts/omap4.dtsi | 9 + arch/arm/boot/dts/omap5.dtsi | 9 + drivers/mailbox/omap-mailbox.c | 499 ++--- drivers/remoteproc/omap_remoteproc.c | 54 ++- drivers/staging/tidspbridge/core/_tiomap.h | 3 +- drivers/staging/tidspbridge/core/io_sm.c | 7 +- drivers/staging/tidspbridge/core/tiomap3430.c | 22 +- drivers/staging/tidspbridge/core/tiomap_io.c | 7 +- .../tidspbridge/include/dspbridge/host_os.h| 1 + .../staging/tidspbridge/include/dspbridge/io_sm.h | 8 +- include/linux/omap-mailbox.h | 15 +- 18 files changed, 584 insertions(+), 227 deletions(-) create mode 100644 Documentation/devicetree/bindings/mailbox/omap-mailbox.txt -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 3/5] ARM: dts: OMAP2+: Add sub mailboxes device node information
The sub-mailbox devices are added to the Mailbox DT nodes on
OMAP2420, OMAP2430, OMAP3, AM33xx, AM43xx, OMAP4 and OMAP5
family of SoCs. This data represents the same mailboxes that
used to be represented in hwmod attribute data previously.
The node name is chosen based on the .name field of
omap_mbox_dev_info structure used in the hwmod data.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 4
arch/arm/boot/dts/am4372.dtsi | 4
arch/arm/boot/dts/omap2420.dtsi | 8
arch/arm/boot/dts/omap2430.dtsi | 4
arch/arm/boot/dts/omap3.dtsi| 4
arch/arm/boot/dts/omap4.dtsi| 8
arch/arm/boot/dts/omap5.dtsi| 8
7 files changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 3a0a161..e4f165a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -354,6 +354,10 @@
ti,hwmods = mailbox;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 8;
+ mbox_wkupm3: wkup_m3 {
+ ti,mbox-tx = 0 0 0;
+ ti,mbox-rx = 0 0 3;
+ };
};
timer1: timer@44e31000 {
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index c9aee0e..3be2a87 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -168,6 +168,10 @@
ti,hwmods = mailbox;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 8;
+ mbox_wkupm3: wkup_m3 {
+ ti,mbox-tx = 0 0 0;
+ ti,mbox-rx = 0 0 3;
+ };
};
timer1: timer@44e31000 {
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index 6d21994..d14f16c 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -159,6 +159,14 @@
ti,hwmods = mailbox;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 6;
+ mbox_dsp: dsp {
+ ti,mbox-tx = 0 0 0;
+ ti,mbox-rx = 1 0 0;
+ };
+ mbox_iva: iva {
+ ti,mbox-tx = 2 1 3;
+ ti,mbox-rx = 3 1 3;
+ };
};
timer1: timer@48028000 {
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index aa6a354..db02be2 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -249,6 +249,10 @@
ti,hwmods = mailbox;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 6;
+ mbox_dsp: dsp {
+ ti,mbox-tx = 0 0 0;
+ ti,mbox-rx = 1 0 0;
+ };
};
timer1: timer@49018000 {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 575a49b..b2ae8b8 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -334,6 +334,10 @@
interrupts = 26;
ti,mbox-num-users = 2;
ti,mbox-num-fifos = 2;
+ mbox_dsp: dsp {
+ ti,mbox-tx = 0 0 0;
+ ti,mbox-rx = 1 0 0;
+ };
};
mcspi1: spi@48098000 {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 69408b5..bc54d66 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -656,6 +656,14 @@
ti,hwmods = mailbox;
ti,mbox-num-users = 3;
ti,mbox-num-fifos = 8;
+ mbox_ipu: mbox_ipu {
+ ti,mbox-tx = 0 0 0;
+ ti,mbox-rx = 1 0 0;
+ };
+ mbox_dsp: mbox_dsp {
+ ti,mbox-tx = 3 0 0;
+ ti,mbox-rx = 2 0 0;
+ };
};
timer1: timer@4a318000 {
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 0e8336e..f7ec4cd 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -643,6 +643,14 @@
ti,hwmods = mailbox;
[PATCHv2 5/5] ARM: dts: OMAP2+: Add #mbox-cells property to all mailbox nodes
The '#mbox-cells' property is added to all the OMAP mailbox
nodes. This property is mandatory with the new mailbox framework.
Cc: Benoît Cousson bcous...@baylibre.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 1 +
arch/arm/boot/dts/am4372.dtsi | 1 +
arch/arm/boot/dts/dra7.dtsi | 13 +
arch/arm/boot/dts/omap2420.dtsi | 1 +
arch/arm/boot/dts/omap2430.dtsi | 1 +
arch/arm/boot/dts/omap3.dtsi| 1 +
arch/arm/boot/dts/omap4.dtsi| 1 +
arch/arm/boot/dts/omap5.dtsi| 1 +
8 files changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index e4f165a..5663ff5 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -352,6 +352,7 @@
reg = 0x480C8000 0x200;
interrupts = 77;
ti,hwmods = mailbox;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 8;
mbox_wkupm3: wkup_m3 {
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 3be2a87..8619519 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -166,6 +166,7 @@
reg = 0x480C8000 0x200;
interrupts = GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 8;
mbox_wkupm3: wkup_m3 {
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 99c40d4..626137f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -342,6 +342,7 @@
compatible = ti,omap4-mailbox;
reg = 0x4a0f4000 0x200;
ti,hwmods = mailbox1;
+ #mbox-cells = 1;
ti,mbox-num-users = 3;
ti,mbox-num-fifos = 8;
status = disabled;
@@ -351,6 +352,7 @@
compatible = ti,omap4-mailbox;
reg = 0x4883a000 0x200;
ti,hwmods = mailbox2;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -360,6 +362,7 @@
compatible = ti,omap4-mailbox;
reg = 0x4883c000 0x200;
ti,hwmods = mailbox3;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -369,6 +372,7 @@
compatible = ti,omap4-mailbox;
reg = 0x4883e000 0x200;
ti,hwmods = mailbox4;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -378,6 +382,7 @@
compatible = ti,omap4-mailbox;
reg = 0x4884 0x200;
ti,hwmods = mailbox5;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -387,6 +392,7 @@
compatible = ti,omap4-mailbox;
reg = 0x48842000 0x200;
ti,hwmods = mailbox6;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -396,6 +402,7 @@
compatible = ti,omap4-mailbox;
reg = 0x48844000 0x200;
ti,hwmods = mailbox7;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -405,6 +412,7 @@
compatible = ti,omap4-mailbox;
reg = 0x48846000 0x200;
ti,hwmods = mailbox8;
+ #mbox-cells = 1;
ti,mbox-num-users = 4;
ti,mbox-num-fifos = 12;
status = disabled;
@@ -414,6 +422,7 @@
compatible = ti,omap4-mailbox;
reg = 0x4885e000 0x200;
ti,hwmods = mailbox9;
+ #mbox-cells = 1;
[PATCHv2 4/5] mailbox/omap: adapt to the new mailbox framework
The OMAP mailbox driver and its existing clients (remoteproc
for OMAP4+ and TI DSP/Bridge for OMAP3) are adapted to use
the generic mailbox framework.
The main changes for the adaptation are:
- The tasklet used for Tx is replaced with the state machine from
the generic mailbox framework. The workqueue used for processing
the received messages stays intact for minimizing the effects on
the OMAP mailbox clients.
- The existing exported client API, omap_mbox_get, omap_mbox_put and
omap_mbox_send_msg are deleted, as the framework provides equivalent
functionality. A OMAP-specific omap_mbox_request_channel is added
though to support non-DT way of requesting mailboxes for OMAP3.
- The OMAP mailbox driver is integrated with the mailbox framework
through the proper implementations of mbox_chan_ops, except for
.last_tx_done and .peek_data. The OMAP mailbox driver does not need
these ops, as it is completely interrupt driven.
- The OMAP mailbox driver uses a custom of_xlate controller ops that
allows phandles for the pargs specifier instead of indexing to avoid
any channel registration order dependencies.
- The new framework does not support multiple clients operating on a
single channel, so the reference counting logic is simplified.
- The remoteproc and tidspbridge drivers (current clients) are adapted
to use the new API. The notifier callbacks used within these clients
are replaced with the regular callbacks from the newer framework.
- The exported OMAP mailbox API are limited to omap_mbox_save_ctx,
omap_mbox_restore_ctx, omap_mbox_enable_irq omap_mbox_disable_irq,
with the signature modified to take in the new mbox_chan handle instead
of the OMAP specific omap_mbox handle. The first 2 will be removed when
the OMAP mailbox driver is adapted to runtime_pm. The other exported
API omap_mbox_request_channel is identical in signature to the framework
API mbox_request_channel, and will be removed once OMAP3 becomes DT-boot
only.
Cc: Jassi Brar jassisinghb...@gmail.com
Cc: Ohad Ben-Cohen o...@wizery.com
Cc: Omar Ramirez Luna omar.rami...@copitl.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/mailbox/omap-mailbox.txt | 24 ++
drivers/mailbox/omap-mailbox.c | 343 -
drivers/remoteproc/omap_remoteproc.c | 54 ++--
drivers/staging/tidspbridge/core/_tiomap.h | 3 +-
drivers/staging/tidspbridge/core/io_sm.c | 7 +-
drivers/staging/tidspbridge/core/tiomap3430.c | 22 +-
drivers/staging/tidspbridge/core/tiomap_io.c | 7 +-
.../tidspbridge/include/dspbridge/host_os.h| 1 +
.../staging/tidspbridge/include/dspbridge/io_sm.h | 8 +-
include/linux/omap-mailbox.h | 15 +-
10 files changed, 281 insertions(+), 203 deletions(-)
diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
index 31fe01d..16379e9 100644
--- a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
+++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
@@ -47,6 +47,9 @@ Required properties:
device. The format is dependent on which interrupt
controller the OMAP device uses
- ti,hwmods: Name of the hwmod associated with the mailbox
+- #mbox-cells: Common mailbox binding property to identify the number
+ of cells required for the mailbox specifier. Should be
+ 1
- ti,mbox-num-users: Number of targets (processor devices) that the mailbox
device can interrupt
- ti,mbox-num-fifos: Number of h/w fifo queues within the mailbox IP block
@@ -75,6 +78,18 @@ data that represent the following:
Cell #3 (usr_id) - mailbox user id for identifying the interrupt line
associated with generating a tx/rx fifo interrupt.
+Mailbox Users:
+==
+A device needing to communicate with a target processor device should specify
+them using the common mailbox binding properties, mbox and mbox-names
+(please see Documentation/devicetree/bindings/mailbox/mailbox.txt for details).
+Each value of mbox should contain a phandle to the mailbox controller device
+node and an args specifier that will be the phandle to the intended sub-mailbox
+child node to be used for communication. The equivalent mbox-names property
+value is used to give a name to the communication channel to be used by the
+client user.
+
+
Example:
@@ -84,6 +99,7 @@ mailbox: mailbox@4a0f4000 {
reg = 0x4a0f4000 0x200;
interrupts = GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mailbox;
+ #mbox-cells = 1;
ti,mbox-num-users = 3;
ti,mbox-num-fifos = 8;
mbox_ipu: mbox_ipu {
@@ -102,6 +118,7 @@
[PATCHv2 1/5] Documentation: dt: add omap mailbox bindings
Add the device tree bindings document for OMAP2+ mailbox. Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Signed-off-by: Suman Anna s-a...@ti.com --- .../devicetree/bindings/mailbox/omap-mailbox.txt | 111 + 1 file changed, 111 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/omap-mailbox.txt diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt new file mode 100644 index 000..31fe01d --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt @@ -0,0 +1,111 @@ +OMAP2+ Mailbox Driver += + +The OMAP mailbox hardware facilitates communication between different processors +using a queued mailbox interrupt mechanism. The IP block is external to the +various processor subsystems and is connected on an interconnect bus. The +communication is achieved through a set of registers for message storage and +interrupt configuration registers. + +Each mailbox IP block has a certain number of h/w fifo queues and output +interrupt lines. An output interrupt line is routed to an interrupt controller +within a processor subsystem, and there can be more than one line going to a +specific processor's interrupt controller. The interrupt line connections are +fixed for an instance and are dictated by the IP integration into the SoC +(excluding the SoCs that have a Interrupt Crossbar IP). Each interrupt line is +programmable through a set of interrupt configuration registers, and have a rx +and tx interrupt source per h/w fifo. Communication between different processors +is achieved through the appropriate programming of the rx and tx interrupt +sources on the appropriate interrupt lines. + +The number of h/w fifo queues and interrupt lines dictate the usable registers. +All the current OMAP SoCs except for the newest DRA7xx SoC has a single IP +instance. DRA7xx has multiple instances with different number of h/w fifo queues +and interrupt lines between different instances. The interrupt lines can also be +routed to different processor sub-systems on DRA7xx as they are routed through +the Crossbar, a kind of interrupt router/multiplexer. + +Mailbox Device Node: + +A Mailbox device node is used to represent a Mailbox IP instance within a SoC. +The sub-mailboxes are represented as child node of this parent node. + +Required properties: + +- compatible: Should be one of the following, + ti,omap2-mailbox for OMAP2420, OMAP2430 SoCs + ti,omap3-mailbox for OMAP3430, OMAP3630 SoCs + ti,am3352-mailbox for AM33xx SoCs + ti,am4372-mailbox for AM43xx SoCs + ti,omap4-mailbox for OMAP44xx, OMAP54xx SoCs and + DRA7xx Mailbox1 instance + ti,dra7-mailbox for DRA7xx (except for Mailbox1 + instance) +- reg: Contains the mailbox register address range (base + address and length) +- interrupts: Contains the interrupt information for the mailbox + device. The format is dependent on which interrupt + controller the OMAP device uses +- ti,hwmods: Name of the hwmod associated with the mailbox +- ti,mbox-num-users: Number of targets (processor devices) that the mailbox + device can interrupt +- ti,mbox-num-fifos: Number of h/w fifo queues within the mailbox IP block + +Child Nodes: + +A child node is used for representing the actual sub-mailbox device that is +used for the communication between the host processor and a remote processor. +Each child node should have a unique node name. + +Required properties: + +- ti,mbox-tx: sub-mailbox descriptor property defining a Tx fifo +- ti,mbox-rx: sub-mailbox descriptor property defining a Rx fifo + +Sub-mailbox Descriptor Data +--- +Each of the above ti,mbox-tx and ti,mbox-rx properties should have 3 cells of +data that represent the following: +Cell #1 (fifo_id) - mailbox fifo id used either for transmitting +(ti,mbox-tx) or for receiving (ti,mbox-rx) +Cell #2 (irq_id) - irq identifier index number to use from the parent's +interrupts data. Should be 0 for most of the cases, a +positive index value is seen only on mailboxes that have +multiple interrupt lines connected to the MPU processor. +Cell #3 (usr_id) - mailbox user id for identifying the interrupt line +
[PATCHv2 2/5] mailbox/omap: add support for parsing dt devices
Logic has been added to the OMAP2+ mailbox code to parse the
mailbox dt nodes and construct the different sub-mailboxes
associated with the instance. The DT representation of the
sub-mailbox devices is different from legacy platform data
representation to allow flexibility of interrupt configuration
between Tx and Rx fifos (to also possibly allow simplex devices
in the future). The DT representation gathers similar information
that was being passed previously through the platform data, except
for the number of fifos, interrupts and interrupt type information,
which are gathered through driver compatible match data.
The non-DT support has to be maintained for now to not break
OMAP3 legacy boot, and the legacy-style code will be cleaned
up once OMAP3 is also converted to DT-boot only.
Cc: Jassi Brar jassisinghb...@gmail.com
Cc: Rob Herring robh...@kernel.org
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/mailbox/omap-mailbox.c | 156 ++---
1 file changed, 132 insertions(+), 24 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index a27e00e..73eb0fb 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -31,6 +31,7 @@
#include linux/err.h
#include linux/notifier.h
#include linux/module.h
+#include linux/of_device.h
#include linux/platform_device.h
#include linux/pm_runtime.h
#include linux/platform_data/mailbox-omap.h
@@ -94,6 +95,18 @@ struct omap_mbox_device {
struct list_head elem;
};
+struct omap_mbox_fifo_info {
+ int tx_id;
+ int tx_usr;
+ int tx_irq;
+
+ int rx_id;
+ int rx_usr;
+ int rx_irq;
+
+ const char *name;
+};
+
struct omap_mbox {
const char *name;
int irq;
@@ -587,24 +600,118 @@ static int omap_mbox_unregister(struct omap_mbox_device
*mdev)
return 0;
}
+static const struct of_device_id omap_mailbox_of_match[] = {
+ {
+ .compatible = ti,omap2-mailbox,
+ .data = (void *)MBOX_INTR_CFG_TYPE1,
+ },
+ {
+ .compatible = ti,omap3-mailbox,
+ .data = (void *)MBOX_INTR_CFG_TYPE1,
+ },
+ {
+ .compatible = ti,omap4-mailbox,
+ .data = (void *)MBOX_INTR_CFG_TYPE2,
+ },
+ {
+ /* end */
+ },
+};
+MODULE_DEVICE_TABLE(of, omap_mailbox_of_match);
+
static int omap_mbox_probe(struct platform_device *pdev)
{
struct resource *mem;
int ret;
struct omap_mbox **list, *mbox, *mboxblk;
struct omap_mbox_pdata *pdata = pdev-dev.platform_data;
- struct omap_mbox_dev_info *info;
+ struct omap_mbox_dev_info *info = NULL;
+ struct omap_mbox_fifo_info *finfo, *finfoblk;
struct omap_mbox_device *mdev;
struct omap_mbox_fifo *fifo;
- u32 intr_type;
+ struct device_node *node = pdev-dev.of_node;
+ struct device_node *child;
+ const struct of_device_id *match;
+ u32 intr_type, info_count;
+ u32 num_users, num_fifos;
+ u32 tmp[3];
u32 l;
int i;
- if (!pdata || !pdata-info_cnt || !pdata-info) {
+ if (!node (!pdata || !pdata-info_cnt || !pdata-info)) {
pr_err(%s: platform not supported\n, __func__);
return -ENODEV;
}
+ if (node) {
+ match = of_match_device(omap_mailbox_of_match, pdev-dev);
+ if (!match)
+ return -ENODEV;
+ intr_type = (u32)match-data;
+
+ if (of_property_read_u32(node, ti,mbox-num-users,
+num_users))
+ return -ENODEV;
+
+ if (of_property_read_u32(node, ti,mbox-num-fifos,
+num_fifos))
+ return -ENODEV;
+
+ info_count = of_get_available_child_count(node);
+ if (!info_count) {
+ dev_err(pdev-dev, no available mbox devices
found\n);
+ return -ENODEV;
+ }
+ } else { /* non-DT device creation */
+ info_count = pdata-info_cnt;
+ info = pdata-info;
+ intr_type = pdata-intr_type;
+ num_users = pdata-num_users;
+ num_fifos = pdata-num_fifos;
+ }
+
+ finfoblk = devm_kzalloc(pdev-dev, info_count * sizeof(*finfoblk),
+ GFP_KERNEL);
+ if (!finfoblk)
+ return -ENOMEM;
+
+ finfo = finfoblk;
+ child = NULL;
+ for (i = 0; i info_count; i++, finfo++) {
+ if (!node) {
+ finfo-tx_id = info-tx_id;
+ finfo-rx_id = info-rx_id;
+ finfo-tx_usr = info-usr_id;
+ finfo-tx_irq = info-irq_id;
+
Re: [PATCHv2 0/5] OMAP Mailbox framework adoption DT support
On 11 July 2014 15:04, Suman Anna s-a...@ti.com wrote: Hi, This is a refresh of the OMAP Mailbox framework adoption DT support series [1], to work with the revised OMAP mailbox DT/hwmod cleanup series [2]. The series has one less patch than the previous series, with the patch mailbox/omap: add a custom of_xlate function squashed into the OMAP mailbox framework adaptation patch. The first 3 patches deal with the OMAP DT bindings and parse support like previous series, and the last 2 patches deal with the mailbox framework adaptation. The testing is also done with the updated v8 version of mailbox framework [3] from Jassi Brar, no changes are required for the v7 to v8 update. The AM335 PM suspend series [4] which relies on this series also does not require any changes. May I ask what branch this series is based upon? I tried a number of branches (3.16-rcX, 3.15, linux-next), and the series won't apply to any of them (other than patch 1/5, which does apply fine, but that also contains no code). Thanks, -Markus -- 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
