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 [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 >--- > 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 >--- 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 >--- > 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); >-
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 [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 [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
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 [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 f
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 >> --- >> 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_
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
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 >> --- >> >> 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_d
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 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 =
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 Signed-off-by: Suman Anna --- 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 --- 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 Signed-off-by: Suman Anna --- 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 #include #include -#include #include #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 #include #include -#include #include #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 --- 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 --- 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 = ; + 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 Signed-off-by: Suman Anna --- 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-omap&m=140365833121612&w=2 [2] https://patchwork.kernel.org/patch/4415881/ [3] http://marc.info/?l=linux-omap&m=140366093024233&w=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 --- 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 = ; 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 Cc: Paul Walmsley Signed-off-by: Suman Anna --- 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 --- 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>; +
[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 Cc: Benoît Cousson Signed-off-by: Suman Anna --- 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-omap&m=140511512208519&w=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" Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Signed-off-by: Suman Anna --- 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"; ti,mbox-num-users = <3>; ti,
[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" Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Signed-off-by: Suman Anna --- 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 = ; 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>; ti,mbox-num-us
[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 Cc: Ohad Ben-Cohen Cc: Omar Ramirez Luna Cc: Greg Kroah-Hartman Signed-off-by: Suman Anna --- .../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 = ; ti,hwmods = "mailbox"; + #mbox-cells = <1>; ti,mbox-num-users = <3>; ti,mbox-num-fifos = <8>; mbox_ipu: mbox_ipu { @@ -102,6 +118,7 @@ mailbox: mailbox@480C8000 { reg = <0x480C8000 0x200>; interrupts = <77>; ti,hwmods = "mailbox"; +
[PATCHv2 1/5] Documentation: dt: add omap mailbox bindings
Add the device tree bindings document for OMAP2+ mailbox. Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Signed-off-by: Suman Anna --- .../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 +associated with generating a tx/rx fifo interrupt. + +Example: + + +/* OMAP4 */ +mailbox: mailbo
[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 Cc: Rob Herring Signed-off-by: Suman Anna --- 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 #include #include +#include #include #include #include @@ -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; + finfo->rx_usr = info->usr_id; + finfo->rx_irq = info->irq_id; + finfo->name = in
Re: [PATCHv2 0/5] OMAP Mailbox framework adoption & DT support
On 11 July 2014 15:04, Suman Anna 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