Re: [PATCH V2] hwmon: (tmp102) Force wait for conversion time for the first valid data

[Guenter Roeck]

On Tue, Dec 01, 2015 at 10:10:21AM -0600, Nishanth Menon wrote:
> TMP102 works based on conversions done periodically. However, as per
> the TMP102 data sheet[1] the first conversion is triggered immediately
> after we program the configuration register. The temperature data
> registers do not reflect proper data until the first conversion is
> complete (in our case HZ/4).
> 
> The driver currently sets the last_update to be jiffies - HZ, just
> after the configuration is complete. When TMP102 driver registers
> with the thermal framework, it immediately tries to read the sensor
> temperature data. This takes place even before the conversion on the
> TMP102 is complete and results in an invalid temperature read.
> 
> Depending on the value read, this may cause thermal framework to
> assume that a critical temperature event has occurred and attempts to
> shutdown the system.
> 
> Instead of causing an invalid mid-conversion value to be read
> erroneously, we mark the last_update to be in-line with the current
> jiffies. This allows the tmp102_update_device function to skip update
> until the required conversion time is complete. Further, we ensure to
> return -EAGAIN result instead of returning spurious temperature (such
> as 0C) values to the caller to prevent any wrong decisions made with
> such values. NOTE: this allows the read functions not to be blocking
> and allows the callers to make the decision if they would like to
> block or try again later. At least the current user(thermal) seems to
> handle this by retrying later.
> 
> A simpler alternative approach could be to sleep in the probe for the
> duration required, but that will result in latency that is undesirable
> and delay boot sequence un-necessarily.
> 
> [1] http://www.ti.com/lit/ds/symlink/tmp102.pdf
> 
> Cc: Eduardo Valentin 
> Reported-by: Aparna Balasubramanian 
> Reported-by: Elvita Lobo 
> Reported-by: Yan Liu 
> Signed-off-by: Nishanth Menon 

Applied.

Thanks,
Guenter
--
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 v02 04/15] dmaengine: edma: Add support for DMA filter mapping to slave devices

[Arnd Bergmann]

On Tuesday 01 December 2015 22:52:12 Vinod Koul wrote:
> On Mon, Nov 30, 2015 at 03:45:34PM +0200, Peter Ujfalusi wrote:
> > Add support for providing device to filter_fn mapping so client drivers
> > can switch to use the dma_request_chan() API.
> 
> Any reason why we dont want to go with DT based only for edma here?

I think the OMAP2 based platforms using edma are all DT-only, but mach-davinci
would need a lot of work for that.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 12/25] mtd: nand: use the mtd instance embedded in struct nand_chip

[Brian Norris]

On Tue, Dec 01, 2015 at 12:03:09PM +0100, Boris Brezillon wrote:
> struct nand_chip now embeds an mtd device. Patch all drivers to make use
> of this mtd instance instead of using the instance embedded in their
> private struct or dynamically allocated.
> 
> Signed-off-by: Boris Brezillon 
> Cc: Julia Lawall 
> ---
> Most of those changes were generated with the coccinelle script added
> in commit c671312 "coccinelle: nand: detect and correct drivers embedding
> an mtd_info object"
> ---
>  drivers/mtd/nand/ams-delta.c   | 13 ++--
>  drivers/mtd/nand/atmel_nand.c  | 13 ++--
>  drivers/mtd/nand/au1550nd.c| 19 ++---
>  drivers/mtd/nand/bcm47xxnflash/bcm47xxnflash.h |  1 -
>  drivers/mtd/nand/bcm47xxnflash/main.c  |  8 ++-
>  drivers/mtd/nand/bcm47xxnflash/ops_bcm4706.c   |  2 +-
>  drivers/mtd/nand/bf5xx_nand.c  | 12 ++--
>  drivers/mtd/nand/brcmnand/brcmnand.c   | 13 ++--
>  drivers/mtd/nand/cafe_nand.c   |  8 +--
>  drivers/mtd/nand/cmx270_nand.c | 11 ++-
>  drivers/mtd/nand/cs553x_nand.c | 13 ++--
>  drivers/mtd/nand/davinci_nand.c| 30 
>  drivers/mtd/nand/denali.c  | 68 ++
>  drivers/mtd/nand/denali.h  |  1 -
>  drivers/mtd/nand/diskonchip.c  | 11 ++-
>  drivers/mtd/nand/docg4.c   | 16 ++---

^^ some errors here too

>  drivers/mtd/nand/fsl_elbc_nand.c   | 26 ---
>  drivers/mtd/nand/fsl_ifc_nand.c| 28 
>  drivers/mtd/nand/fsl_upm.c | 28 
>  drivers/mtd/nand/fsmc_nand.c   | 56 ---
>  drivers/mtd/nand/gpio.c| 20 +++---
>  drivers/mtd/nand/gpmi-nand/gpmi-lib.c  |  2 +-
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 20 +++---
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.h |  1 -
>  drivers/mtd/nand/hisi504_nand.c| 13 ++--
>  drivers/mtd/nand/jz4740_nand.c |  9 ++-
>  drivers/mtd/nand/lpc32xx_mlc.c |  7 +-
>  drivers/mtd/nand/lpc32xx_slc.c |  7 +-
>  drivers/mtd/nand/mpc5121_nfc.c |  3 +-
>  drivers/mtd/nand/mxc_nand.c|  5 +-
>  drivers/mtd/nand/nandsim.c | 12 ++--
>  drivers/mtd/nand/ndfc.c| 24 ---
>  drivers/mtd/nand/nuc900_nand.c | 24 +++
>  drivers/mtd/nand/omap2.c   | 98 
> +++---
>  drivers/mtd/nand/orion_nand.c  |  4 +-
>  drivers/mtd/nand/pasemi_nand.c | 12 ++--
>  drivers/mtd/nand/plat_nand.c   | 15 ++--
>  drivers/mtd/nand/pxa3xx_nand.c | 33 -
>  drivers/mtd/nand/r852.c| 34 -
>  drivers/mtd/nand/r852.h|  1 -
>  drivers/mtd/nand/s3c2410.c | 23 +++---
>  drivers/mtd/nand/sh_flctl.c|  8 +--
>  drivers/mtd/nand/sharpsl.c | 22 +++---
>  drivers/mtd/nand/socrates_nand.c   |  5 +-
>  drivers/mtd/nand/sunxi_nand.c  | 13 ++--
>  drivers/mtd/nand/tmio_nand.c   | 10 +--
>  drivers/mtd/nand/txx9ndfmc.c   |  3 +-
>  drivers/mtd/nand/vf610_nfc.c   |  8 ++-
>  include/linux/mtd/sh_flctl.h   |  3 +-
>  49 files changed, 426 insertions(+), 390 deletions(-)
> 

...

> diff --git a/drivers/mtd/nand/docg4.c b/drivers/mtd/nand/docg4.c
> index da93d7f..f8d5e27 100644
> --- a/drivers/mtd/nand/docg4.c
> +++ b/drivers/mtd/nand/docg4.c
> @@ -1305,14 +1305,13 @@ static int __init probe_docg4(struct platform_device 
> *pdev)
>   return -EIO;
>   }
>  
> - len = sizeof(struct mtd_info) + sizeof(struct nand_chip) +
> - sizeof(struct docg4_priv);
> - mtd = kzalloc(len, GFP_KERNEL);
> - if (mtd == NULL) {
> + len = sizeof(struct nand_chip) + sizeof(struct docg4_priv);
> + nand = kzalloc(len, GFP_KERNEL);
> + if (nand == NULL) {
>   retval = -ENOMEM;
>   goto fail;
>   }
> - nand = (struct nand_chip *) (mtd + 1);
> + mtd = nand_to_mtd(nand);
>   doc = (struct docg4_priv *) (nand + 1);
>   mtd->priv = nand;
>   nand->priv = doc;
> @@ -1355,13 +1354,12 @@ static int __init probe_docg4(struct platform_device 
> *pdev)
>  
>   fail:
>   iounmap(virtadr);
> - if (mtd) {
> + if (nand) {
>   /* re-declarations avoid compiler warning */
> - struct nand_chip *nand = mtd_to_nand(mtd);
>   struct docg4_priv *doc = nand->priv;
>   nand_release(mtd); /* deletes partitions and mtd devices */

drivers/mtd/nand/docg4.c: In function ‘probe_docg4’:

Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

[Arnd Bergmann]

On Tuesday 01 December 2015 22:29:54 Vinod Koul wrote:
> On Mon, Nov 30, 2015 at 03:45:30PM +0200, Peter Ujfalusi wrote:
> > channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode
> > it will use a filter lookup table and retrieves the needed information from
> > the dma_filter_map provided by the DMA drivers.
> 
> That sounds right, for the third case would the arch, driver or someone else
> configure this?

The typical case is for the configuration to be defined in arch or platform
code and passed down to the dmaengine driver.

I just noticed that the text above (and probably the code too) should
be changed so we always fall back to this. There are cases where the
platform is booted with DT in principle, but the DMA engine does not
(yet) use DT and still wants to be converted. I think we can easily
handle that case by always trying this if the other methods fail.

> > This legacy mode needs changes in platform code, in dmaengine drivers and
> > finally the dmaengine user drivers can be converted:
> 
> Are you marking the current APIs as dericated in the end of this series

I think we practically stopped marking things as deprecated in general.
Per Linus decree, whenever we want to get rid of something, we should
instead change all users in tree and then remove the API, expecting
driver maintainers to do something just because you marked it as deprecated
often doesn't work.

I can help out converting a few platforms, maybe one interface at a time.
This is what I see:

arnd@wuerfel:~/arm-soc$ for i in dma_request_slave_channel_reason 
dma_request_slave_channel dma_request_slave_channel_compat dma_request_channel  
; do echo `git grep -wl $i drivers/  | grep -v drivers/dma | wc -l`\  $i ; 
done
14  dma_request_slave_channel_reason
27  dma_request_slave_channel
25  dma_request_slave_channel_compat
34  dma_request_channel

I would probably leave the users of dma_request_channel() while converting
the others, as that is still used by all the platforms that don't use any DT
support.

Changing dma_request_slave_channel_reason and dma_request_slave_channel is
trivial, we can probably use coccinelle for that, as it does not require
any platform changes. That brings us to the users of
dma_request_slave_channel_compat, which currently includes these files:

$ git grep -wl dma_request_slave_channel_compat drivers/ata/pata_pxa.c
drivers/crypto/atmel-aes.c
drivers/crypto/atmel-sha.c
drivers/crypto/atmel-tdes.c
drivers/crypto/omap-aes.c
drivers/crypto/omap-des.c
drivers/crypto/omap-sham.c
drivers/media/platform/omap3isp/isphist.c
drivers/mmc/host/davinci_mmc.c
drivers/mmc/host/omap.c
drivers/mmc/host/omap_hsmmc.c
drivers/mmc/host/pxamci.c
drivers/mmc/host/s3cmci.c
drivers/mmc/host/tmio_mmc_dma.c
drivers/mtd/nand/pxa3xx_nand.c
drivers/net/ethernet/smsc/smc91x.c
drivers/net/irda/pxaficp_ir.c
drivers/spi/spi-omap2-mcspi.c
drivers/spi/spi-pxa2xx-dma.c
drivers/spi/spi-rspi.c
drivers/spi/spi-s3c64xx.c
drivers/spi/spi-sh-msiof.c
drivers/tty/serial/8250/8250_dma.c
drivers/tty/serial/samsung.c
drivers/tty/serial/sh-sci.c
include/linux/dmaengine.h

In other words: arch/avr32 and arch/sh along with omap1, omap2, davinci, pxa, 
and s3c
in terms of ARM platforms.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 12/25] mtd: nand: use the mtd instance embedded in struct nand_chip

[Brian Norris]

Hi Boris,

On Tue, Dec 01, 2015 at 12:03:09PM +0100, Boris Brezillon wrote:
> struct nand_chip now embeds an mtd device. Patch all drivers to make use
> of this mtd instance instead of using the instance embedded in their
> private struct or dynamically allocated.
> 
> Signed-off-by: Boris Brezillon 
> Cc: Julia Lawall 
> ---
> Most of those changes were generated with the coccinelle script added
> in commit c671312 "coccinelle: nand: detect and correct drivers embedding
> an mtd_info object"
> ---
>  drivers/mtd/nand/ams-delta.c   | 13 ++--
>  drivers/mtd/nand/atmel_nand.c  | 13 ++--
>  drivers/mtd/nand/au1550nd.c| 19 ++---
>  drivers/mtd/nand/bcm47xxnflash/bcm47xxnflash.h |  1 -
>  drivers/mtd/nand/bcm47xxnflash/main.c  |  8 ++-
>  drivers/mtd/nand/bcm47xxnflash/ops_bcm4706.c   |  2 +-
>  drivers/mtd/nand/bf5xx_nand.c  | 12 ++--
>  drivers/mtd/nand/brcmnand/brcmnand.c   | 13 ++--
>  drivers/mtd/nand/cafe_nand.c   |  8 +--
>  drivers/mtd/nand/cmx270_nand.c | 11 ++-
>  drivers/mtd/nand/cs553x_nand.c | 13 ++--
>  drivers/mtd/nand/davinci_nand.c| 30 
>  drivers/mtd/nand/denali.c  | 68 ++
>  drivers/mtd/nand/denali.h  |  1 -
>  drivers/mtd/nand/diskonchip.c  | 11 ++-
>  drivers/mtd/nand/docg4.c   | 16 ++---
>  drivers/mtd/nand/fsl_elbc_nand.c   | 26 ---
>  drivers/mtd/nand/fsl_ifc_nand.c| 28 
>  drivers/mtd/nand/fsl_upm.c | 28 
>  drivers/mtd/nand/fsmc_nand.c   | 56 ---
>  drivers/mtd/nand/gpio.c| 20 +++---
>  drivers/mtd/nand/gpmi-nand/gpmi-lib.c  |  2 +-
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 20 +++---
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.h |  1 -
>  drivers/mtd/nand/hisi504_nand.c| 13 ++--
>  drivers/mtd/nand/jz4740_nand.c |  9 ++-
>  drivers/mtd/nand/lpc32xx_mlc.c |  7 +-
>  drivers/mtd/nand/lpc32xx_slc.c |  7 +-
>  drivers/mtd/nand/mpc5121_nfc.c |  3 +-
>  drivers/mtd/nand/mxc_nand.c|  5 +-
>  drivers/mtd/nand/nandsim.c | 12 ++--
>  drivers/mtd/nand/ndfc.c| 24 ---
>  drivers/mtd/nand/nuc900_nand.c | 24 +++
>  drivers/mtd/nand/omap2.c   | 98 
> +++---
>  drivers/mtd/nand/orion_nand.c  |  4 +-
>  drivers/mtd/nand/pasemi_nand.c | 12 ++--
>  drivers/mtd/nand/plat_nand.c   | 15 ++--
>  drivers/mtd/nand/pxa3xx_nand.c | 33 -
>  drivers/mtd/nand/r852.c| 34 -
>  drivers/mtd/nand/r852.h|  1 -
>  drivers/mtd/nand/s3c2410.c | 23 +++---

^^ some errors in this one

>  drivers/mtd/nand/sh_flctl.c|  8 +--
>  drivers/mtd/nand/sharpsl.c | 22 +++---
>  drivers/mtd/nand/socrates_nand.c   |  5 +-
>  drivers/mtd/nand/sunxi_nand.c  | 13 ++--
>  drivers/mtd/nand/tmio_nand.c   | 10 +--
>  drivers/mtd/nand/txx9ndfmc.c   |  3 +-
>  drivers/mtd/nand/vf610_nfc.c   |  8 ++-
>  include/linux/mtd/sh_flctl.h   |  3 +-
>  49 files changed, 426 insertions(+), 390 deletions(-)
> 

[...]

> diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
> index e658b29..3f29734 100644
> --- a/drivers/mtd/nand/s3c2410.c
> +++ b/drivers/mtd/nand/s3c2410.c
> @@ -104,7 +104,6 @@ struct s3c2410_nand_info;
>   * @scan_res: The result from calling nand_scan_ident().
>  */
>  struct s3c2410_nand_mtd {
> - struct mtd_info mtd;
>   struct nand_chipchip;
>   struct s3c2410_nand_set *set;
>   struct s3c2410_nand_info*info;
> @@ -168,7 +167,8 @@ struct s3c2410_nand_info {
>  
>  static struct s3c2410_nand_mtd *s3c2410_nand_mtd_toours(struct mtd_info *mtd)
>  {
> - return container_of(mtd, struct s3c2410_nand_mtd, mtd);
> + return container_of(mtd_to_nand(mtd), struct s3c2410_nand_mtd,
> + chip);
>  }
>  
>  static struct s3c2410_nand_info *s3c2410_nand_mtd_toinfo(struct mtd_info 
> *mtd)
> @@ -745,7 +745,7 @@ static int s3c24xx_nand_remove(struct platform_device 
> *pdev)
>  
>   for (mtdno = 0; mtdno < info->mtd_count; mtdno++, ptr++) {
>   pr_debug("releasing mtd %d (%p)\n", mtdno, ptr);
> - nand_release(>mtd);
> + nand_release(nand_to_mtd(>chip));
>   }
>   }
>  
> @@ -762,9 +762,11 @@ static int s3c2410_nand_add_partition(struct 
> 

Re: [PATCH v2 17/25] mtd: nand: remove useless mtd->priv = chip assignments

[Brian Norris]

On Tue, Dec 01, 2015 at 12:03:14PM +0100, Boris Brezillon wrote:
> mtd_to_nand() now uses the container_of() approach to transform an
> mtd_info pointer into a nand_chip one. Drop useless mtd->priv
> assignments from NAND controller drivers.
> 
> Signed-off-by: Boris Brezillon 
> ---
> Patch generated with the following coccinelle script:
> 
> ---8<
> virtual patch
> 
> @@
> struct mtd_info m;
> struct mtd_info *mp;
> struct nand_chip *c;
> @@
> (
> -(m).priv = c;
> |
> -(mp)->priv = c;
> |
> -(mp)->priv = (void *)c;
> )
> ---8<
> ---

...

> diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
> index 3f29734..ed4184c 100644
> --- a/drivers/mtd/nand/s3c2410.c
> +++ b/drivers/mtd/nand/s3c2410.c
> @@ -834,7 +834,6 @@ static void s3c2410_nand_init_chip(struct 
> s3c2410_nand_info *info,
>   chip->IO_ADDR_R = chip->IO_ADDR_W;
>  
>   nmtd->info = info;
> - mtd->priv  = chip;

After this one, we have:

drivers/mtd/nand/s3c2410.c: In function ‘s3c2410_nand_init_chip’:
drivers/mtd/nand/s3c2410.c:791:19: warning: unused variable ‘mtd’ 
[-Wunused-variable]


>   nmtd->set  = set;
>  
>  #ifdef CONFIG_MTD_NAND_S3C2410_HWECC
 
Brian
--
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] reset: Introduce static inline dummy function when CONFIG_RESET_CONTROLLER

[kbuild test robot]

Hi Nishanth,

[auto build test WARNING on: v4.4-rc3]
[also build test WARNING on: next-20151127]

url:
https://github.com/0day-ci/linux/commits/Nishanth-Menon/reset-Introduce-static-inline-dummy-function-when-CONFIG_RESET_CONTROLLER/20151201-233708
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> include/linux/reset-controller.h:1:2: sparse: unterminated preprocessor 
>> conditional
   include/linux/compiler.h:228:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
   In file included from drivers/reset/core.c:18:0:
   include/linux/reset-controller.h:1:0: error: unterminated #ifndef
#ifndef _LINUX_RESET_CONTROLLER_H_
^
--
>> include/linux/reset-controller.h:1:2: sparse: unterminated preprocessor 
>> conditional
>> include/linux/reset-controller.h:1:2: sparse: unterminated preprocessor 
>> conditional
   include/linux/compiler.h:228:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
   In file included from drivers/clk/qcom/reset.c:17:0:
   include/linux/reset-controller.h:1:0: error: unterminated #ifndef
#ifndef _LINUX_RESET_CONTROLLER_H_
^
   In file included from drivers/clk/qcom/reset.h:17:0,
from drivers/clk/qcom/reset.c:20:
   include/linux/reset-controller.h:1:0: error: unterminated #ifndef
#ifndef _LINUX_RESET_CONTROLLER_H_
^

vim +1 include/linux/reset-controller.h

61fc4131 Philipp Zabel 2012-11-19 @1  #ifndef _LINUX_RESET_CONTROLLER_H_
61fc4131 Philipp Zabel 2012-11-19  2  #define _LINUX_RESET_CONTROLLER_H_
61fc4131 Philipp Zabel 2012-11-19  3  
61fc4131 Philipp Zabel 2012-11-19  4  #include 
61fc4131 Philipp Zabel 2012-11-19  5  
61fc4131 Philipp Zabel 2012-11-19  6  struct reset_controller_dev;
61fc4131 Philipp Zabel 2012-11-19  7  
61fc4131 Philipp Zabel 2012-11-19  8  /**
61fc4131 Philipp Zabel 2012-11-19  9   * struct reset_control_ops

:: The code at line 1 was first introduced by commit
:: 61fc41317666be400802ac793f47de816ef7bd57 reset: Add reset controller API

:: TO: Philipp Zabel <p.za...@pengutronix.de>
:: CC: Philipp Zabel <p.za...@pengutronix.de>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 01/10] ARM: OMAP2+: Fix timer entries for dm814x

[Tony Lindgren]

There's a mux after the oscillator similar to am335x. I did not
notice this on hp t410 as it boots even with no clocks configured.

Cc: Paul Walmsley 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
index 6256052..d5246b3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -599,7 +599,7 @@ static struct omap_timer_capability_dev_attr 
capability_alwon_dev_attr = {
 static struct omap_hwmod dm814x_timer1_hwmod = {
.name   = "timer1",
.clkdm_name = "alwon_l3s_clkdm",
-   .main_clk   = "timer_sys_ck",
+   .main_clk   = "timer1_fck",
.dev_attr   = _alwon_dev_attr,
.class  = _timer_hwmod_class,
.flags  = HWMOD_NO_IDLEST,
@@ -608,7 +608,7 @@ static struct omap_hwmod dm814x_timer1_hwmod = {
 static struct omap_hwmod_ocp_if dm814x_l4_ls__timer1 = {
.master = _l4_ls_hwmod,
.slave  = _timer1_hwmod,
-   .clk= "timer_sys_ck",
+   .clk= "timer1_fck",
.user   = OCP_USER_MPU,
 };
 
@@ -636,7 +636,7 @@ static struct omap_hwmod_ocp_if dm816x_l4_ls__timer1 = {
 static struct omap_hwmod dm814x_timer2_hwmod = {
.name   = "timer2",
.clkdm_name = "alwon_l3s_clkdm",
-   .main_clk   = "timer_sys_ck",
+   .main_clk   = "timer2_fck",
.dev_attr   = _alwon_dev_attr,
.class  = _timer_hwmod_class,
.flags  = HWMOD_NO_IDLEST,
@@ -645,7 +645,7 @@ static struct omap_hwmod dm814x_timer2_hwmod = {
 static struct omap_hwmod_ocp_if dm814x_l4_ls__timer2 = {
.master = _l4_ls_hwmod,
.slave  = _timer2_hwmod,
-   .clk= "timer_sys_ck",
+   .clk= "timer2_fck",
.user   = OCP_USER_MPU,
 };
 
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 08/10] ARM: dts: Fix some mux and divider clocks to get dm814x-evm booting

[Tony Lindgren]

Although we have hp t410 booting, I noticed that dm814x-evm does not boot
after I got one. This is because we don't have the clocks yet configured
properly. Let's start configuring proper clocks starting with the system
timers and clocks that work with existing mux and divider clock drivers.

Note that the oscillator speed register is different from am335x, dm814x
has only one bit that shows the BTMODE[6] at CONTROL_STATUS[21].

Also note that this only gets the system timers working with the defined
clocks. The PLL clocks are still missing and and the devices may or may
not work depending on what the bootloader has enabled.

Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/dm814x-clocks.dtsi | 109 +--
 1 file changed, 79 insertions(+), 30 deletions(-)

diff --git a/arch/arm/boot/dts/dm814x-clocks.dtsi 
b/arch/arm/boot/dts/dm814x-clocks.dtsi
index ef1e8e7..2600158 100644
--- a/arch/arm/boot/dts/dm814x-clocks.dtsi
+++ b/arch/arm/boot/dts/dm814x-clocks.dtsi
@@ -4,25 +4,74 @@
  * published by the Free Software Foundation.
  */
 
+_clocks {
+   timer1_fck: timer1_fck {
+   #clock-cells = <0>;
+   compatible = "ti,mux-clock";
+   clocks = <_ck _clkin0_ck _clkin1_ck
+ _clkin2_ck _ck _ck _ck>;
+   ti,bit-shift = <3>;
+   reg = <0x2e0>;
+   };
+
+   timer2_fck: timer2_fck {
+   #clock-cells = <0>;
+   compatible = "ti,mux-clock";
+   clocks = <_ck _clkin0_ck _clkin1_ck
+ _clkin2_ck _ck _ck _ck>;
+   ti,bit-shift = <6>;
+   reg = <0x2e0>;
+   };
+
+   sysclk18_ck: sysclk18_ck {
+   #clock-cells = <0>;
+   compatible = "ti,mux-clock";
+   clocks = <_ck>, <_ck>;
+   ti,bit-shift = <0>;
+   reg = <0x02f0>;
+   };
+};
+
 _clocks {
+   devosc_ck: devosc_ck {
+   #clock-cells = <0>;
+   compatible = "ti,mux-clock";
+   clocks = <_2000_ck>, <_1920_ck>;
+   ti,bit-shift = <21>;
+   reg = <0x0040>;
+   };
 
-   tclkin_ck: tclkin_ck {
+   /* Optional auxosc, 20 - 30 MHz range, assume 27 MHz by default */
+   auxosc_ck: auxosc_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2700>;
+   };
+
+   /* Optional 32768Hz crystal or clock on RTCOSC pins */
+   rtcosc_ck: rtcosc_ck {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <32768>;
};
 
-   devosc_ck: devosc_ck {
+   /* Optional external clock on TCLKIN pin, set rate in baord dts file */
+   tclkin_ck: tclkin_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <0>;
+   };
+
+   virt_2000_ck: virt_2000_ck {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <2000>;
};
 
-   /* Optional auxosc, 20 - 30 MHz range, assume 27 MHz by default */
-   auxosc_ck: auxosc_ck {
+   virt_1920_ck: virt_1920_ck {
#clock-cells = <0>;
compatible = "fixed-clock";
-   clock-frequency = <2700>;
+   clock-frequency = <1920>;
};
 
mpu_ck: mpu_ck {
@@ -49,12 +98,6 @@
clock-frequency = <4800>;
};
 
-   sysclk18_ck: sysclk18_ck {
-   #clock-cells = <0>;
-   compatible = "fixed-clock";
-   clock-frequency = <32768>;
-   };
-
 cpsw_125mhz_gclk: cpsw_125mhz_gclk {
#clock-cells = <0>;
compatible = "fixed-clock";
@@ -69,7 +112,31 @@
 
 };
 
-_clocks {
+_clocks {
+   osc_src_ck: osc_src_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-factor-clock";
+   clocks = <_ck>;
+   clock-mult = <1>;
+   clock-div = <1>;
+   };
+
+   mpu_clksrc_ck: mpu_clksrc_ck {
+   #clock-cells = <0>;
+   compatible = "ti,mux-clock";
+   clocks = <_ck>, <_ck>;
+   ti,bit-shift = <0>;
+   reg = <0x0040>;
+   };
+
+   /* Fixed divider clock 0.0016384 * devosc */
+   rtcdivider_ck: rtcdivider_ck {
+   #clock-cells = <0>;
+   compatible = "fixed-factor-clock";
+   clocks = <_ck>;
+   clock-mult = <128>;
+   clock-div = <78125>;
+   };
 
aud_clkin0_ck: aud_clkin0_ck {
#clock-cells = <0>;
@@ -88,22 +155,4 @@
compatible = "fixed-clock";
clock-frequency = <2000>;
};
-
-   timer1_mux_ck: timer1_mux_ck {
-   #clock-cells = <0>;
-   

Re: [PATCH 05/10] ARM: OMAP2+: Disable GPIO softreset for dm81xx

[Tony Lindgren]

* Matthijs van Duin  [151201 16:11]:
> On 2 December 2015 at 00:38, Tony Lindgren  wrote:
> > Looks like GPIO softreset status bit on both dm8168 and dm8148
> > is broken and only goes high initially. After writing to sysc
> > softreset bit, the resetdone bit never goes high again.
> 
> The resetdone bit works fine, but it needs all clocks active to come
> up. You're neglecting to enable the debounce clock to the GPIO module:
> 
> > # mw.l 0x4818155c 0x2
> 
> That should write 0x102 instead.

It seems to work only once based on what I've seen :) If you try it
after it's powered it never works. Could be I'm doing something wrong
of course..

> You can disable the debounce clock after resetting the module if you
> don't need it, though I doubt there's any significant power savings
> there. (More likely it exists as a separate bit to allow it to stay
> enabled even if the module isn't, for wakeup on debounced inputs.)

Hmm I tried setting HWMOD_CONTROL_OPT_CLKS_IN_RESET flag like we
have for many SoCs to enable also sysclk18_ck but no luck. I can
recheck that.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/10] ARM: dts: Fix dm814x pinctrl address and mask

[Tony Lindgren]

* Matthijs van Duin  [151201 16:26]:
> On 2 December 2015 at 00:38, Tony Lindgren  wrote:
> > -   pinctrl-single,function-mask = 
> > <0x300ff>;
> > +   pinctrl-single,function-mask = 
> > <0x707ff>;
> 
> Reminder that silicon revision 2.1 and older require input enabled
> (bit 18 set) for all 3.3V I/Os to avoid cumulative hardware damage.
> (Errata advisory 2.1.87)

Ouch. We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3
dts macros that ensure that?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/10] Patches to get dm814x-evm booting to NFSroot

[Tony Lindgren]

Hi all,

Here are some fixes for v4.5 merge window to get dm814x-evm booting.
While hp t410 boots based on the bootloader clocks, dm814x-evm needs
more things configured. Especially the clock dts entries were all
wrong and just happened to be harmless on hp t410.

To boot, you probably want to use v4.4-rc3 because of commit 29f5b34ca1a1
("arm: omap2+: add missing HWMOD_NO_IDLEST in 81xx hwmod data") and also
manually apply commit 0db19b850468 ("net: cpsw: Fix ethernet regression
for dm814x") from Linux next.

I have more changes coming up after this series after I clean them
up a bit. Here's a brief status update for people:

What's working after this series on dm814x-evm and hp t410:

- Timers

- Serial

- Ethernet

- DMA

- I2C (only tested so far with i2cdetect -r 0)

- GPIO (only tested with additional MMC patches for card detect)

I have the following additional patches coming soonish:

- Basic ADPLL clock driver

- MMC support

- USB support

- Minimal j5eco-evm support

Should work with just configuration:

- [PATCH 0/3] pwm: omap: Add PWM support using dual-mode timers

I'm not working on any of the accelerators or graphics FYI. If somebody
has patches coming for those please notify on the linux-omap and
linux-arm-kernel mailings lists so we can avoid duplicate work.

Cheers,

Tony


Tony Lindgren (10):
  ARM: OMAP2+: Fix timer entries for dm814x
  clk: ti: Add few dm814x clock aliases
  ARM: OMAP2+: Add DPPLS clock manager for dm814x
  ARM: OMAP2+: Enable GPIO for dm814x
  ARM: OMAP2+: Disable GPIO softreset for dm81xx
  ARM: OMAP2+: Remove useless check for legacy booting for dm814x
  ARM: dts: Fix dm814x entries for pllss and prcm
  ARM: dts: Fix some mux and divider clocks to get dm814x-evm booting
  ARM: dts: Fix dm8148 control modules ranges
  ARM: dts: Fix dm814x pinctrl address and mask

 arch/arm/boot/dts/dm814x-clocks.dtsi   | 109 +
 arch/arm/boot/dts/dm814x.dtsi  |  25 ---
 arch/arm/mach-omap2/io.c   |   3 +-
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c |  15 ++--
 arch/arm/mach-omap2/prm_common.c   |   6 ++
 drivers/clk/ti/clk-814x.c  |   4 ++
 include/linux/clk/ti.h |   1 +
 7 files changed, 117 insertions(+), 46 deletions(-)

-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 04/10] ARM: OMAP2+: Enable GPIO for dm814x

[Tony Lindgren]

With the basic clocks now working we can enable GPIO.

Cc: Paul Walmsley 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
index d5246b3..1b96cdf 100644
--- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -1230,8 +1230,6 @@ static struct omap_hwmod_ocp_if 
dm81xx_tptc3__alwon_l3_fast = {
 
 /*
  * REVISIT: Test and enable the following once clocks work:
- * dm81xx_l4_ls__gpio1
- * dm81xx_l4_ls__gpio2
  * dm81xx_l4_ls__mailbox
  * dm81xx_alwon_l3_slow__gpmc
  * dm81xx_default_l3_slow__usbss
@@ -1250,6 +1248,8 @@ static struct omap_hwmod_ocp_if *dm814x_hwmod_ocp_ifs[] 
__initdata = {
_l4_ls__wd_timer1,
_l4_ls__i2c1,
_l4_ls__i2c2,
+   _l4_ls__gpio1,
+   _l4_ls__gpio2,
_l4_ls__elm,
_l4_ls__mcspi1,
_alwon_l3_fast__tpcc,
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 09/10] ARM: dts: Fix dm8148 control modules ranges

[Tony Lindgren]

The control module is at offset 0x14000 with size 0x2, not 0x16000.
This causes the pinctrl driver to not work.

Let's also fix the comments related to the TRM "L4LS Instance Summary"
table as that's what's causing the bad entries.

Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/dm814x.dtsi | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/dm814x.dtsi b/arch/arm/boot/dts/dm814x.dtsi
index 5c8de19..68b156b 100644
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -58,8 +58,10 @@
ti,hwmods = "l3_main";
 
/*
-* See TRM "Table 1-317. L4LS Instance Summary", just deduct
-* 0x1000 from the 1-317 addresses to get the device address
+* See TRM "Table 1-317. L4LS Instance Summary" for hints.
+* It shows the module target agent registers though, so the
+* actual device is typically 0x1000 before the target agent
+* except in cases where the module is larger than 0x1000.
 */
l4ls: l4ls@4800 {
compatible = "ti,dm814-l4ls", "simple-bus";
@@ -183,10 +185,10 @@
 
control: control@14 {
compatible = "ti,dm814-scm", "simple-bus";
-   reg = <0x14 0x16d000>;
+   reg = <0x14 0x2>;
#address-cells = <1>;
#size-cells = <1>;
-   ranges = <0 0x16 0x16d000>;
+   ranges = <0 0x14 0x2>;
 
scm_conf: scm_conf@0 {
compatible = "syscon";
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 06/10] ARM: OMAP2+: Remove useless check for legacy booting for dm814x

[Tony Lindgren]

We have never had dm814x booting properly with mainline kernel using
the legacy platform data based booting. Current minimal support is
device tree only.

Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/io.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 3eaeaca..3c87e40 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -612,8 +612,7 @@ void __init ti814x_init_early(void)
ti814x_clockdomains_init();
dm814x_hwmod_init();
omap_hwmod_init_postsetup();
-   if (of_have_populated_dt())
-   omap_clk_soc_init = dm814x_dt_clk_init;
+   omap_clk_soc_init = dm814x_dt_clk_init;
 }
 
 void __init ti816x_init_early(void)
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/10] ARM: dts: Fix dm814x pinctrl address and mask

[Tony Lindgren]

Otherwise pinctrl won't work.

Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/dm814x.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/dm814x.dtsi b/arch/arm/boot/dts/dm814x.dtsi
index 68b156b..7bd1961 100644
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -207,11 +207,11 @@
 
pincntl: pinmux@800 {
compatible = "pinctrl-single";
-   reg = <0x800 0xc38>;
+   reg = <0x800 0x438>;
#address-cells = <1>;
#size-cells = <0>;
pinctrl-single,register-width = <32>;
-   pinctrl-single,function-mask = 
<0x300ff>;
+   pinctrl-single,function-mask = 
<0x707ff>;
};
};
 
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/10] ARM: dts: Fix dm814x entries for pllss and prcm

[Tony Lindgren]

Otherwise drivers under pllss and prcm won't probe properly.

Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/dm814x.dtsi | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/dm814x.dtsi b/arch/arm/boot/dts/dm814x.dtsi
index 7988b42..5c8de19 100644
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -215,7 +215,10 @@
 
prcm: prcm@18 {
compatible = "ti,dm814-prcm", "simple-bus";
-   reg = <0x18 0x4000>;
+   reg = <0x18 0x2000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x18 0x2000>;
 
prcm_clocks: clocks {
#address-cells = <1>;
@@ -226,9 +229,13 @@
};
};
 
+   /* See TRM PLL_SUBSYS_BASE and "PLLSS Registers" */
pllss: pllss@1c5000 {
compatible = "ti,dm814-pllss", "simple-bus";
-   reg = <0x1c5000 0x2000>;
+   reg = <0x1c5000 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x1c5000 0x1000>;
 
pllss_clocks: clocks {
#address-cells = <1>;
-- 
2.6.2

--
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 10/10] ARM: dts: Fix dm814x pinctrl address and mask

[Matthijs van Duin]

On 2 December 2015 at 00:38, Tony Lindgren  wrote:
> -   pinctrl-single,function-mask = 
> <0x300ff>;
> +   pinctrl-single,function-mask = 
> <0x707ff>;

Reminder that silicon revision 2.1 and older require input enabled
(bit 18 set) for all 3.3V I/Os to avoid cumulative hardware damage.
(Errata advisory 2.1.87)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 05/10] ARM: OMAP2+: Disable GPIO softreset for dm81xx

[Tony Lindgren]

Looks like GPIO softreset status bit on both dm8168 and dm8148
is broken and only goes high initially. After writing to sysc
softreset bit, the resetdone bit never goes high again.

I noticed this as GPIOs are enabled from u-boot at least on t410.
And this can be tested easliy with the following commands in u-boot:

# mw.l 0x4818155c 0x2
# md.l 0x48032114 1
48032114: 0001
# mw.l 0x48032010 0x2
# md.l 0x48032114 1
48032114: 

Looks like the GPIO module is functional even with the resetdone
bit down.

Let's just tag the GPIOs for dm81xx with HWMOD_INIT_NO_RESET.

Cc: Paul Walmsley 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
index 1b96cdf..440fd6c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -432,6 +432,7 @@ static struct omap_hwmod_ocp_if dm81xx_l4_ls__elm = {
.user   = OCP_USER_MPU,
 };
 
+/* On dm81xx RESETDONE bit seems to never goes high again after SOFTRESET */
 static struct omap_hwmod_class_sysconfig dm81xx_gpio_sysc = {
.rev_offs   = 0x,
.sysc_offs  = 0x0010,
@@ -463,6 +464,7 @@ static struct omap_hwmod dm81xx_gpio1_hwmod = {
.name   = "gpio1",
.clkdm_name = "alwon_l3s_clkdm",
.class  = _gpio_hwmod_class,
+   .flags  = HWMOD_INIT_NO_RESET,
.main_clk   = "sysclk6_ck",
.prcm = {
.omap4 = {
@@ -490,6 +492,7 @@ static struct omap_hwmod dm81xx_gpio2_hwmod = {
.clkdm_name = "alwon_l3s_clkdm",
.class  = _gpio_hwmod_class,
.main_clk   = "sysclk6_ck",
+   .flags  = HWMOD_INIT_NO_RESET,
.prcm = {
.omap4 = {
.clkctrl_offs = DM81XX_CM_ALWON_GPIO_1_CLKCTRL,
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/10] ARM: OMAP2+: Add DPPLS clock manager for dm814x

[Tony Lindgren]

On dm814x we have some clocks at DPLLS and some at PRCM. Let's add a new
omap_prcm_init_data entry for the DPLLS so we can initalize timer clocks
early.

Cc: Paul Walmsley 
Cc: Tero Kristo 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/prm_common.c | 6 ++
 include/linux/clk/ti.h   | 1 +
 2 files changed, 7 insertions(+)

diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 3fc2cbe..55acc76 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -662,6 +662,11 @@ static struct omap_prcm_init_data am3_prm_data __initdata 
= {
.index = TI_CLKM_PRM,
.init = am33xx_prm_init,
 };
+
+static struct omap_prcm_init_data dm814_pllss_data __initdata = {
+   .index = TI_CLKM_PLLSS,
+   .init = am33xx_prm_init,
+};
 #endif
 
 #ifdef CONFIG_ARCH_OMAP4
@@ -715,6 +720,7 @@ static const struct of_device_id const 
omap_prcm_dt_match_table[] __initconst =
 #endif
 #ifdef CONFIG_SOC_TI81XX
{ .compatible = "ti,dm814-prcm", .data = _prm_data },
+   { .compatible = "ti,dm814-pllss", .data = _pllss_data },
{ .compatible = "ti,dm816-prcm", .data = _prm_data },
 #endif
 #ifdef CONFIG_ARCH_OMAP2
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index 223be69..57663c1 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -195,6 +195,7 @@ enum {
TI_CLKM_PRM,
TI_CLKM_SCRM,
TI_CLKM_CTRL,
+   TI_CLKM_PLLSS,
CLK_MAX_MEMMAPS
 };
 
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 02/10] clk: ti: Add few dm814x clock aliases

[Tony Lindgren]

The timer clock aliases are needed early on dm814x. Let's also
add the aliases for the interconnects and MMC.

Cc: Michael Turquette 
Cc: Stephen Boyd 
Cc: Tero Kristo 
Signed-off-by: Tony Lindgren 
---
 drivers/clk/ti/clk-814x.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/clk/ti/clk-814x.c b/drivers/clk/ti/clk-814x.c
index e172920..9e85fcc 100644
--- a/drivers/clk/ti/clk-814x.c
+++ b/drivers/clk/ti/clk-814x.c
@@ -14,10 +14,14 @@ static struct ti_dt_clk dm814_clks[] = {
DT_CLK(NULL, "devosc_ck", "devosc_ck"),
DT_CLK(NULL, "mpu_ck", "mpu_ck"),
DT_CLK(NULL, "sysclk4_ck", "sysclk4_ck"),
+   DT_CLK(NULL, "sysclk5_ck", "sysclk5_ck"),
DT_CLK(NULL, "sysclk6_ck", "sysclk6_ck"),
+   DT_CLK(NULL, "sysclk8_ck", "sysclk8_ck"),
DT_CLK(NULL, "sysclk10_ck", "sysclk10_ck"),
DT_CLK(NULL, "sysclk18_ck", "sysclk18_ck"),
DT_CLK(NULL, "timer_sys_ck", "devosc_ck"),
+   DT_CLK(NULL, "timer1_fck", "timer1_fck"),
+   DT_CLK(NULL, "timer2_fck", "timer2_fck"),
DT_CLK(NULL, "cpsw_125mhz_gclk", "cpsw_125mhz_gclk"),
DT_CLK(NULL, "cpsw_cpts_rft_clk", "cpsw_cpts_rft_clk"),
{ .node_name = NULL },
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/10] ARM: OMAP2+: Disable GPIO softreset for dm81xx

[Matthijs van Duin]

On 2 December 2015 at 00:38, Tony Lindgren  wrote:
> Looks like GPIO softreset status bit on both dm8168 and dm8148
> is broken and only goes high initially. After writing to sysc
> softreset bit, the resetdone bit never goes high again.

The resetdone bit works fine, but it needs all clocks active to come
up. You're neglecting to enable the debounce clock to the GPIO module:

> # mw.l 0x4818155c 0x2

That should write 0x102 instead.

You can disable the debounce clock after resetting the module if you
don't need it, though I doubt there's any significant power savings
there. (More likely it exists as a separate bit to allow it to stay
enabled even if the module isn't, for wakeup on debounced inputs.)

Matthijs
--
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 10/10] ARM: dts: Fix dm814x pinctrl address and mask

[Matthijs van Duin]

On 2 December 2015 at 01:46, Tony Lindgren  wrote:
> Ouch. We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3
> dts macros that ensure that?

Can't we just keep bit 18 out of the function mask? The bootloader
should already have made sure all pins have bit 18 set (and bit 19 set
to correct values after ROM mucked them up, see advisory 2.1.88), so
all that needs to be done is avoid touching them.

Are the power savings from disabling unnecessary inputs significant
enough to spend any headache on it?

Matthijs
--
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 10/10] ARM: dts: Fix dm814x pinctrl address and mask

[Matthijs van Duin]

On 2 December 2015 at 01:46, Tony Lindgren  wrote:
> We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3
> dts macros that ensure that?

I'm in general no fan of such macros: it feels really awkward to have
to make that distinction in dts when doing pin config.

Note that if you're feeling really enthausiastic about putting in
effort to allow inputs to be disabled while staying clear of the
erratum, I think you can detect at runtime which I/O supplies are 3.3V
by inspecting this register:

#define CTRL_CQDETECT_STATUS0x48140e00

Matthijs
--
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 10/10] ARM: dts: Fix dm814x pinctrl address and mask

[Tony Lindgren]

* Matthijs van Duin  [151201 17:15]:
> On 2 December 2015 at 01:46, Tony Lindgren  wrote:
> > Ouch. We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3
> > dts macros that ensure that?
> 
> Can't we just keep bit 18 out of the function mask? The bootloader
> should already have made sure all pins have bit 18 set (and bit 19 set
> to correct values after ROM mucked them up, see advisory 2.1.88), so
> all that needs to be done is avoid touching them.

Sounds good to me. And people who really want to override the mask can
do it in the board specifc dts file.

> Are the power savings from disabling unnecessary inputs significant
> enough to spend any headache on it?

Only for some battery powered devices, not in this case for sure.

Regards,.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/10] ARM: OMAP2+: Disable GPIO softreset for dm81xx

[Tony Lindgren]

* Tony Lindgren  [151201 16:56]:
> * Tony Lindgren  [151201 16:42]:
> > * Matthijs van Duin  [151201 16:11]:
> > > On 2 December 2015 at 00:38, Tony Lindgren  wrote:
> > > > Looks like GPIO softreset status bit on both dm8168 and dm8148
> > > > is broken and only goes high initially. After writing to sysc
> > > > softreset bit, the resetdone bit never goes high again.
> > > 
> > > The resetdone bit works fine, but it needs all clocks active to come
> > > up. You're neglecting to enable the debounce clock to the GPIO module:
> > > 
> > > > # mw.l 0x4818155c 0x2
> > > 
> > > That should write 0x102 instead.
> > 
> > It seems to work only once based on what I've seen :) If you try it
> > after it's powered it never works. Could be I'm doing something wrong
> > of course..
> > 
> > > You can disable the debounce clock after resetting the module if you
> > > don't need it, though I doubt there's any significant power savings
> > > there. (More likely it exists as a separate bit to allow it to stay
> > > enabled even if the module isn't, for wakeup on debounced inputs.)
> > 
> > Hmm I tried setting HWMOD_CONTROL_OPT_CLKS_IN_RESET flag like we
> > have for many SoCs to enable also sysclk18_ck but no luck. I can
> > recheck that.
> 
> You're right with 0x102 it works, need to debug further.

Looks like also am33xx has opt clocks gate bit 18. Probably the best
way to deal with this in the long run is to set up the clkctrl and
optfclken as gate clocks with the clock framework. This is also needed
as we have some devices sharing a single clkctrl register.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/10] ARM: OMAP2+: Disable GPIO softreset for dm81xx

[Tony Lindgren]

* Tony Lindgren  [151201 16:42]:
> * Matthijs van Duin  [151201 16:11]:
> > On 2 December 2015 at 00:38, Tony Lindgren  wrote:
> > > Looks like GPIO softreset status bit on both dm8168 and dm8148
> > > is broken and only goes high initially. After writing to sysc
> > > softreset bit, the resetdone bit never goes high again.
> > 
> > The resetdone bit works fine, but it needs all clocks active to come
> > up. You're neglecting to enable the debounce clock to the GPIO module:
> > 
> > > # mw.l 0x4818155c 0x2
> > 
> > That should write 0x102 instead.
> 
> It seems to work only once based on what I've seen :) If you try it
> after it's powered it never works. Could be I'm doing something wrong
> of course..
> 
> > You can disable the debounce clock after resetting the module if you
> > don't need it, though I doubt there's any significant power savings
> > there. (More likely it exists as a separate bit to allow it to stay
> > enabled even if the module isn't, for wakeup on debounced inputs.)
> 
> Hmm I tried setting HWMOD_CONTROL_OPT_CLKS_IN_RESET flag like we
> have for many SoCs to enable also sysclk18_ck but no luck. I can
> recheck that.

You're right with 0x102 it works, need to debug further.

Thanks,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 01/18] ARM: am57xx: cl-som-am57x: dts: add basic module support

[Nishanth Menon]

On 12/01/2015 10:43 AM, Tony Lindgren wrote:
> * Dmitry Lifshitz  [151201 08:26]:
>>
>> It might looks the same set of regulators for multiple boards,
>> but it is not. Each board may apply its own regulators usage scheme, and
>> this is our case (as compared to am57xx-beagle-x15.dts).
>>
>> For the best of my knowledge, it used to be in a common *.dtsi file (at
>> least in early OMAP5 DT support in TI kernel tree), but then I found that
>> PMIC registration had been moved to the boards DT files.
> 
> Have you actually looked at how much of the implementation is same across
> the omap5 boards? My guess is that a whole lot is same.. See for example
> omap5-board-common.dtsi.

Unfortunately with DRA7 / AM57xx:
at least 2 different PMICs -> DRA74/DRA72 evms.
even across similar PMIC usage, different voltage rail usage accross
evms: DRA74evm, x15/GPEVM, AM571x-IDK/AM572x-IDK -> they are not
necessarily compatible.

Example: some of them have Ganged voltage rail, others dont - few others
are mixed. if you are trying to get common regulator usage -> it is
kinda pretty hard given the freedom board designers are being given by
TI.. OMAP5 was more controlled in terms of what specific configuration
the board designers had to follow. that is no longer the case for
DRA7/AM57 platforms. just my 2 cents here.

-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 00/15] dmaengine: New 'universal' API for requesting channel

[Vinod Koul]

On Mon, Nov 30, 2015 at 03:45:30PM +0200, Peter Ujfalusi wrote:
> Hi,
> 
> Changes since RFC v01:
> - dma_request_chan(); lost the mask parameter
> - The new API does not rely on RESOURCE_DMA, instead the dma_filter_map table
>   will be used to provide the needed information to the filter function in
>   legacy mode
> - Extended the example patches to convert most of daVinci to use the new API 
> to
>   request the DMA channels.

Hi Peter,

Thanks a bunch for fixing this up!

I think overall I am happy with the proposal and aligning with 2 APIs really
_helps_.

> 
> TODO: Documentation update ;)
>
> 
> As it has been discussed in the following thread:
> http://www.gossamer-threads.com/lists/linux/kernel/2181487#2181487
> 
> Andy: I did looked at the unified device properties, but I decided to not to 
> use
> it as I don't see it to fit well and most of the legacy board files are using
> resources to specify at least their memory regions so adding the DMA resource
> to them would be more inline with the rest of the code.

I think that is okay for now, we can align on that eventually. I think this
doesn't impact the API design though..

> 
> The ARM, mmc and spi patches are converting daVinci drivers board files to use
> the new method of requesting DMA channel.
> 
> With this series I have taken a path which would result two new API, which can
> be used to convert most of the current users already and with some work all
> users might be able to move to this set.
> With this set the filter_fn used for legacy (non DT/ACPI) channel request is 
> no
> longer needed to be exported to client drivers since the selection of the
> correct filter_fn will be done in the core.
> 
> So, the first proposal is to have:
> 
> struct dma_chan *dma_request_chan(struct device *dev, const char *name);
> struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);
> 
> The dma_request_chan_by_mask() is to request any channel matching with the
> requested capabilities, can be used to request channel for memcpy, memset, 
> xor,
> etc where no hardware synchronization is needed.
> 
> The dma_request_chan() is to request a slave channel. The dma_request_chan() 
> will try to find the
> channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode
> it will use a filter lookup table and retrieves the needed information from
> the dma_filter_map provided by the DMA drivers.

That sounds right, for the third case would the arch, driver or someone else
configure this?

> This legacy mode needs changes in platform code, in dmaengine drivers and
> finally the dmaengine user drivers can be converted:

Are you marking the current APIs as dericated in the end of this series

> 
> For each dmaengine driver an array of DMA device, slave and the parameter
> for the filter function needs to be added:
> 
> static struct dma_filter_map da830_edma_map[] = {
>   DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
>   DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
>   DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
>   DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
>   DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
>   DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
>   DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
>   DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
>   DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
>   DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
>   DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
>   DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
> };
> 
> This information is going to be needed by the dmaengine driver, so
> modification to the platform_data is needed, and the driver map should be
> added to the pdata of the DMA driver:
> 
> da8xx_edma0_pdata.filter_map = da830_edma_map;
> da8xx_edma0_pdata.filtercnt = ARRAY_SIZE(da830_edma_map);
> 
> The DMA driver then needs to convigure the needed device -> filter_fn
> mapping before it registers with dma_async_device_register() :
> 
> if (info->filter_map) {
>   ecc->dma_slave.filter_map.map = info->filter_map;
>   ecc->dma_slave.filter_map.mapcnt = info->filtercnt;
>   ecc->dma_slave.filter_map.filter_fn = edma_filter_for_map;
> }
> 
> When neither DT or ACPI lookup is available the dma_request_chan() will
> try to match the requester's device name with the filter_map's list of
> device names, when a match found it will use the information from the
> dma_filter_map to get the channel with the dma_get_channel() internal
> function.
> 
> Regards,
> Peter
> ---
> Peter Ujfalusi (15):
>   dmaengine: core: Allow NULL mask pointer in
> __dma_device_satisfies_mask()
>   dmaengine: core: Move and merge the code paths using private_candidate
>   dmaengine: core: Introduce new, universal API to request a 

Re: [RFC v02 01/15] dmaengine: core: Allow NULL mask pointer in __dma_device_satisfies_mask()

[Vinod Koul]

On Tue, Dec 01, 2015 at 02:58:35PM +0200, Andy Shevchenko wrote:
> On Tue, Dec 1, 2015 at 11:47 AM, Peter Ujfalusi  wrote:
> > On 11/30/2015 04:35 PM, Andy Shevchenko wrote:
> >> On Mon, Nov 30, 2015 at 3:45 PM, Peter Ujfalusi  
> >> wrote:
> >>> Treat as true condition the case when the mask is NULL.
> >>
> >> What do you think about setting some default (all "on") mask when mask
> >> is not supplied?
> >
> > Probably rephrasing the commit message to say that when the mask is NULL it
> > means that the caller does not care about the capabilities of the dma device
> > thus return with true in such a case.
> >
> > We could also drop this patch and in private_candidate() :
> >
> > -   if (!__dma_device_satisfies_mask(dev, mask)) {
> > +   if (mask && !__dma_device_satisfies_mask(dev, mask)) {
> > pr_debug("%s: wrong capabilities\n", __func__);
> > return NULL;
> > }
> 
> Between patch and above proposal I would choose the latter one.

Sounds better to me as well

> 
> >> I don't know for sure but there might be cases when you don't want
> >> literally *any* channel to satisfy.
> >
> > Or set DMA_SLAVE only in dma_request_chan()? What happens if we have cases
> > when we are able to request channel for memcpy via dma_request_chan()
> > (dedicated memcpy channel/DMA engine?) in that case we will have the SLAVE
> > set, but not MEMCPY, or any other variation we do not know yet?
> 
> Frankly, have no idea.

In slave cases I know that some controllers support memcpy but they are not
generic memcpy as they cannot be used for system memcpy but for 'special'
memcpy. So this can be used for memcpy as well

-- 
~Vinod
--
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] clocksource: ti-32k: convert to platform device

[Grygorii Strashko]

On 12/01/2015 06:07 PM, Tony Lindgren wrote:

* Grygorii Strashko  [151201 07:09]:

On 11/30/2015 06:28 PM, Tony Lindgren wrote:


We should be able to make this into an early_platform_device and just
have it depend on the source clock muxes. See the omap initcall changes
patches I just posted.



Sry, may be I've missed smth, but how early_platform_device will help us
to get rid of platform code - We'd still need to power on manually
early_platform_device's from platform code :( through hwmod.


Having minimal platform code early is not a problem. The problem is that
our early code is not minimal.

For the system timers, we should only initialize the mux clocks needed
early to select between 32k and hf oscillator source. This needs to be done
using the clock framework, but we don't need the other clocks initialized
early.

The system timers we're using should be in the alwon power domain, if they
are not, then we should change the timers around so we're using only timers
in the alwon domain for system timers. Typically at least gpt1 and 12 are
always powered. That allows us to leave out the hwmod dependency for system
timers.

Or am I forgetting some other dependency with our system timers?


both counter32 and GP timer have to be enabled through sysc registers.
They are in "Force idle" state after reset.




The main reason why I've tried this is because clocksource will be really 
selected
only at fs_initcall time - and at that time we have no restriction for using 
platform
devices, Pm runtime APIs, etc. (exception/blocker is sched_clock :().


Right. But it seems we can leave out quite a bit of the dependencies
for system timers. We already have gptimer probe not touching the system
timers later on and can use shared gptimer functions after the clock
muxing is done.



--
regards,
-grygorii
--
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] clocksource: ti-32k: convert to platform device

[Tony Lindgren]

* Grygorii Strashko  [151201 09:13]:
> On 12/01/2015 06:07 PM, Tony Lindgren wrote:
> >
> >Or am I forgetting some other dependency with our system timers?
> 
> both counter32 and GP timer have to be enabled through sysc registers.
> They are in "Force idle" state after reset.

That's fine, those are within the timer address space. I'd rather
leave out the hwmod dependency from the system timers at the cost
of a system timer specific minimal init function.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 01/18] ARM: am57xx: cl-som-am57x: dts: add basic module support

[Tony Lindgren]

* Dmitry Lifshitz  [151201 08:26]:
> 
> It might looks the same set of regulators for multiple boards,
> but it is not. Each board may apply its own regulators usage scheme, and
> this is our case (as compared to am57xx-beagle-x15.dts).
> 
> For the best of my knowledge, it used to be in a common *.dtsi file (at
> least in early OMAP5 DT support in TI kernel tree), but then I found that
> PMIC registration had been moved to the boards DT files.

Have you actually looked at how much of the implementation is same across
the omap5 boards? My guess is that a whole lot is same.. See for example
omap5-board-common.dtsi.

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 v02 03/15] dmaengine: core: Introduce new, universal API to request a channel

[Tony Lindgren]

* Peter Ujfalusi  [151201 00:14]:
> On 11/30/2015 05:51 PM, Tony Lindgren wrote:
> > Hi,
> > 
> > * Peter Ujfalusi  [151130 05:49]:
> >>
> >> For each dmaengine driver an array of DMA device, slave and the parameter
> >> for the filter function needs to be added:
> >>
> >> static struct dma_filter_map da830_edma_map[] = {
> >>DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
> >>DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
> >>DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
> >>DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
> >>DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
> >>DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
> >>DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
> >>DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
> >>DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
> >>DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
> >>DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
> >>DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
> >> };
> > 
> > FYI, if the EDMA_CTRL_CHAN above is just the evtmux registers
> 
> No, they are not. They are the eDMA event numbers. I used the EDMA_CTRL_CHAN()
> macro for all board files to have uniform look for the data. The first
> parameter means the eDMA instance number while the second is the event number
> on that eDMA. Since most devices have only one eDMA, we have 0 as eDMA id in
> most cases.
> The eventmux, or crossbar is different thing and we have several versions of
> the event crossbar or mux used.

OK

> > those
> > can be handled with the pinctrl framework. It seems that would allow
> > leaving out some of the built-in look up data, and have the mux parts
> > handled by a proper device driver. Below is a sample from the dm81xx
> > platform for reference.
> > 
> > SoC dtsi file:
> > 
> > evtmux: pinmux@f90 {
> > compatible = "pinctrl-single";
> > reg = <0xf90 0x40>;
> > #address-cells = <1>;
> > #size-cells = <0>;
> > pinctrl-single,register-width = <8>;
> > pinctrl-single,function-mask = <0x1f>;
> > };
> > 
> > Board specific dts file:
> > 
> >  {
> > sd2_edma_pins: pinmux_sd2_edma_pins {
> > pinctrl-single,pins = <
> > 8 1 /* use SDTXEVT1 for EDMA instead of MCASP0TX */
> > 9 2 /* use SDRXEVT1 for EDMA instead of MCASP0RX */
> > >;
> > };
> > };
> 
> I see. The dm81xx basically am33xx/am43xx?

Yeah similar to am33xx with different clocks and with a bunch of accelerators.

> Actually I would prefer to use the dmaengine's event router framework and we
> do have support for the am33xx/am43xx type of crossbar already implemented.
> I'm going to resend the DTS series for am33xx/am43xx to convert them to use
> the new DT bindings along with the dma event router support:
> https://www.mail-archive.com/linux-omap%40vger.kernel.org/msg120828.html

OK yes a dmaengine event router works too when available. Good to see
them as separate driver instances now :) Are only the dts changes missing
now?

FYI, when we have separate interconnect driver instances, we don't want to
and cannot tweak registers outside the interconnect instance because of them
being in separate clock and/or power domains :p

In any case, it seems there's no harm using pinctrl for evtmux on dm81xx
until the event router is available. It's currently only needed on the
t410 emmc that I'm aware of :)

> > Dynamic muxing of these channels can be done too using the pinctrl
> > framework named modes, but probably is not a good idea in the case of
> > SD card and MaASP in case something goes wrong :)
> 
> In theory it can be done, but in practice it is not possible. It is up to the
> board design decision to select which DMA event is not needed to be used in
> default mode and that one can be used to route the crossbar hidden request to 
> it.
> Just imaging: playing audio from MMC (in the example you have), audio needs
> constant DMA, so the MMC would never get DMA request, also the drivers tend to
> request the DMA channel in their probe/init and hold to it as long as they are
> loaded...

Yes dynamic muxing of the dma channels sounds like file corruption waiting
to happen :) Let's stay away from that.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 04/15] dmaengine: edma: Add support for DMA filter mapping to slave devices

[Vinod Koul]

On Mon, Nov 30, 2015 at 03:45:34PM +0200, Peter Ujfalusi wrote:
> Add support for providing device to filter_fn mapping so client drivers
> can switch to use the dma_request_chan() API.

Any reason why we dont want to go with DT based only for edma here?

> 
> Signed-off-by: Peter Ujfalusi 
> ---
>  drivers/dma/edma.c | 24 
>  include/linux/platform_data/edma.h |  5 +
>  2 files changed, 29 insertions(+)
> 
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index 0675e268d577..386f8c9bd606 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -2098,6 +2098,8 @@ static struct dma_chan *of_edma_xlate(struct 
> of_phandle_args *dma_spec,
>  }
>  #endif
>  
> +static bool edma_filter_for_map(struct dma_chan *chan, void *param);
> +
>  static int edma_probe(struct platform_device *pdev)
>  {
>   struct edma_soc_info*info = pdev->dev.platform_data;
> @@ -2297,6 +2299,12 @@ static int edma_probe(struct platform_device *pdev)
>   edma_set_chmap(>slave_chans[i], ecc->dummy_slot);
>   }
>  
> + if (info->filter_map) {
> + ecc->dma_slave.filter_map.map = info->filter_map;
> + ecc->dma_slave.filter_map.mapcnt = info->filtercnt;
> + ecc->dma_slave.filter_map.filter_fn = edma_filter_for_map;
> + }
> +
>   ret = dma_async_device_register(>dma_slave);
>   if (ret) {
>   dev_err(dev, "slave ddev registration failed (%d)\n", ret);
> @@ -2428,6 +2436,22 @@ bool edma_filter_fn(struct dma_chan *chan, void *param)
>  }
>  EXPORT_SYMBOL(edma_filter_fn);
>  
> +static bool edma_filter_for_map(struct dma_chan *chan, void *param)
> +{
> + bool match = false;
> +
> + if (chan->device->dev->driver == _driver.driver) {
> + struct edma_chan *echan = to_edma_chan(chan);
> + unsigned ch_req = (unsigned)param;
> + if (ch_req == echan->ch_num) {
> + /* The channel is going to be used as HW synchronized */
> + echan->hw_triggered = true;
> + match = true;
> + }
> + }
> + return match;
> +}
> +
>  static int edma_init(void)
>  {
>   int ret;
> diff --git a/include/linux/platform_data/edma.h 
> b/include/linux/platform_data/edma.h
> index e2878baeb90e..117a36d63840 100644
> --- a/include/linux/platform_data/edma.h
> +++ b/include/linux/platform_data/edma.h
> @@ -59,6 +59,8 @@ struct edma_rsv_info {
>   const s16   (*rsv_slots)[2];
>  };
>  
> +struct dma_filter_map;
> +
>  /* platform_data for EDMA driver */
>  struct edma_soc_info {
>   /*
> @@ -76,6 +78,9 @@ struct edma_soc_info {
>  
>   s8  (*queue_priority_mapping)[2];
>   const s16   (*xbar_chans)[2];
> +
> + struct dma_filter_map *filter_map;
> + int filtercnt;
>  };
>  
>  #endif
> -- 
> 2.6.3
> 

-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 01/18] ARM: am57xx: cl-som-am57x: dts: add basic module support

[Tony Lindgren]

* Nishanth Menon  [151201 08:48]:
> On 12/01/2015 10:43 AM, Tony Lindgren wrote:
> > * Dmitry Lifshitz  [151201 08:26]:
> >>
> >> It might looks the same set of regulators for multiple boards,
> >> but it is not. Each board may apply its own regulators usage scheme, and
> >> this is our case (as compared to am57xx-beagle-x15.dts).
> >>
> >> For the best of my knowledge, it used to be in a common *.dtsi file (at
> >> least in early OMAP5 DT support in TI kernel tree), but then I found that
> >> PMIC registration had been moved to the boards DT files.
> > 
> > Have you actually looked at how much of the implementation is same across
> > the omap5 boards? My guess is that a whole lot is same.. See for example
> > omap5-board-common.dtsi.
> 
> Unfortunately with DRA7 / AM57xx:
> at least 2 different PMICs -> DRA74/DRA72 evms.
> even across similar PMIC usage, different voltage rail usage accross
> evms: DRA74evm, x15/GPEVM, AM571x-IDK/AM572x-IDK -> they are not
> necessarily compatible.
> 
> Example: some of them have Ganged voltage rail, others dont - few others
> are mixed. if you are trying to get common regulator usage -> it is
> kinda pretty hard given the freedom board designers are being given by
> TI.. OMAP5 was more controlled in terms of what specific configuration
> the board designers had to follow. that is no longer the case for
> DRA7/AM57 platforms. just my 2 cents here.

OK thanks for checking. Best to wait a bit on that then until we have
more common patterns.

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

[PATCH V3 01/19] ARM: dts: am57xx: cl-som-am57x: add basic module support

[Dmitry Lifshitz]

Add support for CompuLab CM-SOM-AM57X board.

CL-SOM-AM57x is a miniature System-on-Module (SoM) based on
TI Sitara AM57x ARM Cortex-A15 System-on-Chip family.

https://www.compulab.co.il/products/computer-on-modules/cl-som-am57x-ti-am5728-am5718-system-on-module/

Add basic DT support for standalone module (without a carrier board):

* Memory configuration
* Heartbeat led
* I2C1 and I2C4
* PMIC
* SATA

Signed-off-by: Dmitry Lifshitz 
Acked-by: Igor Grinberg 
---
 v3:
 
   * Move PMIC to I2C4
   * Reformat subject
 
 v2: 

   * Fixed voltages (for OPP_HIGH) for VDD_GPU, VDD_IVA, VDD_DSPEVE
   * Added comments for VDDA_1V8_PHYA/B
   * Add "regulator-always-on" property for ldousb_reg 

 .../devicetree/bindings/arm/omap/omap.txt  |   3 +
 arch/arm/boot/dts/Makefile |   3 +-
 arch/arm/boot/dts/am57xx-cl-som-am57x.dts  | 274 +
 3 files changed, 279 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/am57xx-cl-som-am57x.dts

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index da84372..dd53c90 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -156,6 +156,9 @@ Boards:
 - AM437x SK EVM: AM437x StarterKit Evaluation Module
   compatible = "ti,am437x-sk-evm", "ti,am4372", "ti,am43"
 
+- AM57XX CL-SOM-AM57x
+  compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", "ti,dra74", 
"ti,dra7"
+
 - DRA742 EVM:  Software Development Board for DRA742
   compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
 
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5492a24..803a020 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -477,8 +477,9 @@ dtb-$(CONFIG_SOC_OMAP5) += \
omap5-sbc-t54.dtb \
omap5-uevm.dtb
 dtb-$(CONFIG_SOC_DRA7XX) += \
-   dra7-evm.dtb \
am57xx-beagle-x15.dtb \
+   am57xx-cl-som-am57x.dtb \
+   dra7-evm.dtb \
dra72-evm.dtb
 dtb-$(CONFIG_ARCH_ORION5X) += \
orion5x-lacie-d2-network.dtb \
diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
new file mode 100644
index 000..087d62e
--- /dev/null
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -0,0 +1,274 @@
+/*
+ * Support for CompuLab CL-SOM-AM57x System-on-Module
+ *
+ * Copyright (C) 2015 CompuLab Ltd. - http://www.compulab.co.il/
+ * Author: Dmitry Lifshitz 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+#include 
+#include 
+#include "dra74x.dtsi"
+
+/ {
+   model = "CompuLab CL-SOM-AM57x";
+   compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", 
"ti,dra74", "ti,dra7";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x2000>; /* 512 MB - minimal 
configuration */
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_default>;
+
+   led@0 {
+   label = "cl-som-am57x:green";
+   gpios = < 5 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   default-state = "off";
+   };
+   };
+};
+
+_pmx_core {
+   leds_pins_default: leds_pins_default {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x347c, PIN_OUTPUT | MUX_MODE14)  
/* gpmc_a15.gpio2_5 */
+   >;
+   };
+
+   i2c1_pins_default: i2c1_pins_default {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3800, PIN_INPUT_PULLUP | MUX_MODE0) 
/* i2c1_sda.sda */
+   DRA7XX_CORE_IOPAD(0x3804, PIN_INPUT_PULLUP | MUX_MODE0) 
/* i2c1_scl.scl */
+   >;
+   };
+
+   i2c4_pins_default: i2c4_pins_default {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x36ac, PIN_INPUT| MUX_MODE10)
/* mcasp1_acl.i2c4_sda */
+   DRA7XX_CORE_IOPAD(0x36b0, PIN_INPUT| MUX_MODE10)
/* mcasp1_fsr.i2c4_scl */
+   >;
+   };
+
+   tps659038_pins_default: tps659038_pins_default {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3818, PIN_INPUT_PULLUP | 
MUX_MODE14) /* wakeup0.gpio1_0 */
+   >;
+   };
+};
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_default>;
+   clock-frequency = <40>;
+};
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_default>;
+   clock-frequency = 

[PATCH V3 15/19] ARM: dts: am57xx: sbc-am57x: add GPIO expander support

[Dmitry Lifshitz]

Add PCA9555 GPIO expander support (over I2C5 bus).

Signed-off-by: Dmitry Lifshitz 
Acked-by: Igor Grinberg 
---

  v3:

   * No fuctional changes
   * Reformat subject

  v2:

   * Fixed patch subject/description

 arch/arm/boot/dts/am57xx-sbc-am57x.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts 
b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
index a3588ba..edce6c6 100644
--- a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
@@ -89,4 +89,11 @@
reg = <0x50>;
pagesize = <16>;
};
+
+   pca9555: pca9555@20 {
+   compatible = "nxp,pca9555";
+   reg = <0x20>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 09/19] ARM: dts: am57xx: cl-som-am57x: add touchscreen support

[Dmitry Lifshitz]

Add ADS7846 touchscreen support.

Signed-off-by: Dmitry Lifshitz 
Acked-by: Igor Grinberg 
---

  v2:

   * No fuctional changes
   * Reformat subject

 arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 44 +++
 1 file changed, 44 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index c603136..a75c382 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -43,6 +43,13 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
};
+
+   ads7846reg: fixedregulator-ads7846-reg {
+   compatible = "regulator-fixed";
+   regulator-name = "ads7846-reg";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
 };
 
 _pmx_core {
@@ -183,6 +190,12 @@
DRA7XX_CORE_IOPAD(0x3594, PIN_INPUT | MUX_MODE15)
>;
};
+
+   ads7846_pins: pinmux_ads7846_pins {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3464, PIN_INPUT_PULLDOWN | 
MUX_MODE14) /* gpmc_a9.gpio1_31 */
+   >;
+   };
 };
 
  {
@@ -451,6 +464,37 @@
reg = <0x10 0x0>;
};
};
+
+   /* touch controller */
+   ads7846@0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   compatible = "ti,ads7846";
+   vcc-supply = <>;
+
+   reg = <1>;  /* CS1 */
+   spi-max-frequency = <150>;
+
+   interrupt-parent = <>;
+   interrupts = <31 0>;
+   pendown-gpio = < 31 0>;
+
+
+   ti,x-min = /bits/ 16 <0x0>;
+   ti,x-max = /bits/ 16 <0x0fff>;
+   ti,y-min = /bits/ 16 <0x0>;
+   ti,y-max = /bits/ 16 <0x0fff>;
+
+   ti,x-plate-ohms = /bits/ 16 <180>;
+   ti,pressure-max = /bits/ 16 <255>;
+
+   ti,debounce-max = /bits/ 16 <30>;
+   ti,debounce-tol = /bits/ 16 <10>;
+   ti,debounce-rep = /bits/ 16 <1>;
+
+   linux,wakeup;
+   };
 };
 
  {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 18/19] ARM: dts: am57xx: sbc-am57x: add HDMI support

[Dmitry Lifshitz]

Add HDMI video output support.

Signed-off-by: Dmitry Lifshitz 
Acked-by: Igor Grinberg 
---

  v2:

   * Fix HDMI lanes polarity
   * Reformat subject

 arch/arm/boot/dts/am57xx-sbc-am57x.dts | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts 
b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
index 8e4c0fd..77bb8e1 100644
--- a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
@@ -18,6 +18,7 @@
 
aliases {
display0 = 
+   display1 = 
};
 };
 
@@ -60,6 +61,19 @@
DRA7XX_CORE_IOPAD(0x3564, PIN_OUTPUT | MUX_MODE14)  
/* vin2a_vsync0.gpio4_0 */
>;
};
+
+   hdmi_pins: pinmux_hdmi_pins {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3808, PIN_INPUT | MUX_MODE1)
/* i2c2_sda.hdmi1_ddc_scl */
+   DRA7XX_CORE_IOPAD(0x380c, PIN_INPUT | MUX_MODE1)
/* i2c2_scl.hdmi1_ddc_sda */
+   >;
+   };
+
+   hdmi_conn_pins: pinmux_hdmi_conn_pins {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x37b8, PIN_INPUT | MUX_MODE14)   
/* spi1_cs2.gpio7_12 */
+   >;
+   };
 };
 
  {
@@ -135,3 +149,31 @@
};
};
 };
+
+ {
+   status = "ok";
+   vdda-supply = <_reg>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   port {
+   hdmi_out: endpoint {
+   remote-endpoint = <_connector_in>;
+   lanes = <1 0 3 2 5 4 7 6>;
+   };
+   };
+};
+
+_conn {
+   pinctrl-names = "default";
+   pinctrl-0 = <_conn_pins>;
+
+   hpd-gpios = < 12 GPIO_ACTIVE_HIGH>;
+
+   port {
+   hdmi_connector_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 16/19] ARM: dts: am57xx: sbc-am57x: add LCD support

[Dmitry Lifshitz]

Startek-kd050c 800x480 LCD panel timings are described in
compulab-sb-som.dtsi.

Add appropriate DT endpoints to connect DPI output and LCD.

Signed-off-by: Dmitry Lifshitz 
Acked-by: Igor Grinberg 
---

  v2:

   * No fuctional changes
   * Reformat subject

 arch/arm/boot/dts/am57xx-sbc-am57x.dts | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts 
b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
index edce6c6..8e4c0fd 100644
--- a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
@@ -15,6 +15,10 @@
 / {
model = "CompuLab CL-SOM-AM57x on SB-SOM-AM57x";
compatible = "compulab,sbc-am57x", "compulab,cl-som-am57x", 
"ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7";
+
+   aliases {
+   display0 = 
+   };
 };
 
 _pmx_core {
@@ -50,6 +54,12 @@
DRA7XX_CORE_IOPAD(0x36b8, PIN_INPUT| MUX_MODE10)
/* mcasp1_axr1.i2c5_scl */
>;
};
+
+   lcd_pins_default: lcd_pins_default {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3564, PIN_OUTPUT | MUX_MODE14)  
/* vin2a_vsync0.gpio4_0 */
+   >;
+   };
 };
 
  {
@@ -97,3 +107,31 @@
#gpio-cells = <2>;
};
 };
+
+ {
+   status = "ok";
+
+   vdda_video-supply = <_reg>;
+
+   port {
+   dpi_lcd_out: endpoint@0 {
+   remote-endpoint = <_in>;
+   data-lines = <24>;
+   };
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_default>;
+
+   enable-gpios = < 14 GPIO_ACTIVE_HIGH
+0 GPIO_ACTIVE_HIGH>;
+
+   port {
+   lcd_in: endpoint {
+   remote-endpoint = <_lcd_out>;
+   data-lines = <24>;
+   };
+   };
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 10/19] ARM: dts: am57xx: cl-som-am57x: add analog audio support

[Dmitry Lifshitz]

Add analog audio DT nodes:

1. simple-audio-card node
2. wm8731 codec node
3. MCASP3 pinmux

Signed-off-by: Dmitry Lifshitz 
Acked-by: Igor Grinberg 
---

  v2:

   * No fuctional changes
   * Reformat subject

 arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 67 +++
 1 file changed, 67 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index a75c382..b2c4451 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -50,6 +50,33 @@
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
};
+
+   sound0: sound@0 {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "CL-SOM-AM57x-Sound-Card";
+   simple-audio-card,format = "i2s";
+   simple-audio-card,bitclock-master = <_master>;
+   simple-audio-card,frame-master = <_master>;
+   simple-audio-card,widgets =
+   "Headphone", "Headphone Jack",
+   "Microphone", "Microphone Jack",
+   "Line", "Line Jack";
+   simple-audio-card,routing =
+   "Headphone Jack", "RHPOUT",
+   "Headphone Jack", "LHPOUT",
+   "LLINEIN", "Line Jack",
+   "MICIN", "Mic Bias",
+   "Mic Bias", "Microphone Jack";
+
+   dailink0_master: simple-audio-card,cpu {
+   sound-dai = <>;
+   };
+
+   simple-audio-card,codec {
+   sound-dai = <>;
+   system-clock-frequency = <1200>;
+   };
+   };
 };
 
 _pmx_core {
@@ -196,6 +223,24 @@
DRA7XX_CORE_IOPAD(0x3464, PIN_INPUT_PULLDOWN | 
MUX_MODE14) /* gpmc_a9.gpio1_31 */
>;
};
+
+   mcasp3_pins_default: mcasp3_pins_default {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3724, PIN_INPUT_PULLDOWN | 
MUX_MODE0) /* mcasp3_aclkx.mcasp3_aclkx */
+   DRA7XX_CORE_IOPAD(0x3728, PIN_INPUT_PULLDOWN | 
MUX_MODE0) /* mcasp3_fsx.mcasp3_fsx */
+   DRA7XX_CORE_IOPAD(0x372c, PIN_OUTPUT_PULLDOWN | 
MUX_MODE0) /* mcasp3_axr0.mcasp3_axr0 */
+   DRA7XX_CORE_IOPAD(0x3730, PIN_INPUT_PULLDOWN | 
MUX_MODE0) /* mcasp3_axr1.mcasp3_axr1 */
+   >;
+   };
+
+   mcasp3_pins_sleep: mcasp3_pins_sleep {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3724, PIN_INPUT | MUX_MODE15)
+   DRA7XX_CORE_IOPAD(0x3728, PIN_INPUT | MUX_MODE15)
+   DRA7XX_CORE_IOPAD(0x372c, PIN_INPUT | MUX_MODE15)
+   DRA7XX_CORE_IOPAD(0x3730, PIN_INPUT | MUX_MODE15)
+   >;
+   };
 };
 
  {
@@ -392,6 +437,13 @@
reg = <0x50>;
pagesize = <16>;
};
+
+   wm8731: wm8731@1a {
+   #sound-dai-cells = <0>;
+   compatible = "wlf,wm8731";
+   reg = <0x1a>;
+   status = "okay";
+   };
 };
 
  {
@@ -538,3 +590,18 @@
  {
dr_mode = "peripheral";
 };
+
+ {
+   #sound-dai-cells = <0>;
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_sleep>;
+   status = "okay";
+
+   op-mode = <0>;  /* MCASP_IIS_MODE */
+   tdm-slots = <2>;
+   /* 4 serializers */
+   serial-dir = <  /* 0: INACTIVE, 1: TX, 2: RX */
+   1 2 0 0
+   >;
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V3 04/19] ARM: dts: am57xx: cl-som-am57x: add EEPROM support

[Dmitry Lifshitz]

On-board EEPROM chip is used for storing a board production
info.

Add module EEPROM support (over I2C4 bus).

Signed-off-by: Dmitry Lifshitz 
---

  v3: 
 
   * No fuctional changes 
   * Reformat subject 

  v2:

   * Fix EEPROM chip model

 arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index 2074fd4..1badfa9 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -261,6 +261,12 @@
compatible = "emmicro,em3027";
reg = <0x56>;
};
+
+   eeprom_module: atmel@50 {
+   compatible = "atmel,24c08";
+   reg = <0x50>;
+   pagesize = <16>;
+   };
 };
 
  {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V3 06/19] ARM: dts: am57xx: cl-som-am57x: add spi-flash support

[Dmitry Lifshitz]

On-board spi-flash chip is used as a main boot device.
Add spi-flash chip support (over QSPI bus).

Signed-off-by: Dmitry Lifshitz 
Acked-by: Igor Grinberg 
---
  v3:

   * Modify "compatible" property to match a proper flash driver
   * Drop RX/TX bus with properties
   * Reformat subject

  v2: 

   * Add "spi-max-frequency" property for  node.

 arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 42 +++
 1 file changed, 42 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index ef94845..f7e163a 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -93,6 +93,17 @@
DRA7XX_CORE_IOPAD(0x3498, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a22.mmc2_dat7 */
>;
};
+
+   qspi1_pins: pinmux_qspi1_pins {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3474, PIN_INPUT | MUX_MODE1)
/* gpmc_a13.qspi1_rtclk */
+   DRA7XX_CORE_IOPAD(0x3480, PIN_INPUT | MUX_MODE1)
/* gpmc_a16.qspi1_d0 */
+   DRA7XX_CORE_IOPAD(0x3484, PIN_INPUT | MUX_MODE1)
/* gpmc_a17.qspi1_d1 */
+   DRA7XX_CORE_IOPAD(0x3488, PIN_INPUT | MUX_MODE1)
/* qpmc_a18.qspi1_sclk */
+   DRA7XX_CORE_IOPAD(0x34b8, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_cs2.qspi1_cs0 */
+   DRA7XX_CORE_IOPAD(0x34bc, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_cs3.qspi1_cs1 */
+   >;
+   };
 };
 
  {
@@ -331,3 +342,34 @@
ti,non-removable;
cap-mmc-dual-data-rate;
 };
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   spi-max-frequency = <2000>;
+
+   spi_flash: spi_flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spansion,m25p80", "jedec,spi-nor";
+   reg = <0>;  /* CS0 */
+   spi-max-frequency = <2000>;
+
+   partition@0 {
+   label = "uboot";
+   reg = <0x0 0xc>;
+   };
+
+   partition@c {
+   label = "uboot environment";
+   reg = <0xc 0x4>;
+   };
+
+   partition@10 {
+   label = "reserved";
+   reg = <0x10 0x0>;
+   };
+   };
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 08/19] ARM: dts: am57xx: cl-som-am57x: add USB support

[Dmitry Lifshitz]

Add USB support.

Signed-off-by: Dmitry Lifshitz 
Acked-by: Igor Grinberg 
---
  v2:

   * No fuctional changes
   * Reformat subject

 arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index fe4baba..c603136 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -478,3 +478,19 @@
pinctrl-0 = <_mdio_pins_default>;
pinctrl-1 = <_mdio_pins_sleep>;
 };
+
+_phy1 {
+   phy-supply = <_reg>;
+};
+
+_phy2 {
+   phy-supply = <_reg>;
+};
+
+ {
+   dr_mode = "host";
+};
+
+ {
+   dr_mode = "peripheral";
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 00/19] Add support for CL-SOM-AM57X and SBC-AM57X

[Dmitry Lifshitz]

SBC-AM57X boards.

CL-SOM-AM57x is a miniature System-on-Module (SoM) based on
TI Sitara AM57x ARM Cortex-A15 System-on-Chip family.

SBC-AM57x is a single board computer, implemented with the
CL-SOM-AM57x computer-on-module providing most of the functions,
and SB-SOM-AM57x carrier board providing additional peripheral
functions and connectors.

The SBC-AM57x has the following features:


CPU:Texas Instruments Sitara AM5728 dual-core ARM Cortex-A15, 
1.5GHz or
Texas Instruments Sitara AM5718 single-core ARM Cortex-A15, 
1.5GHz

RAM:DDR3, 512MB – 4GB

Storage:NAND flash, 512MB - 1GB or eMMC flash, 4GB - 32GB
SPI-flash 2MB

Ethernet:   Up to 2x 10/100/1000Mbps Ethernet ports (MAC+PHY)

WiFi/BT:802.11b/g/n WiFi interface (TI WiLink 8 WL1801 chipset) or
Dual-band 2x2 802.11a/b/g/n WiFi interface (TI WiLink 8 WL1837 
chipset)

Analog Audio:   Audio codec with stereo output, stereo input and microphone 
support

More details can be found here:

https://www.compulab.co.il/products/computer-on-modules/cl-som-am57x-ti-am5728-am5718-system-on-module/

https://www.compulab.co.il/products/sbcs/sbc-am57x-ti-am5728-am5718-single-board-computer/

This series is based on the following patch set ("Add support for sbc-t43" 
Nikita Kiryanov):

https://www.mail-archive.com/linux-omap@vger.kernel.org/msg121905.html

Changes in V2:
- Removed unnecessary line breaks in end of file and elsewhere
- Changed subject lines to start with "ARM: dts:"
- PMIC moved from I2C1 to I2C4
- Fixed SPI flash compatible string
- Skipped resetting ETH PHYs
- Fixed HDMI lanes polarity

Dmitry Lifshitz (19):
  ARM: dts: am57xx: cl-som-am57x: add basic module support
  ARM: dts: am57xx: cl-som-am57x: dts: add RTC support
  ARM: dts: am57xx: cl-som-am57x: add I2C3 support
  ARM: dts: am57xx: cl-som-am57x: add EEPROM support
  ARM: dts: am57xx: cl-som-am57x: add eMMC support
  ARM: dts: am57xx: cl-som-am57x: add spi-flash support
  ARM: dts: am57xx: cl-som-am57x: add dual EMAC support
  ARM: dts: am57xx: cl-som-am57x: add USB support
  ARM: dts: am57xx: cl-som-am57x: add touchscreen support
  ARM: dts: am57xx: cl-som-am57x: add analog audio support
  ARM: dts: am57xx: sbc-am57x: add basic board support
  ARM: dts: am57xx: cl-som-am57x: add MMC1 support
  ARM: dts: am57xx: sbc-am57x: add usb vbus pinmux
  ARM: dts: am57xx: sbc-am57x: add EEPROM support
  ARM: dts: am57xx: sbc-am57x: add GPIO expander support
  ARM: dts: am57xx: sbc-am57x: add LCD support
  ARM: dts: am57xx: compulab-sb-som: add HDMI connector
  ARM: dts: am57xx: sbc-am57x: add HDMI support
  ARM: dts: am57xx: cl-som-am57x: skip resetting ETH PHYs

 .../devicetree/bindings/arm/omap/omap.txt  |   6 +
 arch/arm/boot/dts/Makefile |   4 +-
 arch/arm/boot/dts/am57xx-cl-som-am57x.dts  | 617 +
 arch/arm/boot/dts/am57xx-sbc-am57x.dts | 179 ++
 arch/arm/boot/dts/compulab-sb-som.dtsi |   7 +
 5 files changed, 812 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/am57xx-cl-som-am57x.dts
 create mode 100644 arch/arm/boot/dts/am57xx-sbc-am57x.dts

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V3 12/19] ARM: dts: am57xx: cl-som-am57x: add MMC1 support

[Dmitry Lifshitz]

Add MMC1 support, used for SD/MMC card.

Signed-off-by: Dmitry Lifshitz 
Acked-by: Igor Grinberg 
---

  v3:

   * No fuctional changes
   * Reformat subject

  v2:

   * Fix duplicate SD Card Detect pinmux

 arch/arm/boot/dts/am57xx-sbc-am57x.dts | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts 
b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
index 804ad72..93852e2 100644
--- a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
@@ -24,6 +24,19 @@
DRA7XX_CORE_IOPAD(0x37fc, PIN_INPUT_SLEW | MUX_MODE1)   
/* uart2_rtsn.uart3_txd */
>;
};
+
+   mmc1_pins_default: mmc1_pins_default {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_clk.clk */
+   DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_cmd.cmd */
+   DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat0.dat0 */
+   DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat1.dat1 */
+   DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat2.dat2 */
+   DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat3.dat3 */
+   DRA7XX_CORE_IOPAD(0x376c, PIN_INPUT | MUX_MODE14)   
/* mmc1_sdcd.gpio6_27 */
+   DRA7XX_CORE_IOPAD(0x377c, PIN_INPUT | MUX_MODE14)   
/* mmc1_sdwp.gpio6_28 */
+   >;
+   };
 };
 
  {
@@ -34,3 +47,15 @@
pinctrl-names = "default";
pinctrl-0 = <_pins_default>;
 };
+
+ {
+   status = "okay";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_default>;
+
+   vmmc-supply = <_reg>;
+   bus-width = <4>;
+   cd-gpios = < 27 GPIO_ACTIVE_LOW>;
+   wp-gpios = < 28 GPIO_ACTIVE_HIGH>;
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 05/19] ARM: dts: am57xx: cl-som-am57x: add eMMC support

[Dmitry Lifshitz]

CM-SOM-AM57X has two options of main storage devices - eMMC or NAND.
Add eMMC chip support (over MMC2 bus).

Signed-off-by: Dmitry Lifshitz 
Acked-by: Igor Grinberg 
---

  v2: 
 
   * No fuctional changes 
   * Reformat subject 

 arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 34 +++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index 1badfa9..ef94845 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -36,6 +36,13 @@
default-state = "off";
};
};
+
+   vdd_3v3: fixedregulator-vdd_3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "vdd_3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
 };
 
 _pmx_core {
@@ -71,6 +78,21 @@
DRA7XX_CORE_IOPAD(0x3818, PIN_INPUT_PULLUP | 
MUX_MODE14) /* wakeup0.gpio1_0 */
>;
};
+
+   mmc2_pins_default: mmc2_pins_default {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x349c, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a23.mmc2_clk */
+   DRA7XX_CORE_IOPAD(0x34b0, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_cs1.mmc2_cmd */
+   DRA7XX_CORE_IOPAD(0x34a0, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a24.mmc2_dat0 */
+   DRA7XX_CORE_IOPAD(0x34a4, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a25.mmc2_dat1 */
+   DRA7XX_CORE_IOPAD(0x34a8, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a26.mmc2_dat2 */
+   DRA7XX_CORE_IOPAD(0x34ac, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a27.mmc2_dat3 */
+   DRA7XX_CORE_IOPAD(0x348c, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a19.mmc2_dat4 */
+   DRA7XX_CORE_IOPAD(0x3490, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a20.mmc2_dat5 */
+   DRA7XX_CORE_IOPAD(0x3494, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a21.mmc2_dat6 */
+   DRA7XX_CORE_IOPAD(0x3498, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a22.mmc2_dat7 */
+   >;
+   };
 };
 
  {
@@ -297,3 +319,15 @@
status = "okay";
};
 };
+
+ {
+   status = "okay";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_default>;
+
+   vmmc-supply = <_3v3>;
+   bus-width = <8>;
+   ti,non-removable;
+   cap-mmc-dual-data-rate;
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 13/19] ARM: dts: am57xx: sbc-am57x: add usb vbus pinmux

[Dmitry Lifshitz]

usb1_drvvbus pin is used to Drive-VBUS enable to external charge
pump/power switch.

Add a pinmux for that pin.

Signed-off-by: Dmitry Lifshitz 
Acked-by: Igor Grinberg 
---

  v2:

   * No fuctional changes
   * Reformat subject

 arch/arm/boot/dts/am57xx-sbc-am57x.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts 
b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
index 93852e2..17a1972 100644
--- a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
@@ -37,6 +37,12 @@
DRA7XX_CORE_IOPAD(0x377c, PIN_INPUT | MUX_MODE14)   
/* mmc1_sdwp.gpio6_28 */
>;
};
+
+   usb1_pins: pinmux_usb1_pins {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3680, PIN_INPUT_SLEW | MUX_MODE0) 
/* usb1_drvvbus */
+   >;
+   };
 };
 
  {
@@ -59,3 +65,8 @@
cd-gpios = < 27 GPIO_ACTIVE_LOW>;
wp-gpios = < 28 GPIO_ACTIVE_HIGH>;
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 02/19] ARM: dts: am57xx: cl-som-am57x: dts: add RTC support

[Dmitry Lifshitz]

Add EM3027 RTC chip support (over I2C4 bus).

Signed-off-by: Dmitry Lifshitz 
Acked-by: Igor Grinberg 
---
  v2:

   * No fuctional changes.
   * Refactor patch with respect to the previous changes in I2C4 node structure.
   * Reformat subject

 arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index 087d62e..58156a9 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -242,6 +242,11 @@
#gpio-cells = <2>;
};
};
+
+   rtc0: rtc@56 {
+   compatible = "emmicro,em3027";
+   reg = <0x56>;
+   };
 };
 
  {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 11/19] ARM: dts: am57xx: sbc-am57x: add basic board support

[Dmitry Lifshitz]

SBC-AM57x is a single board computer designed for industrial and
embedded applications. It is based on the Texas Instruments Sitara AM57x
system-on-chip family. SBC-AM57x is implemented with the CL-SOM-AM57x
computer-on-module providing most of the functions, and SB-SOM-AM57x
carrier board providing additional peripheral functions and connectors.

https://www.compulab.co.il/products/sbcs/sbc-am57x-ti-am5728-am5718-single-board-computer/

https://www.compulab.co.il/products/computer-on-modules/cl-som-am57x-ti-am5728-am5718-system-on-module/

Add basic board support, including UART3, used as a serial console.

Signed-off-by: Dmitry Lifshitz 
Acked-by: Igor Grinberg 
---

  v2:

   * No fuctional changes
   * Reformat subject

 .../devicetree/bindings/arm/omap/omap.txt  |  3 ++
 arch/arm/boot/dts/Makefile |  1 +
 arch/arm/boot/dts/am57xx-sbc-am57x.dts | 36 ++
 3 files changed, 40 insertions(+)
 create mode 100644 arch/arm/boot/dts/am57xx-sbc-am57x.dts

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index dd53c90..42cdad1 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -159,6 +159,9 @@ Boards:
 - AM57XX CL-SOM-AM57x
   compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", "ti,dra74", 
"ti,dra7"
 
+- AM57XX SBC-AM57x
+  compatible = "compulab,sbc-am57x", "compulab,cl-som-am57x", "ti,am5728", 
"ti,dra742", "ti,dra74", "ti,dra7"
+
 - DRA742 EVM:  Software Development Board for DRA742
   compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
 
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 803a020..4c73ab9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -479,6 +479,7 @@ dtb-$(CONFIG_SOC_OMAP5) += \
 dtb-$(CONFIG_SOC_DRA7XX) += \
am57xx-beagle-x15.dtb \
am57xx-cl-som-am57x.dtb \
+   am57xx-sbc-am57x.dtb \
dra7-evm.dtb \
dra72-evm.dtb
 dtb-$(CONFIG_ARCH_ORION5X) += \
diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts 
b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
new file mode 100644
index 000..804ad72
--- /dev/null
+++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
@@ -0,0 +1,36 @@
+/*
+ * Support for CompuLab SBC-AM57x single board computer
+ *
+ * Copyright (C) 2015 CompuLab Ltd. - http://www.compulab.co.il/
+ * Author: Dmitry Lifshitz 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include "am57xx-cl-som-am57x.dts"
+#include "compulab-sb-som.dtsi"
+
+/ {
+   model = "CompuLab CL-SOM-AM57x on SB-SOM-AM57x";
+   compatible = "compulab,sbc-am57x", "compulab,cl-som-am57x", 
"ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7";
+};
+
+_pmx_core {
+   uart3_pins_default: uart3_pins_default {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x37f8, PIN_INPUT_SLEW | MUX_MODE2)   
/* uart2_ctsn.uart3_rxd */
+   DRA7XX_CORE_IOPAD(0x37fc, PIN_INPUT_SLEW | MUX_MODE1)   
/* uart2_rtsn.uart3_txd */
+   >;
+   };
+};
+
+ {
+   status = "okay";
+   interrupts-extended = <_mpu GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
+ <_pmx_core 0x3f8>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_default>;
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 17/19] ARM: dts: am57xx: compulab-sb-som: add HDMI connector

[Dmitry Lifshitz]

Add HDMI connector node without a valid input endpoint.

CompuLab SB-SOM is a carrier board, hence the endpoint
should be added in the board DT with a valid HDMI output.

Signed-off-by: Dmitry Lifshitz 
Acked-by: Igor Grinberg 
---

  v2:

   * No fuctional changes
   * Reformat subject

 arch/arm/boot/dts/compulab-sb-som.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/compulab-sb-som.dtsi 
b/arch/arm/boot/dts/compulab-sb-som.dtsi
index 402a143..93d7e23 100644
--- a/arch/arm/boot/dts/compulab-sb-som.dtsi
+++ b/arch/arm/boot/dts/compulab-sb-som.dtsi
@@ -39,4 +39,11 @@
pixelclk-active = <1>;
};
};
+
+   hdmi_conn: connector@0 {
+   compatible = "hdmi-connector";
+   label = "hdmi";
+
+   type = "a";
+   };
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 03/19] ARM: dts: am57xx: cl-som-am57x: add I2C3 support

[Dmitry Lifshitz]

Enable I2C3 bus and add appropriate pinmux.

Signed-off-by: Dmitry Lifshitz 
Acked-by: Igor Grinberg 
---

  v2:

   * No fuctional changes
   * Refactor patch with respect to the previous changes in I2C4 node structure
   * Reformat subject

 arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index 58156a9..2074fd4 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -52,6 +52,13 @@
>;
};
 
+   i2c3_pins_default: i2c3_pins_default {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x36a4, PIN_INPUT| MUX_MODE10)
/* mcasp1_aclkx.i2c3_sda */
+   DRA7XX_CORE_IOPAD(0x36a8, PIN_INPUT| MUX_MODE10)
/* mcasp1_fsx.i2c3_scl */
+   >;
+   };
+
i2c4_pins_default: i2c4_pins_default {
pinctrl-single,pins = <
DRA7XX_CORE_IOPAD(0x36ac, PIN_INPUT| MUX_MODE10)
/* mcasp1_acl.i2c4_sda */
@@ -73,6 +80,13 @@
clock-frequency = <40>;
 };
 
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_default>;
+   clock-frequency = <40>;
+};
+
  {
status = "okay";
pinctrl-names = "default";
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V2 14/19] ARM: dts: am57xx: sbc-am57x: add EEPROM support

[Dmitry Lifshitz]

On-board EEPROM chip is used for storing a board production info.

Add carrier board EEPROM support (over I2C5 bus).

Signed-off-by: Dmitry Lifshitz 
---

  v2:

   * No fuctional changes
   * Reformat subject

 arch/arm/boot/dts/am57xx-sbc-am57x.dts | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts 
b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
index 17a1972..a3588ba 100644
--- a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
@@ -43,6 +43,13 @@
DRA7XX_CORE_IOPAD(0x3680, PIN_INPUT_SLEW | MUX_MODE0) 
/* usb1_drvvbus */
>;
};
+
+   i2c5_pins_default: i2c5_pins_default {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x36b4, PIN_INPUT| MUX_MODE10)
/* mcasp1_axr0.i2c5_sda */
+   DRA7XX_CORE_IOPAD(0x36b8, PIN_INPUT| MUX_MODE10)
/* mcasp1_axr1.i2c5_scl */
+   >;
+   };
 };
 
  {
@@ -70,3 +77,16 @@
pinctrl-names = "default";
pinctrl-0 = <_pins>;
 };
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_default>;
+   clock-frequency = <40>;
+
+   eeprom_base: atmel@50 {
+   compatible = "atmel,24c08";
+   reg = <0x50>;
+   pagesize = <16>;
+   };
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V3 07/19] ARM: dts: am57xx: cl-som-am57x: add dual EMAC support

[Dmitry Lifshitz]

Add dual EMAC support.

Signed-off-by: Dmitry Lifshitz 
Acked-by: Igor Grinberg 
---
  v3: 
 
   * No fuctional changes 
   * Reformat subject 

  v2: 

   * Fix pinmux comments for RGMII0/1 clock/data lines
   * Fix pinmux for MDIO bus clock/data lines
   * Fix PHYs addresses

 arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 105 ++
 1 file changed, 105 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index f7e163a..fe4baba 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -104,6 +104,85 @@
DRA7XX_CORE_IOPAD(0x34bc, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_cs3.qspi1_cs1 */
>;
};
+
+   cpsw_pins_default: cpsw_pins_default {
+   pinctrl-single,pins = <
+   /* Slave at addr 0x0 */
+   DRA7XX_CORE_IOPAD(0x3650, PIN_OUTPUT | MUX_MODE0)   
/* rgmii0_tclk */
+   DRA7XX_CORE_IOPAD(0x3654, PIN_OUTPUT | MUX_MODE0)   
/* rgmii0_tctl */
+   DRA7XX_CORE_IOPAD(0x3658, PIN_OUTPUT | MUX_MODE0)   
/* rgmii0_td3 */
+   DRA7XX_CORE_IOPAD(0x365c, PIN_OUTPUT | MUX_MODE0)   
/* rgmii0_td2 */
+   DRA7XX_CORE_IOPAD(0x3660, PIN_OUTPUT | MUX_MODE0)   
/* rgmii0_td1 */
+   DRA7XX_CORE_IOPAD(0x3664, PIN_OUTPUT | MUX_MODE0)   
/* rgmii0_td0 */
+   DRA7XX_CORE_IOPAD(0x3668, PIN_INPUT_PULLDOWN | 
MUX_MODE0) /* rgmii0_rclk */
+   DRA7XX_CORE_IOPAD(0x366c, PIN_INPUT_PULLDOWN | 
MUX_MODE0) /* rgmii0_rctl */
+   DRA7XX_CORE_IOPAD(0x3670, PIN_INPUT_PULLDOWN | 
MUX_MODE0) /* rgmii0_rd3 */
+   DRA7XX_CORE_IOPAD(0x3674, PIN_INPUT_PULLDOWN | 
MUX_MODE0) /* rgmii0_rd2 */
+   DRA7XX_CORE_IOPAD(0x3678, PIN_INPUT_PULLDOWN | 
MUX_MODE0) /* rgmii0_rd1 */
+   DRA7XX_CORE_IOPAD(0x367c, PIN_INPUT_PULLDOWN | 
MUX_MODE0) /* rgmii0_rd0 */
+
+   /* Slave at addr 0x1 */
+   DRA7XX_CORE_IOPAD(0x3598, PIN_OUTPUT | MUX_MODE3)   
/* vin2a_d12.rgmii1_tclk */
+   DRA7XX_CORE_IOPAD(0x359c, PIN_OUTPUT | MUX_MODE3)   
/* vin2a_d13.rgmii1_tctl */
+   DRA7XX_CORE_IOPAD(0x35a0, PIN_OUTPUT | MUX_MODE3)   
/* vin2a_d14.rgmii1_td3 */
+   DRA7XX_CORE_IOPAD(0x35a4, PIN_OUTPUT | MUX_MODE3)   
/* vin2a_d15.rgmii1_td2 */
+   DRA7XX_CORE_IOPAD(0x35a8, PIN_OUTPUT | MUX_MODE3)   
/* vin2a_d16.rgmii1_td1 */
+   DRA7XX_CORE_IOPAD(0x35ac, PIN_OUTPUT | MUX_MODE3)   
/* vin2a_d17.rgmii1_td0 */
+   DRA7XX_CORE_IOPAD(0x35b0, PIN_INPUT_PULLDOWN | 
MUX_MODE3) /* vin2a_d18.rgmii1_rclk */
+   DRA7XX_CORE_IOPAD(0x35b4, PIN_INPUT_PULLDOWN | 
MUX_MODE3) /* vin2a_d19.rgmii1_rctl */
+   DRA7XX_CORE_IOPAD(0x35b8, PIN_INPUT_PULLDOWN | 
MUX_MODE3) /* vin2a_d20.rgmii1_rd3 */
+   DRA7XX_CORE_IOPAD(0x35bc, PIN_INPUT_PULLDOWN | 
MUX_MODE3) /* vin2a_d21.rgmii1_rd2 */
+   DRA7XX_CORE_IOPAD(0x35c0, PIN_INPUT_PULLDOWN | 
MUX_MODE3) /* vin2a_d22.rgmii1_rd1 */
+   DRA7XX_CORE_IOPAD(0x35c4, PIN_INPUT_PULLUP | MUX_MODE3) 
/* vin2a_d23.rgmii1_rd0 */
+   >;
+   };
+
+   cpsw_pins_sleep: cpsw_pins_sleep {
+   pinctrl-single,pins = <
+   /* Slave 1 */
+   DRA7XX_CORE_IOPAD(0x3650, PIN_INPUT | MUX_MODE15)
+   DRA7XX_CORE_IOPAD(0x3654, PIN_INPUT | MUX_MODE15)
+   DRA7XX_CORE_IOPAD(0x3658, PIN_INPUT | MUX_MODE15)
+   DRA7XX_CORE_IOPAD(0x365c, PIN_INPUT | MUX_MODE15)
+   DRA7XX_CORE_IOPAD(0x3660, PIN_INPUT | MUX_MODE15)
+   DRA7XX_CORE_IOPAD(0x3664, PIN_INPUT | MUX_MODE15)
+   DRA7XX_CORE_IOPAD(0x3668, PIN_INPUT | MUX_MODE15)
+   DRA7XX_CORE_IOPAD(0x366c, PIN_INPUT | MUX_MODE15)
+   DRA7XX_CORE_IOPAD(0x3670, PIN_INPUT | MUX_MODE15)
+   DRA7XX_CORE_IOPAD(0x3674, PIN_INPUT | MUX_MODE15)
+   DRA7XX_CORE_IOPAD(0x3678, PIN_INPUT | MUX_MODE15)
+   DRA7XX_CORE_IOPAD(0x367c, PIN_INPUT | MUX_MODE15)
+
+   /* Slave 2 */
+   DRA7XX_CORE_IOPAD(0x3598, PIN_INPUT | MUX_MODE15)
+   DRA7XX_CORE_IOPAD(0x359c, PIN_INPUT | MUX_MODE15)
+   DRA7XX_CORE_IOPAD(0x35a0, PIN_INPUT | MUX_MODE15)
+   DRA7XX_CORE_IOPAD(0x35a4, PIN_INPUT | MUX_MODE15)
+   DRA7XX_CORE_IOPAD(0x35a8, PIN_INPUT | MUX_MODE15)
+   

[PATCH 19/19] ARM: dts: am57xx: cl-som-am57x: skip resetting ETH PHYs

[Dmitry Lifshitz]

ETH PHYs setup on CL-SOM-AM57X is established in U-Boot along with
bringing them out of reset. This is done by toggling GPIOs belonging
to GPIO2/3 controllers on AM57xx.

Skip resetting ETH PHYs, by adding "ti,no-reset-on-init" to GPIO2/3
controllers DT nodes.

Signed-off-by: Dmitry Lifshitz 
---
 arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts 
b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index b2c4451..c538826 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -605,3 +605,13 @@
1 2 0 0
>;
 };
+
+ {
+   status = "okay";
+   ti,no-reset-on-init;
+};
+
+ {
+   status = "okay";
+   ti,no-reset-on-init;
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Brian Norris]

Hi Roger,

On Tue, Dec 01, 2015 at 04:41:16PM +0200, Roger Quadros wrote:
> On 30/11/15 21:54, Brian Norris wrote:
> > On Tue, Oct 27, 2015 at 11:37:03AM +0200, Roger Quadros wrote:
> >> On 26/10/15 23:23, Brian Norris wrote:
> >>> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
>  - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
>  with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
>  This causes performance increase when using prefetch-irq mode.
>  30% increase in read, 17% increase in write in prefetch-irq mode.
> >>>
> >>> Have you pinpointed the exact causes for the performance increase, or
> >>> can you give an educated guess? AIUI, you're reducing the number of
> >>> interrupts needed for NAND prefetch mode, but you're also removing a bit
> >>> of abstraction and implementing hooks that look awfully like the
> >>> existing abstractions:
> >>>
> >>> +   int (*nand_irq_enable)(enum gpmc_nand_irq irq);
> >>> +   int (*nand_irq_disable)(enum gpmc_nand_irq irq);
> >>> +   void (*nand_irq_clear)(enum gpmc_nand_irq irq);
> >>> +   u32 (*nand_irq_status)(void);
> >>>
> >>> That's not really a problem if there's a good reason for them (brcmnand
> >>> implements similar hooks because of quirks in the implementation of
> >>> interrupts across various BRCM SoCs, and it's not worth writing irqchip
> >>> drivers for those cases). I'm mainly curious for an explanation.
> >>
> >> I have both implementations with me. My guess is that the 20% performance
> >> gain is due to absence of irqchip/irqdomain translation code.
> >> I haven't investigated further though.
> > 
> > I don't have much context for whether this makes sense or not. According
> > to your tests, you're getting ~800K interrupts over ~15 seconds. So
> > should you start noticing performance hits due to abstraction at 53K
> > interrupts per second?
> 
> Yes, this was my understanding.

Am I computing wrong, or is that a pretty insane rate of interrupts?

> > But anyway, I'm not sure that completely answered my question. My
> > question was whether you were removing the irqchip code solely for
> > performance reasons, or are there others?
> 
> Yes. Only for performance reasons.

Hmm, that's not my favorite answer. I'd prefer that more analysis was
done here before scrapping irqchip...

But maybe that's not too bad. It seems like your patch set overall is a
net positive for disentangling some of arch/ and drivers/.

I'll take another pass over your patch set, but if things are looking
better, how do you expect to merge this? There are significant portions
that touch at least 2 or 3 different subsystem trees, AFAICT.

Brian
--
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 v02 04/15] dmaengine: edma: Add support for DMA filter mapping to slave devices

[Vinod Koul]

On Tue, Dec 01, 2015 at 09:20:28PM +0100, Arnd Bergmann wrote:
> On Tuesday 01 December 2015 22:52:12 Vinod Koul wrote:
> > On Mon, Nov 30, 2015 at 03:45:34PM +0200, Peter Ujfalusi wrote:
> > > Add support for providing device to filter_fn mapping so client drivers
> > > can switch to use the dma_request_chan() API.
> > 
> > Any reason why we dont want to go with DT based only for edma here?
> 
> I think the OMAP2 based platforms using edma are all DT-only, but mach-davinci
> would need a lot of work for that.

Okay sound fine then

-- 
~Vinod
--
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 v02 00/15] dmaengine: New 'universal' API for requesting channel

[Vinod Koul]

On Tue, Dec 01, 2015 at 09:17:06PM +0100, Arnd Bergmann wrote:
> On Tuesday 01 December 2015 22:29:54 Vinod Koul wrote:
> > On Mon, Nov 30, 2015 at 03:45:30PM +0200, Peter Ujfalusi wrote:
> > > channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode
> > > it will use a filter lookup table and retrieves the needed information 
> > > from
> > > the dma_filter_map provided by the DMA drivers.
> > 
> > That sounds right, for the third case would the arch, driver or someone else
> > configure this?
> 
> The typical case is for the configuration to be defined in arch or platform
> code and passed down to the dmaengine driver.
> 
> I just noticed that the text above (and probably the code too) should
> be changed so we always fall back to this. There are cases where the
> platform is booted with DT in principle, but the DMA engine does not
> (yet) use DT and still wants to be converted. I think we can easily
> handle that case by always trying this if the other methods fail.

I agree that this makes sense, not just for DT cases but ACPI as well

> 
> > > This legacy mode needs changes in platform code, in dmaengine drivers and
> > > finally the dmaengine user drivers can be converted:
> > 
> > Are you marking the current APIs as dericated in the end of this series
> 
> I think we practically stopped marking things as deprecated in general.
> Per Linus decree, whenever we want to get rid of something, we should
> instead change all users in tree and then remove the API, expecting
> driver maintainers to do something just because you marked it as deprecated
> often doesn't work.

Yes but while we do conversion we don't know if new users get added which use
old API..

> 
> I can help out converting a few platforms, maybe one interface at a time.

Great yes we all will have to chip in and start removing these, i will try
doing few after new year

Am sure Andy can chip in as well :)

> This is what I see:
> 
> arnd@wuerfel:~/arm-soc$ for i in dma_request_slave_channel_reason 
> dma_request_slave_channel dma_request_slave_channel_compat 
> dma_request_channel  ; do echo `git grep -wl $i drivers/  | grep -v 
> drivers/dma | wc -l`\  $i ; done
> 14  dma_request_slave_channel_reason
> 27  dma_request_slave_channel
> 25  dma_request_slave_channel_compat
> 34  dma_request_channel
> 
> I would probably leave the users of dma_request_channel() while converting
> the others, as that is still used by all the platforms that don't use any DT
> support.
> 
> Changing dma_request_slave_channel_reason and dma_request_slave_channel is
> trivial, we can probably use coccinelle for that, as it does not require
> any platform changes. That brings us to the users of
> dma_request_slave_channel_compat, which currently includes these files:
> 
> $ git grep -wl dma_request_slave_channel_compat drivers/ata/pata_pxa.c
> drivers/crypto/atmel-aes.c
> drivers/crypto/atmel-sha.c
> drivers/crypto/atmel-tdes.c
> drivers/crypto/omap-aes.c
> drivers/crypto/omap-des.c
> drivers/crypto/omap-sham.c
> drivers/media/platform/omap3isp/isphist.c
> drivers/mmc/host/davinci_mmc.c
> drivers/mmc/host/omap.c
> drivers/mmc/host/omap_hsmmc.c
> drivers/mmc/host/pxamci.c
> drivers/mmc/host/s3cmci.c
> drivers/mmc/host/tmio_mmc_dma.c
> drivers/mtd/nand/pxa3xx_nand.c
> drivers/net/ethernet/smsc/smc91x.c
> drivers/net/irda/pxaficp_ir.c
> drivers/spi/spi-omap2-mcspi.c
> drivers/spi/spi-pxa2xx-dma.c
> drivers/spi/spi-rspi.c
> drivers/spi/spi-s3c64xx.c
> drivers/spi/spi-sh-msiof.c
> drivers/tty/serial/8250/8250_dma.c
> drivers/tty/serial/samsung.c
> drivers/tty/serial/sh-sci.c
> include/linux/dmaengine.h
> 
> In other words: arch/avr32 and arch/sh along with omap1, omap2, davinci, pxa, 
> and s3c
> in terms of ARM platforms.
> 
>   Arnd

-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

Brian,

On 02/12/15 08:56, Brian Norris wrote:
> Hi Roger,
> 
> On Tue, Dec 01, 2015 at 04:41:16PM +0200, Roger Quadros wrote:
>> On 30/11/15 21:54, Brian Norris wrote:
>>> On Tue, Oct 27, 2015 at 11:37:03AM +0200, Roger Quadros wrote:
 On 26/10/15 23:23, Brian Norris wrote:
> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
>> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
>> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
>> This causes performance increase when using prefetch-irq mode.
>> 30% increase in read, 17% increase in write in prefetch-irq mode.
>
> Have you pinpointed the exact causes for the performance increase, or
> can you give an educated guess? AIUI, you're reducing the number of
> interrupts needed for NAND prefetch mode, but you're also removing a bit
> of abstraction and implementing hooks that look awfully like the
> existing abstractions:
>
> +   int (*nand_irq_enable)(enum gpmc_nand_irq irq);
> +   int (*nand_irq_disable)(enum gpmc_nand_irq irq);
> +   void (*nand_irq_clear)(enum gpmc_nand_irq irq);
> +   u32 (*nand_irq_status)(void);
>
> That's not really a problem if there's a good reason for them (brcmnand
> implements similar hooks because of quirks in the implementation of
> interrupts across various BRCM SoCs, and it's not worth writing irqchip
> drivers for those cases). I'm mainly curious for an explanation.

 I have both implementations with me. My guess is that the 20% performance
 gain is due to absence of irqchip/irqdomain translation code.
 I haven't investigated further though.
>>>
>>> I don't have much context for whether this makes sense or not. According
>>> to your tests, you're getting ~800K interrupts over ~15 seconds. So
>>> should you start noticing performance hits due to abstraction at 53K
>>> interrupts per second?
>>
>> Yes, this was my understanding.
> 
> Am I computing wrong, or is that a pretty insane rate of interrupts?

I don't have the test board with me right now and so can't tell you
for sure if the mtd tests took 15 seconds or more.

I can try it out on a different board that I have and let you know
for sure about how many interrupts we get per second.
> 
>>> But anyway, I'm not sure that completely answered my question. My
>>> question was whether you were removing the irqchip code solely for
>>> performance reasons, or are there others?
>>
>> Yes. Only for performance reasons.
> 
> Hmm, that's not my favorite answer. I'd prefer that more analysis was
> done here before scrapping irqchip...

I agree. We could retain the irqchip model till we have more satisfying
analysis.

> 
> But maybe that's not too bad. It seems like your patch set overall is a
> net positive for disentangling some of arch/ and drivers/.

:)

> 
> I'll take another pass over your patch set, but if things are looking
> better, how do you expect to merge this? There are significant portions
> that touch at least 2 or 3 different subsystem trees, AFAICT.

Tony could create an immutable branch with all the dts and memory changes.
You could base the mtd changes on top of that?

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 v02 02/15] dmaengine: core: Move and merge the code paths using private_candidate

[Peter Ujfalusi]

On 11/30/2015 04:42 PM, Andy Shevchenko wrote:
> On Mon, Nov 30, 2015 at 3:45 PM, Peter Ujfalusi  wrote:
>> Channel matching with private_candidate() is used in two paths, the error
>> checking is slightly different in them and they are duplicating code also.
>> Move the code under dma_get_channel() to provide consistent execution and
>> going to allow us to reuse this mode of channel lookup later.
>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>>  drivers/dma/dmaengine.c | 81 
>> +
>>  1 file changed, 42 insertions(+), 39 deletions(-)
>>
>> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
>> index 52c3eee48e2e..1249165fb4b2 100644
>> --- a/drivers/dma/dmaengine.c
>> +++ b/drivers/dma/dmaengine.c
>> @@ -549,6 +549,42 @@ static struct dma_chan *private_candidate(const 
>> dma_cap_mask_t *mask,
>> return NULL;
>>  }
>>
>> +static struct dma_chan *dma_get_channel(struct dma_device *device,
> 
> Naming scheme inside dmaengine.c looks like a mess.

Yes, I agree.

> 
> Since it's static function that utilizes private_candidate() may I
> propose the name like find_candidate() ?

I had __* version as well, but the find_candidate() sounds better.

Thanks,
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 01/15] dmaengine: core: Allow NULL mask pointer in __dma_device_satisfies_mask()

[Peter Ujfalusi]

On 11/30/2015 04:35 PM, Andy Shevchenko wrote:
> On Mon, Nov 30, 2015 at 3:45 PM, Peter Ujfalusi  wrote:
>> Treat as true condition the case when the mask is NULL.
> 
> What do you think about setting some default (all "on") mask when mask
> is not supplied?

Probably rephrasing the commit message to say that when the mask is NULL it
means that the caller does not care about the capabilities of the dma device
thus return with true in such a case.

We could also drop this patch and in private_candidate() :

-   if (!__dma_device_satisfies_mask(dev, mask)) {
+   if (mask && !__dma_device_satisfies_mask(dev, mask)) {
pr_debug("%s: wrong capabilities\n", __func__);
return NULL;
}


> I don't know for sure but there might be cases when you don't want
> literally *any* channel to satisfy.

Or set DMA_SLAVE only in dma_request_chan()? What happens if we have cases
when we are able to request channel for memcpy via dma_request_chan()
(dedicated memcpy channel/DMA engine?) in that case we will have the SLAVE
set, but not MEMCPY, or any other variation we do not know yet?

>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>>  drivers/dma/dmaengine.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
>> index daf54a39bcc7..52c3eee48e2e 100644
>> --- a/drivers/dma/dmaengine.c
>> +++ b/drivers/dma/dmaengine.c
>> @@ -184,6 +184,9 @@ __dma_device_satisfies_mask(struct dma_device *device,
>>  {
>> dma_cap_mask_t has;
>>
>> +   if (!want)
>> +   return true;
>> +
>> bitmap_and(has.bits, want->bits, device->cap_mask.bits,
>> DMA_TX_TYPE_END);
>> return bitmap_equal(want->bits, has.bits, DMA_TX_TYPE_END);
>> --
>> 2.6.3
>>
> 
> 
> 


-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 03/15] dmaengine: core: Introduce new, universal API to request a channel

[Peter Ujfalusi]

On 11/30/2015 04:09 PM, Arnd Bergmann wrote:
> On Monday 30 November 2015 15:45:33 Peter Ujfalusi wrote:
>>   const char *name);
>>  struct dma_chan *dma_request_slave_channel(struct device *dev, const char 
>> *name);
>> +
>> +struct dma_chan *dma_request_chan(struct device *dev, const char *name);
>> +struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);
>> +
>>  void dma_release_channel(struct dma_chan *chan);
>>  int dma_get_slave_caps(struct dma_chan *chan, struct dma_slave_caps *caps);
>>  #else
>> @@ -1268,6 +1291,14 @@ static inline struct dma_chan 
>> *dma_request_slave_channel(struct device *dev,
>>  {
>> return NULL;
>>  }
>> +static inline struct dma_chan *dma_request_chan(struct device *dev)
>> +{
>> +   return ERR_PTR(-ENODEV);
>> +}
>>
> 
> The prototypes for dma_request_chan() don't match, otherwise looks good.

Aargh, the !CONFIG_DMA_ENGINE path...
Fixed for the next RFC

Thanks,
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 03/15] dmaengine: core: Introduce new, universal API to request a channel

[Peter Ujfalusi]

On 11/30/2015 04:51 PM, Andy Shevchenko wrote:
>> +struct dma_chan *dma_request_chan(struct device *dev, const char *name)
>> +{
>> +   struct dma_device *device, *_d;
>> +   struct dma_chan *chan = NULL;
>> +
>> +   /* If device-tree is present get slave info from here */
>> +   if (dev->of_node)
>> +   chan = of_dma_request_slave_channel(dev->of_node, name);
>> +
>> +   /* If device was enumerated by ACPI get slave info from here */
>> +   if (ACPI_HANDLE(dev) && !chan)
> 
> The preferable way is to use
> has_acpi_companion() instead of ACPI_HANDLE().

I have done this part based on the dma_request_slave_channel_reason().
Will switch to use the has_acpi_companion() for the next RFC.

>> +   chan = acpi_dma_request_slave_chan_by_name(dev, name);
>> +
>> +   if (chan)
>> +   return chan;
>> +

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 04/15] dmaengine: edma: Add support for DMA filter mapping to slave devices

[Peter Ujfalusi]

On 11/30/2015 04:11 PM, Arnd Bergmann wrote:
> On Monday 30 November 2015 15:45:34 Peter Ujfalusi wrote:
>> @@ -2428,6 +2436,22 @@ bool edma_filter_fn(struct dma_chan *chan, void 
>> *param)
>>  }
>>  EXPORT_SYMBOL(edma_filter_fn);
>>  
>> +static bool edma_filter_for_map(struct dma_chan *chan, void *param)
>> +{
>> +   bool match = false;
>> +
>> +   if (chan->device->dev->driver == _driver.driver) {
>> +   struct edma_chan *echan = to_edma_chan(chan);
>> +   unsigned ch_req = (unsigned)param;
>> +   if (ch_req == echan->ch_num) {
>> +   /* The channel is going to be used as HW 
>> synchronized */
>> +   echan->hw_triggered = true;
>> +   match = true;
>> +   }
>> +   }
>> +   return match;
>> +}
>> +
>>  static int edma_init(void)
>>
> 
> I don't see the difference between edma_filter_fn and edma_filter_for_map.
> Why do you need both?

edma_filter_fn:
unsigned ch_req = *(unsigned *)param;

edma_filter_for_map:
unsigned ch_req = (unsigned)param;


If I want to reuse the edma_filter_fn, I would need an unsigned array for the
eDMA event numbers in the board files to be able to provide the pointer to
each of them.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 03/15] dmaengine: core: Introduce new, universal API to request a channel

[Andy Shevchenko]

On Tue, Dec 1, 2015 at 11:56 AM, Peter Ujfalusi  wrote:
> On 11/30/2015 04:51 PM, Andy Shevchenko wrote:
>>> +struct dma_chan *dma_request_chan(struct device *dev, const char *name)
>>> +{
>>> +   struct dma_device *device, *_d;
>>> +   struct dma_chan *chan = NULL;
>>> +
>>> +   /* If device-tree is present get slave info from here */
>>> +   if (dev->of_node)
>>> +   chan = of_dma_request_slave_channel(dev->of_node, name);
>>> +
>>> +   /* If device was enumerated by ACPI get slave info from here */
>>> +   if (ACPI_HANDLE(dev) && !chan)
>>
>> The preferable way is to use
>> has_acpi_companion() instead of ACPI_HANDLE().
>
> I have done this part based on the dma_request_slave_channel_reason().

Understood, though that function was implemented before
has_acpi_companion() has been introduced.

> Will switch to use the has_acpi_companion() for the next RFC.

Good.

-- 
With Best Regards,
Andy Shevchenko
--
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 v02 00/15] dmaengine: New 'universal' API for requesting channel

[Peter Ujfalusi]

On 11/30/2015 04:18 PM, Arnd Bergmann wrote:
> On Monday 30 November 2015 15:45:30 Peter Ujfalusi wrote:
>> Changes since RFC v01:
>> - dma_request_chan(); lost the mask parameter
>> - The new API does not rely on RESOURCE_DMA, instead the dma_filter_map table
>>  will be used to provide the needed information to the filter function in
>>  legacy mode
>> - Extended the example patches to convert most of daVinci to use the new API 
>> to
>>  request the DMA channels.
> 
> Very nice overall. Just a few minor comments.
> 
>> static struct dma_filter_map da830_edma_map[] = {
>> DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
>> DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
>> DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
>> DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
>> DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
>> DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
>> DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
>> DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
>> DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
>> DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
>> DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
>> DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
>> };
> 
> I wonder if we should mandate that the lookup table is 'const'.

I had been wondering the same, I'll make it const for the next round.

> We could also drop the DMA_FILTER_ENTRY() macro above, and open-code the
> table like
> 
> static struct dma_filter_map da830_edma_map[] = {
>  { "davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)},
>  { "davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)},
>  { "davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)},
>...
> };
> 
> which is a little more compact and more obvious, but loses the
> named initializers.

We would need:
{ "da830-mmc.0", "rx", (void*)EDMA_CTLR_CHAN(0, 16) },
{ "da830-mmc.0", "tx", (void*)EDMA_CTLR_CHAN(0, 17) },

as we need to cast the param.
It is still compact, but having to add the (void*) casting makes it a bit ugly.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v02 04/15] dmaengine: edma: Add support for DMA filter mapping to slave devices

[Arnd Bergmann]

On Tuesday 01 December 2015 11:58:53 Peter Ujfalusi wrote:
> On 11/30/2015 04:11 PM, Arnd Bergmann wrote:
> > On Monday 30 November 2015 15:45:34 Peter Ujfalusi wrote:
> >> @@ -2428,6 +2436,22 @@ bool edma_filter_fn(struct dma_chan *chan, void 
> >> *param)
> >>  }
> >>  EXPORT_SYMBOL(edma_filter_fn);
> >>  
> >> +static bool edma_filter_for_map(struct dma_chan *chan, void *param)
> >> +{
> >> +   bool match = false;
> >> +
> >> +   if (chan->device->dev->driver == _driver.driver) {
> >> +   struct edma_chan *echan = to_edma_chan(chan);
> >> +   unsigned ch_req = (unsigned)param;
> >> +   if (ch_req == echan->ch_num) {
> >> +   /* The channel is going to be used as HW 
> >> synchronized */
> >> +   echan->hw_triggered = true;
> >> +   match = true;
> >> +   }
> >> +   }
> >> +   return match;
> >> +}
> >> +
> >>  static int edma_init(void)
> >>
> > 
> > I don't see the difference between edma_filter_fn and edma_filter_for_map.
> > Why do you need both?
> 
> edma_filter_fn:
> unsigned ch_req = *(unsigned *)param;
> 
> edma_filter_for_map:
> unsigned ch_req = (unsigned)param;

I see.

> If I want to reuse the edma_filter_fn, I would need an unsigned array for the
> eDMA event numbers in the board files to be able to provide the pointer to
> each of them.

How about this:

#define EDMA_CTLR_CHANP(ctlr, chan)  ((const int[]){ [0] = ((ctlr) << 16) | 
(chan)})

static struct dma_filter_map da830_edma_map[] = {
 { "davinci-mcasp.0", "rx", EDMA_CTLR_CHANP(0, 0)},
 { "davinci-mcasp.0", "tx", EDMA_CTLR_CHANP(0, 1)},
 { "davinci-mcasp.1", "rx", EDMA_CTLR_CHANP(0, 2)},
 ...
};

That way, you create an anonymous constant integer expression and the data
points to that.

Arnd
--
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 v02 00/15] dmaengine: New 'universal' API for requesting channel

[Arnd Bergmann]

On Tuesday 01 December 2015 12:12:47 Peter Ujfalusi wrote:
> 
> We would need:
> { "da830-mmc.0", "rx", (void*)EDMA_CTLR_CHAN(0, 16) },
> { "da830-mmc.0", "tx", (void*)EDMA_CTLR_CHAN(0, 17) },
> 
> as we need to cast the param.
> It is still compact, but having to add the (void*) casting makes it a bit 
> ugly.

Right, I forgot that, but the cast could also be part of EDMA_CTLR_CHAN(),
and with the version I just posted in my other reply that part is solved
as well.

Arnd
--
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 v02 03/15] dmaengine: core: Introduce new, universal API to request a channel

[Peter Ujfalusi]

On 11/30/2015 05:51 PM, Tony Lindgren wrote:
> Hi,
> 
> * Peter Ujfalusi  [151130 05:49]:
>>
>> For each dmaengine driver an array of DMA device, slave and the parameter
>> for the filter function needs to be added:
>>
>> static struct dma_filter_map da830_edma_map[] = {
>>  DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)),
>>  DMA_FILTER_ENTRY("davinci-mcasp.0", "tx", EDMA_CTLR_CHAN(0, 1)),
>>  DMA_FILTER_ENTRY("davinci-mcasp.1", "rx", EDMA_CTLR_CHAN(0, 2)),
>>  DMA_FILTER_ENTRY("davinci-mcasp.1", "tx", EDMA_CTLR_CHAN(0, 3)),
>>  DMA_FILTER_ENTRY("davinci-mcasp.2", "rx", EDMA_CTLR_CHAN(0, 4)),
>>  DMA_FILTER_ENTRY("davinci-mcasp.2", "tx", EDMA_CTLR_CHAN(0, 5)),
>>  DMA_FILTER_ENTRY("spi_davinci.0", "rx", EDMA_CTLR_CHAN(0, 14)),
>>  DMA_FILTER_ENTRY("spi_davinci.0", "tx", EDMA_CTLR_CHAN(0, 15)),
>>  DMA_FILTER_ENTRY("da830-mmc.0", "rx", EDMA_CTLR_CHAN(0, 16)),
>>  DMA_FILTER_ENTRY("da830-mmc.0", "tx", EDMA_CTLR_CHAN(0, 17)),
>>  DMA_FILTER_ENTRY("spi_davinci.1", "rx", EDMA_CTLR_CHAN(0, 18)),
>>  DMA_FILTER_ENTRY("spi_davinci.1", "tx", EDMA_CTLR_CHAN(0, 19)),
>> };
> 
> FYI, if the EDMA_CTRL_CHAN above is just the evtmux registers

No, they are not. They are the eDMA event numbers. I used the EDMA_CTRL_CHAN()
macro for all board files to have uniform look for the data. The first
parameter means the eDMA instance number while the second is the event number
on that eDMA. Since most devices have only one eDMA, we have 0 as eDMA id in
most cases.
The eventmux, or crossbar is different thing and we have several versions of
the event crossbar or mux used.

> those
> can be handled with the pinctrl framework. It seems that would allow
> leaving out some of the built-in look up data, and have the mux parts
> handled by a proper device driver. Below is a sample from the dm81xx
> platform for reference.
> 
> SoC dtsi file:
> 
> evtmux: pinmux@f90 {
>   compatible = "pinctrl-single";
>   reg = <0xf90 0x40>;
>   #address-cells = <1>;
>   #size-cells = <0>;
>   pinctrl-single,register-width = <8>;
>   pinctrl-single,function-mask = <0x1f>;
> };
> 
> Board specific dts file:
> 
>  {
>   sd2_edma_pins: pinmux_sd2_edma_pins {
>   pinctrl-single,pins = <
>   8 1 /* use SDTXEVT1 for EDMA instead of MCASP0TX */
>   9 2 /* use SDRXEVT1 for EDMA instead of MCASP0RX */
>   >;
>   };
> };

I see. The dm81xx basically am33xx/am43xx?

Actually I would prefer to use the dmaengine's event router framework and we
do have support for the am33xx/am43xx type of crossbar already implemented.
I'm going to resend the DTS series for am33xx/am43xx to convert them to use
the new DT bindings along with the dma event router support:
https://www.mail-archive.com/linux-omap%40vger.kernel.org/msg120828.html

> Dynamic muxing of these channels can be done too using the pinctrl
> framework named modes, but probably is not a good idea in the case of
> SD card and MaASP in case something goes wrong :)

In theory it can be done, but in practice it is not possible. It is up to the
board design decision to select which DMA event is not needed to be used in
default mode and that one can be used to route the crossbar hidden request to 
it.
Just imaging: playing audio from MMC (in the example you have), audio needs
constant DMA, so the MMC would never get DMA request, also the drivers tend to
request the DMA channel in their probe/init and hold to it as long as they are
loaded...

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 16/25] mtd: nand: update mtd_to_nand()

[Boris Brezillon]

Now that all drivers are using the mtd instance embedded in the nand_chip
struct we can safely update the mtd_to_nand() implementation to use
the container_of macro instead of returning the content of mtd->priv.
This will allow us to remove mtd->priv = chip assignments done in all
NAND controller drivers.

Signed-off-by: Boris Brezillon 
---
 include/linux/mtd/nand.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 8ec071e..873646d 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -734,7 +734,7 @@ static inline struct device_node 
*nand_get_flash_node(struct nand_chip *chip)
 
 static inline struct nand_chip *mtd_to_nand(struct mtd_info *mtd)
 {
-   return mtd->priv;
+   return container_of(mtd, struct nand_chip, mtd);
 }
 
 static inline struct mtd_info *nand_to_mtd(struct nand_chip *chip)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 22/25] mtd: nand: add helpers to access ->priv

[Boris Brezillon]

Add two helpers to access the field reserved for private controller data.
This makes it clearer what this field is reserved for and ease future
refactoring.

Signed-off-by: Boris Brezillon 
---
 include/linux/mtd/nand.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index f12efe1..4afa263 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -739,6 +739,16 @@ static inline struct mtd_info *nand_to_mtd(struct 
nand_chip *chip)
return >mtd;
 }
 
+static inline void *nand_get_controller_data(struct nand_chip *chip)
+{
+   return chip->priv;
+}
+
+static inline void nand_set_controller_data(struct nand_chip *chip, void *priv)
+{
+   chip->priv = priv;
+}
+
 /*
  * NAND Flash Manufacturer ID Codes
  */
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwmon: (tmp102) Force wait for conversion time for the first valid data

[Guenter Roeck]

On 12/01/2015 06:21 AM, Nishanth Menon wrote:
[ ... ]



Hint about how the patch will look like:


Looks ok (and better).

Guenter


diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index 65482624ea2c..5289aa0980a8 100644
--- a/drivers/hwmon/tmp102.c
+++ b/drivers/hwmon/tmp102.c
@@ -58,6 +58,7 @@ struct tmp102 {
u16 config_orig;
unsigned long last_update;
int temp[3];
+   bool first_time;
  };

  /* convert left adjusted 13-bit TMP102 register value to milliCelsius */
@@ -93,6 +94,7 @@ static struct tmp102 *tmp102_update_device(struct device *dev)
tmp102->temp[i] = tmp102_reg_to_mC(status);
}
tmp102->last_update = jiffies;
+   tmp102->first_time = false;
}
mutex_unlock(>lock);
return tmp102;
@@ -102,6 +104,12 @@ static int tmp102_read_temp(void *dev, int *temp)
  {
struct tmp102 *tmp102 = tmp102_update_device(dev);

+   /* Is it too early even to return a conversion? */
+   if (tmp102->first_time) {
+   dev_dbg(dev, "%s: Conversion not ready yet..\n", __func__);
+   return -EAGAIN;
+   }
+
*temp = tmp102->temp[0];

return 0;
@@ -114,6 +122,10 @@ static ssize_t tmp102_show_temp(struct device *dev,
struct sensor_device_attribute *sda = to_sensor_dev_attr(attr);
struct tmp102 *tmp102 = tmp102_update_device(dev);

+   /* Is it too early even to return a read? */
+   if (tmp102->first_time)
+   return -EAGAIN;
+
return sprintf(buf, "%d\n", tmp102->temp[sda->index]);
  }

@@ -207,7 +219,9 @@ static int tmp102_probe(struct i2c_client *client,
status = -ENODEV;
goto fail_restore_config;
}
-   tmp102->last_update = jiffies - HZ;
+   tmp102->last_update = jiffies;
+   /* Mark that we are not ready with data until conversion is complete */
+   tmp102->first_time = true;
mutex_init(>lock);

hwmon_dev = hwmon_device_register_with_groups(dev, client->name,



--
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] clocksource: ti-32k: convert to platform device

[Grygorii Strashko]

Hi Tony,

On 11/30/2015 06:28 PM, Tony Lindgren wrote:
> * Grygorii Strashko  [151127 12:11]:
>> On 11/20/2015 08:21 PM, Felipe Balbi wrote:
>>> Grygorii Strashko  writes:
 Since system clocksource is finally selected by Clocksource core at
 fs_initcall stage during boot there are no reasons to initialize
 ti_32k_timer at early boot stages. Hence, ti_32k_timer can be
 converted to use platform device/driver model and its PM can be
 implemented using PM runtime which is common for OMAP devices.

 Platform specific initialization code has to be disabled once as
 ti_32k_timer is converted to platform device - otherwise OMAP platform
 code will generate boot warnings.

 After this change, all counter_32k's platform code can be removed
 once all OMAP boards will be converted to DT.

 Cc: Tony Lindgren 
 Cc: Felipe Balbi 
 Signed-off-by: Grygorii Strashko 
 ---
>>
>> [...]
>>
 +
 +static struct platform_driver ti_32k_driver __initdata = {
 +  .probe  = ti_32k_probe,
 +  .driver = {
 +  .name   = "ti_32k_timer",
 +  .of_match_table = of_match_ptr(ti_32k_of_table),
 +  }
 +};
 +
 +static int __init ti_32k_init(void)
 +{
 +  return platform_driver_register(_32k_driver);
}
 -CLOCKSOURCE_OF_DECLARE(ti_32k_timer, "ti,omap-counter32k",
 -  ti_32k_timer_init);
 +
 +subsys_initcall(ti_32k_init);
 +
 +MODULE_AUTHOR("Paul Mundt");
 +MODULE_AUTHOR("Juha Yrjölä");
 +MODULE_DESCRIPTION("OMAP2 32k Timer");
 +MODULE_ALIAS("platform:ti_32k_timer");
 +MODULE_LICENSE("GPL v2");
>>>
>>> this will break clksource_of_init(), right ? Eventually, we want that to
>>> be the only thing called by our .init_time method. I'll leave it to Tony
>>> to decide, but IMO this is not a good path forward for timers.
>>>
>>
>> Yeh :(.  I did additional tests, and, unfortunately, this can't be used as 
>> is.
>> But not because of clocksource_of_init() which will just produce boot 
>> warning.
>> It can't be done because of sched_clock_register() which is expected to be
>> called during early boot time only and with disabled IRQs.
>>
>> It was so tempting to try :)
> 
> We should be able to make this into an early_platform_device and just
> have it depend on the source clock muxes. See the omap initcall changes
> patches I just posted.
> 

Sry, may be I've missed smth, but how early_platform_device will help us
to get rid of platform code - We'd still need to power on manually 
early_platform_device's from platform code :( through hwmod.

The main reason why I've tried this is because clocksource will be really 
selected
only at fs_initcall time - and at that time we have no restriction for using 
platform
devices, Pm runtime APIs, etc. (exception/blocker is sched_clock :().

-- 
regards,
-grygorii
--
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] hwmon: (tmp102) Force wait for conversion time for the first valid data

[Nishanth Menon]

On 12/01/2015 09:09 AM, Guenter Roeck wrote:
> On 12/01/2015 06:21 AM, Nishanth Menon wrote:
> [ ... ]
> 
>>
>> Hint about how the patch will look like:
> 
> Looks ok (and better).
Thanks for the feedback. Will post the same.


-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] reset: Introduce static inline dummy function when CONFIG_RESET_CONTROLLER

[Nishanth Menon]

When CONFIG_RESET_CONTROLLER is not defined (example COMPILE_TEST),
provide a dummy static inline implementation.

Signed-off-by: Nishanth Menon 
---
 include/linux/reset-controller.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/linux/reset-controller.h b/include/linux/reset-controller.h
index ce6b962ffed4..4badecb2619e 100644
--- a/include/linux/reset-controller.h
+++ b/include/linux/reset-controller.h
@@ -48,7 +48,16 @@ struct reset_controller_dev {
unsigned int nr_resets;
 };
 
+#if IS_ENABLED(CONFIG_RESET_CONTROLLER)
 int reset_controller_register(struct reset_controller_dev *rcdev);
 void reset_controller_unregister(struct reset_controller_dev *rcdev);
+#else
+static inline int reset_controller_register(struct reset_controller_dev *r)
+{
+   return -EINVAL;
+}
 
+static inline void reset_controller_unregister(struct reset_controller_dev *r)
+{
+}
 #endif
-- 
2.6.2.402.g2635c2b

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: OMAP2+: Initialize timers later with late_time_init

[Tony Lindgren]

* Grygorii Strashko  [151201 05:53]:
> On 11/30/2015 06:26 PM, Tony Lindgren wrote:
> > We don't need timers right away and initializing them later gives us few
> > nice things like interrupts and kmalloc. As the timers have a dependency
> > to the clock framework, we're better off initializing things later rather
> > than early if things go wrong. And this allows us to make the mux clock
> > driver needed for system timers into early_platform drivers.
> > 
> > Note that smp_prepare_cpus() will get called later on during the init so
> > we just need to local_irq_enable/disable for clocksource_probe().
> > 
> > Cc: Felipe Balbi 
> > Cc: Grygorii Strashko 
> > Cc: Paul Walmsley 
> > Cc: Tero Kristo 
> > Signed-off-by: Tony Lindgren 
> > ---
> >   arch/arm/mach-omap2/timer.c | 46 
> > +++--
> >   1 file changed, 40 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> > index b18ebbe..68bf482 100644
> > --- a/arch/arm/mach-omap2/timer.c
> > +++ b/arch/arm/mach-omap2/timer.c
> > @@ -478,36 +478,56 @@ static void __init __omap_sync32k_timer_init(int 
> > clkev_nr, const char *clkev_src
> > omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
> >   
> > /* Enable the use of clocksource="gp_timer" kernel parameter */
> > +   local_irq_disable();
> > if (use_gptimer_clksrc || gptimer)
> > omap2_gptimer_clocksource_init(clksrc_nr, clksrc_src,
> > clksrc_prop);
> > else
> > omap2_sync32k_clocksource_init();
> > +   local_irq_enable();
> 
> So, this will be called now after sched_clock_postinit() and to W/A warnings
> you've added local_irq_disable()/local_irq_enable(). Am I right?
> 
> Are you sure this is safe?

Hmm good point, update_sched_clock() is never called again and so it's
running on jiffies. We could separate out the sched_clock when the 32k
source or a local timer is used. But that does allow initializing the
gptimer later on. Anyways, clearly this needs more work.

Regards,

Tony


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] reset: Introduce static inline dummy function when CONFIG_RESET_CONTROLLER

[kbuild test robot]

Hi Nishanth,

[auto build test ERROR on v4.4-rc3]
[also build test ERROR on next-20151127]

url:
https://github.com/0day-ci/linux/commits/Nishanth-Menon/reset-Introduce-static-inline-dummy-function-when-CONFIG_RESET_CONTROLLER/20151201-233708
config: i386-randconfig-n0-201548 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from drivers/reset/core.c:18:0:
>> include/linux/reset-controller.h:1:0: error: unterminated #ifndef
#ifndef _LINUX_RESET_CONTROLLER_H_
^

vim +1 include/linux/reset-controller.h

61fc4131 Philipp Zabel 2012-11-19 @1  #ifndef _LINUX_RESET_CONTROLLER_H_
61fc4131 Philipp Zabel 2012-11-19  2  #define _LINUX_RESET_CONTROLLER_H_
61fc4131 Philipp Zabel 2012-11-19  3  
61fc4131 Philipp Zabel 2012-11-19  4  #include 

:: The code at line 1 was first introduced by commit
:: 61fc41317666be400802ac793f47de816ef7bd57 reset: Add reset controller API

:: TO: Philipp Zabel <p.za...@pengutronix.de>
:: CC: Philipp Zabel <p.za...@pengutronix.de>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH v2 21/25] mtd: nand: kill the chip->flash_node field

[Boris Brezillon]

Now that the nand_chip struct directly embeds an mtd_info struct we can
get rid of the ->flash_node field and forward set/get_flash_node requests
to the MTD layer.

As a side effect, we no longer need the mtd_set_of_node() call done in
nand_dt_init().

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/nand_base.c | 3 ---
 include/linux/mtd/nand.h | 7 ++-
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index ae3fd2a..8bb8ebd6 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3945,9 +3945,6 @@ static int nand_dt_init(struct nand_chip *chip)
if (!dn)
return 0;
 
-   /* MTD can automatically handle DT partitions, etc. */
-   mtd_set_of_node(nand_to_mtd(chip), dn);
-
if (of_get_nand_bus_width(dn) == 16)
chip->options |= NAND_BUSWIDTH_16;
 
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 873646d..f12efe1 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -545,7 +545,6 @@ struct nand_buffers {
  * flash device
  * @IO_ADDR_W: [BOARDSPECIFIC] address to write the 8 I/O lines of the
  * flash device.
- * @flash_node:[BOARDSPECIFIC] device node describing this 
instance
  * @read_byte: [REPLACEABLE] read one byte from the chip
  * @read_word: [REPLACEABLE] read one word from the chip
  * @write_byte:[REPLACEABLE] write a single byte to the chip 
on the
@@ -645,8 +644,6 @@ struct nand_chip {
void __iomem *IO_ADDR_R;
void __iomem *IO_ADDR_W;
 
-   struct device_node *flash_node;
-
uint8_t (*read_byte)(struct mtd_info *mtd);
u16 (*read_word)(struct mtd_info *mtd);
void (*write_byte)(struct mtd_info *mtd, uint8_t byte);
@@ -724,12 +721,12 @@ struct nand_chip {
 static inline void nand_set_flash_node(struct nand_chip *chip,
   struct device_node *np)
 {
-   chip->flash_node = np;
+   mtd_set_of_node(>mtd, np);
 }
 
 static inline struct device_node *nand_get_flash_node(struct nand_chip *chip)
 {
-   return chip->flash_node;
+   return mtd_get_of_node(>mtd);
 }
 
 static inline struct nand_chip *mtd_to_nand(struct mtd_info *mtd)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 20/25] mtd: nand: simplify nand_dt_init() usage

[Boris Brezillon]

nand_dt_init() function requires 3 arguments where it actually needs one
(dn and mtd can both be retrieved from chip). Drop these parameters.

Testing for dn != NULL inside nand_dt_init() also helps simplifying the
caller code.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/nand_base.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 5aec154..ae3fd2a 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3937,11 +3937,17 @@ ident_done:
return type;
 }
 
-static int nand_dt_init(struct mtd_info *mtd, struct nand_chip *chip,
-   struct device_node *dn)
+static int nand_dt_init(struct nand_chip *chip)
 {
+   struct device_node *dn = nand_get_flash_node(chip);
int ecc_mode, ecc_strength, ecc_step;
 
+   if (!dn)
+   return 0;
+
+   /* MTD can automatically handle DT partitions, etc. */
+   mtd_set_of_node(nand_to_mtd(chip), dn);
+
if (of_get_nand_bus_width(dn) == 16)
chip->options |= NAND_BUSWIDTH_16;
 
@@ -3989,14 +3995,9 @@ int nand_scan_ident(struct mtd_info *mtd, int maxchips,
struct nand_flash_dev *type;
int ret;
 
-   if (nand_get_flash_node(chip)) {
-   /* MTD can automatically handle DT partitions, etc. */
-   mtd_set_of_node(mtd, nand_get_flash_node(chip));
-
-   ret = nand_dt_init(mtd, chip, nand_get_flash_node(chip));
-   if (ret)
-   return ret;
-   }
+   ret = nand_dt_init(chip);
+   if (ret)
+   return ret;
 
/* Set the default functions */
nand_set_defaults(chip, chip->options & NAND_BUSWIDTH_16);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 01/25] ARM: nand: make use of mtd_to_nand() where appropriate

[Boris Brezillon]

mtd_to_nand() was recently introduced to avoid direct accesses to the
mtd->priv field. Update all ARM specific implementations to use this
helper.

Signed-off-by: Boris Brezillon 
---
 arch/arm/mach-ep93xx/snappercl15.c   | 4 ++--
 arch/arm/mach-ep93xx/ts72xx.c| 4 ++--
 arch/arm/mach-imx/mach-qong.c| 2 +-
 arch/arm/mach-ixp4xx/ixdp425-setup.c | 2 +-
 arch/arm/mach-omap1/board-nand.c | 2 +-
 arch/arm/mach-orion5x/ts78xx-setup.c | 6 +++---
 arch/arm/mach-pxa/balloon3.c | 2 +-
 arch/arm/mach-pxa/em-x270.c  | 2 +-
 arch/arm/mach-pxa/palmtx.c   | 2 +-
 9 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-ep93xx/snappercl15.c 
b/arch/arm/mach-ep93xx/snappercl15.c
index c490426..b2db791 100644
--- a/arch/arm/mach-ep93xx/snappercl15.c
+++ b/arch/arm/mach-ep93xx/snappercl15.c
@@ -49,7 +49,7 @@
 static void snappercl15_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
  unsigned int ctrl)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
static u16 nand_state = SNAPPERCL15_NAND_WPN;
u16 set;
 
@@ -76,7 +76,7 @@ static void snappercl15_nand_cmd_ctrl(struct mtd_info *mtd, 
int cmd,
 
 static int snappercl15_nand_dev_ready(struct mtd_info *mtd)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
 
return !!(__raw_readw(NAND_CTRL_ADDR(chip)) & SNAPPERCL15_NAND_RDY);
 }
diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index 61f4b5d..45b81a2 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -74,7 +74,7 @@ static void __init ts72xx_map_io(void)
 static void ts72xx_nand_hwcontrol(struct mtd_info *mtd,
  int cmd, unsigned int ctrl)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
 
if (ctrl & NAND_CTRL_CHANGE) {
void __iomem *addr = chip->IO_ADDR_R;
@@ -96,7 +96,7 @@ static void ts72xx_nand_hwcontrol(struct mtd_info *mtd,
 
 static int ts72xx_nand_device_ready(struct mtd_info *mtd)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
void __iomem *addr = chip->IO_ADDR_R;
 
addr += (1 << TS72XX_NAND_BUSY_ADDR_LINE);
diff --git a/arch/arm/mach-imx/mach-qong.c b/arch/arm/mach-imx/mach-qong.c
index a213e7b..5c27646 100644
--- a/arch/arm/mach-imx/mach-qong.c
+++ b/arch/arm/mach-imx/mach-qong.c
@@ -131,7 +131,7 @@ static void qong_init_nor_mtd(void)
  */
 static void qong_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int 
ctrl)
 {
-   struct nand_chip *nand_chip = mtd->priv;
+   struct nand_chip *nand_chip = mtd_to_nand(mtd);
 
if (cmd == NAND_CMD_NONE)
return;
diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c 
b/arch/arm/mach-ixp4xx/ixdp425-setup.c
index e7b8bef..333b0f9 100644
--- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
+++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
@@ -76,7 +76,7 @@ static struct mtd_partition ixdp425_partitions[] = {
 static void
 ixdp425_flash_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
 {
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
int offset = (int)this->priv;
 
if (ctrl & NAND_CTRL_CHANGE) {
diff --git a/arch/arm/mach-omap1/board-nand.c b/arch/arm/mach-omap1/board-nand.c
index 4d08353..7684f92 100644
--- a/arch/arm/mach-omap1/board-nand.c
+++ b/arch/arm/mach-omap1/board-nand.c
@@ -22,7 +22,7 @@
 
 void omap1_nand_cmd_ctl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
 {
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
unsigned long mask;
 
if (cmd == NAND_CMD_NONE)
diff --git a/arch/arm/mach-orion5x/ts78xx-setup.c 
b/arch/arm/mach-orion5x/ts78xx-setup.c
index 1b704d3..96cf6b5 100644
--- a/arch/arm/mach-orion5x/ts78xx-setup.c
+++ b/arch/arm/mach-orion5x/ts78xx-setup.c
@@ -176,7 +176,7 @@ static void ts78xx_ts_rtc_unload(void)
 static void ts78xx_ts_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
unsigned int ctrl)
 {
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
 
if (ctrl & NAND_CTRL_CHANGE) {
unsigned char bits;
@@ -200,7 +200,7 @@ static int ts78xx_ts_nand_dev_ready(struct mtd_info *mtd)
 static void ts78xx_ts_nand_write_buf(struct mtd_info *mtd,
const uint8_t *buf, int len)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
void __iomem *io_base = chip->IO_ADDR_W;
unsigned long off = ((unsigned long)buf & 3);
int sz;
@@ -227,7 +227,7 @@ static void ts78xx_ts_nand_write_buf(struct mtd_info *mtd,
 static void ts78xx_ts_nand_read_buf(struct mtd_info *mtd,

Re: [PATCH] ARM: OMAP4: execute initcall to reserve SRAM for I688 only on OMAP4

[Lucas Stach]

Am Montag, den 30.11.2015, 20:27 +0200 schrieb Grygorii Strashko:
> On 11/30/2015 07:27 PM, Lucas Stach wrote:
> > Am Montag, den 16.11.2015, 14:24 +0200 schrieb Grygorii Strashko:
> >> On 11/16/2015 01:25 PM, Lucas Stach wrote:
> >>> omap_interconnect_sync() is the only user of the SRAM scratch area
> >>> allocated in the omap4_sram_init initcall. The interconnect sync is
> >>> used exclusively in the OMAP4 specific WFI implementation, so there
> >>> is no point in allocating the SRAM scratch on other SoC types.
> >>>
> >>> Bail out of the initcall if the kernel is not running on OMAP4 to
> >>> avoid a confusing warning about being unable to allocate the SRAM
> >>> needed for I688 handling.
> >>>
> >>> Signed-off-by: Lucas Stach 
> >>> Tested-by: Bastian Stender 
> >>> ---
> >>>arch/arm/mach-omap2/omap4-common.c | 3 +++
> >>>1 file changed, 3 insertions(+)
> >>>
> >>> diff --git a/arch/arm/mach-omap2/omap4-common.c 
> >>> b/arch/arm/mach-omap2/omap4-common.c
> >>> index 949696b6f17b..6db393a30a28 100644
> >>> --- a/arch/arm/mach-omap2/omap4-common.c
> >>> +++ b/arch/arm/mach-omap2/omap4-common.c
> >>> @@ -131,6 +131,9 @@ static int __init omap4_sram_init(void)
> >>>   struct device_node *np;
> >>>   struct gen_pool *sram_pool;
> >>>
> >>> + if (!cpu_is_omap44xx())
> >>> + return 0;
> >>
> >> This one affects on am43xx also
> >>
> > So you are saying this erratum is also present on AM43xx? I wasn't able
> > to deduce this from the information provided by Richard Woodruff.
> > 
> 
> "..SOCs using similar chassis components of OMAP4430 time are impacted..."
> "..But AM335x should be immune from this particular issue..."
> 
> Advisory 11 Asynchronous Bridge Corruption
> http://www.ti.com/lit/er/sprz408b/sprz408b.pdf
> 
> 
Thanks for the link, it makes things a lot more clear.
> 
> >>
> >>> +
> >>>   np = of_find_compatible_node(NULL, NULL, "ti,omap4-mpu");
> >>>   if (!np)
> >>>   pr_warn("%s:Unable to allocate sram needed to handle 
> >>> errata I688\n",
> >>
> >> Since all OMAP4+ platforms are now DT based why can't we just return from 
> >> here silently?
> >>
> > If we are unable to allocate the SRAM needed to work around I688 this is
> > a real error on platforms that expose this erratum, so silently bailing
> > out at this point may obscure a real issue.
> > 
> 
> SRAM is not allocated here - It's just check to understand do we need it or 
> not
> in case of multiplatform build where CONFIG_OMAP_INTERCONNECT_BARRIER will be 
> selected most
> probably.
> 
> And if "ti,omap4-mpu" was not found - it just means that this, particular, 
> platform
> is not affected by i688 errata.
> If someone misses corresponding node in DT - we can't do nothing :)
> 
Okay, so the above document says that AM43xx is affected by the erratum,
but the am4372.dtsi doesn't contain a "ti,omap4-mpu" node, so the
workaround will not be applied. If we silence the warning, we now have a
system that will be prone to data corruption without ever warning the
user about it. This is surely not what anyone wants.

Regards,
Lucas
-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
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 v02 01/15] dmaengine: core: Allow NULL mask pointer in __dma_device_satisfies_mask()

[Andy Shevchenko]

On Tue, Dec 1, 2015 at 11:47 AM, Peter Ujfalusi  wrote:
> On 11/30/2015 04:35 PM, Andy Shevchenko wrote:
>> On Mon, Nov 30, 2015 at 3:45 PM, Peter Ujfalusi  
>> wrote:
>>> Treat as true condition the case when the mask is NULL.
>>
>> What do you think about setting some default (all "on") mask when mask
>> is not supplied?
>
> Probably rephrasing the commit message to say that when the mask is NULL it
> means that the caller does not care about the capabilities of the dma device
> thus return with true in such a case.
>
> We could also drop this patch and in private_candidate() :
>
> -   if (!__dma_device_satisfies_mask(dev, mask)) {
> +   if (mask && !__dma_device_satisfies_mask(dev, mask)) {
> pr_debug("%s: wrong capabilities\n", __func__);
> return NULL;
> }

Between patch and above proposal I would choose the latter one.

>> I don't know for sure but there might be cases when you don't want
>> literally *any* channel to satisfy.
>
> Or set DMA_SLAVE only in dma_request_chan()? What happens if we have cases
> when we are able to request channel for memcpy via dma_request_chan()
> (dedicated memcpy channel/DMA engine?) in that case we will have the SLAVE
> set, but not MEMCPY, or any other variation we do not know yet?

Frankly, have no idea.

-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/7] ARM: mvebu: remove unused mach/gpio.h

[Gregory CLEMENT]

Hi Arnd,
 
 On mar., déc. 01 2015, Arnd Bergmann  wrote:

> This file was left over from a cleanup of asm/gpio.h and has
> not been used in a while. Let's just remove it now, so the
> arch/arm/mach-mvebu/include/ directory can also disappear.
>
> Signed-off-by: Arnd Bergmann 

Applied on mvebu/cleanup

Thanks,

Gregory
> ---
>  arch/arm/mach-mvebu/include/mach/gpio.h | 1 -
>  1 file changed, 1 deletion(-)
>  delete mode 100644 arch/arm/mach-mvebu/include/mach/gpio.h
>
> diff --git a/arch/arm/mach-mvebu/include/mach/gpio.h 
> b/arch/arm/mach-mvebu/include/mach/gpio.h
> deleted file mode 100644
> index 40a8c178f10d..
> --- a/arch/arm/mach-mvebu/include/mach/gpio.h
> +++ /dev/null
> @@ -1 +0,0 @@
> -/* empty */
> -- 
> 2.1.0.rc2
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 00/25] mtd: nand: refactor the NAND subsystem (part 1)

[Boris Brezillon]

Hello,

This huge series aims at clarifying the relationship between the mtd and
nand_chip structures and hiding NAND framework internals to NAND
controller drivers.

The first part of the series provide an mtd_to_nand() helper to hide the
way mtd and nand_chip are linked together.

The second part of the series embeds the mtd structure into the nand_chip
one so that NAND controller drivers don't have to bother allocating the
MTD device and linking it with the NAND chip.

The last part of the series hides accesses to the chip->priv field behind
two helper functions.

This allows removal of some of the boilerplate code done in all NAND
controller drivers, but most importantly, it unifies a bit the way NAND
chip structures are instantiated (even though we still have two different
kinds of drivers: those embedding the nand_chip struct into their private
nand chip representation, and those allocating two different structures
and linking them together with the chip->priv field).

As said in the title, this refactoring is only the first step. I plan to
rework the NAND controller / NAND chip separation for pretty much the same
reasons: clarifying the separation between the two concepts, and getting
rid of more boilerplate code in NAND controller drivers.

Stay tuned ;-).

Best Regards,

Boris

Changes since v1:
- dropped already applied patches
- fixed some typos
- manually fixed some modifications omitted by the coccinelle scripts
- manually reworked modifactions done by coccinelle scripts to improve
  readability and fix coding style issues

Boris Brezillon (25):
  ARM: nand: make use of mtd_to_nand() where appropriate
  blackfin: nand: make use of mtd_to_nand() where appropriate
  cris: nand: make use of mtd_to_nand() where appropriate
  mips: nand: make use of mtd_to_nand() where appropriate
  sh: nand: make use of mtd_to_nand() where appropriate
  mtd: nand: make use of mtd_to_nand() in NAND core code
  mtd: nand: make use of mtd_to_nand() in NAND drivers
  staging: mt29f_spinand: make use of mtd_to_nand()
  mtd: nand: embed an mtd_info structure into nand_chip
  mtd: nand: add nand_to_mtd() helper
  coccinelle: nand: detect and correct drivers embedding an mtd_info
object
  mtd: nand: use the mtd instance embedded in struct nand_chip
  mtd: nand: update the documentation to reflect framework changes
  staging: mt29f_spinand: use the mtd instance embedded in struct
nand_chip
  cris: nand: use the mtd instance embedded in struct nand_chip
  mtd: nand: update mtd_to_nand()
  mtd: nand: remove useless mtd->priv = chip assignments
  cris: nand: remove useless mtd->priv = chip assignments
  staging: mt29f_spinand: remove useless mtd->priv = chip assignment
  mtd: nand: simplify nand_dt_init() usage
  mtd: nand: kill the chip->flash_node field
  mtd: nand: add helpers to access ->priv
  ARM: make use of nand_set/get_controller_data() helpers
  mtd: nand: make use of nand_set/get_controller_data() helpers
  staging: mt29f_spinand: make use of nand_set/get_controller_data()
helpers

 Documentation/DocBook/mtdnand.tmpl |  31 +++---
 arch/arm/mach-ep93xx/snappercl15.c |   4 +-
 arch/arm/mach-ep93xx/ts72xx.c  |   4 +-
 arch/arm/mach-imx/mach-qong.c  |   2 +-
 arch/arm/mach-ixp4xx/ixdp425-setup.c   |   6 +-
 arch/arm/mach-omap1/board-nand.c   |   2 +-
 arch/arm/mach-orion5x/ts78xx-setup.c   |   6 +-
 arch/arm/mach-pxa/balloon3.c   |   2 +-
 arch/arm/mach-pxa/em-x270.c|   2 +-
 arch/arm/mach-pxa/palmtx.c |   2 +-
 arch/blackfin/mach-bf537/boards/stamp.c|   2 +-
 arch/blackfin/mach-bf561/boards/acvilon.c  |   2 +-
 arch/cris/arch-v32/drivers/mach-a3/nandflash.c |   8 +-
 arch/cris/arch-v32/drivers/mach-fs/nandflash.c |   8 +-
 arch/mips/alchemy/devboards/db1200.c   |   2 +-
 arch/mips/alchemy/devboards/db1300.c   |   2 +-
 arch/mips/alchemy/devboards/db1550.c   |   2 +-
 arch/mips/pnx833x/common/platform.c|   2 +-
 arch/mips/rb532/devices.c  |   2 +-
 arch/sh/boards/mach-migor/setup.c  |   2 +-
 drivers/mtd/nand/ams-delta.c   |  26 ++---
 drivers/mtd/nand/atmel_nand.c  | 118 ++--
 drivers/mtd/nand/au1550nd.c|  40 +++
 drivers/mtd/nand/bcm47xxnflash/bcm47xxnflash.h |   1 -
 drivers/mtd/nand/bcm47xxnflash/main.c  |   9 +-
 drivers/mtd/nand/bcm47xxnflash/ops_bcm4706.c   |  34 +++---
 drivers/mtd/nand/bf5xx_nand.c  |  25 ++---
 drivers/mtd/nand/brcmnand/brcmnand.c   |  54 +
 drivers/mtd/nand/cafe_nand.c   |  51 +
 drivers/mtd/nand/cmx270_nand.c |  20 ++--
 drivers/mtd/nand/cs553x_nand.c |  30 +++--
 drivers/mtd/nand/davinci_nand.c|  37 ---
 drivers/mtd/nand/denali.c  |  67 ++-
 

Re: [PATCH v2 12/25] mtd: nand: use the mtd instance embedded in struct nand_chip

[kbuild test robot]

Hi Boris,

[auto build test ERROR on next-20151127]
[cannot apply to mtd/master v4.4-rc3 v4.4-rc2 v4.4-rc1 v4.4-rc3]

url:
https://github.com/0day-ci/linux/commits/Boris-Brezillon/mtd-nand-refactor-the-NAND-subsystem-part-1/20151201-190822
config: arm-imx_v6_v7_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/mtd/nand/gpmi-nand/gpmi-nand.c: In function 
'set_geometry_by_ecc_info':
>> drivers/mtd/nand/gpmi-nand/gpmi-nand.c:142:39: error: 'mtd' undeclared 
>> (first use in this function)
 struct nand_chip *chip = mtd_to_nand(mtd);
  ^
   drivers/mtd/nand/gpmi-nand/gpmi-nand.c:142:39: note: each undeclared 
identifier is reported only once for each function it appears in
   drivers/mtd/nand/gpmi-nand/gpmi-nand.c: In function 'gpmi_init_last':
   drivers/mtd/nand/gpmi-nand/gpmi-nand.c:1840:39: error: 'mtd' undeclared 
(first use in this function)
 struct nand_chip *chip = mtd_to_nand(mtd);
  ^
   drivers/mtd/nand/gpmi-nand/gpmi-nand.c:1841:19: warning: unused variable 
'mtd' [-Wunused-variable]
 struct mtd_info *mtd = nand_to_mtd(chip);
  ^

vim +/mtd +142 drivers/mtd/nand/gpmi-nand/gpmi-nand.c

2febcdf84 Huang Shijie2013-05-17  136   *
2febcdf84 Huang Shijie2013-05-17  137   * We may have available oob space 
in this case.
2febcdf84 Huang Shijie2013-05-17  138   */
2febcdf84 Huang Shijie2013-05-17  139  static bool 
set_geometry_by_ecc_info(struct gpmi_nand_data *this)
2febcdf84 Huang Shijie2013-05-17  140  {
2febcdf84 Huang Shijie2013-05-17  141   struct bch_geometry *geo = 
>bch_geometry;
6bdedcfa5 Boris Brezillon 2015-12-01 @142   struct nand_chip *chip = 
mtd_to_nand(mtd);
4864cfd67 Boris Brezillon 2015-12-01  143   struct mtd_info *mtd = 
nand_to_mtd(chip);
2febcdf84 Huang Shijie2013-05-17  144   struct nand_oobfree *of = 
gpmi_hw_ecclayout.oobfree;
2febcdf84 Huang Shijie2013-05-17  145   unsigned int 
block_mark_bit_offset;

:: The code at line 142 was first introduced by commit
:: 6bdedcfa57b52f471682054a599855677b1b132c mtd: nand: make use of 
mtd_to_nand() in NAND drivers

:: TO: Boris Brezillon <boris.brezil...@free-electrons.com>
:: CC: 0day robot <fengguang...@intel.com>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH v2 23/25] ARM: make use of nand_set/get_controller_data() helpers

[Boris Brezillon]

New helpers have been added to avoid directly accessing chip->field. Use
them where appropriate.

Signed-off-by: Boris Brezillon 
---
 arch/arm/mach-ixp4xx/ixdp425-setup.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c 
b/arch/arm/mach-ixp4xx/ixdp425-setup.c
index 333b0f9..508c2d7 100644
--- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
+++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
@@ -77,7 +77,7 @@ static void
 ixdp425_flash_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
 {
struct nand_chip *this = mtd_to_nand(mtd);
-   int offset = (int)this->priv;
+   int offset = (int)nand_get_controller_data(this);
 
if (ctrl & NAND_CTRL_CHANGE) {
if (ctrl & NAND_NCE) {
@@ -88,7 +88,7 @@ ixdp425_flash_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, 
unsigned int ctrl)
 
offset = (ctrl & NAND_CLE) ? IXDP425_NAND_CMD_BYTE : 0;
offset |= (ctrl & NAND_ALE) ? IXDP425_NAND_ADDR_BYTE : 0;
-   this->priv = (void *)offset;
+   nand_set_controller_data(this, (void *)offset);
}
 
if (cmd != NAND_CMD_NONE)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 25/25] staging: mt29f_spinand: make use of nand_set/get_controller_data() helpers

[Boris Brezillon]

New helpers have been added to avoid directly accessing chip->field. Use
them where appropriate.

Signed-off-by: Boris Brezillon 
---
 drivers/staging/mt29f_spinand/mt29f_spinand.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c 
b/drivers/staging/mt29f_spinand/mt29f_spinand.c
index b7d429d..5b3027a 100644
--- a/drivers/staging/mt29f_spinand/mt29f_spinand.c
+++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c
@@ -32,7 +32,7 @@
 static inline struct spinand_state *mtd_to_state(struct mtd_info *mtd)
 {
struct nand_chip *chip = mtd_to_nand(mtd);
-   struct spinand_info *info = (struct spinand_info *)chip->priv;
+   struct spinand_info *info = (struct spinand_info 
*)nand_get_controller_data(chip);
struct spinand_state *state = (struct spinand_state *)info->priv;
 
return state;
@@ -633,7 +633,7 @@ static int spinand_read_page_hwecc(struct mtd_info *mtd, 
struct nand_chip *chip,
u8 *p = buf;
int eccsize = chip->ecc.size;
int eccsteps = chip->ecc.steps;
-   struct spinand_info *info = (struct spinand_info *)chip->priv;
+   struct spinand_info *info = (struct spinand_info 
*)nand_get_controller_data(chip);
 
enable_read_hw_ecc = 1;
 
@@ -679,7 +679,7 @@ static u8 spinand_read_byte(struct mtd_info *mtd)
 
 static int spinand_wait(struct mtd_info *mtd, struct nand_chip *chip)
 {
-   struct spinand_info *info = (struct spinand_info *)chip->priv;
+   struct spinand_info *info = (struct spinand_info 
*)nand_get_controller_data(chip);
 
unsigned long timeo = jiffies;
int retval, state = chip->state;
@@ -745,7 +745,7 @@ static void spinand_cmdfunc(struct mtd_info *mtd, unsigned 
int command,
int column, int page)
 {
struct nand_chip *chip = mtd_to_nand(mtd);
-   struct spinand_info *info = (struct spinand_info *)chip->priv;
+   struct spinand_info *info = (struct spinand_info 
*)nand_get_controller_data(chip);
struct spinand_state *state = (struct spinand_state *)info->priv;
 
switch (command) {
@@ -894,7 +894,7 @@ static int spinand_probe(struct spi_device *spi_nand)
 #endif
 
nand_set_flash_node(chip, spi_nand->dev.of_node);
-   chip->priv  = info;
+   nand_set_controller_data(chip, info);
chip->read_buf  = spinand_read_buf;
chip->write_buf = spinand_write_buf;
chip->read_byte = spinand_read_byte;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 19/25] staging: mt29f_spinand: remove useless mtd->priv = chip assignment

[Boris Brezillon]

mtd_to_nand() now uses the container_of() approach to transform an
mtd_info pointer into a nand_chip one. Drop useless mtd->priv
assignments from NAND controller drivers.

Signed-off-by: Boris Brezillon 
---
Patch generated with the following coccinelle script:

---8<
virtual patch

@@
struct mtd_info m;
struct mtd_info *mp;
struct nand_chip *c;
@@
(
-(m).priv = c;
|
-(mp)->priv = c;
|
-(mp)->priv = (void *)c;
)
---8<
---
 drivers/staging/mt29f_spinand/mt29f_spinand.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c 
b/drivers/staging/mt29f_spinand/mt29f_spinand.c
index 8171b74..b7d429d 100644
--- a/drivers/staging/mt29f_spinand/mt29f_spinand.c
+++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c
@@ -907,7 +907,6 @@ static int spinand_probe(struct spi_device *spi_nand)
 
dev_set_drvdata(_nand->dev, mtd);
 
-   mtd->priv = chip;
mtd->dev.parent = _nand->dev;
mtd->oobsize = 64;
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 15/25] cris: nand: use the mtd instance embedded in struct nand_chip

[Boris Brezillon]

struct nand_chip now embeds an mtd device. Patch all drivers to make use
of this mtd instance instead of using the instance embedded in their
private struct or dynamically allocated.

Signed-off-by: Boris Brezillon 
---
Most of those changes were generated with the coccinelle script added
in commit c671312 "coccinelle: nand: detect and correct drivers embedding
an mtd_info object"
---
 arch/cris/arch-v32/drivers/mach-a3/nandflash.c | 3 +--
 arch/cris/arch-v32/drivers/mach-fs/nandflash.c | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/cris/arch-v32/drivers/mach-a3/nandflash.c 
b/arch/cris/arch-v32/drivers/mach-a3/nandflash.c
index db953cf..ee74e45 100644
--- a/arch/cris/arch-v32/drivers/mach-a3/nandflash.c
+++ b/arch/cris/arch-v32/drivers/mach-a3/nandflash.c
@@ -36,7 +36,6 @@
 #define CE_BIT 12
 
 struct mtd_info_wrapper {
-   struct mtd_info info;
struct nand_chip chip;
 };
 
@@ -148,7 +147,7 @@ struct mtd_info *__init crisv32_nand_flash_probe(void)
 
/* Get pointer to private data */
this = >chip;
-   crisv32_mtd = >info;
+   crisv32_mtd = nand_to_mtd(this);
 
/* Link the private data with the MTD structure */
crisv32_mtd->priv = this;
diff --git a/arch/cris/arch-v32/drivers/mach-fs/nandflash.c 
b/arch/cris/arch-v32/drivers/mach-fs/nandflash.c
index 22a6467..5626297 100644
--- a/arch/cris/arch-v32/drivers/mach-fs/nandflash.c
+++ b/arch/cris/arch-v32/drivers/mach-fs/nandflash.c
@@ -31,7 +31,6 @@
 #define BY_BIT 7
 
 struct mtd_info_wrapper {
-   struct mtd_info info;
struct nand_chip chip;
 };
 
@@ -129,7 +128,7 @@ struct mtd_info *__init crisv32_nand_flash_probe(void)
 
/* Get pointer to private data */
this = >chip;
-   crisv32_mtd = >info;
+   crisv32_mtd = nand_to_mtd(this);
 
pa_oe.oe |= 1 << CE_BIT;
pa_oe.oe |= 1 << ALE_BIT;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 18/25] cris: nand: remove useless mtd->priv = chip assignments

[Boris Brezillon]

mtd_to_nand() now uses the container_of() approach to transform an
mtd_info pointer into a nand_chip one. Drop useless mtd->priv
assignments from NAND controller drivers.

Signed-off-by: Boris Brezillon 
---
Patch generated with the following coccinelle script:

---8<
virtual patch

@@
struct mtd_info m;
struct mtd_info *mp;
struct nand_chip *c;
@@
(
-(m).priv = c;
|
-(mp)->priv = c;
|
-(mp)->priv = (void *)c;
)
---8<
---
 arch/cris/arch-v32/drivers/mach-a3/nandflash.c | 3 ---
 arch/cris/arch-v32/drivers/mach-fs/nandflash.c | 3 ---
 2 files changed, 6 deletions(-)

diff --git a/arch/cris/arch-v32/drivers/mach-a3/nandflash.c 
b/arch/cris/arch-v32/drivers/mach-a3/nandflash.c
index ee74e45..5aa3f51 100644
--- a/arch/cris/arch-v32/drivers/mach-a3/nandflash.c
+++ b/arch/cris/arch-v32/drivers/mach-a3/nandflash.c
@@ -149,9 +149,6 @@ struct mtd_info *__init crisv32_nand_flash_probe(void)
this = >chip;
crisv32_mtd = nand_to_mtd(this);
 
-   /* Link the private data with the MTD structure */
-   crisv32_mtd->priv = this;
-
/* Set address of NAND IO lines */
this->IO_ADDR_R = read_cs;
this->IO_ADDR_W = write_cs;
diff --git a/arch/cris/arch-v32/drivers/mach-fs/nandflash.c 
b/arch/cris/arch-v32/drivers/mach-fs/nandflash.c
index 5626297..a7c17b0 100644
--- a/arch/cris/arch-v32/drivers/mach-fs/nandflash.c
+++ b/arch/cris/arch-v32/drivers/mach-fs/nandflash.c
@@ -140,9 +140,6 @@ struct mtd_info *__init crisv32_nand_flash_probe(void)
bif_cfg.gated_csp1 = regk_bif_core_wr;
REG_WR(bif_core, regi_bif_core, rw_grp3_cfg, bif_cfg);
 
-   /* Link the private data with the MTD structure */
-   crisv32_mtd->priv = this;
-
/* Set address of NAND IO lines */
this->IO_ADDR_R = read_cs;
this->IO_ADDR_W = write_cs;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 03/25] cris: nand: make use of mtd_to_nand() where appropriate

[Boris Brezillon]

mtd_to_nand() was recently introduced to avoid direct accesses to the
mtd->priv field. Update all CRIS specific implementations to use this
helper.

Signed-off-by: Boris Brezillon 
---
 arch/cris/arch-v32/drivers/mach-a3/nandflash.c | 2 +-
 arch/cris/arch-v32/drivers/mach-fs/nandflash.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/cris/arch-v32/drivers/mach-a3/nandflash.c 
b/arch/cris/arch-v32/drivers/mach-a3/nandflash.c
index 7fb5212..db953cf 100644
--- a/arch/cris/arch-v32/drivers/mach-a3/nandflash.c
+++ b/arch/cris/arch-v32/drivers/mach-a3/nandflash.c
@@ -52,7 +52,7 @@ static void crisv32_hwcontrol(struct mtd_info *mtd, int cmd,
 {
unsigned long flags;
reg_pio_rw_dout dout;
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
 
local_irq_save(flags);
 
diff --git a/arch/cris/arch-v32/drivers/mach-fs/nandflash.c 
b/arch/cris/arch-v32/drivers/mach-fs/nandflash.c
index e032384..22a6467 100644
--- a/arch/cris/arch-v32/drivers/mach-fs/nandflash.c
+++ b/arch/cris/arch-v32/drivers/mach-fs/nandflash.c
@@ -51,7 +51,7 @@ static void crisv32_hwcontrol(struct mtd_info *mtd, int cmd,
 {
unsigned long flags;
reg_gio_rw_pa_dout dout;
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
 
local_irq_save(flags);
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 05/25] sh: nand: make use of mtd_to_nand() where appropriate

[Boris Brezillon]

mtd_to_nand() was recently introduced to avoid direct accesses to the
mtd->priv field. Update all SH specific implementations to use this
helper.

Signed-off-by: Boris Brezillon 
---
 arch/sh/boards/mach-migor/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sh/boards/mach-migor/setup.c 
b/arch/sh/boards/mach-migor/setup.c
index 29b7c0d..8673f91 100644
--- a/arch/sh/boards/mach-migor/setup.c
+++ b/arch/sh/boards/mach-migor/setup.c
@@ -167,7 +167,7 @@ static struct mtd_partition migor_nand_flash_partitions[] = 
{
 static void migor_nand_flash_cmd_ctl(struct mtd_info *mtd, int cmd,
 unsigned int ctrl)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
 
if (cmd == NAND_CMD_NONE)
return;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 04/25] mips: nand: make use of mtd_to_nand() where appropriate

[Boris Brezillon]

mtd_to_nand() was recently introduced to avoid direct accesses to the
mtd->priv field. Update all MIPS specific implementations to use this
helper.

Signed-off-by: Boris Brezillon 
---
 arch/mips/alchemy/devboards/db1200.c | 2 +-
 arch/mips/alchemy/devboards/db1300.c | 2 +-
 arch/mips/alchemy/devboards/db1550.c | 2 +-
 arch/mips/pnx833x/common/platform.c  | 2 +-
 arch/mips/rb532/devices.c| 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/mips/alchemy/devboards/db1200.c 
b/arch/mips/alchemy/devboards/db1200.c
index 8c13675..992442a 100644
--- a/arch/mips/alchemy/devboards/db1200.c
+++ b/arch/mips/alchemy/devboards/db1200.c
@@ -200,7 +200,7 @@ static struct i2c_board_info db1200_i2c_devs[] __initdata = 
{
 static void au1200_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
 unsigned int ctrl)
 {
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
unsigned long ioaddr = (unsigned long)this->IO_ADDR_W;
 
ioaddr &= 0xff00;
diff --git a/arch/mips/alchemy/devboards/db1300.c 
b/arch/mips/alchemy/devboards/db1300.c
index b580770..d3c087f 100644
--- a/arch/mips/alchemy/devboards/db1300.c
+++ b/arch/mips/alchemy/devboards/db1300.c
@@ -150,7 +150,7 @@ static void __init db1300_gpio_config(void)
 static void au1300_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
 unsigned int ctrl)
 {
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
unsigned long ioaddr = (unsigned long)this->IO_ADDR_W;
 
ioaddr &= 0xff00;
diff --git a/arch/mips/alchemy/devboards/db1550.c 
b/arch/mips/alchemy/devboards/db1550.c
index 5740bcf..b518f02 100644
--- a/arch/mips/alchemy/devboards/db1550.c
+++ b/arch/mips/alchemy/devboards/db1550.c
@@ -128,7 +128,7 @@ static struct i2c_board_info db1550_i2c_devs[] __initdata = 
{
 static void au1550_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
 unsigned int ctrl)
 {
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
unsigned long ioaddr = (unsigned long)this->IO_ADDR_W;
 
ioaddr &= 0xff00;
diff --git a/arch/mips/pnx833x/common/platform.c 
b/arch/mips/pnx833x/common/platform.c
index b4b774b..3cd3577 100644
--- a/arch/mips/pnx833x/common/platform.c
+++ b/arch/mips/pnx833x/common/platform.c
@@ -180,7 +180,7 @@ static struct platform_device pnx833x_sata_device = {
 static void
 pnx833x_flash_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
 {
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
unsigned long nandaddr = (unsigned long)this->IO_ADDR_W;
 
if (cmd == NAND_CMD_NONE)
diff --git a/arch/mips/rb532/devices.c b/arch/mips/rb532/devices.c
index 9bd7a2d..0966adc 100644
--- a/arch/mips/rb532/devices.c
+++ b/arch/mips/rb532/devices.c
@@ -148,7 +148,7 @@ static int rb532_dev_ready(struct mtd_info *mtd)
 
 static void rb532_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
unsigned char orbits, nandbits;
 
if (ctrl & NAND_CTRL_CHANGE) {
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 02/25] blackfin: nand: make use of mtd_to_nand() where appropriate

[Boris Brezillon]

mtd_to_nand() was recently introduced to avoid direct accesses to the
mtd->priv field. Update all blackfin specific implementations to use
this helper.

Signed-off-by: Boris Brezillon 
---
 arch/blackfin/mach-bf537/boards/stamp.c   | 2 +-
 arch/blackfin/mach-bf561/boards/acvilon.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/blackfin/mach-bf537/boards/stamp.c 
b/arch/blackfin/mach-bf537/boards/stamp.c
index 88a19fc..c181543 100644
--- a/arch/blackfin/mach-bf537/boards/stamp.c
+++ b/arch/blackfin/mach-bf537/boards/stamp.c
@@ -404,7 +404,7 @@ static struct mtd_partition bfin_plat_nand_partitions[] = {
 #define BFIN_NAND_PLAT_ALE 1
 static void bfin_plat_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned 
int ctrl)
 {
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
 
if (cmd == NAND_CMD_NONE)
return;
diff --git a/arch/blackfin/mach-bf561/boards/acvilon.c 
b/arch/blackfin/mach-bf561/boards/acvilon.c
index 6ab9515..37f8f25 100644
--- a/arch/blackfin/mach-bf561/boards/acvilon.c
+++ b/arch/blackfin/mach-bf561/boards/acvilon.c
@@ -267,7 +267,7 @@ static struct mtd_partition bfin_plat_nand_partitions[] = {
 static void bfin_plat_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
unsigned int ctrl)
 {
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
 
if (cmd == NAND_CMD_NONE)
return;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 11/25] coccinelle: nand: detect and correct drivers embedding an mtd_info object

[Julia Lawall]

On Tue, 1 Dec 2015, Boris Brezillon wrote:

> Add nand-priv-no-mtd.cocci to detect and correct NAND controller drivers
> directly embedding an mtd_info struct in their private struct.
>
> Signed-off-by: Boris Brezillon 
> Cc: Julia Lawall 
> ---
> Hi Julia,
>
> Not sure this is the correct way to detect and fix offending drivers,
> but I get some warnings when launching coccicheck in org or report mode:
>
> "warning: fix2: inherited metavariable __chipfield not used in the -, +,
> or context code"
>
> Note that I don't get those warnings when running in patch mode.
>
> Any idea (feel free to propose a better solution to detect and fix those
> offending drivers)?

Hi,

Is this code generated with sgen?  If so, could you send me the original
semantic patch?

Another thing that is immediately apparent is that you have <... ...> on
the outside of one of the rules.  This should never be needed.

The warning suggests that your org and report versions are not doing as
much as the patch version.  If you have used sgen to generate the semantic
patch then that would be strange.  If you have hand written the whole
thing, then maybe you could simplify it to just do the patch version, and
then I can check it and run sgen on it to make a complete version.

julia

>
> Best Regards,
>
> Boris
> ---
>  scripts/coccinelle/api/nand-priv-no-mtd.cocci | 91 
> +++
>  1 file changed, 91 insertions(+)
>  create mode 100644 scripts/coccinelle/api/nand-priv-no-mtd.cocci
>
> diff --git a/scripts/coccinelle/api/nand-priv-no-mtd.cocci 
> b/scripts/coccinelle/api/nand-priv-no-mtd.cocci
> new file mode 100644
> index 000..b2c0c22
> --- /dev/null
> +++ b/scripts/coccinelle/api/nand-priv-no-mtd.cocci
> @@ -0,0 +1,91 @@
> +/// Fix NAND controller drivers declaring their own mtd_info struct instead
> +/// of the one provided in struct nand_chip.
> +///
> +// Confidence: Low
> +// Copyright: (C) 2015 Boris Brezillon GPL v2.
> +
> +virtual patch
> +virtual context
> +virtual org
> +virtual report
> +
> +@match1@
> +identifier __chipfield, __mtdfield;
> +type __type;
> +@@
> +(
> + __type {
> + ...
> + struct nand_chip __chipfield;
> + ...
> + struct mtd_info __mtdfield;
> + ...
> + };
> +|
> + __type {
> + ...
> + struct mtd_info __mtdfield;
> + ...
> + struct nand_chip __chipfield;
> + ...
> + };
> +)
> +
> +@fix1 depends on match1 && patch && !context && !org && !report@
> +identifier match1.__mtdfield;
> +type match1.__type;
> +@@
> + __type {
> + ...
> +-struct mtd_info __mtdfield;
> + ...
> + };
> +
> +@fix2 depends on match1 && patch && !context && !org && !report@
> +identifier match1.__chipfield, match1.__mtdfield;
> +identifier __subfield;
> +type match1.__type;
> +__type *__priv;
> +@@
> +<...
> +(
> +-__priv->__mtdfield.__subfield
> ++nand_to_mtd(&__priv->__chipfield)->__subfield
> +|
> +-&(__priv->__mtdfield)
> ++nand_to_mtd(&__priv->__chipfield)
> +)
> +...>
> +
> +// 
> 
> +
> +@fix1_context depends on match1 && !patch && (context || org || report)@
> +identifier match1.__mtdfield;
> +type match1.__type;
> +position j0;
> +@@
> +
> + __type {
> + ...
> +*struct mtd_info __mtdfield@j0;
> + ...
> + };
> +
> +// 
> 
> +
> +@script:python fix1_org depends on org@
> +j0 << fix1_context.j0;
> +@@
> +
> +msg = "struct nand_chip already embeds an mtd_info object (use 
> nand_to_mtd())."
> +coccilib.org.print_todo(j0[0], msg)
> +
> +// 
> 
> +
> +@script:python fix1_report depends on report@
> +j0 << fix1_context.j0;
> +@@
> +
> +msg = "struct nand_chip already embeds an mtd_info object (use 
> nand_to_mtd())."
> +coccilib.report.print_report(j0[0], msg)
> +
> --
> 2.1.4
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 17/25] mtd: nand: remove useless mtd->priv = chip assignments

[Boris Brezillon]

mtd_to_nand() now uses the container_of() approach to transform an
mtd_info pointer into a nand_chip one. Drop useless mtd->priv
assignments from NAND controller drivers.

Signed-off-by: Boris Brezillon 
---
Patch generated with the following coccinelle script:

---8<
virtual patch

@@
struct mtd_info m;
struct mtd_info *mp;
struct nand_chip *c;
@@
(
-(m).priv = c;
|
-(mp)->priv = c;
|
-(mp)->priv = (void *)c;
)
---8<
---
 drivers/mtd/nand/ams-delta.c   | 3 ---
 drivers/mtd/nand/atmel_nand.c  | 1 -
 drivers/mtd/nand/au1550nd.c| 1 -
 drivers/mtd/nand/bcm47xxnflash/main.c  | 1 -
 drivers/mtd/nand/bf5xx_nand.c  | 1 -
 drivers/mtd/nand/brcmnand/brcmnand.c   | 1 -
 drivers/mtd/nand/cafe_nand.c   | 1 -
 drivers/mtd/nand/cmx270_nand.c | 1 -
 drivers/mtd/nand/cs553x_nand.c | 1 -
 drivers/mtd/nand/davinci_nand.c| 1 -
 drivers/mtd/nand/denali.c  | 1 -
 drivers/mtd/nand/diskonchip.c  | 1 -
 drivers/mtd/nand/docg4.c   | 1 -
 drivers/mtd/nand/fsl_elbc_nand.c   | 1 -
 drivers/mtd/nand/fsl_ifc_nand.c| 1 -
 drivers/mtd/nand/fsl_upm.c | 1 -
 drivers/mtd/nand/fsmc_nand.c   | 1 -
 drivers/mtd/nand/gpio.c| 1 -
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 1 -
 drivers/mtd/nand/hisi504_nand.c| 1 -
 drivers/mtd/nand/jz4740_nand.c | 1 -
 drivers/mtd/nand/lpc32xx_mlc.c | 1 -
 drivers/mtd/nand/lpc32xx_slc.c | 1 -
 drivers/mtd/nand/mpc5121_nfc.c | 1 -
 drivers/mtd/nand/mxc_nand.c| 1 -
 drivers/mtd/nand/nandsim.c | 1 -
 drivers/mtd/nand/ndfc.c| 1 -
 drivers/mtd/nand/nuc900_nand.c | 1 -
 drivers/mtd/nand/omap2.c   | 1 -
 drivers/mtd/nand/orion_nand.c  | 1 -
 drivers/mtd/nand/pasemi_nand.c | 1 -
 drivers/mtd/nand/plat_nand.c   | 1 -
 drivers/mtd/nand/pxa3xx_nand.c | 1 -
 drivers/mtd/nand/r852.c| 1 -
 drivers/mtd/nand/s3c2410.c | 1 -
 drivers/mtd/nand/sh_flctl.c| 1 -
 drivers/mtd/nand/sharpsl.c | 1 -
 drivers/mtd/nand/socrates_nand.c   | 1 -
 drivers/mtd/nand/sunxi_nand.c  | 1 -
 drivers/mtd/nand/tmio_nand.c   | 1 -
 drivers/mtd/nand/txx9ndfmc.c   | 2 --
 drivers/mtd/nand/vf610_nfc.c   | 1 -
 42 files changed, 45 deletions(-)

diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 0f638c6..1a18938 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -193,9 +193,6 @@ static int ams_delta_init(struct platform_device *pdev)
ams_delta_mtd = nand_to_mtd(this);
ams_delta_mtd->owner = THIS_MODULE;
 
-   /* Link the private data with the MTD structure */
-   ams_delta_mtd->priv = this;
-
/*
 * Don't try to request the memory region from here,
 * it should have been already requested from the
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 9ba2831..18c4e14 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -2128,7 +2128,6 @@ static int atmel_nand_probe(struct platform_device *pdev)
}
 
nand_chip->priv = host; /* link the private data structures */
-   mtd->priv = nand_chip;
mtd->dev.parent = >dev;
 
/* Set address of NAND IO lines */
diff --git a/drivers/mtd/nand/au1550nd.c b/drivers/mtd/nand/au1550nd.c
index 280e5b6..341ea49 100644
--- a/drivers/mtd/nand/au1550nd.c
+++ b/drivers/mtd/nand/au1550nd.c
@@ -441,7 +441,6 @@ static int au1550nd_probe(struct platform_device *pdev)
 
this = >chip;
mtd = nand_to_mtd(this);
-   mtd->priv = this;
mtd->dev.parent = >dev;
 
/* figure out which CS# r->start belongs to */
diff --git a/drivers/mtd/nand/bcm47xxnflash/main.c 
b/drivers/mtd/nand/bcm47xxnflash/main.c
index 4711ca2b..0f0a798 100644
--- a/drivers/mtd/nand/bcm47xxnflash/main.c
+++ b/drivers/mtd/nand/bcm47xxnflash/main.c
@@ -37,7 +37,6 @@ static int bcm47xxnflash_probe(struct platform_device *pdev)
b47n->nand_chip.priv = b47n;
mtd = nand_to_mtd(>nand_chip);
mtd->dev.parent = >dev;
-   mtd->priv = >nand_chip; /* Required */
b47n->cc = container_of(nflash, struct bcma_drv_cc, nflash);
 
if (b47n->cc->core->bus->chipinfo.id == BCMA_CHIP_ID_BCM4706) {
diff --git a/drivers/mtd/nand/bf5xx_nand.c b/drivers/mtd/nand/bf5xx_nand.c
index 928d599..9514e13 100644
--- a/drivers/mtd/nand/bf5xx_nand.c
+++ b/drivers/mtd/nand/bf5xx_nand.c
@@ -782,7 +782,6 @@ static int bf5xx_nand_probe(struct platform_device *pdev)
chip->chip_delay   = 0;
 
/* initialise mtd info data struct */
-   mtd->priv   = chip;
mtd->dev.parent = >dev;
 
/* initialise the hardware */
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
b/drivers/mtd/nand/brcmnand/brcmnand.c

[PATCH v2 13/25] mtd: nand: update the documentation to reflect framework changes

[Boris Brezillon]

The MTD device is now directly embedded in the nand_chip struct. Update the
mtdnand documentation to mention this aspect and fix the different
examples.

Signed-off-by: Boris Brezillon 
---
 Documentation/DocBook/mtdnand.tmpl | 31 +++
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/Documentation/DocBook/mtdnand.tmpl 
b/Documentation/DocBook/mtdnand.tmpl
index 403a7ab..b442921 100644
--- a/Documentation/DocBook/mtdnand.tmpl
+++ b/Documentation/DocBook/mtdnand.tmpl
@@ -162,12 +162,15 @@

Basic defines

-   At least you have to provide a mtd structure and
-   a storage for the ioremap'ed chip address.
-   You can allocate the mtd structure using kmalloc
-   or you can allocate it statically.
-   In case of static allocation you have to allocate
-   a nand_chip structure too.
+   At least you have to provide a nand_chip structure
+   and a storage for the ioremap'ed chip address.
+   You can allocate the nand_chip structure using
+   kmalloc or you can allocate it statically.
+   The NAND chip structure embeds an mtd structure
+   which will be registered to the MTD subsystem.
+   You can extract a pointer to the mtd structure
+   from a nand_chip pointer using the nand_to_mtd()
+   helper.


Kmalloc based example
@@ -180,7 +183,6 @@ static void __iomem *baseaddr;
Static example


-static struct mtd_info board_mtd;
 static struct nand_chip board_chip;
 static void __iomem *baseaddr;

@@ -274,13 +276,15 @@ static int __init board_init (void)
int err = 0;
 
/* Allocate memory for MTD device structure and private data */
-   board_mtd = kzalloc(sizeof(struct mtd_info) + sizeof(struct nand_chip), 
GFP_KERNEL);
-   if (!board_mtd) {
+   this = kzalloc(sizeof(struct nand_chip), GFP_KERNEL);
+   if (!this) {
printk ("Unable to allocate NAND MTD device structure.\n");
err = -ENOMEM;
goto out;
}
 
+   board_mtd = nand_to_mtd(this);
+
/* map physical address */
baseaddr = ioremap(CHIP_PHYSICAL_ADDRESS, 1024);
if (!baseaddr) {
@@ -289,11 +293,6 @@ static int __init board_init (void)
goto out_mtd;
}
 
-   /* Get pointer to private data */
-   this = (struct nand_chip *) ();
-   /* Link the private data with the MTD structure */
-   board_mtd->priv = this;
-
/* Set address of NAND IO lines */
this->IO_ADDR_R = baseaddr;
this->IO_ADDR_W = baseaddr;
@@ -317,7 +316,7 @@ static int __init board_init (void)
 out_ior:
iounmap(baseaddr);
 out_mtd:
-   kfree (board_mtd);
+   kfree (this);
 out:
return err;
 }
@@ -343,7 +342,7 @@ static void __exit board_cleanup (void)
iounmap(baseaddr);

/* Free the MTD device structure */
-   kfree (board_mtd);
+   kfree (mtd_to_nand(board_mtd));
 }
 module_exit(board_cleanup);
 #endif
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 10/25] mtd: nand: add nand_to_mtd() helper

[Boris Brezillon]

Add a new helper to retrieve the MTD device attached to a NAND chip.

Signed-off-by: Boris Brezillon 
---
 include/linux/mtd/nand.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index c4e39ff..8ec071e 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -737,6 +737,11 @@ static inline struct nand_chip *mtd_to_nand(struct 
mtd_info *mtd)
return mtd->priv;
 }
 
+static inline struct mtd_info *nand_to_mtd(struct nand_chip *chip)
+{
+   return >mtd;
+}
+
 /*
  * NAND Flash Manufacturer ID Codes
  */
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 09/25] mtd: nand: embed an mtd_info structure into nand_chip

[Boris Brezillon]

Currently all NAND controller drivers are providing both the mtd_info and
nand_chip struct and then let the NAND subsystem to initialize a few
things before registering the mtd instance to the MTD layer.
Embed an mtd_info field into nand_chip to add some consistency to all NAND
controller drivers.
This change will also help factorizing boilerplate code copied in all NAND
drivers.

Signed-off-by: Boris Brezillon 
---
 include/linux/mtd/nand.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 056d165..c4e39ff 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -540,6 +540,7 @@ struct nand_buffers {
 
 /**
  * struct nand_chip - NAND Private Flash Chip Data
+ * @mtd:   MTD device registered to the MTD framework
  * @IO_ADDR_R: [BOARDSPECIFIC] address to read the 8 I/O lines of the
  * flash device
  * @IO_ADDR_W: [BOARDSPECIFIC] address to write the 8 I/O lines of the
@@ -640,6 +641,7 @@ struct nand_buffers {
  */
 
 struct nand_chip {
+   struct mtd_info mtd;
void __iomem *IO_ADDR_R;
void __iomem *IO_ADDR_W;
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html