Re: [PATCH] ARM: dts: dra7-evm: Fix NAND GPMC timings (for 3.17)

[Roger Quadros]

Hi Tony,

This is needed for 3.17 otherwise NAND is broken on dra7-evm. Thanks.

cheers,
-roger

On 09/05/2014 03:04 PM, Roger Quadros wrote:
 The nand timings were scaled down by 2 to account for
 the 2x rate returned by clk_get_rate(gpmc_fclk).
 
 As the clock data got fixed by [1], revert back to actual
 timings (i.e. scale them up by 2).
 
 Without this NAND doesn't work on dra7-evm.
 
 [1] - commit dd94324b983afe114ba9e7ee3649313b451f63ce
 ARM: dts: dra7xx-clocks: Fix the l3 and l4 clock rates
 
 Fixes: ff66a3c86e00 (ARM: dts: dra7: add support for parallel NAND flash)
 Cc: sta...@vger.kernel.org[3.16]
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  arch/arm/boot/dts/dra7-evm.dts | 27 ---
  1 file changed, 12 insertions(+), 15 deletions(-)
 
 diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
 index 990ee6a..a120d8f 100644
 --- a/arch/arm/boot/dts/dra7-evm.dts
 +++ b/arch/arm/boot/dts/dra7-evm.dts
 @@ -427,22 +427,19 @@
   gpmc,device-width = 2;
   gpmc,sync-clk-ps = 0;
   gpmc,cs-on-ns = 0;
 - gpmc,cs-rd-off-ns = 40;
 - gpmc,cs-wr-off-ns = 40;
 + gpmc,cs-rd-off-ns = 80;
 + gpmc,cs-wr-off-ns = 80;
   gpmc,adv-on-ns = 0;
 - gpmc,adv-rd-off-ns = 30;
 - gpmc,adv-wr-off-ns = 30;
 - gpmc,we-on-ns = 5;
 - gpmc,we-off-ns = 25;
 - gpmc,oe-on-ns = 2;
 - gpmc,oe-off-ns = 20;
 - gpmc,access-ns = 20;
 - gpmc,wr-access-ns = 40;
 - gpmc,rd-cycle-ns = 40;
 - gpmc,wr-cycle-ns = 40;
 - gpmc,wait-pin = 0;
 - gpmc,wait-on-read;
 - gpmc,wait-on-write;
 + gpmc,adv-rd-off-ns = 60;
 + gpmc,adv-wr-off-ns = 60;
 + gpmc,we-on-ns = 10;
 + gpmc,we-off-ns = 50;
 + gpmc,oe-on-ns = 4;
 + gpmc,oe-off-ns = 40;
 + gpmc,access-ns = 40;
 + gpmc,wr-access-ns = 80;
 + gpmc,rd-cycle-ns = 80;
 + gpmc,wr-cycle-ns = 80;
   gpmc,bus-turnaround-ns = 0;
   gpmc,cycle2cycle-delay-ns = 0;
   gpmc,clk-activation-ns = 0;
 

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

[PATCH v2 3/3] nand: omap2: Replace pr_err with dev_err

[Ezequiel Garcia]

Usage of pr_err is frowned upon, so replace it with dev_err.
Aditionally, the message on nand_bch_init() error is redundant,
since proper error is showed if the function fails.

Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar
---
 drivers/mtd/nand/omap2.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index f97a4ff..eb5e898 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1375,7 +1375,7 @@ static int omap_elm_correct_data(struct mtd_info *mtd, 
u_char *data,
erased_ecc_vec = bch16_vector;
break;
default:
-   pr_err(invalid driver configuration\n);
+   dev_err(info-pdev-dev, invalid driver configuration\n);
return -EINVAL;
}
 
@@ -1446,7 +1446,8 @@ static int omap_elm_correct_data(struct mtd_info *mtd, 
u_char *data,
err = 0;
for (i = 0; i  eccsteps; i++) {
if (err_vec[i].error_uncorrectable) {
-   pr_err(nand: uncorrectable bit-flips found\n);
+   dev_err(info-pdev-dev,
+   uncorrectable bit-flips found\n);
err = -EBADMSG;
} else if (err_vec[i].error_reported) {
for (j = 0; j  err_vec[i].error_count; j++) {
@@ -1483,8 +1484,9 @@ static int omap_elm_correct_data(struct mtd_info *mtd, 
u_char *data,
1  bit_pos;
}
} else {
-   pr_err(invalid bit-flip @ %d:%d\n,
-byte_pos, bit_pos);
+   dev_err(info-pdev-dev,
+   invalid bit-flip @ %d:%d\n,
+   byte_pos, bit_pos);
err = -EBADMSG;
}
}
@@ -1598,13 +1600,13 @@ static bool is_elm_present(struct omap_nand_info *info,
 
/* check whether elm-id is passed via DT */
if (!elm_node) {
-   pr_err(nand: error: ELM DT node not found\n);
+   dev_err(info-pdev-dev, ELM devicetree node not found\n);
return false;
}
pdev = of_find_device_by_node(elm_node);
/* check whether ELM device is registered */
if (!pdev) {
-   pr_err(nand: error: ELM device not found\n);
+   dev_err(info-pdev-dev, ELM device not found\n);
return false;
}
/* ELM module available, now configure it */
@@ -1734,14 +1736,14 @@ static int omap_nand_probe(struct platform_device *pdev)
/* scan NAND device connected to chip controller */
nand_chip-options |= pdata-devsize  NAND_BUSWIDTH_16;
if (nand_scan_ident(mtd, 1, NULL)) {
-   pr_err(nand device scan failed, may be bus-width mismatch\n);
+   dev_err(info-pdev-dev, scan failed, may be bus-width 
mismatch\n);
err = -ENXIO;
goto return_error;
}
 
/* check for small page devices */
if ((mtd-oobsize  64)  (pdata-ecc_opt != OMAP_ECC_HAM1_CODE_HW)) {
-   pr_err(small page devices are not supported\n);
+   dev_err(info-pdev-dev, small page devices are not 
supported\n);
err = -EINVAL;
goto return_error;
}
@@ -1959,7 +1961,6 @@ static int omap_nand_probe(struct platform_device *pdev)
nand_chip-ecc.bytes,
ecclayout);
if (!nand_chip-ecc.priv) {
-   pr_err(nand: error: unable to use s/w BCH library\n);
err = -EINVAL;
goto return_error;
}
@@ -2026,7 +2027,7 @@ static int omap_nand_probe(struct platform_device *pdev)
ecclayout-eccpos[ecclayout-eccbytes - 1] + 1;
break;
default:
-   pr_err(nand: error: invalid or unsupported ECC scheme\n);
+   dev_err(info-pdev-dev, invalid or unsupported ECC 
scheme\n);
err = -EINVAL;
goto return_error;
}
@@ -2038,8 +2039,9 @@ static int omap_nand_probe(struct platform_device *pdev)
ecclayout-oobfree-length = mtd-oobsize - ecclayout-oobfree-offset;
/* check if NAND device's OOB is enough to store ECC signatures */
if (mtd-oobsize  (ecclayout-eccbytes + BADBLOCK_MARKER_LENGTH)) {
-   pr_err(not enough OOB bytes required = %d, available=%d\n,
-  ecclayout-eccbytes, mtd-oobsize);
+   dev_err(info-pdev-dev,
+  

[PATCH v2 1/3] nand: omap2: Add support for flash-based bad block table

[Ezequiel Garcia]

This commit adds a new platform-data boolean property that enables use
of a flash-based bad block table. This can also be enabled by setting
the 'nand-on-flash-bbt' devicetree property.

If the flash BBT is not enabled, the driver falls back to use OOB
bad block markers only, as before. If the flash BBT is enabled the
kernel will keep track of bad blocks using a BBT, in addition to
the OOB markers.

As explained by Brian Norris the reasons for using a BBT are:


The primary reason would be that NAND datasheets specify it these days.
A better argument is that nobody guarantees that you can write a
bad block marker to a worn out block; you may just get program failures.

This has been acknowledged by several developers over the last several
years.

Additionally, you get a boot-time performance improvement if you only
have to read a few pages, instead of a page or two from every block on
the flash.


Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar
---
 arch/arm/mach-omap2/gpmc.c   | 2 ++
 drivers/mtd/nand/omap2.c | 6 +-
 include/linux/platform_data/mtd-nand-omap2.h | 1 +
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 2f97228..b55a225 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1440,6 +1440,8 @@ static int gpmc_probe_nand_child(struct platform_device 
*pdev,
break;
}
 
+   gpmc_nand_data-flash_bbt = of_get_nand_on_flash_bbt(child);
+
val = of_get_nand_bus_width(child);
if (val == 16)
gpmc_nand_data-devsize = NAND_BUSWIDTH_16;
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5967b38..e1a9b31 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1663,7 +1663,6 @@ static int omap_nand_probe(struct platform_device *pdev)
mtd-owner  = THIS_MODULE;
nand_chip   = info-nand;
nand_chip-ecc.priv = NULL;
-   nand_chip-options  |= NAND_SKIP_BBTSCAN;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
nand_chip-IO_ADDR_R = devm_ioremap_resource(pdev-dev, res);
@@ -1692,6 +1691,11 @@ static int omap_nand_probe(struct platform_device *pdev)
nand_chip-chip_delay = 50;
}
 
+   if (pdata-flash_bbt)
+   nand_chip-bbt_options |= NAND_BBT_USE_FLASH | NAND_BBT_NO_OOB;
+   else
+   nand_chip-options |= NAND_SKIP_BBTSCAN;
+
/* scan NAND device connected to chip controller */
nand_chip-options |= pdata-devsize  NAND_BUSWIDTH_16;
if (nand_scan_ident(mtd, 1, NULL)) {
diff --git a/include/linux/platform_data/mtd-nand-omap2.h 
b/include/linux/platform_data/mtd-nand-omap2.h
index 16ec262..090bbab 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -71,6 +71,7 @@ struct omap_nand_platform_data {
struct mtd_partition*parts;
int nr_parts;
booldev_ready;
+   boolflash_bbt;
enum nand_ioxfer_type;
int devsize;
enum omap_ecc   ecc_opt;
-- 
2.0.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 0/3] nand: omap2: Two and a half improvements

[Ezequiel Garcia]

Changes from v1:

  * Rebased on v3.14-rc2.

  * Removed a few s/pr_err/dev_err change from patch two, and added it
to patch three. This was some git-rebase leftover.

Pekon's attempt to add flash BBT support for this driver made me realise
the addition made sense and there were good reasons for it. The first patch
adds support for enabling a flash BBT either from legacy board files or
from devicetree.

While testing this, I noticed how the driver relied on a whole bunch of
horrible #ifdefs, which prevented me from loading the driver as a module.
The second patch attempts to fix that.

The third patch is just a dummy cleanup replacing pr_errs with dev_errs.
This driver is abusing from user messages, but I'm not sure fixing them
worths the trouble.

Ezequiel Garcia (3):
  nand: omap2: Add support for flash-based bad block table
  nand: omap2: Remove horrible ifdefs to fix module probe
  nand: omap2: Replace pr_err with dev_err

 arch/arm/mach-omap2/gpmc.c   |   2 +
 drivers/mtd/nand/omap2.c | 162 +++
 include/linux/platform_data/elm.h|  14 +++
 include/linux/platform_data/mtd-nand-omap2.h |   1 +
 4 files changed, 107 insertions(+), 72 deletions(-)

-- 
2.0.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 2/3] nand: omap2: Remove horrible ifdefs to fix module probe

[Ezequiel Garcia]

The current code abuses ifdefs to determine if the selected ECC scheme
is supported by the running kernel. As a result the code is hard to read,
and it also fails to load as a module.

This commit removes all the ifdefs and instead introduces a function
omap2_nand_ecc_check() to check if the ECC is supported by using
IS_ENABLED(CONFIG_xxx).

Since IS_ENABLED() is true when a config is =y or =m, this change fixes the
module so it can be loaded with no issues.

Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar
---
 drivers/mtd/nand/omap2.c  | 130 +-
 include/linux/platform_data/elm.h |  14 
 2 files changed, 85 insertions(+), 59 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index e1a9b31..f97a4ff 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -136,7 +136,6 @@
 
 #define BADBLOCK_MARKER_LENGTH 2
 
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
 static u_char bch16_vector[] = {0xf5, 0x24, 0x1c, 0xd0, 0x61, 0xb3, 0xf1, 0x55,
0x2e, 0x2c, 0x86, 0xa3, 0xed, 0x36, 0x1b, 0x78,
0x48, 0x76, 0xa9, 0x3b, 0x97, 0xd1, 0x7a, 0x93,
@@ -144,7 +143,6 @@ static u_char bch16_vector[] = {0xf5, 0x24, 0x1c, 0xd0, 
0x61, 0xb3, 0xf1, 0x55,
 static u_char bch8_vector[] = {0xf3, 0xdb, 0x14, 0x16, 0x8b, 0xd2, 0xbe, 0xcc,
0xac, 0x6b, 0xff, 0x99, 0x7b};
 static u_char bch4_vector[] = {0x00, 0x6b, 0x31, 0xdd, 0x41, 0xbc, 0x10};
-#endif
 
 /* oob info generated runtime depending on ecc algorithm and layout selected */
 static struct nand_ecclayout omap_oobinfo;
@@ -1292,7 +1290,6 @@ static int __maybe_unused omap_calculate_ecc_bch(struct 
mtd_info *mtd,
return 0;
 }
 
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
 /**
  * erased_sector_bitflips - count bit flips
  * @data:  data sector buffer
@@ -1593,33 +1590,71 @@ static int omap_read_page_bch(struct mtd_info *mtd, 
struct nand_chip *chip,
 /**
  * is_elm_present - checks for presence of ELM module by scanning DT nodes
  * @omap_nand_info: NAND device structure containing platform data
- * @bch_type: 0x0=BCH4, 0x1=BCH8, 0x2=BCH16
  */
-static int is_elm_present(struct omap_nand_info *info,
-   struct device_node *elm_node, enum bch_ecc bch_type)
+static bool is_elm_present(struct omap_nand_info *info,
+  struct device_node *elm_node)
 {
struct platform_device *pdev;
-   struct nand_ecc_ctrl *ecc = info-nand.ecc;
-   int err;
+
/* check whether elm-id is passed via DT */
if (!elm_node) {
pr_err(nand: error: ELM DT node not found\n);
-   return -ENODEV;
+   return false;
}
pdev = of_find_device_by_node(elm_node);
/* check whether ELM device is registered */
if (!pdev) {
pr_err(nand: error: ELM device not found\n);
-   return -ENODEV;
+   return false;
}
/* ELM module available, now configure it */
info-elm_dev = pdev-dev;
-   err = elm_config(info-elm_dev, bch_type,
-   (info-mtd.writesize / ecc-size), ecc-size, ecc-bytes);
+   return true;
+}
 
-   return err;
+static bool omap2_nand_ecc_check(struct omap_nand_info *info,
+struct omap_nand_platform_data *pdata)
+{
+   bool ecc_needs_bch, ecc_needs_omap_bch, ecc_needs_elm;
+
+   switch (info-ecc_opt) {
+   case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW:
+   case OMAP_ECC_BCH8_CODE_HW_DETECTION_SW:
+   ecc_needs_omap_bch = false;
+   ecc_needs_bch = true;
+   ecc_needs_elm = false;
+   break;
+   case OMAP_ECC_BCH4_CODE_HW:
+   case OMAP_ECC_BCH8_CODE_HW:
+   case OMAP_ECC_BCH16_CODE_HW:
+   ecc_needs_omap_bch = true;
+   ecc_needs_bch = false;
+   ecc_needs_elm = true;
+   break;
+   default:
+   ecc_needs_omap_bch = false;
+   ecc_needs_bch = false;
+   ecc_needs_elm = false;
+   break;
+   }
+
+   if (ecc_needs_bch  !IS_ENABLED(CONFIG_MTD_NAND_ECC_BCH)) {
+   dev_err(info-pdev-dev,
+   CONFIG_MTD_NAND_ECC_BCH not enabled\n);
+   return false;
+   }
+   if (ecc_needs_omap_bch  !IS_ENABLED(CONFIG_MTD_NAND_OMAP_BCH)) {
+   dev_err(info-pdev-dev,
+   CONFIG_MTD_NAND_OMAP_BCH not enabled\n);
+   return false;
+   }
+   if (ecc_needs_elm  !is_elm_present(info, pdata-elm_of_node)) {
+   dev_err(info-pdev-dev, ELM not available\n);
+   return false;
+   }
+
+   return true;
 }
-#endif /* CONFIG_MTD_NAND_ECC_BCH */
 
 static int omap_nand_probe(struct platform_device *pdev)
 {
@@ -1797,6 +1832,11 @@ static int omap_nand_probe(struct platform_device *pdev)
goto return_error;

Re: [PATCH 2/2] ARM: dts: omap5: Add dr_mode for dwc3

[Dmitry Lifshitz]

Hi Felipe, Roger

On 04/16/2014 07:16 PM, Felipe Balbi wrote:

On Fri, Oct 11, 2013 at 05:46:12PM +0300, Roger Quadros wrote:

Hi,

On 10/10/2013 01:49 PM, Kishon Vijay Abraham I wrote:

From: George Cherian george.cher...@ti.com

Added dr_mode property in dwc3 and set its default mode to device.


If there is a specific reason why this is not set to otg, we need
to explain it here.

AFAIK the port is meant to be used as OTG port.


we still don't have the workaround for dual role ports, I've been
working on it but still need to retest and make sure it's working fine
before merging upstream.




Does the OTG port suppose to work with OMAP5? I mean role switching 
mechanism?


I'm testing kernel v3.16 with OMAP5 based board (CM-T54).

If I set CONFIG_USB_DWC3_DUAL_ROLE, than nothing is going on when I plug 
some device/host cable into micro USB3.0 port (VBUS/ID detection with 
extcon events works fine).


CONFIG_USB_DWC3_HOST/CONFIG_USB_DWC3_GADGET bring port to appropriate 
mode and it works.


What is the purpose of setting dr_mode = peripheral in omap5.dtsi, 
since it is overridden by config options in dwc3_probe()?


Thank you in advance for the assistance,

Dmitry

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

Re: [PATCH 2/2] ARM: dts: omap5: Add dr_mode for dwc3

[Roger Quadros]

On 09/08/2014 02:34 PM, Dmitry Lifshitz wrote:
 Hi Felipe, Roger
 
 On 04/16/2014 07:16 PM, Felipe Balbi wrote:
 On Fri, Oct 11, 2013 at 05:46:12PM +0300, Roger Quadros wrote:
 Hi,

 On 10/10/2013 01:49 PM, Kishon Vijay Abraham I wrote:
 From: George Cherian george.cher...@ti.com

 Added dr_mode property in dwc3 and set its default mode to device.

 If there is a specific reason why this is not set to otg, we need
 to explain it here.

 AFAIK the port is meant to be used as OTG port.

 we still don't have the workaround for dual role ports, I've been
 working on it but still need to retest and make sure it's working fine
 before merging upstream.

 
 
 Does the OTG port suppose to work with OMAP5? I mean role switching mechanism?
 
 I'm testing kernel v3.16 with OMAP5 based board (CM-T54).
 
 If I set CONFIG_USB_DWC3_DUAL_ROLE, than nothing is going on when I plug some 
 device/host cable into micro USB3.0 port (VBUS/ID detection with extcon 
 events works fine).
 
 CONFIG_USB_DWC3_HOST/CONFIG_USB_DWC3_GADGET bring port to appropriate mode 
 and it works.
 
 What is the purpose of setting dr_mode = peripheral in omap5.dtsi, since it 
 is overridden by config options in dwc3_probe()?

If dual role works it should be otg then. I'm not sure why it was set to 
peripheral. Maybe the role switching mechanism
was not in place earlier.

George any objections for otg?

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

Re: [PATCH v2 3/3] nand: omap2: Replace pr_err with dev_err

[Roger Quadros]

Hi Ezequiel,

On 09/08/2014 02:27 PM, Ezequiel Garcia wrote:
 Usage of pr_err is frowned upon, so replace it with dev_err.
 Aditionally, the message on nand_bch_init() error is redundant,
 since proper error is showed if the function fails.
 
 Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar
 ---
  drivers/mtd/nand/omap2.c | 26 ++
  1 file changed, 14 insertions(+), 12 deletions(-)
 
 diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
 index f97a4ff..eb5e898 100644
 --- a/drivers/mtd/nand/omap2.c
 +++ b/drivers/mtd/nand/omap2.c
 @@ -1375,7 +1375,7 @@ static int omap_elm_correct_data(struct mtd_info *mtd, 
 u_char *data,
   erased_ecc_vec = bch16_vector;
   break;
   default:
 - pr_err(invalid driver configuration\n);
 + dev_err(info-pdev-dev, invalid driver configuration\n);
   return -EINVAL;
   }
  
 @@ -1446,7 +1446,8 @@ static int omap_elm_correct_data(struct mtd_info *mtd, 
 u_char *data,
   err = 0;
   for (i = 0; i  eccsteps; i++) {
   if (err_vec[i].error_uncorrectable) {
 - pr_err(nand: uncorrectable bit-flips found\n);
 + dev_err(info-pdev-dev,
 + uncorrectable bit-flips found\n);
   err = -EBADMSG;
   } else if (err_vec[i].error_reported) {
   for (j = 0; j  err_vec[i].error_count; j++) {
 @@ -1483,8 +1484,9 @@ static int omap_elm_correct_data(struct mtd_info *mtd, 
 u_char *data,
   1  bit_pos;
   }
   } else {
 - pr_err(invalid bit-flip @ %d:%d\n,
 -  byte_pos, bit_pos);
 + dev_err(info-pdev-dev,
 + invalid bit-flip @ %d:%d\n,
 + byte_pos, bit_pos);
   err = -EBADMSG;
   }
   }
 @@ -1598,13 +1600,13 @@ static bool is_elm_present(struct omap_nand_info 
 *info,
  
   /* check whether elm-id is passed via DT */
   if (!elm_node) {
 - pr_err(nand: error: ELM DT node not found\n);
 + dev_err(info-pdev-dev, ELM devicetree node not found\n);
   return false;
   }
   pdev = of_find_device_by_node(elm_node);
   /* check whether ELM device is registered */
   if (!pdev) {
 - pr_err(nand: error: ELM device not found\n);
 + dev_err(info-pdev-dev, ELM device not found\n);
   return false;
   }
   /* ELM module available, now configure it */
 @@ -1734,14 +1736,14 @@ static int omap_nand_probe(struct platform_device 
 *pdev)
   /* scan NAND device connected to chip controller */
   nand_chip-options |= pdata-devsize  NAND_BUSWIDTH_16;
   if (nand_scan_ident(mtd, 1, NULL)) {
 - pr_err(nand device scan failed, may be bus-width mismatch\n);
 + dev_err(info-pdev-dev, scan failed, may be bus-width 
 mismatch\n);
   err = -ENXIO;
   goto return_error;
   }
  
   /* check for small page devices */
   if ((mtd-oobsize  64)  (pdata-ecc_opt != OMAP_ECC_HAM1_CODE_HW)) {
 - pr_err(small page devices are not supported\n);
 + dev_err(info-pdev-dev, small page devices are not 
 supported\n);
   err = -EINVAL;
   goto return_error;
   }
 @@ -1959,7 +1961,6 @@ static int omap_nand_probe(struct platform_device *pdev)
   nand_chip-ecc.bytes,
   ecclayout);
   if (!nand_chip-ecc.priv) {
 - pr_err(nand: error: unable to use s/w BCH library\n);

Where would the error be printed in this case?

I also noticed a similar message in the OMAP_ECC_BCH4_CODE_HW_DETECTION_SW case.
And it seems to be missing a goto return_error there.

   err = -EINVAL;
   goto return_error;
   }
 @@ -2026,7 +2027,7 @@ static int omap_nand_probe(struct platform_device *pdev)
   ecclayout-eccpos[ecclayout-eccbytes - 1] + 1;
   break;
   default:
 - pr_err(nand: error: invalid or unsupported ECC scheme\n);
 + dev_err(info-pdev-dev, invalid or unsupported ECC 
 scheme\n);
   err = -EINVAL;
   goto return_error;
   }
 @@ -2038,8 +2039,9 @@ static int omap_nand_probe(struct platform_device *pdev)
   ecclayout-oobfree-length = mtd-oobsize - ecclayout-oobfree-offset;
   /* check if NAND device's OOB is enough to store ECC signatures */
   if (mtd-oobsize  (ecclayout-eccbytes + 

Re: [PATCH 2/2] ARM: dts: omap5: Add dr_mode for dwc3

[Dmitry Lifshitz]

Hi Roger,

Thank you for a quick reply. See, my reply below.

On 09/08/2014 02:39 PM, Roger Quadros wrote:

On 09/08/2014 02:34 PM, Dmitry Lifshitz wrote:

Hi Felipe, Roger

On 04/16/2014 07:16 PM, Felipe Balbi wrote:

On Fri, Oct 11, 2013 at 05:46:12PM +0300, Roger Quadros wrote:

Hi,

On 10/10/2013 01:49 PM, Kishon Vijay Abraham I wrote:

From: George Cherian george.cher...@ti.com

Added dr_mode property in dwc3 and set its default mode to device.


If there is a specific reason why this is not set to otg, we need
to explain it here.

AFAIK the port is meant to be used as OTG port.


we still don't have the workaround for dual role ports, I've been
working on it but still need to retest and make sure it's working fine
before merging upstream.




Does the OTG port suppose to work with OMAP5? I mean role switching mechanism?

I'm testing kernel v3.16 with OMAP5 based board (CM-T54).

If I set CONFIG_USB_DWC3_DUAL_ROLE, than nothing is going on when I plug some 
device/host cable into micro USB3.0 port (VBUS/ID detection with extcon events 
works fine).

CONFIG_USB_DWC3_HOST/CONFIG_USB_DWC3_GADGET bring port to appropriate mode and 
it works.

What is the purpose of setting dr_mode = peripheral in omap5.dtsi, since it 
is overridden by config options in dwc3_probe()?


If dual role works it should be otg then. I'm not sure why it was set to 
peripheral. Maybe the role switching mechanism
was not in place earlier.



This is what I have when setting dr_mode = otg (and compiling with 
CONFIG_USB_DWC3_DUAL_ROLE):


when load gadget driver and plugging host PC cable:

root@cm-debian:~# modprobe g_ether
using random self ethernet address
using random host ethernet address
usb0: HOST MAC fa:db:52:7f:95:c5
usb0: MAC be:75:8d:71:6d:02
using random self ethernet address
using random host ethernet address
g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
g_ether gadget: g_ether ready
root@cm-debian:~# [ cut here ]
WARNING: CPU: 0 PID: 65 at 
/home/lifshitz/workroot/git-repo/OMAP5/omap5-kernel/drivers/bus/omap_l3_noc.c:147 
l3_handle_target.isra.2+0x230/0x27c()
4400.ocp:L3 Standard Error: MASTER UN IDENTIFIED TARGET OCMRAM 
(Read): At Address: 0x : Data Access in User mode during 
Functional access
Modules linked in: usb_f_eem g_ether usb_f_rndis libcomposite u_ether 
configfs rfcomm ecb btmrvl_sdio btmrvl bluetooth mwifiex_sdio mwifiex 
dwc3 ahci_platform libahci_platform libahci libata snd_soc_cm_t54 
ads7846 dwc3_omap extcon_palmas rtc_palmas extcon_class at24 
snd_soc_wm8731 snd_soc_omap_mcbsp
CPU: 0 PID: 65 Comm: irq/39-palmas Tainted: GW 
3.16.0-cm-t54+ #99

[c00156d0] (unwind_backtrace) from [c00124ac] (show_stack+0x10/0x14)
[c00124ac] (show_stack) from [c05e29dc] (dump_stack+0x74/0x8c)
[c05e29dc] (dump_stack) from [c0037dbc] (warn_slowpath_common+0x70/0x88)
[c0037dbc] (warn_slowpath_common) from [c0037e68] 
(warn_slowpath_fmt+0x30/0x40)
[c0037e68] (warn_slowpath_fmt) from [c02d88b8] 
(l3_handle_target.isra.2+0x230/0x27c)
[c02d88b8] (l3_handle_target.isra.2) from [c02d89b0] 
(l3_interrupt_handler+0xac/0x13c)
[c02d89b0] (l3_interrupt_handler) from [c007ea00] 
(handle_irq_event_percpu+0x7c/0x230)
[c007ea00] (handle_irq_event_percpu) from [c007ebf8] 
(handle_irq_event+0x44/0x64)
[c007ebf8] (handle_irq_event) from [c0081b78] 
(handle_fasteoi_irq+0xa8/0x134)
[c0081b78] (handle_fasteoi_irq) from [c007e398] 
(generic_handle_irq+0x20/0x30)

[c007e398] (generic_handle_irq) from [c000f4ac] (handle_IRQ+0x40/0x90)
[c000f4ac] (handle_IRQ) from [c0008620] (gic_handle_irq+0x2c/0x60)
[c0008620] (gic_handle_irq) from [c05eacc0] (__irq_svc+0x40/0x50)
Exception stack(0xec939d80 to 0xec939dc8)
9d80: ecb729b0 2013  0001 ecb72800 eca1e000  
ec939e44
9da0: ec939ed0 2013 ecb72818 ed005e14 ec939ec8 ec939dc8 bf015f54 
c05ea548

9dc0: 8013 
[c05eacc0] (__irq_svc) from [c05ea548] 
(_raw_spin_unlock_irqrestore+0x1c/0x20)
[c05ea548] (_raw_spin_unlock_irqrestore) from [bf015f54] 
(extcon_update_state+0x144/0x1c4 [extcon_class])
[bf015f54] (extcon_update_state [extcon_class]) from [bf023288] 
(palmas_vbus_irq_handler+0x64/0xa0 [extcon_palmas])
[bf023288] (palmas_vbus_irq_handler [extcon_palmas]) from [c00815a8] 
(handle_nested_irq+0xa0/0x10c)
[c00815a8] (handle_nested_irq) from [c03ab85c] 
(regmap_irq_thread+0x184/0x300)

[c03ab85c] (regmap_irq_thread) from [c007f8b8] (irq_thread_fn+0x1c/0x40)
[c007f8b8] (irq_thread_fn) from [c007f6a4] (irq_thread+0x120/0x15c)
[c007f6a4] (irq_thread) from [c0056434] (kthread+0xdc/0xf0)
[c0056434] (kthread) from [c000eb98] (ret_from_fork+0x14/0x3c)
---[ end trace 3b365a734f7f3202 ]---
palmas-usb 4807.i2c:palmas@48:palmas_usb: USB cable is attached



when plugging storage device:

root@cm-debian:~# dmesg | tail -n20
...
omap-dwc3 4a02.omap_dwc3: ID GND
palmas-usb 4807.i2c:palmas@48:palmas_usb: USB-HOST cable is attached
palmas-usb 4807.i2c:palmas@48:palmas_usb: USB cable is attached

and nothing is 

Re: [PATCH 2/2] ARM: dts: omap5: Add dr_mode for dwc3

[Felipe Balbi]

Hi,

On Mon, Sep 08, 2014 at 02:34:33PM +0300, Dmitry Lifshitz wrote:
 Hi Felipe, Roger
 
 On 04/16/2014 07:16 PM, Felipe Balbi wrote:
 On Fri, Oct 11, 2013 at 05:46:12PM +0300, Roger Quadros wrote:
 Hi,
 
 On 10/10/2013 01:49 PM, Kishon Vijay Abraham I wrote:
 From: George Cherian george.cher...@ti.com
 
 Added dr_mode property in dwc3 and set its default mode to device.
 
 If there is a specific reason why this is not set to otg, we need
 to explain it here.
 
 AFAIK the port is meant to be used as OTG port.
 
 we still don't have the workaround for dual role ports, I've been
 working on it but still need to retest and make sure it's working fine
 before merging upstream.
 
 
 
 Does the OTG port suppose to work with OMAP5? I mean role switching
 mechanism?
 
 I'm testing kernel v3.16 with OMAP5 based board (CM-T54).
 
 If I set CONFIG_USB_DWC3_DUAL_ROLE, than nothing is going on when I plug
 some device/host cable into micro USB3.0 port (VBUS/ID detection with extcon
 events works fine).

Dual role does not work. We allow the driver to the built with both Host
and Peripheral support because some platforms have more than one port
and building the driver with dual role allows us to make one port host
and one peripheral.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 2/2] ARM: dts: omap5: Add dr_mode for dwc3

[Felipe Balbi]

Hi,

On Mon, Sep 08, 2014 at 03:32:37PM +0300, Dmitry Lifshitz wrote:
 Hi Roger,
 
 Thank you for a quick reply. See, my reply below.
 
 On 09/08/2014 02:39 PM, Roger Quadros wrote:
 On 09/08/2014 02:34 PM, Dmitry Lifshitz wrote:
 Hi Felipe, Roger
 
 On 04/16/2014 07:16 PM, Felipe Balbi wrote:
 On Fri, Oct 11, 2013 at 05:46:12PM +0300, Roger Quadros wrote:
 Hi,
 
 On 10/10/2013 01:49 PM, Kishon Vijay Abraham I wrote:
 From: George Cherian george.cher...@ti.com
 
 Added dr_mode property in dwc3 and set its default mode to device.
 
 If there is a specific reason why this is not set to otg, we need
 to explain it here.
 
 AFAIK the port is meant to be used as OTG port.
 
 we still don't have the workaround for dual role ports, I've been
 working on it but still need to retest and make sure it's working fine
 before merging upstream.
 
 
 
 Does the OTG port suppose to work with OMAP5? I mean role switching 
 mechanism?
 
 I'm testing kernel v3.16 with OMAP5 based board (CM-T54).
 
 If I set CONFIG_USB_DWC3_DUAL_ROLE, than nothing is going on when I plug 
 some device/host cable into micro USB3.0 port (VBUS/ID detection with 
 extcon events works fine).
 
 CONFIG_USB_DWC3_HOST/CONFIG_USB_DWC3_GADGET bring port to appropriate mode 
 and it works.
 
 What is the purpose of setting dr_mode = peripheral in omap5.dtsi, since 
 it is overridden by config options in dwc3_probe()?
 
 If dual role works it should be otg then. I'm not sure why it was set to 
 peripheral. Maybe the role switching mechanism
 was not in place earlier.
 
 
 This is what I have when setting dr_mode = otg (and compiling with
 CONFIG_USB_DWC3_DUAL_ROLE):
 
 when load gadget driver and plugging host PC cable:
 
 root@cm-debian:~# modprobe g_ether
 using random self ethernet address
 using random host ethernet address
 usb0: HOST MAC fa:db:52:7f:95:c5
 usb0: MAC be:75:8d:71:6d:02
 using random self ethernet address
 using random host ethernet address
 g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
 g_ether gadget: g_ether ready
 root@cm-debian:~# [ cut here ]
 WARNING: CPU: 0 PID: 65 at 
 /home/lifshitz/workroot/git-repo/OMAP5/omap5-kernel/drivers/bus/omap_l3_noc.c:147
 l3_handle_target.isra.2+0x230/0x27c()
 4400.ocp:L3 Standard Error: MASTER UN IDENTIFIED TARGET OCMRAM (Read):
 At Address: 0x : Data Access in User mode during Functional access
 Modules linked in: usb_f_eem g_ether usb_f_rndis libcomposite u_ether
 configfs rfcomm ecb btmrvl_sdio btmrvl bluetooth mwifiex_sdio mwifiex dwc3
 ahci_platform libahci_platform libahci libata snd_soc_cm_t54 ads7846
 dwc3_omap extcon_palmas rtc_palmas extcon_class at24 snd_soc_wm8731
 snd_soc_omap_mcbsp
 CPU: 0 PID: 65 Comm: irq/39-palmas Tainted: GW 3.16.0-cm-t54+ #99
 [c00156d0] (unwind_backtrace) from [c00124ac] (show_stack+0x10/0x14)
 [c00124ac] (show_stack) from [c05e29dc] (dump_stack+0x74/0x8c)
 [c05e29dc] (dump_stack) from [c0037dbc] (warn_slowpath_common+0x70/0x88)
 [c0037dbc] (warn_slowpath_common) from [c0037e68]
 (warn_slowpath_fmt+0x30/0x40)
 [c0037e68] (warn_slowpath_fmt) from [c02d88b8]
 (l3_handle_target.isra.2+0x230/0x27c)
 [c02d88b8] (l3_handle_target.isra.2) from [c02d89b0]
 (l3_interrupt_handler+0xac/0x13c)
 [c02d89b0] (l3_interrupt_handler) from [c007ea00]
 (handle_irq_event_percpu+0x7c/0x230)
 [c007ea00] (handle_irq_event_percpu) from [c007ebf8]
 (handle_irq_event+0x44/0x64)
 [c007ebf8] (handle_irq_event) from [c0081b78]
 (handle_fasteoi_irq+0xa8/0x134)
 [c0081b78] (handle_fasteoi_irq) from [c007e398]
 (generic_handle_irq+0x20/0x30)
 [c007e398] (generic_handle_irq) from [c000f4ac] (handle_IRQ+0x40/0x90)
 [c000f4ac] (handle_IRQ) from [c0008620] (gic_handle_irq+0x2c/0x60)
 [c0008620] (gic_handle_irq) from [c05eacc0] (__irq_svc+0x40/0x50)
 Exception stack(0xec939d80 to 0xec939dc8)
 9d80: ecb729b0 2013  0001 ecb72800 eca1e000 
 ec939e44
 9da0: ec939ed0 2013 ecb72818 ed005e14 ec939ec8 ec939dc8 bf015f54
 c05ea548
 9dc0: 8013 
 [c05eacc0] (__irq_svc) from [c05ea548]
 (_raw_spin_unlock_irqrestore+0x1c/0x20)
 [c05ea548] (_raw_spin_unlock_irqrestore) from [bf015f54]
 (extcon_update_state+0x144/0x1c4 [extcon_class])
 [bf015f54] (extcon_update_state [extcon_class]) from [bf023288]
 (palmas_vbus_irq_handler+0x64/0xa0 [extcon_palmas])
 [bf023288] (palmas_vbus_irq_handler [extcon_palmas]) from [c00815a8]
 (handle_nested_irq+0xa0/0x10c)
 [c00815a8] (handle_nested_irq) from [c03ab85c]
 (regmap_irq_thread+0x184/0x300)
 [c03ab85c] (regmap_irq_thread) from [c007f8b8] (irq_thread_fn+0x1c/0x40)
 [c007f8b8] (irq_thread_fn) from [c007f6a4] (irq_thread+0x120/0x15c)
 [c007f6a4] (irq_thread) from [c0056434] (kthread+0xdc/0xf0)
 [c0056434] (kthread) from [c000eb98] (ret_from_fork+0x14/0x3c)
 ---[ end trace 3b365a734f7f3202 ]---
 palmas-usb 4807.i2c:palmas@48:palmas_usb: USB cable is attached
 
 
 
 when plugging storage device:
 
 root@cm-debian:~# dmesg | tail -n20
 ...
 omap-dwc3 4a02.omap_dwc3: ID GND
 

[PATCH 12/13] ARM: dts: am4372: Add control module syscon node

[Roger Quadros]

Use syscon regmap to expose the Control module register space.
This register space is shared between many users e.g. DCAN, USB, display, etc.

Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/boot/dts/am4372.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index a705e50..d38a0ed 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -59,6 +59,11 @@
cache-level = 2;
};
 
+   am43xx_control_module: control_module@4a002000 {
+   compatible = syscon;
+   reg = 0x44e1 0x7f4;
+   };
+
am43xx_pinmux: pinmux@44e10800 {
compatible = pinctrl-single;
reg = 0x44e10800 0x31c;
-- 
1.8.3.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/13] net: can: c_can: Add support for START pulse in RAMINIT sequence

[Roger Quadros]

Some SoCs e.g. (TI DRA7xx) need a START pulse to start the
RAMINIT sequence i.e. START bit must be set and cleared before
checking for the DONE bit status. Add a new DT property raminit-pulse
to specify if this mechanism must be used for RAMINIT.

Signed-off-by: Roger Quadros rog...@ti.com
---
 Documentation/devicetree/bindings/net/can/c_can.txt | 3 +++
 drivers/net/can/c_can/c_can.h   | 1 +
 drivers/net/can/c_can/c_can_platform.c  | 8 
 3 files changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt 
b/Documentation/devicetree/bindings/net/can/c_can.txt
index 0856209..2f0a6bb 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -19,6 +19,9 @@ Optional properties:
  register within the syscon region
 - raminit-start-bit: Bit posistion of START bit in the RAMINIT register
 - raminit-done-bit : Bit position of DONE bit in the RAMINIT register
+- raminit-pulse: Property must exist if START pulse is needed 
for RAMINIT
+ sequence i.e. START bit will be set and cleared before
+ checking for DONE bit.
 
 Note: ti,hwmods field is used to fetch the base address and irq
 resources from TI, omap hwmod data base during device registration.
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index bf68822..85b5ad0 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -175,6 +175,7 @@ struct c_can_raminit {
unsigned int reg;   /* register index within syscon */
u8 start_bit;   /* START bit position in raminit reg. */
u8 done_bit;/* DONE bit position in raminit reg. */
+   bool needs_pulse;   /* If set, sets and clears START bit (pulse) */
 };
 
 /* c_can private data structure */
diff --git a/drivers/net/can/c_can/c_can_platform.c 
b/drivers/net/can/c_can/c_can_platform.c
index e7ec3b6..bc09695 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -123,6 +123,12 @@ static void c_can_hw_raminit_syscon(const struct 
c_can_priv *priv, bool enable)
ctrl |= 1  raminit-start_bit;
regmap_write(raminit-syscon, raminit-reg, ctrl);
 
+   /* clear START bit if start pulse is needed */
+   if (raminit-needs_pulse) {
+   ctrl = ~(1  raminit-start_bit);
+   regmap_write(raminit-syscon, raminit-reg, ctrl);
+   }
+
ctrl |= 1  raminit-done_bit;
c_can_hw_raminit_wait_syscon(priv, mask, ctrl);
}
@@ -343,6 +349,8 @@ static int c_can_plat_probe(struct platform_device *pdev)
}
 
priv-raminit_sys.done_bit = val;
+   priv-raminit_sys.needs_pulse = of_property_read_bool(np,
+ 
raminit-pulse);
priv-raminit = c_can_hw_raminit_syscon;
break;
default:
-- 
1.8.3.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/13] net: can: c_can: Add syscon/regmap RAMINIT mechanism

[Roger Quadros]

Some TI SoCs like DRA7 have a RAMINIT register specification
different from the other AMxx SoCs and as expected by the
existing driver.

To add more insanity, this register is shared with other
IPs like DSS, PCIe and PWM.

Provides a more generic mechanism to specify the RAMINIT
register location and START/DONE bit position and use the
syscon/regmap framework to access the register.

Signed-off-by: Roger Quadros rog...@ti.com
---
 .../devicetree/bindings/net/can/c_can.txt  |   7 ++
 drivers/net/can/c_can/c_can.h  |  11 ++-
 drivers/net/can/c_can/c_can_platform.c | 106 +++--
 3 files changed, 95 insertions(+), 29 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt 
b/Documentation/devicetree/bindings/net/can/c_can.txt
index 8f1ae81..0856209 100644
--- a/Documentation/devicetree/bindings/net/can/c_can.txt
+++ b/Documentation/devicetree/bindings/net/can/c_can.txt
@@ -13,6 +13,13 @@ Optional properties:
 - ti,hwmods: Must be d_cann or c_cann, n being the
  instance number
 
+- raminit-syscon   : Handle to system control region that contains the
+ RAMINIT register. If specified, the second memory 
resource
+ in the reg property must index into the RAMINIT
+ register within the syscon region
+- raminit-start-bit: Bit posistion of START bit in the RAMINIT register
+- raminit-done-bit : Bit position of DONE bit in the RAMINIT register
+
 Note: ti,hwmods field is used to fetch the base address and irq
 resources from TI, omap hwmod data base during device registration.
 Future plan is to migrate hwmod data base contents into device tree
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 99ad1aa..bf68822 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -169,6 +169,14 @@ enum c_can_dev_id {
BOSCH_D_CAN,
 };
 
+/* Out of band RAMINIT register access via syscon regmap */
+struct c_can_raminit {
+   struct regmap *syscon;  /* for raminit ctrl. reg. access */
+   unsigned int reg;   /* register index within syscon */
+   u8 start_bit;   /* START bit position in raminit reg. */
+   u8 done_bit;/* DONE bit position in raminit reg. */
+};
+
 /* c_can private data structure */
 struct c_can_priv {
struct can_priv can;/* must be the first member */
@@ -186,8 +194,7 @@ struct c_can_priv {
const u16 *regs;
void *priv; /* for board-specific data */
enum c_can_dev_id type;
-   u32 __iomem *raminit_ctrlreg;
-   int instance;
+   struct c_can_raminit raminit_sys;   /* RAMINIT via syscon regmap */
void (*raminit) (const struct c_can_priv *priv, bool enable);
u32 comm_rcv_high;
u32 rxmasked;
diff --git a/drivers/net/can/c_can/c_can_platform.c 
b/drivers/net/can/c_can/c_can_platform.c
index b144e71..e7ec3b6 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -32,6 +32,8 @@
 #include linux/clk.h
 #include linux/of.h
 #include linux/of_device.h
+#include linux/mfd/syscon.h
+#include linux/regmap.h
 
 #include linux/can/dev.h
 
@@ -72,48 +74,59 @@ static void c_can_plat_write_reg_aligned_to_32bit(const 
struct c_can_priv *priv,
writew(val, priv-base + 2 * priv-regs[index]);
 }
 
-static void c_can_hw_raminit_wait_ti(const struct c_can_priv *priv, u32 mask,
- u32 val)
+static void c_can_hw_raminit_wait_syscon(const struct c_can_priv *priv,
+u32 mask, u32 val)
 {
int timeout = 0;
+   const struct c_can_raminit *raminit = priv-raminit_sys;
+   u32 ctrl;
+
/* We look only at the bits of our instance. */
val = mask;
-   while ((readl(priv-raminit_ctrlreg)  mask) != val) {
+   do {
udelay(1);
timeout++;
 
+   regmap_read(raminit-syscon, raminit-reg, ctrl);
if (timeout == 1000) {
dev_err(priv-dev-dev, %s: time out\n, __func__);
break;
}
-   }
+   } while ((ctrl  mask) != val);
 }
 
-static void c_can_hw_raminit_ti(const struct c_can_priv *priv, bool enable)
+static void c_can_hw_raminit_syscon(const struct c_can_priv *priv, bool enable)
 {
-   u32 mask = CAN_RAMINIT_ALL_MASK(priv-instance);
+   u32 mask;
u32 ctrl;
+   const struct c_can_raminit *raminit = priv-raminit_sys;
 
spin_lock(raminit_lock);
 
-   ctrl = readl(priv-raminit_ctrlreg);
+   mask = 1  raminit-start_bit | 1  raminit-done_bit;
+   regmap_read(raminit-syscon, raminit-reg, ctrl);
+
/* We clear the done and start bit first. The start bit is
 * looking at the 0 - transition, but is not self clearing;
 * And we clear the init done bit as well.
+ 

[PATCH 10/13] arm: dts: am437x-gp: Add dcan support

[Roger Quadros]

From: Mugunthan V N mugunthan...@ti.com

Add DCAN support for AM437x GP EVM with both DCAN instances.

Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: George Cherian george.cher...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index e7ac47f..6d03baa 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -254,6 +254,20 @@
0x238 (PIN_OUTPUT_PULLUP | MUX_MODE7)
;
};
+
+   dcan0_default: dcan0_default_pins {
+   pinctrl-single,pins = 
+   0x178 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* 
uart1_ctsn.d_can0_tx */
+   0x17c (PIN_INPUT_PULLUP | MUX_MODE2) /* 
uart1_rtsn.d_can0_rx */
+   ;
+   };
+
+   dcan1_default: dcan1_default_pins {
+   pinctrl-single,pins = 
+   0x180 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* 
uart1_rxd.d_can1_tx */
+   0x184 (PIN_INPUT_PULLUP | MUX_MODE2) /* 
uart1_txd.d_can1_rx */
+   ;
+   };
 };
 
 i2c0 {
@@ -511,3 +525,15 @@
};
};
 };
+
+dcan0 {
+   pinctrl-names = default;
+   pinctrl-0 = dcan0_default;
+   status = okay;
+};
+
+dcan1 {
+   pinctrl-names = default;
+   pinctrl-0 = dcan1_default;
+   status = okay;
+};
-- 
1.8.3.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/13] ARM: dts: dra72-evm: Add CAN support

[Roger Quadros]

The board has 2 CAN ports but only the first one can be used.
Enable the first CAN port.

The second one cannot be used without hardware modification
so we don't enable the second port.

Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/boot/dts/dra72-evm.dts | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 5147023..e5b7172 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -19,6 +19,29 @@
};
 };
 
+dra7_pmx_core {
+   dcan1_pins_default: dcan1_pins_default {
+   pinctrl-single,pins = 
+   0x3d4   (PIN_INPUT | MUX_MODE0) /* dcan1_tx */
+   0x418   (PIN_INPUT | MUX_MODE1) /* 
wakeup0.dcan1_rx */
+   ;
+   };
+
+   dcan1_pins_sleep: dcan1_pins_sleep {
+   pinctrl-single,pins = 
+   0x3d4   (PIN_INPUT | MUX_MODE15)/* dcan1_tx.off 
*/
+   0x418   (PIN_INPUT | MUX_MODE15)/* wakeup0.off 
*/
+   ;
+   };
+};
+
 uart1 {
status = okay;
 };
+
+dcan1 {
+   status = ok;
+   pinctrl-names = default, sleep;
+   pinctrl-0 = dcan1_pins_default;
+   pinctrl-1 = dcan1_pins_sleep;
+};
-- 
1.8.3.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 13/13] ARM: dts: am4372: Add dcan raminit bits

[Roger Quadros]

Add RAMINIT specific bits into the DCAN nodes.

Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/boot/dts/am4372.dtsi | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d38a0ed..33d27cd 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -899,7 +899,10 @@
clocks = dcan0_fck;
clock-names = fck;
reg = 0x481cc000 0x2000
-   0x44e10644 0x4;
+   0x644 0x4; /* index to RAMINIT reg within 
syscon */
+   raminit-syscon = am43xx_control_module;
+   raminit-start-bit = 0;
+   raminit-done-bit = 8;
interrupts = GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH;
status = disabled;
};
@@ -910,7 +913,10 @@
clocks = dcan1_fck;
clock-names = fck;
reg = 0x481d 0x2000
-   0x44e10644 0x4;
+   0x644 0x4; /* index to RAMINIT reg within 
syscon */
+   raminit-syscon = am43xx_control_module;
+   raminit-start-bit = 1;
+   raminit-done-bit = 9;
interrupts = GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH;
status = disabled;
};
-- 
1.8.3.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 01/13] can: c_can_platform: Fix c_can_hw_raminit_ti() and add timeout

[Roger Quadros]

Pass the correct 'mask' and 'value' bits to c_can_hw_raminit_wait_ti().
They seem to have been swapped in the usage instances.

TI's RAMINIT DONE mechanism is buggy and may not always be
set after the START bit is set. So add a timeout mechanism to
c_can_hw_raminit_wait_ti().

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/net/can/c_can/c_can_platform.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/net/can/c_can/c_can_platform.c 
b/drivers/net/can/c_can/c_can_platform.c
index 109cb44..b144e71 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -75,10 +75,18 @@ static void c_can_plat_write_reg_aligned_to_32bit(const 
struct c_can_priv *priv,
 static void c_can_hw_raminit_wait_ti(const struct c_can_priv *priv, u32 mask,
  u32 val)
 {
+   int timeout = 0;
/* We look only at the bits of our instance. */
val = mask;
-   while ((readl(priv-raminit_ctrlreg)  mask) != val)
+   while ((readl(priv-raminit_ctrlreg)  mask) != val) {
udelay(1);
+   timeout++;
+
+   if (timeout == 1000) {
+   dev_err(priv-dev-dev, %s: time out\n, __func__);
+   break;
+   }
+   }
 }
 
 static void c_can_hw_raminit_ti(const struct c_can_priv *priv, bool enable)
@@ -97,14 +105,14 @@ static void c_can_hw_raminit_ti(const struct c_can_priv 
*priv, bool enable)
ctrl |= CAN_RAMINIT_DONE_MASK(priv-instance);
writel(ctrl, priv-raminit_ctrlreg);
ctrl = ~CAN_RAMINIT_DONE_MASK(priv-instance);
-   c_can_hw_raminit_wait_ti(priv, ctrl, mask);
+   c_can_hw_raminit_wait_ti(priv, mask, ctrl);
 
if (enable) {
/* Set start bit and wait for the done bit. */
ctrl |= CAN_RAMINIT_START_MASK(priv-instance);
writel(ctrl, priv-raminit_ctrlreg);
ctrl |= CAN_RAMINIT_DONE_MASK(priv-instance);
-   c_can_hw_raminit_wait_ti(priv, ctrl, mask);
+   c_can_hw_raminit_wait_ti(priv, mask, ctrl);
}
spin_unlock(raminit_lock);
 }
-- 
1.8.3.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 05/13] ARM: dts: DRA7: Add DCAN nodes

[Roger Quadros]

The SoC supports 2 DCAN nodes. Add them.

Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/boot/dts/dra7.dtsi | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 370009e..4ce1a4f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -34,6 +34,8 @@
serial3 = uart4;
serial4 = uart5;
serial5 = uart6;
+   d_can0 = dcan1;
+   d_can1 = dcan2;
};
 
timer {
@@ -1267,6 +1269,34 @@
ti,irqs-skip = 10 133 139 140;
ti,irqs-safe-map = 0;
};
+
+   dcan1: d_can@481cc000 {
+   compatible = bosch,d_can;
+   ti,hwmods = dcan1;
+   reg = 0x4ae3c000 0x2000,
+ 0x558 0x4; /* index to RAMINIT reg within 
syscon */
+   raminit-syscon = dra7_ctrl_core;
+   raminit-start-bit = 3;
+   raminit-done-bit = 1;
+   raminit-pulse;
+   interrupts = GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH;
+   clocks = dcan1_sys_clk_mux;
+   status = disabled;
+   };
+
+   dcan2: d_can@481d {
+   compatible = bosch,d_can;
+   ti,hwmods = dcan2;
+   reg = 0x4848 0x2000,
+ 0x558 0x4; /* index to RAMINIT reg within 
syscon */
+   raminit-syscon = dra7_ctrl_core;
+   raminit-start-bit = 5;
+   raminit-done-bit = 2;
+   raminit-pulse;
+   interrupts = GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH;
+   clocks = sys_clkin1;
+   status = disabled;
+   };
};
 };
 
-- 
1.8.3.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/13] ARM: dts: dra7: Add syscon regmap for CORE CONTROL area

[Roger Quadros]

Display and DCAN drivers use syscon regmap to access some registers
in the CORE control area. Add the syscon regmap node for this
area.

Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/boot/dts/dra7.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d678152..370009e 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -200,6 +200,11 @@
ti,hwmods = counter_32k;
};
 
+   dra7_ctrl_core: ctrl_core@4a002000 {
+   compatible = syscon;
+   reg = 0x4a002000 0x6d0;
+   };
+
dra7_ctrl_general: tisyscon@4a002e00 {
compatible = syscon;
reg = 0x4a002e00 0x7c;
-- 
1.8.3.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/13] arm: dts: am4372: Add dcan nodes

[Roger Quadros]

From: Afzal Mohammed af...@ti.com

Add dcan nodes.

Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: George Cherian george.cher...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
 arch/arm/boot/dts/am4372.dtsi | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 8689949..3514d0a 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -885,6 +885,28 @@
clock-names = fck;
};
};
+
+   dcan0: can@481cc000 {
+   compatible = bosch,d_can;
+   ti,hwmods = d_can0;
+   clocks = dcan0_fck;
+   clock-names = fck;
+   reg = 0x481cc000 0x2000
+   0x44e10644 0x4;
+   interrupts = GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH;
+   status = disabled;
+   };
+
+   dcan1: can@481d {
+   compatible = bosch,d_can;
+   ti,hwmods = d_can1;
+   clocks = dcan1_fck;
+   clock-names = fck;
+   reg = 0x481d 0x2000
+   0x44e10644 0x4;
+   interrupts = GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH;
+   status = disabled;
+   };
};
 };
 
-- 
1.8.3.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/13] ARM: dts: AM43xx: Add aliases to d_can nodes

[Roger Quadros]

The d_can driver expects appropriately named aliases for
the d_can nodes for the RAMINIT control register access.

Provide those, otherwise RAMINIT register won't be configured.
Get's rid of the following messages during boot.

[   16.419354] c_can_platform 481cc000.can: control memory is not used for 
raminit
[   16.449142] c_can_platform 481d.can: control memory is not used for 
raminit

Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
 arch/arm/boot/dts/am4372.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 3514d0a..a705e50 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -25,6 +25,8 @@
serial0 = uart0;
ethernet0 = cpsw_emac0;
ethernet1 = cpsw_emac1;
+   d_can0 = dcan0;
+   d_can1 = dcan1;
};
 
cpus {
-- 
1.8.3.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 11/13] ARM: dts: am437x-gp-evm: Add pinctrl sleep states for dcan pins

[Roger Quadros]

From: Dave Gerlach d-gerl...@ti.com

Define pinctrl sleep states for both dcan0 and dcan1 to place pull downs
on the lines to optimize power savings during suspend.

Signed-off-by: Dave Gerlach d-gerl...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 6d03baa..ca9e1ab 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -262,12 +262,26 @@
;
};
 
+   dcan0_sleep: dcan0_sleep_pins {
+   pinctrl-single,pins = 
+   0x178 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+   0x17c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+   ;
+   };
+
dcan1_default: dcan1_default_pins {
pinctrl-single,pins = 
0x180 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* 
uart1_rxd.d_can1_tx */
0x184 (PIN_INPUT_PULLUP | MUX_MODE2) /* 
uart1_txd.d_can1_rx */
;
};
+
+   dcan1_sleep: dcan1_sleep_pins {
+   pinctrl-single,pins = 
+   0x180 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+   0x184 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+   ;
+   };
 };
 
 i2c0 {
@@ -527,13 +541,15 @@
 };
 
 dcan0 {
-   pinctrl-names = default;
+   pinctrl-names = default, sleep;
pinctrl-0 = dcan0_default;
+   pinctrl-1 = dcan0_sleep;
status = okay;
 };
 
 dcan1 {
-   pinctrl-names = default;
+   pinctrl-names = default, sleep;
pinctrl-0 = dcan1_default;
+   pinctrl-1 = dcan1_sleep;
status = okay;
 };
-- 
1.8.3.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/13] ARM: dts: dra7-evm: Add CAN support

[Roger Quadros]

The board has 2 CAN ports but only the first one can be used.
Enable the first CAN port.

The second one cannot be used without hardware modification
so we don't enable the second port.

Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
 arch/arm/boot/dts/dra7-evm.dts | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index e03fbf3..d6b9b27 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -171,6 +171,20 @@
0xd0(PIN_OUTPUT | MUX_MODE0)/* 
gpmc_be0n_cle */
;
};
+
+   dcan1_pins_default: dcan1_pins_default {
+   pinctrl-single,pins = 
+   0x3d4   (PIN_INPUT | MUX_MODE0) /* dcan1_tx */
+   0x3d8   (PIN_INPUT | MUX_MODE0) /* dcan1_rx */
+   ;
+   };
+
+   dcan1_pins_sleep: dcan1_pins_sleep {
+   pinctrl-single,pins = 
+   0x3d4   (PIN_INPUT | MUX_MODE15)/* dcan1_tx */
+   0x3d8   (PIN_INPUT | MUX_MODE15)/* dcan1_rx */
+   ;
+   };
 };
 
 i2c1 {
@@ -529,3 +543,10 @@
ti,no-reset-on-init;
ti,no-idle-on-init;
 };
+
+dcan1 {
+   status = ok;
+   pinctrl-names = default, sleep;
+   pinctrl-0 = dcan1_pins_default;
+   pinctrl-1 = dcan1_pins_sleep;
+};
-- 
1.8.3.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 00/13] net: can: Add can support for TI platforms

[Roger Quadros]

Hi,

Some hardware (TI am43xx) has a buggy RAMINIT DONE mechanism and it might
not always set the DONE bit. This will result in a lockup in 
c_can_hw_raminit_wait_ti(),
so patch 1 adds a timeout mechanism there.

There is a non compliancy within TI platforms with respect to the
layout of the RAMINIT register. The patches 2 and 3 address this issue
and make a flexible but standard way of defining the RAMINIT hardware register
layout in the device tree. The RAMINIT register is accessed using the syscon
regmap framework.

The patches 4 to 13 add adaptation details for am43xx and dra7x Socs and
EVMs.

cheers,
-roger

---

Afzal Mohammed (1):
  arm: dts: am4372: Add dcan nodes

Dave Gerlach (1):
  ARM: dts: am437x-gp-evm: Add pinctrl sleep states for dcan pins

Mugunthan V N (1):
  arm: dts: am437x-gp: Add dcan support

Roger Quadros (10):
  can: c_can_platform: Fix c_can_hw_raminit_ti() and add timeout
  net: can: c_can: Add syscon/regmap RAMINIT mechanism
  net: can: c_can: Add support for START pulse in RAMINIT sequence
  ARM: dts: dra7: Add syscon regmap for CORE CONTROL area
  ARM: dts: DRA7: Add DCAN nodes
  ARM: dts: dra7-evm: Add CAN support
  ARM: dts: dra72-evm: Add CAN support
  ARM: dts: AM43xx: Add aliases to d_can nodes
  ARM: dts: am4372: Add control module syscon node
  ARM: dts: am4372: Add dcan raminit bits

 .../devicetree/bindings/net/can/c_can.txt  |  10 ++
 arch/arm/boot/dts/am4372.dtsi  |  35 ++
 arch/arm/boot/dts/am437x-gp-evm.dts|  42 
 arch/arm/boot/dts/dra7-evm.dts |  21 
 arch/arm/boot/dts/dra7.dtsi|  35 ++
 arch/arm/boot/dts/dra72-evm.dts|  23 
 drivers/net/can/c_can/c_can.h  |  12 ++-
 drivers/net/can/c_can/c_can_platform.c | 120 -
 8 files changed, 270 insertions(+), 28 deletions(-)

-- 
1.8.3.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 3/5] usb: phy: twl4030-usb: Move code from twl4030_phy_power to the runtime PM calls

[Kishon Vijay Abraham I]

Hi Tony,

On Thursday 04 September 2014 10:37 PM, Tony Lindgren wrote:
 * Kishon Vijay Abraham I kis...@ti.com [140904 06:51]:
 Hi Tony,

 On Thursday 28 August 2014 04:58 AM, Tony Lindgren wrote:
 We don't need twl4030_phy_power() any longer now that we have
 the runtime PM calls. Let's get rid of it as it's confusing.
 No functional changes, just move the code and use res instead
 of ret as we are not returning that value.

 Now that you are doing pm_runtime_get_sync in twl4030_phy_init, won't it 
 power
 on the phy even before initializing it (since runtime_resume will be invoked
 even before doing phy_init)?
 
 Yes. The logic being that it should not matter as we are not
 configuring the phy until in twl4030_phy_power_on(). Maybe we
 should add code to make sure the phy is deconfigured initially
 though :)
 
 In twl4030_phy_init() we just want to check the ID pin state to get
 things right initially. In the twl4030-usb case the I2C chip is
 always on, but let's try to get the runtime PM set up like any
 standard Linux driver would do it to avoid confusion.
 
 Even if pm_runtime_get_sync in not done in twl4030_phy_init, phy-core itself
 does pm_runtime_get_sync in phy_init().
 
 Hmm OK. Looking at that, looks like we don't neeed any of these
 custom exports though:
 
 $ git grep phy_pm_runtime | grep EXPORT_SYMBOL
 drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_get);
 drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_get_sync);
 drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_put);
 drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_put_sync);
 drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_allow);
 drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_forbid);
 
 The reasons why I think we don't need the above at all is:
 
 1. We already have a framework for that in Linux runtime PM and we
can follow the standard Linux runtime PM calls and not proxy
them in phy-core.c

The reason for adding these are for providing fine grained control of the PHY
by the controller drivers. In most cases the controller driver determines when
the PHY should be active or idle.
 
 2. We can allow idling the phy properly on the bus it's connected
to, in this case I2C, even if USB driver is not loaded. We
eventually should idle the phy even if usb_add_phy_dev()
failed

yes.. that's why we have ops like phy_power_on to tell when the PHY should be
active. So these PHYs can be idled in probe.
 
 3. There's no actual need for phy-core.c to proxy the runtime
PM calls
 
 So we can and should just let the phy drivers do their own runtime PM
 as needed based on just the phy init, power_on and power_off calls.
 
 Probably the same goes for the regulator_enable in phy-core.c. That
 should be handled in the phy driver as phy-core is already unable
 to handle it properly. For example, for phy-twl4030-usb.c we have
 three regulators to deal with and the phy framework won't have any
 idea how to deal with those.

hmm.. It was modelled for basic PHY drivers that have a single regulator (e.g.,
TI PIPE3 PHY). The idea is not to duplicate getting and enabling regulator in
each of the PHY drivers when it can be abstracted in phy-core.

Thanks
Kishon
--
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 3/3] nand: omap2: Replace pr_err with dev_err

[Ezequiel Garcia]

On 08 Sep 02:57 PM, Roger Quadros wrote:
 Hi Ezequiel,
 
 On 09/08/2014 02:27 PM, Ezequiel Garcia wrote:
  Usage of pr_err is frowned upon, so replace it with dev_err.
  Aditionally, the message on nand_bch_init() error is redundant,
  since proper error is showed if the function fails.
  
  Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar
  ---
   drivers/mtd/nand/omap2.c | 26 ++
   1 file changed, 14 insertions(+), 12 deletions(-)
  
  diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
  index f97a4ff..eb5e898 100644
  --- a/drivers/mtd/nand/omap2.c
  +++ b/drivers/mtd/nand/omap2.c
  @@ -1375,7 +1375,7 @@ static int omap_elm_correct_data(struct mtd_info 
  *mtd, u_char *data,
  erased_ecc_vec = bch16_vector;
  break;
  default:
  -   pr_err(invalid driver configuration\n);
  +   dev_err(info-pdev-dev, invalid driver configuration\n);
  return -EINVAL;
  }
   
  @@ -1446,7 +1446,8 @@ static int omap_elm_correct_data(struct mtd_info 
  *mtd, u_char *data,
  err = 0;
  for (i = 0; i  eccsteps; i++) {
  if (err_vec[i].error_uncorrectable) {
  -   pr_err(nand: uncorrectable bit-flips found\n);
  +   dev_err(info-pdev-dev,
  +   uncorrectable bit-flips found\n);
  err = -EBADMSG;
  } else if (err_vec[i].error_reported) {
  for (j = 0; j  err_vec[i].error_count; j++) {
  @@ -1483,8 +1484,9 @@ static int omap_elm_correct_data(struct mtd_info 
  *mtd, u_char *data,
  1  bit_pos;
  }
  } else {
  -   pr_err(invalid bit-flip @ %d:%d\n,
  -byte_pos, bit_pos);
  +   dev_err(info-pdev-dev,
  +   invalid bit-flip @ %d:%d\n,
  +   byte_pos, bit_pos);
  err = -EBADMSG;
  }
  }
  @@ -1598,13 +1600,13 @@ static bool is_elm_present(struct omap_nand_info 
  *info,
   
  /* check whether elm-id is passed via DT */
  if (!elm_node) {
  -   pr_err(nand: error: ELM DT node not found\n);
  +   dev_err(info-pdev-dev, ELM devicetree node not found\n);
  return false;
  }
  pdev = of_find_device_by_node(elm_node);
  /* check whether ELM device is registered */
  if (!pdev) {
  -   pr_err(nand: error: ELM device not found\n);
  +   dev_err(info-pdev-dev, ELM device not found\n);
  return false;
  }
  /* ELM module available, now configure it */
  @@ -1734,14 +1736,14 @@ static int omap_nand_probe(struct platform_device 
  *pdev)
  /* scan NAND device connected to chip controller */
  nand_chip-options |= pdata-devsize  NAND_BUSWIDTH_16;
  if (nand_scan_ident(mtd, 1, NULL)) {
  -   pr_err(nand device scan failed, may be bus-width mismatch\n);
  +   dev_err(info-pdev-dev, scan failed, may be bus-width 
  mismatch\n);
  err = -ENXIO;
  goto return_error;
  }
   
  /* check for small page devices */
  if ((mtd-oobsize  64)  (pdata-ecc_opt != OMAP_ECC_HAM1_CODE_HW)) {
  -   pr_err(small page devices are not supported\n);
  +   dev_err(info-pdev-dev, small page devices are not 
  supported\n);
  err = -EINVAL;
  goto return_error;
  }
  @@ -1959,7 +1961,6 @@ static int omap_nand_probe(struct platform_device 
  *pdev)
  nand_chip-ecc.bytes,
  ecclayout);
  if (!nand_chip-ecc.priv) {
  -   pr_err(nand: error: unable to use s/w BCH library\n);
 
 Where would the error be printed in this case?
 

Well, nand_bch_init() has a lot of messages for the errors, but I just noticed
some cases where there's no message printed. Would you prefer to leave these
untouched?

 I also noticed a similar message in the OMAP_ECC_BCH4_CODE_HW_DETECTION_SW 
 case.
 And it seems to be missing a goto return_error there.
 

Argh, right. I'll have to resend this one.
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
--
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 v8 00/18] 8250-core based serial driver for OMAP + DMA

[Frans Klaver]

Hi,

On Fri, Sep 05, 2014 at 09:02:35PM +0200, Sebastian Andrzej Siewior wrote:
 This is my complete queue fo the omap serial driver based on the 8250 core
 code. I played with it on beagle bone, am335x-evm and dra7xx including DMA.
 The runtime-pm pieces look now bug-compatible with the omap-serial driver.
 Besides the runtime-om improvement I also fixed a few corner cases for the
 TX-DMA problem. The DMA fixes (in edma and omap-dma) were dropped and the
 problem has been in 8250-dma via patch #13.

Thanks for the respin. I've just tested the series a bit. Here's some
things I ran into.

- Basic console use is better than the previous series. It behaves
  pretty much like the omap-serial implementation.

- ncurses based applications (vi, less) don't play nice for me on the
  console with this series. less doesn't show me anything. vi doesn't
  return to console properly.

- I seem seem to get stuck in a serial8250: too much work for irq%d
  loop somewhat reliably. We have a rather demanding application with
  typically somewhere between 600 and 1000 byte packets being sent at
  240Hz (roughly somewhere between 1.5 and 2 Mb/s). We run at baudrate
  3500k. I get into this too much work thing already when running at
  300 bytes per packet.

I hope this is of some use to you. I'll do more testing later.

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

[PATCH] ARM: omap: fix Kconfig warning

[Arnd Bergmann]

A small mistake during the recent Kconfig cleanup has led
to a harmless warning for OMAP1:

warning: (ARCH_OMAP1) selects ARCH_OMAP which has unmet direct dependencies 
(ARCH_MULTI_V6 || ARCH_MULTI_V7)

We can easily avoid that by moving the ARCH_OMAP symbol outside of the
OMAP2 submenu.

Signed-off-by: Arnd Bergmann a...@arndb.de

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index e7189dcc9309..30d787e99e1a 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -1,9 +1,9 @@
-menu TI OMAP/AM/DM/DRA Family
-   depends on ARCH_MULTI_V6 || ARCH_MULTI_V7
-
 config ARCH_OMAP
bool
 
+menu TI OMAP/AM/DM/DRA Family
+   depends on ARCH_MULTI_V6 || ARCH_MULTI_V7
+
 config ARCH_OMAP2
bool TI OMAP2
depends on ARCH_MULTI_V6

--
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 v8 00/18] 8250-core based serial driver for OMAP + DMA

[Sebastian Andrzej Siewior]

* Frans Klaver | 2014-09-08 16:46:18 [+0200]:

- ncurses based applications (vi, less) don't play nice for me on the
  console with this series. less doesn't show me anything. vi doesn't
  return to console properly.

Can you give a test case 

- I seem seem to get stuck in a serial8250: too much work for irq%d
  loop somewhat reliably. We have a rather demanding application with
  typically somewhere between 600 and 1000 byte packets being sent at
  240Hz (roughly somewhere between 1.5 and 2 Mb/s). We run at baudrate
  3500k. I get into this too much work thing already when running at
  300 bytes per packet.

Do you get this message also at lower baud rates, say 115200?

What I am trying to understand is why you are spinning in the handler. 
_With_ DMA you should hardly get into the serial handler under normal 
conditions. Running at 3.5MB/sec should give one byte every 2.8us and
48 Bytes every ~137us. This looks like plenty of time to get  out of
the handler. My *guess* is that serial8250_handle_irq() has IIR often
set to timeout and you end up fetching byte after byte. 

This patch should protocol when and why you got into the handler.

diff --git a/drivers/tty/serial/8250/8250_core.c 
b/drivers/tty/serial/8250/8250_core.c
index 7111b22de000..59852069e4a0 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1583,6 +1583,7 @@ int serial8250_handle_irq(struct uart_port *port, 
unsigned int iir)
status = serial_port_in(port, UART_LSR);
 
DEBUG_INTR(status = %x..., status);
+   trace_printk(l%d IIR %x LSR %x\n, port-line, iir, status);
 
if (status  (UART_LSR_DR | UART_LSR_BI)) {
if (up-dma)
@@ -1707,6 +1708,7 @@ static irqreturn_t serial8250_interrupt(int irq, void 
*dev_id)
 
spin_unlock(i-lock);
 
+   trace_printk(%d e\n, irq);
DEBUG_INTR(end.\n);
 
return IRQ_RETVAL(handled);

I hope this is of some use to you. I'll do more testing later.

Which SoC do you use and do you have DMA enabled?

Thanks,
Frans

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

Re: [PATCH] ARM: omap: fix Kconfig warning

[Tony Lindgren]

* Arnd Bergmann a...@arndb.de [140908 08:01]:
 A small mistake during the recent Kconfig cleanup has led
 to a harmless warning for OMAP1:
 
 warning: (ARCH_OMAP1) selects ARCH_OMAP which has unmet direct dependencies 
 (ARCH_MULTI_V6 || ARCH_MULTI_V7)
 
 We can easily avoid that by moving the ARCH_OMAP symbol outside of the
 OMAP2 submenu.

OK I made a similar patch, but I moved it into plat-omap/Kconfig
as it's also used by omap1. The regression was probably caused by
commit 21278aeafbfa (ARM: use menuconfig for sub-arch menus).

If that works for you, I'll verify the regression causing commit
and post it with a description.

Regards,

Tony

--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -1,9 +1,6 @@
 menu TI OMAP/AM/DM/DRA Family
depends on ARCH_MULTI_V6 || ARCH_MULTI_V7
 
-config ARCH_OMAP
-   bool
-
 config ARCH_OMAP2
bool TI OMAP2
depends on ARCH_MULTI_V6
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -1,3 +1,6 @@
+config ARCH_OMAP
+   bool
+
 if ARCH_OMAP
 
 menu TI OMAP Common Features
--
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: [BUG(?)] Kconfig warning when selecting ARCH_OMAP1

[Tony Lindgren]

* Andreas Ruprecht rup...@einserver.de [140907 11:39]:
 Hi all,
 
 I found the following inconsistency in the Kconfig dependencies for
 ARCH_OMAP1 during my research, and as I don't know the exact requirements
 for the OMAP configuration (and how the dependencies could be restructured
 to get rid of the warning), I figured you might be able to help me out.
 
 When selecting ARCH_OMAP1 as the system type, Kconfig issues a warning:
 warning: (ARCH_OMAP1) selects ARCH_OMAP which has unmet direct
 dependencies (ARCH_MULTI_V6 || ARCH_MULTI_V7)
 
 When I investigated this further, I found the reason to be as follows:
 - ARCH_OMAP1 selects ARCH_OMAP
 - ARCH_OMAP depends on ARCH_MULTI_V6 || ARCH_MULTI_V7
 - ARCH_MULTI_V{6,7} depend on ARCH_MULTIPLATFORM
 - ARCH_MULTIPLATFORM is in the same choice (System Type - ARM system type)
 as ARCH_OMAP1, and thus the two can never be enabled at the same time.
 
 Might there be an easy way to resolve this inconsistency by restructuring
 the Kconfig dependencies?

Probably to move the config ARCH_OMAP to plat-omap/Kconfig. Suggested fix
being discussed in the [PATCH] ARM: omap: fix Kconfig warning thread FYI.

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 3/3] mfd: palmas: Add support for optional wakeup

[Nishanth Menon]

On 23:13-20140905, Thomas Gleixner wrote:
 On Fri, 5 Sep 2014, Nishanth Menon wrote:
  +   if (!palmas-wakeirq)
  +   goto no_wake_irq;
  +
  +   ret = devm_request_irq(palmas-dev, palmas-wakeirq,
  +  palmas_wake_irq,
  +  IRQF_ONESHOT | pdata-irq_flags,
 
 Why is this marked IRQF_ONESHOT?

Uggh.. should have dropped it. my bad.. removed in the revision below.
Thanks for catching it.
 
  +  dev_name(palmas-dev),
  +  palmas);
  +   if (ret  0)
  +   goto err_i2c;
 
 Why err and not doing the obvious clearing of palmas-wakeirq and
 keep at least the i2c functional?
Hmmm.. true.. we can stay alive even though without wakeup capability if
someone messes up configuration..

Fixed version below. Let me know if you are ok with the following.
8
From 6da58ac66eedea46cf7282c6644c76c8f328f5ee Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Tue, 12 Aug 2014 12:00:52 -0500
Subject: [PATCH V3 3/3] mfd: palmas: Add support for optional wakeup

With the recent pinctrl-single changes, omaps can treat wake-up events
from deeper power  states as interrupts.

This is to handle the case where the system needs two interrupt
sources when SoC is in deep sleep(1 to exit from deep power mode such
as sleep, and other from the module handling the actual event during
system active state). This is not the same as threaded interrupts as the
wakeup interrupt source is used only as part of deeper power saving
mode.

Let's add support for the optional second interrupt for wake-up
events. And then SoC can wakeup and handle the event using it's
regular handler.

This is similar in approach to commit 2a0b965cfb6e (serial: omap: Add
support for optional wake-up)

Signed-off-by: Nishanth Menon n...@ti.com
---
 drivers/mfd/palmas.c   |   62 
 include/linux/mfd/palmas.h |2 ++
 2 files changed, 64 insertions(+)

diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 28cb048..de7d204 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -24,6 +24,7 @@
 #include linux/mfd/core.h
 #include linux/mfd/palmas.h
 #include linux/of_device.h
+#include linux/of_irq.h
 
 static const struct regmap_config palmas_regmap_config[PALMAS_NUM_CLIENTS] = {
{
@@ -326,6 +327,16 @@ static struct regmap_irq_chip tps65917_irq_chip = {
PALMAS_INT1_MASK),
 };
 
+static irqreturn_t palmas_wake_irq(int irq, void *_palmas)
+{
+   /*
+* Return Not handled so that interrupt is disabled.
+* Level event ensures that the event is eventually handled
+* by the appropriate chip handler already registered
+*/
+   return IRQ_NONE;
+}
+
 int palmas_ext_control_req_config(struct palmas *palmas,
enum palmas_external_requestor_id id,  int ext_ctrl, bool enable)
 {
@@ -409,6 +420,7 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
pdata-mux_from_pdata = 1;
pdata-pad2 = prop;
}
+   pdata-wakeirq = irq_of_parse_and_map(node, 1);
 
/* The default for this register is all masked */
ret = of_property_read_u32(node, ti,power-ctrl, prop);
@@ -521,6 +533,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
i2c_set_clientdata(i2c, palmas);
palmas-dev = i2c-dev;
palmas-irq = i2c-irq;
+   palmas-wakeirq = pdata-wakeirq;
 
match = of_match_device(of_palmas_match_tbl, i2c-dev);
 
@@ -587,6 +600,25 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
if (ret  0)
goto err_i2c;
 
+   if (!palmas-wakeirq)
+   goto no_wake_irq;
+
+   ret = devm_request_irq(palmas-dev, palmas-wakeirq,
+  palmas_wake_irq,
+  pdata-irq_flags,
+  dev_name(palmas-dev),
+  palmas);
+   if (ret  0) {
+   dev_err(palmas-dev, Invalid wakeirq(%d) (res: %d), skiping\n,
+   palmas-wakeirq, ret);
+   palmas-wakeirq = 0;
+   } else {
+   /* We use wakeirq only during suspend-resume path */
+   device_set_wakeup_capable(palmas-dev, true);
+   disable_irq_nosync(palmas-wakeirq);
+   }
+
+no_wake_irq:
 no_irq:
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
@@ -706,6 +738,34 @@ static int palmas_i2c_remove(struct i2c_client *i2c)
return 0;
 }
 
+static int palmas_i2c_suspend(struct i2c_client *i2c,  pm_message_t mesg)
+{
+   struct palmas *palmas = i2c_get_clientdata(i2c);
+   struct device *dev = i2c-dev;
+
+   if (!palmas-wakeirq)
+   return 0;
+
+   if (device_may_wakeup(dev))
+   enable_irq(palmas-wakeirq);
+
+   return 0;
+}
+
+static int palmas_i2c_resume(struct i2c_client *i2c)
+{
+ 

Re: [PATCH 00/10] ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle

[Nishanth Menon]

On 08/27/2014 02:15 PM, Kevin Hilman wrote:
 Nishanth Menon n...@ti.com writes:
 
 The following series are various fixes and improvements for
 supporting suspend-to-ram. This depends on the following for basic 
 functionality:
 series 1/6 where powerdomain fixes were involved.
 
 I had a look through this series, and it looks good overall.  I think Daniel
 needs to weigh in on the CPUidle driver, otherwise.
 
 Reviewed-by: Kevin Hilman khil...@linaro.org
 
 I also tested on omap5uevm with the pm_debug/wakeup_timer_seconds patch.
 
 Tested-by: Kevin Hilman khil...@linaro.org
 
 Kevin
 

I am dropping cpuidle patch for the moment, and sending remaining
stuff to Tony for merge with Kevin's Reviewed and Tested. we will send
cpuidle once we have Daniel's response.

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

Re: [PATCH 0/3] ARM: OMAP5+: pdata quirks for pinctrl

[Nishanth Menon]

On 08/22/2014 08:55 AM, Nishanth Menon wrote:
 The following series are various fixes and improvements for daisychain
 support in OMAP5+ using pinctrl framework similar to that done for
 OMAP3+
 
 This is part 3/6 series which eventually enables framework for
 suspend-to-ram and cpuidle for OMAP5 and DRA7
 
 Each of series is based on v3.17-rc1 and this specific series is available:
 weblink: 
 https://github.com/nmenon/linux-2.6-playground/commits/push/v3.17/prm-pdata-quirks
 
 git repo: https://github.com/nmenon/linux-2.6-playground.git 
 push/v3.17/prm-pdata-quirks
 
 An complete integrated branch is available here: 
 https://github.com/nmenon/linux-2.6-playground/commits/testing/v3.17/cpu-idle-suspend-dra7-omap5-framework
 
 Minor note: thanks to existing style in pdata-quirks, new entries
 continue to possess 'over 80 character' checkpatch warnings
 
 Keerthy (1):
   ARM: AM437x: use pdata quirks for pinctrl information
 
 Nishanth Menon (2):
   ARM: OMAP5: use pdata quirks for pinctrl information
   ARM: DRA7: use pdata quirks for pinctrl information
 
  arch/arm/mach-omap2/pdata-quirks.c |   10 ++
  1 file changed, 10 insertions(+)
 

Since there are no further comments (and the pinctrl side of the fixes
were accepted by Linus W[1], will send this for merge to Tony.


[1] http://marc.info/?l=linux-kernelm=140871666506706w=2 (acked by
Tony, picked by Linus)

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

Re: [PATCH v8 00/18] 8250-core based serial driver for OMAP + DMA

[Sebastian Andrzej Siewior]

* Sebastian Andrzej Siewior | 2014-09-08 17:15:01 [+0200]:

* Frans Klaver | 2014-09-08 16:46:18 [+0200]:

- ncurses based applications (vi, less) don't play nice for me on the
  console with this series. less doesn't show me anything. vi doesn't
  return to console properly.

Can you give a test case 

Okay. less. My am335x-evm freezes after a while for no obvious reason.
The data that hits the RX fifo is still received but the TX won't do
anything. The DMA request is pending, the FIFO level is @64 bytes and
the UART doesn't make any progress.
On beagle-board I see what you described: less on a file and nothing
happens.
Disabling DMA seems to help fix the problem omap3. Nothing changes for
am335x.

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

Re: [PATCH 3/5] usb: phy: twl4030-usb: Move code from twl4030_phy_power to the runtime PM calls

[Tony Lindgren]

* Kishon Vijay Abraham I kis...@ti.com [140908 07:26]:
 Hi Tony,
 
 On Thursday 04 September 2014 10:37 PM, Tony Lindgren wrote:
  * Kishon Vijay Abraham I kis...@ti.com [140904 06:51]:
  Hi Tony,
 
  On Thursday 28 August 2014 04:58 AM, Tony Lindgren wrote:
  We don't need twl4030_phy_power() any longer now that we have
  the runtime PM calls. Let's get rid of it as it's confusing.
  No functional changes, just move the code and use res instead
  of ret as we are not returning that value.
 
  Now that you are doing pm_runtime_get_sync in twl4030_phy_init, won't it 
  power
  on the phy even before initializing it (since runtime_resume will be 
  invoked
  even before doing phy_init)?
  
  Yes. The logic being that it should not matter as we are not
  configuring the phy until in twl4030_phy_power_on(). Maybe we
  should add code to make sure the phy is deconfigured initially
  though :)
  
  In twl4030_phy_init() we just want to check the ID pin state to get
  things right initially. In the twl4030-usb case the I2C chip is
  always on, but let's try to get the runtime PM set up like any
  standard Linux driver would do it to avoid confusion.
  
  Even if pm_runtime_get_sync in not done in twl4030_phy_init, phy-core 
  itself
  does pm_runtime_get_sync in phy_init().
  
  Hmm OK. Looking at that, looks like we don't neeed any of these
  custom exports though:
  
  $ git grep phy_pm_runtime | grep EXPORT_SYMBOL
  drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_get);
  drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_get_sync);
  drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_put);
  drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_put_sync);
  drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_allow);
  drivers/phy/phy-core.c:EXPORT_SYMBOL_GPL(phy_pm_runtime_forbid);
  
  The reasons why I think we don't need the above at all is:
  
  1. We already have a framework for that in Linux runtime PM and we
 can follow the standard Linux runtime PM calls and not proxy
 them in phy-core.c
 
 The reason for adding these are for providing fine grained control of the PHY
 by the controller drivers. In most cases the controller driver determines when
 the PHY should be active or idle.

Yeah but having the USB controller driver attempt to manage the
PHY did not work well. That all had to be ripped out of musb driver
in commits 30a70b026b4c and 8b2bc2c9351b.

I took a brief look at trying to fix musb + twl4030-usb runtime PM
so the USB controller driver would manage it. And that's probably
so far the only USB driver and PHY controller combo where we've had
runtime PM working in various forms in the mainline kernel.

Attempting to make the USB controller driver manage the runtime PM
for the PHY would make things unnecesarily complicated. The PHY can
sleep since it's on the I2C bus. So we'd have to implement some kind
of completion checking all over the place to attempt to keep things
in sync.

Meanwhile, having independent PHY drivers doing their own runtime
PM avoids all these issues. At minimum, it just means the PHY
driver needs to implement PHY init, power_on and power_off functions
like they already do. Then as needed, the PHY driver can implement
it's runtime PM calls.

I think what does make sense to do in the PHY framework is to keep
track of the PHY state in a generic way, and have a generic way of
telling the USB controller driver of the PHY state. That might allow
us eventually remove things like omap_musb_mailbox() calls.

And the custom exported functions above are unused AFAIK, so let's
just remove them.

  2. We can allow idling the phy properly on the bus it's connected
 to, in this case I2C, even if USB driver is not loaded. We
 eventually should idle the phy even if usb_add_phy_dev()
 failed
 
 yes.. that's why we have ops like phy_power_on to tell when the PHY should be
 active. So these PHYs can be idled in probe.

Yeah phy_power_on et al are good, and needed. But the runtime PM
should be implemented in the actual PHY drivers because of the
reasons above.
 
  3. There's no actual need for phy-core.c to proxy the runtime
 PM calls
  
  So we can and should just let the phy drivers do their own runtime PM
  as needed based on just the phy init, power_on and power_off calls.
  
  Probably the same goes for the regulator_enable in phy-core.c. That
  should be handled in the phy driver as phy-core is already unable
  to handle it properly. For example, for phy-twl4030-usb.c we have
  three regulators to deal with and the phy framework won't have any
  idea how to deal with those.
 
 hmm.. It was modelled for basic PHY drivers that have a single regulator 
 (e.g.,
 TI PIPE3 PHY). The idea is not to duplicate getting and enabling regulator in
 each of the PHY drivers when it can be abstracted in phy-core.

There's no need to for that AFAIK. That too can be implemented in the
PHY driver as part of runtime PM as needed.

Regards,

Tony
--
To 

Re: [PATCH 05/13] ARM: dts: DRA7: Add DCAN nodes

[Sergei Shtylyov]

Hello.

On 9/8/2014 6:10 PM, Roger Quadros wrote:


The SoC supports 2 DCAN nodes. Add them.



Signed-off-by: Roger Quadros rog...@ti.com
---
  arch/arm/boot/dts/dra7.dtsi | 30 ++
  1 file changed, 30 insertions(+)



diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 370009e..4ce1a4f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi

[...]

@@ -1267,6 +1269,34 @@
ti,irqs-skip = 10 133 139 140;
ti,irqs-safe-map = 0;
};
+
+   dcan1: d_can@481cc000 {


   The ePAPR standard has something to say here:


The name of a node should be somewhat generic, reflecting the function of the 
device and not its precise programming model. If appropriate, the name should 
be one of the following choices:


• can



+   compatible = bosch,d_can;
+   ti,hwmods = dcan1;
+   reg = 0x4ae3c000 0x2000,
+ 0x558 0x4; /* index to RAMINIT reg within 
syscon */
+   raminit-syscon = dra7_ctrl_core;
+   raminit-start-bit = 3;
+   raminit-done-bit = 1;
+   raminit-pulse;


   Hm, aren't the above 4 properties vendor specific? If so, they should 
start with a vendor prefix and comma.



+   interrupts = GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH;
+   clocks = dcan1_sys_clk_mux;
+   status = disabled;
+   };


WBR, Sergei

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

Re: [PATCH 08/18] tty: serial: Add 8250-core based omap driver

[Tony Lindgren]

* Sebastian Andrzej Siewior bige...@linutronix.de [140905 12:03]:
 
 It has been only tested as console UART on am335x-evm, dra7-evm and
 beagle bone. I also did some longer raw-transfers to meassure the load.

You may want to also update this with beagleboard xm now too?

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 11/18] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx

[Tony Lindgren]

* Sebastian Andrzej Siewior bige...@linutronix.de [140905 12:28]:
 This problem has not been seen on DRA7 or beaglebone (OMAP3). I am not
 sure if this is UART-IP core specific or DMA engine.

Maybe check this comment for future reference too because
beaglebone and bealeboard do different things for PM.. Do
you mean Beaglebone or beagleboard? Or both?

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 11/18] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx

[Sebastian Andrzej Siewior]

On 09/08/2014 06:41 PM, Tony Lindgren wrote:
 * Sebastian Andrzej Siewior bige...@linutronix.de [140905 12:28]:
 This problem has not been seen on DRA7 or beaglebone (OMAP3). I am not
 sure if this is UART-IP core specific or DMA engine.
 
 Maybe check this comment for future reference too because
 beaglebone and bealeboard do different things for PM.. Do
 you mean Beaglebone or beagleboard? Or both?

Beagle bone (am335x) has the problem.
Beagle board xm (omap3) does not have the problem.
So let me replace beaglebone with beagle board xm

 
 Regards,
 
 Tony
 

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

Re: [PATCH v6 5/7] net: cpsw: Add am33xx MACID readout

[Tony Lindgren]

* Markus Pargmann m...@pengutronix.de [140907 10:20]:
 This patch adds a function to get the MACIDs from the am33xx SoC
 control module registers which hold unique vendor MACIDs. This is only
 used if of_get_mac_address() fails to get a valid mac address.
...

 @@ -1928,8 +1960,16 @@ static int cpsw_probe_dt(struct cpsw_platform_data 
 *data,
PHY_ID_FMT, mdio-name, phyid);
  
   mac_addr = of_get_mac_address(slave_node);
 - if (mac_addr)
 + if (mac_addr) {
   memcpy(slave_data-mac_addr, mac_addr, ETH_ALEN);
 + } else {
 + if (of_machine_is_compatible(ti,am33xx)) {
 + ret = cpsw_am33xx_cm_get_macid(pdev-dev, i,
 + slave_data-mac_addr);
 + if (ret)
 + return ret;
 + }
 + }
  
   slave_data-phy_if = of_get_phy_mode(slave_node);
   if (slave_data-phy_if  0) {

Thanks for updating this, this looks more future proof for adding
the dra7 related patch.

For the long run, it probably makes sense to add SoC specific
compatible values such as ti,cpsw-am3350 and so on. Then the
mac address functions can be initialized based on the of_device_id
entry for .data. The wiring is cleary SoC specific here.

So for the purpose of this series, I'm fine with this series,
please feel free to add for this patch:

Acked-by: Tony Lindgren t...@atomide.com

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

[GIT PULL 1/2] ARM: OMAP 4+: powerdomain fixes

[Nishanth Menon]

Hi Tony,
Please pull the following changes.
Series discussed in:
http://marc.info/?l=linux-kernelm=140871554106082w=2
Includes (v2 patch) https://patchwork.kernel.org/patch/4790541/
Status: Acked by Santosh and Reviewed-by Kevin  

These could go into your tree for the branch omap-for-v3.18/fixes-not-urgent

The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:

  Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)

are available in the git repository at:

  https://github.com/nmenon/linux-2.6-playground.git 
pull/v3.18/powerdomain-fixes

for you to fetch changes up to 3e6a1c945950140926dd6e2cc667893de0a7fe3b:

  ARM: OMAP4+: PM: Use only valid low power state for CPU hotplug (2014-09-08 
11:22:43 -0500)


Nishanth Menon (7):
  ARM: OMAP: DRA7: powerdomain data: fix powerdomain powerstate
  ARM: OMAP5: powerdomain data: fix powerdomain powerstate
  ARM: OMAP2+: powerdomain: pwrdm_for_each_clkdm iterate only valid clkdms
  ARM: OMAP2+: powerdomain: introduce logic for finding valid power domain
  ARM: OMAP4+: PM: Make logic state programmable
  ARM: OMAP4+: PM: use only valid low power state for suspend
  ARM: OMAP4+: PM: Use only valid low power state for CPU hotplug

 arch/arm/mach-omap2/omap-mpuss-lowpower.c   |4 ++
 arch/arm/mach-omap2/pm44xx.c|9 ++-
 arch/arm/mach-omap2/powerdomain.c   |   79 ++-
 arch/arm/mach-omap2/powerdomain.h   |4 ++
 arch/arm/mach-omap2/powerdomains54xx_data.c |   12 ++--
 arch/arm/mach-omap2/powerdomains7xx_data.c  |   14 ++---
 6 files changed, 106 insertions(+), 16 deletions(-)

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

[GIT PULL 2/2] ARM: OMAP4+: PRM fixes, DRA7 suspend-to-ram support

[Nishanth Menon]

Hi Tony,
Please pull the following changes.

part 2: ARM: OMAP3+: PRM: fix up prm_handling
http://marc.info/?l=linux-kernelm=140871580806186w=2
Status: Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

part 3: ARM: OMAP5+: pdata quirks for pinctrl
http://marc.info/?l=linux-kernelm=140871598306262w=2
Status: Sending pull based on 
http://marc.info/?l=linux-kernelm=140871666506706w=2 (Acked by Tony, Pulled 
by Linus W)

part 5: ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle
http://marc.info/?l=linux-kernelm=140871637106555w=2
Status: picked up kevin's tested and reviewed-by, dropped cpuidle for this pull

These could go into your tree for the branch  omap-for-v3.18/soc

The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:

  Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)

are available in the git repository at:

  https://github.com/nmenon/linux-2.6-playground.git pull/v3.18/for-omap-soc

for you to fetch changes up to 628ed4717000789bff827c5799d1aac4c1008541:

  ARM: OMAP5: Add hook in SoC initcalls to enable pm initialization (2014-09-08 
11:38:43 -0500)


Keerthy (1):
  ARM: AM437x: use pdata quirks for pinctrl information

Nishanth Menon (8):
  ARM: OMAP4+: prminst: provide function to find prm_dev instance offset
  ARM: OMAP4: PRM: use the generic prm_inst to allow logic to be abstracted
  ARM: OMAP4+: PRM: register interrupt information from DT
  ARM: OMAP4+: PRM: remove wkup event
  ARM: OMAP4+: PRM: Enable wakeup capability for OMAP5, DRA7
  ARM: OMAP3+: PRM: register interrupt information from DT
  ARM: OMAP5: use pdata quirks for pinctrl information
  ARM: DRA7: use pdata quirks for pinctrl information

Rajendra Nayak (2):
  ARM: OMAP5 / DRA7: PM: Avoid all SAR saves
  ARM: OMAP5 / DRA7: Enable CPU RET on suspend

Santosh Shilimkar (6):
  ARM: OMAP5 / DRA7: PM: Update CPU context register offset
  ARM: OMAP5 / DRA7: PM: Set MPUSS-EMIF clock-domain static dependency
  ARM: OMAP5 / DRA7: PM / wakeupgen: Enables ES2 PM mode by default
  ARM: OMAP5 / DRA7: PM: Enable Mercury retention mode on CPUx powerdomains
  ARM: OMAP5 / DRA7: PM: Provide a dummy startup function for CPU hotplug
  ARM: OMAP5: Add hook in SoC initcalls to enable pm initialization

 arch/arm/mach-omap2/common.h  |2 +-
 arch/arm/mach-omap2/io.c  |3 +
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |  102 -
 arch/arm/mach-omap2/omap-secure.h |1 +
 arch/arm/mach-omap2/omap-wakeupgen.c  |   20 +-
 arch/arm/mach-omap2/omap-wakeupgen.h  |1 +
 arch/arm/mach-omap2/pdata-quirks.c|   10 +++
 arch/arm/mach-omap2/pm.h  |1 +
 arch/arm/mach-omap2/pm44xx.c  |   48 --
 arch/arm/mach-omap2/prm3xxx.c |   18 +
 arch/arm/mach-omap2/prm44xx.c |   90 +
 arch/arm/mach-omap2/prminst44xx.c |   40 ++-
 arch/arm/mach-omap2/prminst44xx.h |3 +
 13 files changed, 275 insertions(+), 64 deletions(-)

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

Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Grazvydas Ignotas]

Hi,

On Sat, Sep 6, 2014 at 12:15 AM, Nishanth Menon n...@ti.com wrote:

 Hi,

 Updated patch below:
 Do let me know if this is ok with folks.

 ---8
 From 1b9e11834dac2bd75c396aa7495c806b027653fe Mon Sep 17 00:00:00 2001
 From: Rajendra Nayak rna...@ti.com
 Date: Mon, 27 May 2013 15:46:44 +0530
 Subject: [PATCH V2 7/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

 On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
 and instead attempt a CPU RET and side effect, MPU RET in suspend.

 NOTE: the hardware was originally designed to be capable of achieving
 deep power states such as OFF and OSWR, however due to various issues
 and risks, deepest valid state was determined to be CSWR - hence we use

Would be great to have some more details here..
So there is no hope for OFF mode on OMAP5?


-- 
Gražvydas
--
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 v8 00/18] 8250-core based serial driver for OMAP + DMA

[Tony Lindgren]

* Sebastian Andrzej Siewior bige...@linutronix.de [140905 12:03]:
 This is my complete queue fo the omap serial driver based on the 8250 core
 code. I played with it on beagle bone, am335x-evm and dra7xx including DMA.
 The runtime-pm pieces look now bug-compatible with the omap-serial driver.
 Besides the runtime-om improvement I also fixed a few corner cases for the
 TX-DMA problem. The DMA fixes (in edma and omap-dma) were dropped and the
 problem has been in 8250-dma via patch #13.
 
 The whole queue is available at
   git://git.breakpoint.cc/bigeasy/linux.git uart_v8

Gave the above branch a quick try, but it again does not idle for
my omap3 test cases. It seems that now the cm_idlest1_core sdma
bit is blocking deeper idle states. Is that the correct branch
to use?

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 04/13] ARM: dts: dra7: Add syscon regmap for CORE CONTROL area

[Tony Lindgren]

* Roger Quadros rog...@ti.com [140908 07:11]:
 Display and DCAN drivers use syscon regmap to access some registers
 in the CORE control area. Add the syscon regmap node for this
 area.

Please repost the .dts changes in a separate series to avoid
conflicts.

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 v8 00/18] 8250-core based serial driver for OMAP + DMA

[Tony Lindgren]

* Tony Lindgren t...@atomide.com [140908 10:41]:
 * Sebastian Andrzej Siewior bige...@linutronix.de [140905 12:03]:
  This is my complete queue fo the omap serial driver based on the 8250 core
  code. I played with it on beagle bone, am335x-evm and dra7xx including DMA.
  The runtime-pm pieces look now bug-compatible with the omap-serial driver.
  Besides the runtime-om improvement I also fixed a few corner cases for the
  TX-DMA problem. The DMA fixes (in edma and omap-dma) were dropped and the
  problem has been in 8250-dma via patch #13.
  
  The whole queue is available at
git://git.breakpoint.cc/bigeasy/linux.git uart_v8
 
 Gave the above branch a quick try, but it again does not idle for
 my omap3 test cases. It seems that now the cm_idlest1_core sdma
 bit is blocking deeper idle states. Is that the correct branch
 to use?

Never mind. User error. I forgot to apply my own patch for force
idling the UARTs for the omap hwmod. And the sdma bit clears if
I do sleep 5 before attempting to read the sysfs entry..

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] ARM: omap: fix Kconfig warning

[Arnd Bergmann]

On Monday 08 September 2014 08:34:00 Tony Lindgren wrote:
 * Arnd Bergmann a...@arndb.de [140908 08:01]:
  A small mistake during the recent Kconfig cleanup has led
  to a harmless warning for OMAP1:
  
  warning: (ARCH_OMAP1) selects ARCH_OMAP which has unmet direct dependencies 
  (ARCH_MULTI_V6 || ARCH_MULTI_V7)
  
  We can easily avoid that by moving the ARCH_OMAP symbol outside of the
  OMAP2 submenu.
 
 OK I made a similar patch, but I moved it into plat-omap/Kconfig
 as it's also used by omap1. The regression was probably caused by
 commit 21278aeafbfa (ARM: use menuconfig for sub-arch menus).
 
 If that works for you, I'll verify the regression causing commit
 and post it with a description.

Yes, sounds good. Your version is better than mind.

Arnd

 
 --- a/arch/arm/mach-omap2/Kconfig
 +++ b/arch/arm/mach-omap2/Kconfig
 @@ -1,9 +1,6 @@
  menu TI OMAP/AM/DM/DRA Family
   depends on ARCH_MULTI_V6 || ARCH_MULTI_V7
  
 -config ARCH_OMAP
 - bool
 -
  config ARCH_OMAP2
   bool TI OMAP2
   depends on ARCH_MULTI_V6
 --- a/arch/arm/plat-omap/Kconfig
 +++ b/arch/arm/plat-omap/Kconfig
 @@ -1,3 +1,6 @@
 +config ARCH_OMAP
 + bool
 +
  if ARCH_OMAP
  
  menu TI OMAP Common Features

--
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 v8 00/18] 8250-core based serial driver for OMAP + DMA

[Frans Klaver]

On Mon, Sep 08, 2014 at 06:33:13PM +0200, Sebastian Andrzej Siewior wrote:
 * Sebastian Andrzej Siewior | 2014-09-08 17:15:01 [+0200]:
 
 * Frans Klaver | 2014-09-08 16:46:18 [+0200]:
 
 - ncurses based applications (vi, less) don't play nice for me on the
   console with this series. less doesn't show me anything. vi doesn't
   return to console properly.
 
 Can you give a test case 
 
 Okay. less. My am335x-evm freezes after a while for no obvious reason.
 The data that hits the RX fifo is still received but the TX won't do
 anything. The DMA request is pending, the FIFO level is @64 bytes and
 the UART doesn't make any progress.
 On beagle-board I see what you described: less on a file and nothing
 happens.

Exactly that, yes.

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

Re: [PATCH v8 00/18] 8250-core based serial driver for OMAP + DMA

[Frans Klaver]

On Mon, Sep 08, 2014 at 05:15:01PM +0200, Sebastian Andrzej Siewior wrote:
 * Frans Klaver | 2014-09-08 16:46:18 [+0200]:
 
 - I seem seem to get stuck in a serial8250: too much work for irq%d
   loop somewhat reliably. We have a rather demanding application with
   typically somewhere between 600 and 1000 byte packets being sent at
   240Hz (roughly somewhere between 1.5 and 2 Mb/s). We run at baudrate
   3500k. I get into this too much work thing already when running at
   300 bytes per packet.
 
 Do you get this message also at lower baud rates, say 115200?

I don't get this message at lower data rates. Haven't tested lower baud
rates yet.

 What I am trying to understand is why you are spinning in the handler. 
 _With_ DMA you should hardly get into the serial handler under normal 
 conditions. Running at 3.5MB/sec should give one byte every 2.8us and
 48 Bytes every ~137us. This looks like plenty of time to get  out of
 the handler. My *guess* is that serial8250_handle_irq() has IIR often
 set to timeout and you end up fetching byte after byte. 
 
 This patch should protocol when and why you got into the handler.

 diff --git a/drivers/tty/serial/8250/8250_core.c 
 b/drivers/tty/serial/8250/8250_core.c
 index 7111b22de000..59852069e4a0 100644
 --- a/drivers/tty/serial/8250/8250_core.c
 +++ b/drivers/tty/serial/8250/8250_core.c
 @@ -1583,6 +1583,7 @@ int serial8250_handle_irq(struct uart_port *port, 
 unsigned int iir)
   status = serial_port_in(port, UART_LSR);
  
   DEBUG_INTR(status = %x..., status);
 + trace_printk(l%d IIR %x LSR %x\n, port-line, iir, status);
  
   if (status  (UART_LSR_DR | UART_LSR_BI)) {
   if (up-dma)
 @@ -1707,6 +1708,7 @@ static irqreturn_t serial8250_interrupt(int irq, void 
 *dev_id)
  
   spin_unlock(i-lock);
  
 + trace_printk(%d e\n, irq);
   DEBUG_INTR(end.\n);
  
   return IRQ_RETVAL(handled);
 

Thanks. I'll give it a spin on Wednesday.


 I hope this is of some use to you. I'll do more testing later.
 
 Which SoC do you use and do you have DMA enabled?

am335x, DMA is enabled, unless I need to do something extra in the
device tree. We depend on am335x.dtsi, so I would think that would be
automatic if CONFIG_SERIAL_8250_DMA=y.

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

Re: [PATCH 07/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend

[Nishanth Menon]

On 20:23-20140908, Grazvydas Ignotas wrote:
 On Sat, Sep 6, 2014 at 12:15 AM, Nishanth Menon n...@ti.com wrote:
 
  Hi,
 
  Updated patch below:
  Do let me know if this is ok with folks.
 
  ---8
  From 1b9e11834dac2bd75c396aa7495c806b027653fe Mon Sep 17 00:00:00 2001
  From: Rajendra Nayak rna...@ti.com
  Date: Mon, 27 May 2013 15:46:44 +0530
  Subject: [PATCH V2 7/10] ARM: OMAP5 / DRA7: Enable CPU RET on suspend
 
  On OMAP5 / DRA7, prevent a CPU powerdomain OFF and resulting MPU OSWR
  and instead attempt a CPU RET and side effect, MPU RET in suspend.
 
  NOTE: the hardware was originally designed to be capable of achieving
  deep power states such as OFF and OSWR, however due to various issues
  and risks, deepest valid state was determined to be CSWR - hence we use
 
 Would be great to have some more details here..

Sorry, I have no details that can be published publically. Lets say, TI
refocus?

 So there is no hope for OFF mode on OMAP5?

Yep, There is *NO* hope for OFF or OSWR on OMAP5/DRA7.

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

Re: [PATCH 6/6] ARM: dts: dra7-evm: Mark uart1 rxd as wakeup capable

[Nishanth Menon]

On 09:03-20140822, Nishanth Menon wrote:
   status = okay;
   pinctrl-names = default;
   pinctrl-0 = uart1_pins;
 + interrupts-extended = gic GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH
 +dra7_pmx_core 0x3e0;
^^
Thanks to Lee Jones pointing this out to me in a different context[1]
I made the wrong usage. Fixing the syntax to stay in sync with
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt

[1] http://marc.info/?l=linux-omapm=140930980325273w=2

-8
From c3c284ebd2b8d5535abf297ef7537b2caa7fe67b Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Fri, 6 Jun 2014 20:53:22 -0500
Subject: [PATCH V2 6/6] ARM: dts: dra7-evm: Mark uart1 rxd as wakeup capable

Mark rxd as wakeupcapable for 115200n8 no hardware-flow control
configuration. If h/w flow control is being used, then rts/cts
appropriately should be used.

Signed-off-by: Nishanth Menon n...@ti.com
---
 arch/arm/boot/dts/dra7-evm.dts |2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 50f8022..08434c7 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -303,6 +303,8 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = uart1_pins;
+   interrupts-extended = gic GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH,
+ dra7_pmx_core 0x3e0;
 };
 
 uart2 {
-- 
1.7.9.5


-- 
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

[resend PATCH 0/3] Add DRA7xx CPSW Ethernet support in Device Tree

[Mugunthan V N]

Adding device tree entry for CPSW to make it work in Dual EMAC mode.

These patches were tested with DRA7 hwmod patches on top of linux-next.
The patches were already reviewed [1] and has been waiting for cross bar
and hwmod to be pulled in. Now since all dependent patches has already
pulled in, so reposting the patches again.

Patches are tested on linux-next, the boot logs on DRA7xx EVM [2]

[1] https://lkml.org/lkml/2014/5/13/89
[2] http://slexy.org/view/s2YqO0Wj9b 

Mugunthan V N (3):
  pinctrl: dra7: dt-bindings: add pin off modes for dra7 SoC
  arm/dts: dra7xx: Add CPSW and MDIO module nodes for dra7xx
  arm/dts: dra7xx: Enable CPSW and MDIO for dra7xx EVM

 arch/arm/boot/dts/dra7-evm.dts| 107 ++
 arch/arm/boot/dts/dra7.dtsi   |  59 +
 include/dt-bindings/pinctrl/dra.h |   8 +++
 3 files changed, 174 insertions(+)

-- 
2.1.0

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

[resend PATCH 3/3] arm/dts: dra7xx: Enable CPSW and MDIO for dra7xx EVM

[Mugunthan V N]

Adding CPSW phy-id, CPSW and MDIO pinmux configuration for active and
sleep states and enable them in board evm dts file.

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 arch/arm/boot/dts/dra7-evm.dts | 107 +
 1 file changed, 107 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index fd96ced..57e69c4 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -151,6 +151,87 @@
0xd0(PIN_OUTPUT | MUX_MODE0)/* 
gpmc_be0n_cle */
;
};
+
+   cpsw_default: cpsw_default {
+   pinctrl-single,pins = 
+   /* Slave 1 */
+   0x250 (PIN_OUTPUT | MUX_MODE0)  /* rgmii1_tclk */
+   0x254 (PIN_OUTPUT | MUX_MODE0)  /* rgmii1_tctl */
+   0x258 (PIN_OUTPUT | MUX_MODE0)  /* rgmii1_td3 */
+   0x25c (PIN_OUTPUT | MUX_MODE0)  /* rgmii1_td2 */
+   0x260 (PIN_OUTPUT | MUX_MODE0)  /* rgmii1_td1 */
+   0x264 (PIN_OUTPUT | MUX_MODE0)  /* rgmii1_td0 */
+   0x268 (PIN_INPUT | MUX_MODE0)   /* rgmii1_rclk */
+   0x26c (PIN_INPUT | MUX_MODE0)   /* rgmii1_rctl */
+   0x270 (PIN_INPUT | MUX_MODE0)   /* rgmii1_rd3 */
+   0x274 (PIN_INPUT | MUX_MODE0)   /* rgmii1_rd2 */
+   0x278 (PIN_INPUT | MUX_MODE0)   /* rgmii1_rd1 */
+   0x27c (PIN_INPUT | MUX_MODE0)   /* rgmii1_rd0 */
+
+   /* Slave 2 */
+   0x198 (PIN_OUTPUT | MUX_MODE3)  /* rgmii2_tclk */
+   0x19c (PIN_OUTPUT | MUX_MODE3)  /* rgmii2_tctl */
+   0x1a0 (PIN_OUTPUT | MUX_MODE3)  /* rgmii2_td3 */
+   0x1a4 (PIN_OUTPUT | MUX_MODE3)  /* rgmii2_td2 */
+   0x1a8 (PIN_OUTPUT | MUX_MODE3)  /* rgmii2_td1 */
+   0x1ac (PIN_OUTPUT | MUX_MODE3)  /* rgmii2_td0 */
+   0x1b0 (PIN_INPUT | MUX_MODE3)   /* rgmii2_rclk */
+   0x1b4 (PIN_INPUT | MUX_MODE3)   /* rgmii2_rctl */
+   0x1b8 (PIN_INPUT | MUX_MODE3)   /* rgmii2_rd3 */
+   0x1bc (PIN_INPUT | MUX_MODE3)   /* rgmii2_rd2 */
+   0x1c0 (PIN_INPUT | MUX_MODE3)   /* rgmii2_rd1 */
+   0x1c4 (PIN_INPUT | MUX_MODE3)   /* rgmii2_rd0 */
+   ;
+
+   };
+
+   cpsw_sleep: cpsw_sleep {
+   pinctrl-single,pins = 
+   /* Slave 1 */
+   0x250 (PIN_OFF_NONE)
+   0x254 (PIN_OFF_NONE)
+   0x258 (PIN_OFF_NONE)
+   0x25c (PIN_OFF_NONE)
+   0x260 (PIN_OFF_NONE)
+   0x264 (PIN_OFF_NONE)
+   0x268 (PIN_OFF_NONE)
+   0x26c (PIN_OFF_NONE)
+   0x270 (PIN_OFF_NONE)
+   0x274 (PIN_OFF_NONE)
+   0x278 (PIN_OFF_NONE)
+   0x27c (PIN_OFF_NONE)
+
+   /* Slave 1 */
+   0x198 (PIN_OFF_NONE)
+   0x19c (PIN_OFF_NONE)
+   0x1a0 (PIN_OFF_NONE)
+   0x1a4 (PIN_OFF_NONE)
+   0x1a8 (PIN_OFF_NONE)
+   0x1ac (PIN_OFF_NONE)
+   0x1b0 (PIN_OFF_NONE)
+   0x1b4 (PIN_OFF_NONE)
+   0x1b8 (PIN_OFF_NONE)
+   0x1bc (PIN_OFF_NONE)
+   0x1c0 (PIN_OFF_NONE)
+   0x1c4 (PIN_OFF_NONE)
+   ;
+   };
+
+   davinci_mdio_default: davinci_mdio_default {
+   pinctrl-single,pins = 
+   /* MDIO */
+   0x23c (PIN_OUTPUT_PULLUP | MUX_MODE0)   /* mdio_data */
+   0x240 (PIN_INPUT_PULLUP | MUX_MODE0)/* mdio_clk */
+   ;
+   };
+
+   davinci_mdio_sleep: davinci_mdio_sleep {
+   pinctrl-single,pins = 
+   0x23c (PIN_OFF_NONE)
+   0x240 (PIN_OFF_NONE)
+   ;
+   };
+
 };
 
 i2c1 {
@@ -503,3 +584,29 @@
 usb2_phy2 {
phy-supply = ldousb_reg;
 };
+
+mac {
+   status = okay;
+   pinctrl-names = default, sleep;
+   pinctrl-0 = cpsw_default;
+   pinctrl-1 = cpsw_sleep;
+   dual_emac;
+};
+
+cpsw_emac0 {
+   phy_id = davinci_mdio, 2;
+   phy-mode = rgmii;
+   dual_emac_res_vlan = 1;
+};
+
+cpsw_emac1 {
+   phy_id = davinci_mdio, 3;
+   phy-mode = rgmii;
+   dual_emac_res_vlan = 2;
+};
+
+davinci_mdio {
+   pinctrl-names = default, sleep;
+   pinctrl-0 = davinci_mdio_default;
+   pinctrl-1 = davinci_mdio_sleep;
+};
-- 
2.1.0

--
To unsubscribe from this 

[resend PATCH 1/3] pinctrl: dra7: dt-bindings: add pin off modes for dra7 SoC

[Mugunthan V N]

Add pin off modes for dra7 SoC so that during module disable or suspend
state it can help saving power

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 include/dt-bindings/pinctrl/dra.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/dt-bindings/pinctrl/dra.h 
b/include/dt-bindings/pinctrl/dra.h
index 002a285..a0ff2d0 100644
--- a/include/dt-bindings/pinctrl/dra.h
+++ b/include/dt-bindings/pinctrl/dra.h
@@ -46,5 +46,13 @@
 #define PIN_INPUT_PULLUP   (PULL_ENA | INPUT_EN | PULL_UP)
 #define PIN_INPUT_PULLDOWN (PULL_ENA | INPUT_EN)
 
+/* Off mode states */
+#define PIN_OFF_NONE   0
+#define PIN_OFF_OUTPUT_HIGH(OFF_EN | OFFOUT_EN | OFFOUT_VAL)
+#define PIN_OFF_OUTPUT_LOW (OFF_EN | OFFOUT_EN)
+#define PIN_OFF_INPUT_PULLUP   (OFF_EN | OFF_PULL_EN | OFF_PULL_UP)
+#define PIN_OFF_INPUT_PULLDOWN (OFF_EN | OFF_PULL_EN)
+#define PIN_OFF_WAKEUPENABLE   WAKEUP_EN
+
 #endif
 
-- 
2.1.0

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

[resend PATCH 0/3] Add DRA7xx CPSW Ethernet support in Device Tree

[Mugunthan V N]

Adding device tree entry for CPSW to make it work in Dual EMAC mode.

These patches were tested with DRA7 hwmod patches on top of linux-next.
The patches were already reviewed [1] and has been waiting for cross bar
and hwmod to be pulled in. Now since all dependent patches has already
pulled in, so reposting the patches again.

Patches are tested on linux-next, the boot logs on DRA7xx EVM [2]

[1] https://lkml.org/lkml/2014/5/13/89
[2] http://slexy.org/view/s2YqO0Wj9b 

Mugunthan V N (3):
  pinctrl: dra7: dt-bindings: add pin off modes for dra7 SoC
  arm/dts: dra7xx: Add CPSW and MDIO module nodes for dra7xx
  arm/dts: dra7xx: Enable CPSW and MDIO for dra7xx EVM

 arch/arm/boot/dts/dra7-evm.dts| 107 ++
 arch/arm/boot/dts/dra7.dtsi   |  59 +
 include/dt-bindings/pinctrl/dra.h |   8 +++
 3 files changed, 174 insertions(+)

-- 
2.1.0

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

[resend PATCH 2/3] arm/dts: dra7xx: Add CPSW and MDIO module nodes for dra7xx

[Mugunthan V N]

Add CPSW and MDIO related device tree data for DRA7XX and made as status
disabled. Phy-id, pinmux for active and sleep state needs to be added in
board dts files and enable the CPSW device.

Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
 arch/arm/boot/dts/dra7.dtsi | 59 +
 1 file changed, 59 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index b6060d3..d588c1e 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -34,6 +34,8 @@
serial3 = uart4;
serial4 = uart5;
serial5 = uart6;
+   ethernet0 = cpsw_emac0;
+   ethernet1 = cpsw_emac1;
};
 
timer {
@@ -1134,6 +1136,63 @@
ti,irqs-skip = 10 133 139 140;
ti,irqs-safe-map = 0;
};
+
+   mac: ethernet@4a10 {
+   compatible = ti,cpsw;
+   ti,hwmods = gmac;
+   cpdma_channels = 8;
+   ale_entries = 1024;
+   bd_ram_size = 0x2000;
+   no_bd_ram = 0;
+   rx_descs = 64;
+   mac_control = 0x20;
+   slaves = 2;
+   active_slave = 0;
+   cpts_clock_mult = 0x8000;
+   cpts_clock_shift = 29;
+   reg = 0x48484000 0x1000
+  0x48485200 0x2E00;
+   #address-cells = 1;
+   #size-cells = 1;
+   /*
+* rx_thresh_pend
+* rx_pend
+* tx_pend
+* misc_pend
+*/
+   interrupts = GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH;
+   ranges;
+   status = disabled;
+
+   davinci_mdio: mdio@48485000 {
+   compatible = ti,davinci_mdio;
+   #address-cells = 1;
+   #size-cells = 0;
+   ti,hwmods = davinci_mdio;
+   bus_freq = 100;
+   reg = 0x48485000 0x100;
+   };
+
+   cpsw_emac0: slave@48480200 {
+   /* Filled in by U-Boot */
+   mac-address = [ 00 00 00 00 00 00 ];
+   };
+
+   cpsw_emac1: slave@48480300 {
+   /* Filled in by U-Boot */
+   mac-address = [ 00 00 00 00 00 00 ];
+   };
+
+   phy_sel: cpsw-phy-sel@4a002554 {
+   compatible = ti,dra7xx-cpsw-phy-sel;
+   reg= 0x4a002554 0x4;
+   reg-names = gmii-sel;
+   };
+   };
+
};
 };
 
-- 
2.1.0

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

Re: [resend PATCH 1/3] pinctrl: dra7: dt-bindings: add pin off modes for dra7 SoC

[Nishanth Menon]

On 00:49-20140909, Mugunthan V N wrote:
 Add pin off modes for dra7 SoC so that during module disable or suspend
 state it can help saving power
 
 Signed-off-by: Mugunthan V N mugunthan...@ti.com
 ---
  include/dt-bindings/pinctrl/dra.h | 8 
  1 file changed, 8 insertions(+)
 
 diff --git a/include/dt-bindings/pinctrl/dra.h 
 b/include/dt-bindings/pinctrl/dra.h
 index 002a285..a0ff2d0 100644
 --- a/include/dt-bindings/pinctrl/dra.h
 +++ b/include/dt-bindings/pinctrl/dra.h
 @@ -46,5 +46,13 @@
  #define PIN_INPUT_PULLUP (PULL_ENA | INPUT_EN | PULL_UP)
  #define PIN_INPUT_PULLDOWN   (PULL_ENA | INPUT_EN)
  
 +/* Off mode states */
 +#define PIN_OFF_NONE 0
 +#define PIN_OFF_OUTPUT_HIGH  (OFF_EN | OFFOUT_EN | OFFOUT_VAL)
 +#define PIN_OFF_OUTPUT_LOW   (OFF_EN | OFFOUT_EN)
 +#define PIN_OFF_INPUT_PULLUP (OFF_EN | OFF_PULL_EN | OFF_PULL_UP)
 +#define PIN_OFF_INPUT_PULLDOWN   (OFF_EN | OFF_PULL_EN)
 +#define PIN_OFF_WAKEUPENABLE WAKEUP_EN
 +
  #endif

NAK for OFF_NONE, OFF_xyz etc.

A) There is no OFF mode on DRA7. in sleep state use mode 15 (gated).
B) when using this for wakeup - use pinctrl wakeup handling to do the
wakeup.

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: [resend PATCH 3/3] arm/dts: dra7xx: Enable CPSW and MDIO for dra7xx EVM

[Nishanth Menon]

On 00:49-20140909, Mugunthan V N wrote:
 Adding CPSW phy-id, CPSW and MDIO pinmux configuration for active and
 sleep states and enable them in board evm dts file.
 
 Signed-off-by: Mugunthan V N mugunthan...@ti.com
 ---
  arch/arm/boot/dts/dra7-evm.dts | 107 
 +
  1 file changed, 107 insertions(+)
 
 diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
 index fd96ced..57e69c4 100644
 --- a/arch/arm/boot/dts/dra7-evm.dts
 +++ b/arch/arm/boot/dts/dra7-evm.dts
 @@ -151,6 +151,87 @@
   0xd0(PIN_OUTPUT | MUX_MODE0)/* 
 gpmc_be0n_cle */
   ;
   };
 +
 + cpsw_default: cpsw_default {
 + pinctrl-single,pins = 
 + /* Slave 1 */
 + 0x250 (PIN_OUTPUT | MUX_MODE0)  /* rgmii1_tclk */
 + 0x254 (PIN_OUTPUT | MUX_MODE0)  /* rgmii1_tctl */
 + 0x258 (PIN_OUTPUT | MUX_MODE0)  /* rgmii1_td3 */
 + 0x25c (PIN_OUTPUT | MUX_MODE0)  /* rgmii1_td2 */
 + 0x260 (PIN_OUTPUT | MUX_MODE0)  /* rgmii1_td1 */
 + 0x264 (PIN_OUTPUT | MUX_MODE0)  /* rgmii1_td0 */
 + 0x268 (PIN_INPUT | MUX_MODE0)   /* rgmii1_rclk */
 + 0x26c (PIN_INPUT | MUX_MODE0)   /* rgmii1_rctl */
 + 0x270 (PIN_INPUT | MUX_MODE0)   /* rgmii1_rd3 */
 + 0x274 (PIN_INPUT | MUX_MODE0)   /* rgmii1_rd2 */
 + 0x278 (PIN_INPUT | MUX_MODE0)   /* rgmii1_rd1 */
 + 0x27c (PIN_INPUT | MUX_MODE0)   /* rgmii1_rd0 */
 +
 + /* Slave 2 */
 + 0x198 (PIN_OUTPUT | MUX_MODE3)  /* rgmii2_tclk */
 + 0x19c (PIN_OUTPUT | MUX_MODE3)  /* rgmii2_tctl */
 + 0x1a0 (PIN_OUTPUT | MUX_MODE3)  /* rgmii2_td3 */
 + 0x1a4 (PIN_OUTPUT | MUX_MODE3)  /* rgmii2_td2 */
 + 0x1a8 (PIN_OUTPUT | MUX_MODE3)  /* rgmii2_td1 */
 + 0x1ac (PIN_OUTPUT | MUX_MODE3)  /* rgmii2_td0 */
 + 0x1b0 (PIN_INPUT | MUX_MODE3)   /* rgmii2_rclk */
 + 0x1b4 (PIN_INPUT | MUX_MODE3)   /* rgmii2_rctl */
 + 0x1b8 (PIN_INPUT | MUX_MODE3)   /* rgmii2_rd3 */
 + 0x1bc (PIN_INPUT | MUX_MODE3)   /* rgmii2_rd2 */
 + 0x1c0 (PIN_INPUT | MUX_MODE3)   /* rgmii2_rd1 */
 + 0x1c4 (PIN_INPUT | MUX_MODE3)   /* rgmii2_rd0 */
 + ;
 +
 + };
 +
 + cpsw_sleep: cpsw_sleep {
 + pinctrl-single,pins = 
 + /* Slave 1 */
 + 0x250 (PIN_OFF_NONE)
 + 0x254 (PIN_OFF_NONE)
 + 0x258 (PIN_OFF_NONE)
 + 0x25c (PIN_OFF_NONE)
 + 0x260 (PIN_OFF_NONE)
 + 0x264 (PIN_OFF_NONE)
 + 0x268 (PIN_OFF_NONE)
 + 0x26c (PIN_OFF_NONE)
 + 0x270 (PIN_OFF_NONE)
 + 0x274 (PIN_OFF_NONE)
 + 0x278 (PIN_OFF_NONE)
 + 0x27c (PIN_OFF_NONE)
 +
 + /* Slave 1 */
 + 0x198 (PIN_OFF_NONE)
 + 0x19c (PIN_OFF_NONE)
 + 0x1a0 (PIN_OFF_NONE)
 + 0x1a4 (PIN_OFF_NONE)
 + 0x1a8 (PIN_OFF_NONE)
 + 0x1ac (PIN_OFF_NONE)
 + 0x1b0 (PIN_OFF_NONE)
 + 0x1b4 (PIN_OFF_NONE)
 + 0x1b8 (PIN_OFF_NONE)
 + 0x1bc (PIN_OFF_NONE)
 + 0x1c0 (PIN_OFF_NONE)
 + 0x1c4 (PIN_OFF_NONE)
 + ;
 + };

NAK to sleep states - you should be using mode 15 if you really want to
save power.

-- 
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: [resend PATCH 0/3] Add DRA7xx CPSW Ethernet support in Device Tree

[Nishanth Menon]

On 00:49-20140909, Mugunthan V N wrote:
 Adding device tree entry for CPSW to make it work in Dual EMAC mode.
 
 These patches were tested with DRA7 hwmod patches on top of linux-next.
 The patches were already reviewed [1] and has been waiting for cross bar
 and hwmod to be pulled in. Now since all dependent patches has already
 pulled in, so reposting the patches again.
 
 Patches are tested on linux-next, the boot logs on DRA7xx EVM [2]
 
 [1] https://lkml.org/lkml/2014/5/13/89
 [2] http://slexy.org/view/s2YqO0Wj9b 

Sorry this is now blocked inside TI. could you explain the testing done
for sleep state? did you attempt sleep mode before testing this?

 
 Mugunthan V N (3):
   pinctrl: dra7: dt-bindings: add pin off modes for dra7 SoC
   arm/dts: dra7xx: Add CPSW and MDIO module nodes for dra7xx
   arm/dts: dra7xx: Enable CPSW and MDIO for dra7xx EVM
 
  arch/arm/boot/dts/dra7-evm.dts| 107 
 ++
  arch/arm/boot/dts/dra7.dtsi   |  59 +
  include/dt-bindings/pinctrl/dra.h |   8 +++
  3 files changed, 174 insertions(+)
 
-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] ARM: dts: dra72-evm: Add i2c1 and tps65917 nodes

[Nishanth Menon]

On 18:05-20140812, Keerthy wrote:
 On Monday 28 July 2014 02:52 PM, Keerthy wrote:
 On Monday 28 July 2014 12:00 PM, Lokesh Vutla wrote:
 On Monday 28 July 2014 11:48 AM, Keerthy wrote:
 The patch series adds i2c1 and tps65917 and related nodes.
 The patch series is boot tested on DRA72-EVM.
 
 Thanks to Lokesh lokeshvu...@ti.com for testing the series.
 
 Correcting the 'to' list.
 
 Hi Tony,
 
 If there are no comments could you please pull these two patches?

With 3.17-rc4, I tested this series:
dra72-evm-before: http://paste.ubuntu.org.cn/1496342
dra72-evm-after: http://paste.ubuntu.org.cn/1496341

Patches:
https://patchwork.kernel.org/patch/4632391/
https://patchwork.kernel.org/patch/4632421/

Could we pick these with 3.18?

Please free to add:

Tested-by: Nishanth Menon n...@ti.com
-- 
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 PATCH 2/2] of/clk: use clkops-clocks to specify clocks handled by clock_ops domain

[Kevin Hilman]

Laurent Pinchart laurent.pinch...@ideasonboard.com writes:

 Hi Grygorii and Grant,

 On Monday 28 July 2014 23:52:34 Grant Likely wrote:
 On Mon, Jul 28, 2014 at 11:47 AM, Grygorii Strashko wrote:
  On 07/28/2014 05:05 PM, Grant Likely wrote:
  On Thu, 12 Jun 2014 19:53:43 +0300, Grygorii Strashko wrote:

[...]

 
  - Where and when to call of_clk_register_runtime_pm_clocks()?
  
Bus notifier/ platform core/ device drivers
 
 I would say in device drivers.

 I tend to agree with that.

 It will help here to take a step back and remember what the problem we're 
 trying to solve is.

[jumping in late, after Grygorii ping'd me about looking at this]

Laurent, thanks for summarizing the problem so well.  It helped me
catchup on the discussion.

 At the root is clock management. Our system comprise many clocks, and they 
 need to be handled. The Common Clock Framework nicely models the clocks, and 
 offers an API for drivers to retrieve device clocks and control them. Drivers 
 can thus implement clock management manually without much pain.

 A clock can be managed in roughly three different ways :

 - it can be enabled at probe time and disabled at remove time ;

 - it can be enabled right before the device leaves its idle state and 
 disabled 
 when the device goes back to idle ; or

 - it can be enabled and disabled in a more fine-grained, device-specific 
 manner.

 The selected clock management granularity depends on constraints specific to 
 the device and on how aggressive power saving needs to be. Enabling the 
 clocks 
 at probe time and disabling them at remove time is enough for most devices, 
 but leads to a high power consumption. For that reason the second clock 
 management scheme is often desired.

 Managing clocks manually in the driver is a valid option. However, when 
 adding 
 runtime PM to the equation, and realizing that the clocks need to be enabled 
 in the runtime PM resume handler and disabled in the suspend handler, the 
 clock management code starts looking very similar in most drivers. We're thus 
 tempted to factorize it away from the drivers into a shared location.

 It's important to note at this point that the goal here is only to simplify 
 drivers. Moving clock management code out of the drivers doesn't (unless I'm 
 missing something) open the door to new possibilities, it just serves as a 
 simplification.

I disagree. Actually, it opens up the door to lots of new possibilities
that are crucial for fine-grained PM with QoS.  It is not just
simplification.  There are many good reasons that some SoCs have moved
all the management of PM-related clocks *out* of device drivers.  More
on that below...

 Now, as Grygorii mentioned, differences between how a given IP core is 
 integrated in various SoCs can make clock management SoC-dependent. In the 
 vast majority of cases (which is really what we need to target, given that 
 our 
 target is simplifying drivers) SoC integration can be described as a list of 
 clocks that must be managed. That list can be common to all devices in a 
 given 
 SoC, or can be device-dependent as well.

If we care about fine-grained PM, this is a way-too oversimplified
version of what SoC integragion means.

There are lots of pieces which fall under SoC integration, for
example: clock domains, power domains, voltage domains, SoC-specific
wakeup capabilities, etc. etc.  Then, for fun throw in QoS constraints,
and things get really exciting.

IOW, if you care about fine-grained PM and QoS, you simply can't reduce
SoC integration down to a list of clocks to be managed.

QoS makes this interesting as well because a device driver's decision to
gate its own clocks may have serious repercussions on the wakeup latency
of *other* devices in the same power domain.  For example, the clock
gating of the last active device in a powerdomain may cause the
enclosing power-domain to be power gated, having a major impact on the
wakup latency of *all* devices in that power domain.

So if we're going to manage the list of PM-related clocks in the device
driver, we'll also keep track of all the other devices in the same power
domain, whether or not they're active, whether or not they have QoS
constraints, etc. etc.  Hopefully you can see that we're quickly way
outside the scope of the IP block that the device driver is intended to
manage.

All of this is SoC integration knowledge, and IMO doen't belong in the
device drivers.  It belongs at the SoC integration level, and in todays
kernel frameworks that means pm_domain/genpd.

 Few locations can be used to express a per-device list of per-SoC clocks. We 
 can have clocks lists in a per-SoC and per-device location, per-device clocks 
 lists in an SoC-specific location, or per-SoC clocks lists in a device-
 specific location.

 The first option would require listing clocks to be managed by runtime PM in 
 DT nodes, as proposed by this patch set. I don't think this is the best 
 option, as that information is a mix of 

Re: [PATCH] ARM: omap: fix Kconfig warning

[Tony Lindgren]

* Arnd Bergmann a...@arndb.de [140908 11:17]:
 On Monday 08 September 2014 08:34:00 Tony Lindgren wrote:
  * Arnd Bergmann a...@arndb.de [140908 08:01]:
   A small mistake during the recent Kconfig cleanup has led
   to a harmless warning for OMAP1:
   
   warning: (ARCH_OMAP1) selects ARCH_OMAP which has unmet direct 
   dependencies (ARCH_MULTI_V6 || ARCH_MULTI_V7)
   
   We can easily avoid that by moving the ARCH_OMAP symbol outside of the
   OMAP2 submenu.
  
  OK I made a similar patch, but I moved it into plat-omap/Kconfig
  as it's also used by omap1. The regression was probably caused by
  commit 21278aeafbfa (ARM: use menuconfig for sub-arch menus).
  
  If that works for you, I'll verify the regression causing commit
  and post it with a description.
 
 Yes, sounds good. Your version is better than mind.

OK here's the patch again with breaking commit and reported by.

Regards,

Tony


8 -
From: Tony Lindgren t...@atomide.com
Date: Mon, 8 Sep 2014 07:52:11 -0700
Subject: [PATCH] ARM: OMAP: Fix Kconfig warning for omap1

Commit 21278aeafbfa (ARM: use menuconfig for sub-arch menus) improved
the sub-arch menus, but accidentally caused new warnings for omap1.
This was because the commit added a menu entry around config ARCH_OMAP
bool entry where the menu had depends on ARCH_MULTI_V6 || ARCH_MULTI_V7.

As ARCH_OMAP is shared between omap1 and omap2plus, let's fix the
issue by defining ARCH_OMAP in the shared plat-omap/Kconfig.

Fixes: 21278aeafbfa (ARM: use menuconfig for sub-arch menus)
Reported-by: Andreas Ruprecht rup...@einserver.de
Cc: Arnd Bergmann a...@arndb.de
Signed-off-by: Tony Lindgren t...@atomide.com

--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -1,9 +1,6 @@
 menu TI OMAP/AM/DM/DRA Family
depends on ARCH_MULTI_V6 || ARCH_MULTI_V7
 
-config ARCH_OMAP
-   bool
-
 config ARCH_OMAP2
bool TI OMAP2
depends on ARCH_MULTI_V6
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 02fc10d..d055db3 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -1,3 +1,6 @@
+config ARCH_OMAP
+   bool
+
 if ARCH_OMAP
 
 menu TI OMAP Common Features
--
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: [GIT PULL 1/2] ARM: OMAP 4+: powerdomain fixes

[Tony Lindgren]

* Nishanth Menon n...@ti.com [140908 10:00]:
 Hi Tony,
 Please pull the following changes.
 Series discussed in:
 http://marc.info/?l=linux-kernelm=140871554106082w=2
 Includes (v2 patch) https://patchwork.kernel.org/patch/4790541/
 Status: Acked by Santosh and Reviewed-by Kevin
 
 These could go into your tree for the branch omap-for-v3.18/fixes-not-urgent

Thanks pulling them there.

Tony
 
 The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:
 
   Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)
 
 are available in the git repository at:
 
   https://github.com/nmenon/linux-2.6-playground.git 
 pull/v3.18/powerdomain-fixes
 
 for you to fetch changes up to 3e6a1c945950140926dd6e2cc667893de0a7fe3b:
 
   ARM: OMAP4+: PM: Use only valid low power state for CPU hotplug (2014-09-08 
 11:22:43 -0500)
 
 
 Nishanth Menon (7):
   ARM: OMAP: DRA7: powerdomain data: fix powerdomain powerstate
   ARM: OMAP5: powerdomain data: fix powerdomain powerstate
   ARM: OMAP2+: powerdomain: pwrdm_for_each_clkdm iterate only valid clkdms
   ARM: OMAP2+: powerdomain: introduce logic for finding valid power domain
   ARM: OMAP4+: PM: Make logic state programmable
   ARM: OMAP4+: PM: use only valid low power state for suspend
   ARM: OMAP4+: PM: Use only valid low power state for CPU hotplug
 
  arch/arm/mach-omap2/omap-mpuss-lowpower.c   |4 ++
  arch/arm/mach-omap2/pm44xx.c|9 ++-
  arch/arm/mach-omap2/powerdomain.c   |   79 
 ++-
  arch/arm/mach-omap2/powerdomain.h   |4 ++
  arch/arm/mach-omap2/powerdomains54xx_data.c |   12 ++--
  arch/arm/mach-omap2/powerdomains7xx_data.c  |   14 ++---
  6 files changed, 106 insertions(+), 16 deletions(-)
 
 Regards,
 Nishanth Menon
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 10/11] ARM: OMAP2+: AM33XX: Basic suspend resume support

[Kevin Hilman]

+Ohad

Dave Gerlach d-gerl...@ti.com writes:

 AM335x supports various low power modes as documented
 in section 8.1.4.3 of the AM335x Technical Reference Manual.

 DeepSleep0 mode offers the lowest power mode with limited
 wakeup sources without a system reboot and is mapped as
 the suspend state in the kernel. In this state, MPU and
 PER domains are turned off with the internal RAM held in
 retention to facilitate the resume process. As part of
 the boot process, the assembly code is copied over to OCMCRAM
 using the OMAP SRAM code so it can be executed to turn of the
 EMIF.

 AM335x has a Cortex-M3 (WKUP_M3) which assists the MPU
 in DeepSleep0 and Standby entry and exit. WKUP_M3 takes care
 of the clockdomain and powerdomain transitions based on the
 intended low power state. MPU needs to load the appropriate
 WKUP_M3 binary onto the WKUP_M3 memory space before it can
 leverage any of the PM features like DeepSleep.

 The WKUP_M3 is managed by a remoteproc driver. The PM code hooks
 into the remoteproc driver through an rproc_ready callback to
 allow PM features to become available once the firmware for the
 wkup_m3 has been loaded. This code maintains its own state machine
 for the wkup_m3 so that it can be used in the manner intended for
 low power modes.

 In the current implementation when the suspend process
 is initiated, MPU interrupts the WKUP_M3 to let it know about
 the intent of entering DeepSleep0 and waits for an ACK. When
 the ACK is received MPU continues with its suspend process
 to suspend all the drivers and then jumps to assembly in
 OCMC RAM. The assembly code puts the external RAM in self-refresh
 mode, gates the MPU clock, and then finally executes the WFI
 instruction. Execution of the WFI instruction with MPU clock gated
 triggers another interrupt to the WKUP_M3 which then continues
 with the power down sequence wherein the clockdomain and
 powerdomain transition takes place. As part of the sleep sequence,
 WKUP_M3 unmasks the interrupt lines for the wakeup sources. WFI
 execution on WKUP_M3 causes the hardware to disable the main
 oscillator of the SoC and from here system remains in sleep state
 until a wake source brings the system into resume path.

 When a wakeup event occurs, WKUP_M3 starts the power-up
 sequence by switching on the power domains and finally
 enabling the clock to MPU. Since the MPU gets powered down
 as part of the sleep sequence in the resume path ROM code
 starts executing. The ROM code detects a wakeup from sleep
 and then jumps to the resume location in OCMC which was
 populated in one of the IPC registers as part of the suspend
 sequence.

 Code is based on work by Vaibhav Bedia.

 Signed-off-by: Dave Gerlach d-gerl...@ti.com
 ---
 v3-v4:
   Remove all direct wkup_m3 usage and moved to rproc driver introduced
   in previous patch.

This statement is rather confusing as there's still quite a bit of
direct wkup_m3 usage, including the guts of the protocal for message
passing.  I thought you had agreed based on earilier reviews to split
out the wkup_m3 into it's on little driver with a clear/clean API which
could be called from here?

To me, it's not terribly clear how you made the split between this PM
core code an the remoteproc code.  In the changelog for the remoteproc
patch, it states it's to load the firmware for and boot the wkup_m3.
But, while parts of the IPC are here in pm33xx.c, parts of the IPC are
also inside the remoteproc driver, so I'm quite curious if that's OK
with the remoteproc maintainers.  Either way, please make it clearer how
and why you made the split, and please isolate the wkup_m3 IPC/protocol
from this code.  Think of people wanting to rework/extend the wkup_m3
firmware.  They shouldn't be messing around in here, but rather inside a
driver specificaly for the wkup_m3.

Also, I'll beat this drum again even though nobody is listening: it's
still very fuzzy to me how this approach is going to be used to manage
low-power idle?  Is low-power idle just being completely ignored for
this SoC?

Kevin
--
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: [GIT PULL 2/2] ARM: OMAP4+: PRM fixes, DRA7 suspend-to-ram support

[Tony Lindgren]

* Nishanth Menon n...@ti.com [140908 10:02]:
 Hi Tony,
 Please pull the following changes.
 
 part 2: ARM: OMAP3+: PRM: fix up prm_handling
 http://marc.info/?l=linux-kernelm=140871580806186w=2
 Status: Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
 
 part 3: ARM: OMAP5+: pdata quirks for pinctrl
 http://marc.info/?l=linux-kernelm=140871598306262w=2
 Status: Sending pull based on 
 http://marc.info/?l=linux-kernelm=140871666506706w=2 (Acked by Tony, Pulled 
 by Linus W)
 
 part 5: ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle
 http://marc.info/?l=linux-kernelm=140871637106555w=2
 Status: picked up kevin's tested and reviewed-by, dropped cpuidle for this 
 pull
 
 These could go into your tree for the branch  omap-for-v3.18/soc
 
 The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:
 
   Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)
 
 are available in the git repository at:
 
   https://github.com/nmenon/linux-2.6-playground.git pull/v3.18/for-omap-soc

Thanks pulling into omap-for-v3.18/soc.

Regards,

Tony
 
 for you to fetch changes up to 628ed4717000789bff827c5799d1aac4c1008541:
 
   ARM: OMAP5: Add hook in SoC initcalls to enable pm initialization 
 (2014-09-08 11:38:43 -0500)
 
 
 Keerthy (1):
   ARM: AM437x: use pdata quirks for pinctrl information
 
 Nishanth Menon (8):
   ARM: OMAP4+: prminst: provide function to find prm_dev instance offset
   ARM: OMAP4: PRM: use the generic prm_inst to allow logic to be 
 abstracted
   ARM: OMAP4+: PRM: register interrupt information from DT
   ARM: OMAP4+: PRM: remove wkup event
   ARM: OMAP4+: PRM: Enable wakeup capability for OMAP5, DRA7
   ARM: OMAP3+: PRM: register interrupt information from DT
   ARM: OMAP5: use pdata quirks for pinctrl information
   ARM: DRA7: use pdata quirks for pinctrl information
 
 Rajendra Nayak (2):
   ARM: OMAP5 / DRA7: PM: Avoid all SAR saves
   ARM: OMAP5 / DRA7: Enable CPU RET on suspend
 
 Santosh Shilimkar (6):
   ARM: OMAP5 / DRA7: PM: Update CPU context register offset
   ARM: OMAP5 / DRA7: PM: Set MPUSS-EMIF clock-domain static dependency
   ARM: OMAP5 / DRA7: PM / wakeupgen: Enables ES2 PM mode by default
   ARM: OMAP5 / DRA7: PM: Enable Mercury retention mode on CPUx 
 powerdomains
   ARM: OMAP5 / DRA7: PM: Provide a dummy startup function for CPU hotplug
   ARM: OMAP5: Add hook in SoC initcalls to enable pm initialization
 
  arch/arm/mach-omap2/common.h  |2 +-
  arch/arm/mach-omap2/io.c  |3 +
  arch/arm/mach-omap2/omap-mpuss-lowpower.c |  102 
 -
  arch/arm/mach-omap2/omap-secure.h |1 +
  arch/arm/mach-omap2/omap-wakeupgen.c  |   20 +-
  arch/arm/mach-omap2/omap-wakeupgen.h  |1 +
  arch/arm/mach-omap2/pdata-quirks.c|   10 +++
  arch/arm/mach-omap2/pm.h  |1 +
  arch/arm/mach-omap2/pm44xx.c  |   48 --
  arch/arm/mach-omap2/prm3xxx.c |   18 +
  arch/arm/mach-omap2/prm44xx.c |   90 +
  arch/arm/mach-omap2/prminst44xx.c |   40 ++-
  arch/arm/mach-omap2/prminst44xx.h |3 +
  13 files changed, 275 insertions(+), 64 deletions(-)
 
 Regards,
 Nishanth Menon
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
--
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] ARM: dts: dra7-evm: Fix NAND GPMC timings (for 3.17)

[Tony Lindgren]

* Roger Quadros rog...@ti.com [140908 01:08]:
 Hi Tony,
 
 This is needed for 3.17 otherwise NAND is broken on dra7-evm. Thanks.

Thanks applying into omap-for-v3.17/fixes-v2.

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: [GIT PULL 2/2] ARM: OMAP4+: PRM fixes, DRA7 suspend-to-ram support

[Nishanth Menon]

On 15:32-20140908, Tony Lindgren wrote:
 * Nishanth Menon n...@ti.com [140908 10:02]:
  Hi Tony,
  Please pull the following changes.
  
  part 2: ARM: OMAP3+: PRM: fix up prm_handling
  http://marc.info/?l=linux-kernelm=140871580806186w=2
  Status: Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
  
  part 3: ARM: OMAP5+: pdata quirks for pinctrl
  http://marc.info/?l=linux-kernelm=140871598306262w=2
  Status: Sending pull based on 
  http://marc.info/?l=linux-kernelm=140871666506706w=2 (Acked by Tony, 
  Pulled by Linus W)
  
  part 5: ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle
  http://marc.info/?l=linux-kernelm=140871637106555w=2
  Status: picked up kevin's tested and reviewed-by, dropped cpuidle for this 
  pull
  
  These could go into your tree for the branch  omap-for-v3.18/soc
  
  The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:
  
Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)
  
  are available in the git repository at:
  
https://github.com/nmenon/linux-2.6-playground.git pull/v3.18/for-omap-soc
 
 Thanks pulling into omap-for-v3.18/soc.

Tony, Apologies, I missed the last patch in the series:

https://patchwork.kernel.org/patch/4765011/

If you could cherry-pick the same with 
Reviewed-by: Kevin Hilman khil...@linaro.org
Tested-by: Kevin Hilman khil...@linaro.org
based on Kevin's feedback:
http://marc.info/?l=linux-arm-kernelm=140916701909122w=2

-- 
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: [GIT PULL 2/2] ARM: OMAP4+: PRM fixes, DRA7 suspend-to-ram support

[Tony Lindgren]

* Nishanth Menon n...@ti.com [140908 15:45]:
 On 15:32-20140908, Tony Lindgren wrote:
  * Nishanth Menon n...@ti.com [140908 10:02]:
   Hi Tony,
   Please pull the following changes.
   
   part 2: ARM: OMAP3+: PRM: fix up prm_handling
   http://marc.info/?l=linux-kernelm=140871580806186w=2
   Status: Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
   
   part 3: ARM: OMAP5+: pdata quirks for pinctrl
   http://marc.info/?l=linux-kernelm=140871598306262w=2
   Status: Sending pull based on 
   http://marc.info/?l=linux-kernelm=140871666506706w=2 (Acked by Tony, 
   Pulled by Linus W)
   
   part 5: ARM: OMAP5 / DRA7: Add framework for suspend and cpuidle
   http://marc.info/?l=linux-kernelm=140871637106555w=2
   Status: picked up kevin's tested and reviewed-by, dropped cpuidle for 
   this pull
   
   These could go into your tree for the branch  omap-for-v3.18/soc
   
   The following changes since commit 
   7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:
   
 Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)
   
   are available in the git repository at:
   
 https://github.com/nmenon/linux-2.6-playground.git 
   pull/v3.18/for-omap-soc
  
  Thanks pulling into omap-for-v3.18/soc.
 
 Tony, Apologies, I missed the last patch in the series:
 
 https://patchwork.kernel.org/patch/4765011/
 
 If you could cherry-pick the same with 
 Reviewed-by: Kevin Hilman khil...@linaro.org
 Tested-by: Kevin Hilman khil...@linaro.org
 based on Kevin's feedback:
 http://marc.info/?l=linux-arm-kernelm=140916701909122w=2

OK no problem, will apply into omap-for-v3.18/soc.

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: [GIT PULL 2/2] ARM: OMAP4+: PRM fixes, DRA7 suspend-to-ram support

[Nishanth Menon]

On 15:51-20140908, Tony Lindgren wrote:
[...]

are available in the git repository at:

  https://github.com/nmenon/linux-2.6-playground.git 
pull/v3.18/for-omap-soc
   
   Thanks pulling into omap-for-v3.18/soc.
  
  Tony, Apologies, I missed the last patch in the series:
  
  https://patchwork.kernel.org/patch/4765011/
  
  If you could cherry-pick the same with 
  Reviewed-by: Kevin Hilman khil...@linaro.org
  Tested-by: Kevin Hilman khil...@linaro.org
  based on Kevin's feedback:
  http://marc.info/?l=linux-arm-kernelm=140916701909122w=2
 
 OK no problem, will apply into omap-for-v3.18/soc.

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

Re: [PATCH v9 5/9] arm: omap1: Migrate debug_ll macros to use 8250.S

[Tony Lindgren]

* Daniel Thompson daniel.thomp...@linaro.org [140819 08:19]:
 The omap1's debug-macro.S is similar to the generic 8250 code. Compared to
 the 8520 code the omap1 macro automatically determines what UART to use
 based on breadcrumbs left by the bootloader and automatically copes with
 the eccentric register layout on OMAP7XX.
 
 This patch drops both these features and relies instead on the generic
 8250 macros:
 
 1. Dropping support for the bootloader breadcrumbs is identical to the
way the migration was handled for OMAP2 (see 808b7e07464d...).
 
 2. Support for OMAP7XX still exists but it must be configured by hand
(DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime.
 
 Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org
 Cc: Russell King li...@arm.linux.org.uk
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: Tony Lindgren t...@atomide.com
 Cc: Arnd Bergmann arnd.bergm...@linaro.org
 Cc: linux-omap@vger.kernel.org
 Tested-by: Aaro Koskinen aaro.koski...@iki.fi

This should be safe to queue together with your other debug_ll
patches, so:

Acked-by: Tony Lindgren t...@atomide.com

If you want me to queue this one instead, please let me know.

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 0/2] ARM: dts: dra72-evm: Add i2c1 and tps65917 nodes

[Tony Lindgren]

* Nishanth Menon n...@ti.com [140908 13:05]:
 On 18:05-20140812, Keerthy wrote:
  On Monday 28 July 2014 02:52 PM, Keerthy wrote:
  On Monday 28 July 2014 12:00 PM, Lokesh Vutla wrote:
  On Monday 28 July 2014 11:48 AM, Keerthy wrote:
  The patch series adds i2c1 and tps65917 and related nodes.
  The patch series is boot tested on DRA72-EVM.
  
  Thanks to Lokesh lokeshvu...@ti.com for testing the series.
  
  Correcting the 'to' list.
  
  Hi Tony,
  
  If there are no comments could you please pull these two patches?
 
 With 3.17-rc4, I tested this series:
 dra72-evm-before: http://paste.ubuntu.org.cn/1496342
 dra72-evm-after: http://paste.ubuntu.org.cn/1496341
 
 Patches:
 https://patchwork.kernel.org/patch/4632391/
 https://patchwork.kernel.org/patch/4632421/
 
 Could we pick these with 3.18?
 
 Please free to add:
 
 Tested-by: Nishanth Menon n...@ti.com

OK applying into omap-for-v3.18/dt thanks.

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: [PATCHv3 0/5] OMAP Mailbox framework adoption DT support

[Tony Lindgren]

* Suman Anna s-a...@ti.com [140729 17:37]:
 Hi,
 
 This is an updated version of the OMAP Mailbox framework adoption 
 DT support series, refreshed to work with the v9 version of the mailbox
 framework [1] from Jassi Brar while also addressing some minor review
 comments. Detailed changes are summarized below. Patches are based on
 3.16-rc2.

Sorry for the delay, just noticed that I'm supposed to queue
these too. I'll queue these into omap-for-v3.18/mailbox against
v3.17-rc1 and will probably also merge it into omap-for-v3.18/dt
as well.

Regards,

Tony
 
 The series depends on the OMAP mailbox DT/hwmod cleanup series [2] and the
 OMAP mailbox cleanup series [3]. Both these series are staged to be merged
 for 3.17 [4]. The last 2 framework adaptation patches require the v9 framework
 patches to build successfully. The reference branch with all the patches is
 hosted (not for merging - includes an additional patch for dsp/bridge 
 changes) at 
 https://github.com/sumananna/mailbox/commits/submit/3.16-rc2-omap-mbox-v9-fwk-v3
 
 The AM335 PM suspend series [5] which relies on this series needs to have
 the wkupm3 node updated to use the new property name mboxes instead of
 mbox, and use the updated mbox_request_channel API.
 
 Changes in v3:
 - Revised the OMAP mailbox bindings to reflect the updated compatible
   strings (Patch 1) and the updated common mailbox properties in
   the v9 framework (Patch 4)
 - Code rearrangement/flip of if code blocks in omap_mailbox probe to address
   Markus Mayer's comments from v2 (Patch 2)
 - omap_mbox_of_xlate updated to add a missing of_node_put (Patch 4)
 - Adjust the added OMAP non-DT support API, omap_mbox_request_channel, to
   handle the loss of the chan_name field in the mbox_client structure
   from v8 to v9 of mailbox framework (Patch 4)
 - Dropped mailbox adaptation changes to TI DSP/Bridge driver, as it will be
   deleted in 3.17 (Patch 4)
 - No changes to DTS patches (Patches 3 and 5)
 - Tested against v9 of mailbox framework
 
 v2:
 - http://www.spinics.net/lists/linux-omap/msg109379.html
 - Updated the OMAP DT bindings document for the added back DT properties:
   ti,mbox-num-users and ti,mbox-num-fifos. Also added information
   regarding #mbox-cells and DT client usage.
 - Updated the OMAP DT adaptation patch to parse the added back DT properties
   and clean up the previous match data structure.
 - Squashed custom xlate patch into the framework adaptation patch.
 - Tested against v8 of mailbox framework.
 
 v1:
 - http://www.spinics.net/lists/linux-omap/msg108595.html
 - Tested against v7 of mailbox framework
 
 
 The following shows the boot/validation logs on various OMAP platforms:
   OMAP2 (SDP2430)   : http://slexy.org/view/s20ZcIovmA
   OMAP3 (BeagleXM)  : http://slexy.org/view/s2jWS6RPDJ
   OMAP4 (PandaBoard): http://slexy.org/view/s21Mxi3Z4v
   OMAP5 (OMAP5 uEVM): http://slexy.org/view/s2EUjy49h9
   DRA7  (DRA7 EVM)  : http://slexy.org/view/s29ehoRZWl
   AM33xx (BeagleBone Black) : http://slexy.org/view/s20A8RDPRy
   AM43xx (AM437x GP EVM): http://slexy.org/view/s21HMTnL2t
 
 [1] https://lkml.org/lkml/2014/7/22/613
 [2] http://marc.info/?l=linux-omapm=140511512208519w=2
 [3] http://www.spinics.net/lists/linux-omap/msg108574.html
 [4] 
 https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/?h=omap-for-v3.17/mailbox
 [5] http://www.spinics.net/lists/linux-omap/msg109331.html
 
 Suman Anna (5):
   Documentation: dt: add omap mailbox bindings
   mailbox/omap: add support for parsing dt devices
   ARM: dts: OMAP2+: Add sub mailboxes device node information
   mailbox/omap: adapt to the new mailbox framework
   ARM: dts: OMAP2+: Add #mbox-cells property to all mailbox nodes
 
  .../devicetree/bindings/mailbox/omap-mailbox.txt   | 132 ++
  arch/arm/boot/dts/am33xx.dtsi  |   5 +
  arch/arm/boot/dts/am4372.dtsi  |   5 +
  arch/arm/boot/dts/dra7.dtsi|  13 +
  arch/arm/boot/dts/omap2420.dtsi|   9 +
  arch/arm/boot/dts/omap2430.dtsi|   5 +
  arch/arm/boot/dts/omap3.dtsi   |   5 +
  arch/arm/boot/dts/omap4.dtsi   |   9 +
  arch/arm/boot/dts/omap5.dtsi   |   9 +
  drivers/mailbox/omap-mailbox.c | 502 
 ++---
  drivers/remoteproc/omap_remoteproc.c   |  51 ++-
  include/linux/omap-mailbox.h   |  16 +-
  12 files changed, 557 insertions(+), 204 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
 
 -- 
 2.0.0
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 5/8] ARM: dts: am33xx: Add external clock provider

[Tony Lindgren]

* Jyri Sarha jsa...@ti.com [140818 14:49]:
 Add external clock provider for am33xx devices.

Please send all the .dts and defconfig changes separately
so I can pick them up and we don't get pointless merge
conflicts.

Regards,

TOny
 
 Signed-off-by: Jyri Sarha jsa...@ti.com
 ---
  arch/arm/boot/dts/am33xx.dtsi |   10 ++
  1 file changed, 10 insertions(+)
 
 diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
 index 3a0a161..d2cc397 100644
 --- a/arch/arm/boot/dts/am33xx.dtsi
 +++ b/arch/arm/boot/dts/am33xx.dtsi
 @@ -92,6 +92,16 @@
   pinctrl-single,function-mask = 0x7f;
   };
  
 + ext_clocks {
 + compatible = ti,external-clocks;
 +
 + ext_clocks: clocks {
 + };
 +
 + ext_clockdomains: clockdomains {
 + };
 + };
 +
   /*
* XXX: Use a flat representation of the AM33XX interconnect.
* The real AM33XX interconnect network is quite complex. Since
 -- 
 1.7.9.5
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/18] tty: serial: 8250_core: allow to set -throttle / -unthrottle callbacks

[Greg Kroah-Hartman]

On Fri, Sep 05, 2014 at 09:02:38PM +0200, Sebastian Andrzej Siewior wrote:
 The OMAP UART provides support for HW assisted flow control. What is
 missing is the support to throttle / unthrottle callbacks which are used
 by the omap-serial driver at the moment.
 This patch adds the callbacks. It should be safe to add them since they
 are only invoked from the serial_core (uart_throttle()) if the feature
 flags are set.
 
 Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de

Due to other recent changes, this patch fails to apply :(

I've applied your first two, can you respin the rest and resend as a new
series?

thanks,

greg k-h
--
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: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)

[Pali Rohár]

On Sunday 08 December 2013 00:22:06 Tony Lindgren wrote:
 * Sebastian Reichel s...@ring0.de [131207 15:04]:
  On Sat, Dec 07, 2013 at 01:11:37PM -0800, Tony Lindgren wrote:
I asked Pali to send me his copy of the updated NOLO
bootloader, so that I can test this. I just checked the
omap documentation (I only have access to the public
one) and crypto related stuff is not documented for the
L3_PM_READ_PERMISSION register. There are a couple of
reserved bits, which may be used for this, though.

I also CC'd Joel Fernandes, since he worked on the
driver before and may have access to the documentation.
   
   Looks like at least the 36xx public version referenced
   here has them:
   
   http://www.spinics.net/lists/linux-omap/msg21857.html
   
   I'd assume the registers are the same for 34xx since we
   don't have them defined separately in the kernel.
  
  I can't find it in the omap36xx documentation either. Maybe
  I search at the wrong position. I tried to find something
  crypto related in
  
  Table 9-89. L3_PM_READ_PERMISSION_i
 
 Hmm maybe it's done based on the address in
 L3_PM_ADDR_MATCH_k?
 
 I guess the thing to do would be to compare the register
 output between the two different firmware versions.
 
 Regards,
 
 Tony

Hello, I found some info about omap firewall:
http://web.archive.org/web/20140703081349/http://droid-developers.org/wiki/L3_firewall

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 2/2] mfd: twl4030-power: use 'ti,system-power-controller' as alternative way to support system power off

[Tony Lindgren]

* Nishanth Menon n...@ti.com [140903 12:07]:
 ti,system-power-controller is more or less the standard way of
 indicating that the PMIC is the system wide power controller and hence
 may be used to switch off the system. Almost ALL TI PMIC drivers and
 many Maxim PMIC drivers follow the same style.
 
 So support 'ti,system-power-controller' in addition to the usual
 'ti,use_poweroff' to indicate that the PMIC instance has control for
 switching off the system.
 
 Signed-off-by: Nishanth Menon n...@ti.com

Acked-by: Tony Lindgren t...@atomide.com

 ---
  drivers/mfd/twl4030-power.c |3 +++
  1 file changed, 3 insertions(+)
 
 diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
 index 3bc969a..1c129ba 100644
 --- a/drivers/mfd/twl4030-power.c
 +++ b/drivers/mfd/twl4030-power.c
 @@ -627,6 +627,9 @@ static bool twl4030_power_use_poweroff(const struct 
 twl4030_power_data *pdata,
   if (pdata  pdata-use_poweroff)
   return true;
  
 + if (of_property_read_bool(node, ti,system-power-controller))
 + return true;
 +
   if (of_property_read_bool(node, ti,use_poweroff))
   return true;
  
 -- 
 1.7.9.5
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP2+: board-generic: add support for AM57xx family

[Tony Lindgren]

* Nishanth Menon n...@ti.com [140818 12:10]:
 AM57xx processor family are variants of DRA7 family of processors and
 targetted at industrial and non-automotive applications.
 
 Signed-off-by: Nishanth Menon n...@ti.com

Applying into omap-for-v3.18/dt thanks.

Tony

 ---
 
 NOTE: there is no discrenable features yet defined in register set at
 this point in time.
 
 Tested on AM5728 compatible platform and based on v3.17-rc1
 
  .../devicetree/bindings/arm/omap/omap.txt  |   12 
  arch/arm/mach-omap2/board-generic.c|4 
  2 files changed, 16 insertions(+)
 
 diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
 b/Documentation/devicetree/bindings/arm/omap/omap.txt
 index 0edc903..ddd9bcd 100644
 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
 +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
 @@ -85,6 +85,18 @@ SoCs:
  - DRA722
compatible = ti,dra722, ti,dra72, ti,dra7
  
 +- AM5728
 +  compatible = ti,am5728, ti,dra742, ti,dra74, ti,dra7
 +
 +- AM5726
 +  compatible = ti,am5726, ti,dra742, ti,dra74, ti,dra7
 +
 +- AM5718
 +  compatible = ti,am5718, ti,dra722, ti,dra72, ti,dra7
 +
 +- AM5716
 +  compatible = ti,am5716, ti,dra722, ti,dra72, ti,dra7
 +
  - AM4372
compatible = ti,am4372, ti,am43
  
 diff --git a/arch/arm/mach-omap2/board-generic.c 
 b/arch/arm/mach-omap2/board-generic.c
 index 9480997..bdb5194 100644
 --- a/arch/arm/mach-omap2/board-generic.c
 +++ b/arch/arm/mach-omap2/board-generic.c
 @@ -241,6 +241,8 @@ MACHINE_END
  
  #ifdef CONFIG_SOC_DRA7XX
  static const char *dra74x_boards_compat[] __initconst = {
 + ti,am5728,
 + ti,am5726,
   ti,dra742,
   ti,dra7,
   NULL,
 @@ -260,6 +262,8 @@ DT_MACHINE_START(DRA74X_DT, Generic DRA74X (Flattened 
 Device Tree))
  MACHINE_END
  
  static const char *dra72x_boards_compat[] __initconst = {
 + ti,am5718,
 + ti,am5716,
   ti,dra722,
   NULL,
  };
 -- 
 1.7.9.5
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4 v2] arm: omap: tao3530: Add pdata-quirk for the mmc2 internal clock

[Tony Lindgren]

* Stefan Roese s...@denx.de [140829 03:40]:
 Set internal clock source for MMC2 on tao3530.
 
 Signed-off-by: Stefan Roese s...@denx.de
 Cc: Thorsten Eisbein thorsten.eisb...@head-acoustics.de
 Cc: Tapani Utriainen tap...@technexion.com
 Cc: Tony Lindgren t...@atomide.com
 ---
 v2:
 - Patch description added to commit text

Applying all into omap-for-v3.18/dt thanks.

Tony
 
  arch/arm/mach-omap2/pdata-quirks.c | 6 ++
  1 file changed, 6 insertions(+)
 
 diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
 b/arch/arm/mach-omap2/pdata-quirks.c
 index 90c88d4..b9d091b 100644
 --- a/arch/arm/mach-omap2/pdata-quirks.c
 +++ b/arch/arm/mach-omap2/pdata-quirks.c
 @@ -253,6 +253,11 @@ static void __init nokia_n900_legacy_init(void)
  
   }
  }
 +
 +static void __init omap3_tao3530_legacy_init(void)
 +{
 + hsmmc2_internal_input_clk();
 +}
  #endif /* CONFIG_ARCH_OMAP3 */
  
  #ifdef CONFIG_ARCH_OMAP4
 @@ -377,6 +382,7 @@ static struct pdata_init pdata_quirks[] __initdata = {
   { ti,omap3-evm-37xx, omap3_evm_legacy_init, },
   { ti,omap3-zoom3, omap3_zoom_legacy_init, },
   { ti,am3517-evm, am3517_evm_legacy_init, },
 + { technexion,omap3-tao3530, omap3_tao3530_legacy_init, },
  #endif
  #ifdef CONFIG_ARCH_OMAP4
   { ti,omap4-sdp, omap4_sdp_legacy_init, },
 -- 
 2.1.0
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: omap5.dtsi: add DSS RFBI node

[Tony Lindgren]

* Nishanth Menon n...@ti.com [140904 06:45]:
 $subject: ARM: dts: OMAP5: Add DSS RFBI node
 
 On 09/04/2014 01:28 AM, Tomi Valkeinen wrote:
  The RFBI node for OMAP DSS was left out when adding the rest of the DSS
  nodes, because it was not clear how to set up the clocks for the RFBI.
  
  However, it seems that if there is a HWMOD for a device, we also need a
  DT node for it. Otherwise, at boot, we get:
  
  WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2542 
  _init+0x464/0x4e0()
  omap_hwmod: dss_rfbi: doesn't have mpu register target base
  
  Now that v3.17-rc3 contains a fix
  (8fd46439e1f5a7f86d76a08733459b74debd9468) for the L3 ICLK required by
  the RFBI, let's add the RFBI node to get rid of the warning.
 The usual style is to use the following style:
 Commit 8fd46439e1f5 (ARM: dts: omap54xx-clocks: Fix the l3 and l4
 clock rates)

Applying into omap-for-v3.18/dt with the above part of the
changelog updated.

Regards,

Tony 
 
  Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
  ---
   arch/arm/boot/dts/omap5.dtsi | 9 +
   1 file changed, 9 insertions(+)
  
  diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
  index fc8df1739f39..1e6ff61a7f12 100644
  --- a/arch/arm/boot/dts/omap5.dtsi
  +++ b/arch/arm/boot/dts/omap5.dtsi
  @@ -945,6 +945,15 @@
  clock-names = fck;
  };
   
  +   rfbi: encoder@58002000  {
  +   compatible = ti,omap5-rfbi;
  +   reg = 0x58002000 0x100;
  +   status = disabled;
  +   ti,hwmods = dss_rfbi;
  +   clocks = dss_dss_clk, l3_iclk_div;
  +   clock-names = fck, ick;
  +   };
  +
  dsi1: encoder@58004000 {
  compatible = ti,omap5-dsi;
  reg = 0x58004000 0x200,
  
 
 before-omap5-evm: http://paste.ubuntu.org.cn/1477659
 
 after-omap5-evm:  http://paste.ubuntu.org.cn/1477658
 
 So, yep, no more warning.
 
 
 -- 
 Regards,
 Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: dts: cm-t54: fix serial console power supply.

[Tony Lindgren]

* Paul Walmsley p...@pwsan.com [140904 08:44]:
 On Thu, 4 Sep 2014, Dmitry Lifshitz wrote:
 
  LDO8 regulator is used for act led and serial cosole power supply.
  
  Its DT status is declared as disabled, however the serial console was
  functional until Commit 318dbb02b (regulator: palmas: Fix SMPS
  enable/disable/is_enabled) wich properly turns off LDO8 on boot.
  
  Fix serial cosole power supply (and act led) on boot by turning LDO8 on.
  
  Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
 
 Tested-by: Paul Walmsley p...@pwsan.com

Applying this into omap-for-v3.17/fixes-v2, the second into
omap-for-v3.18/dt 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] ARM: dts: am335x-boneblack: Add names for remaining regulators

[Tony Lindgren]

* Mark Brown broo...@kernel.org [140905 14:12]:
 Add regulator-name properties for the regulators that don't have them,
 allowing the kernel to display the name from the schematic rather than
 the name of the regulator on the PMIC in order to improve diagnostics.
 
 Signed-off-by: Mark Brown broo...@kernel.org

Applying into omap-for-v3.18/dt thanks.

Tony

 ---
  arch/arm/boot/dts/am335x-bone-common.dtsi | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi 
 b/arch/arm/boot/dts/am335x-bone-common.dtsi
 index bde1777b62be..fe983d204b2b 100644
 --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
 +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
 @@ -227,6 +227,7 @@
  tps {
   regulators {
   dcdc1_reg: regulator@0 {
 + regulator-name = vdds_dpr;
   regulator-always-on;
   };
  
 @@ -249,18 +250,22 @@
   };
  
   ldo1_reg: regulator@3 {
 + regulator-name = vio,vrtc,vdds;
   regulator-always-on;
   };
  
   ldo2_reg: regulator@4 {
 + regulator-name = vdd_3v3aux;
   regulator-always-on;
   };
  
   ldo3_reg: regulator@5 {
 + regulator-name = vdd_1v8;
   regulator-always-on;
   };
  
   ldo4_reg: regulator@6 {
 + regulator-name = vdd_3v3a;
   regulator-always-on;
   };
   };
 -- 
 2.1.0
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: omap: Remove stray ARCH_HAS_OPP references

[Tony Lindgren]

* Nishanth Menon n...@ti.com [140906 07:11]:
 On 09/06/2014 05:14 AM, Mark Brown wrote:
 OPP is now a normal kernel library selected by its users rather than a
 feature that architectures need to enable so ARCH_HAS_OPP serves no
 function any more - remove the selects.
 
 Signed-off-by: Mark Brown broo...@kernel.org
... 
 
 Acked-by: Nishanth Menon n...@ti.com

Applying into omap-for-v3.18/soc 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 03/18] tty: serial: 8250_core: allow to set -throttle / -unthrottle callbacks

[Tony Lindgren]

* Greg Kroah-Hartman gre...@linuxfoundation.org [140908 16:33]:
 On Fri, Sep 05, 2014 at 09:02:38PM +0200, Sebastian Andrzej Siewior wrote:
  The OMAP UART provides support for HW assisted flow control. What is
  missing is the support to throttle / unthrottle callbacks which are used
  by the omap-serial driver at the moment.
  This patch adds the callbacks. It should be safe to add them since they
  are only invoked from the serial_core (uart_throttle()) if the feature
  flags are set.
  
  Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
 
 Due to other recent changes, this patch fails to apply :(
 
 I've applied your first two, can you respin the rest and resend as a new
 series?

It seems that we've reached pretty much omap-serial compability and
the remaining bugs are either already there with omap-serial or are
SoC specific and/or DMA related. So Sebastian, please feel also free
to add this when reposting:

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

Re: [PATCH 1/6] ARM: dts: OMAP3+: Add PRM interrupt

[Tony Lindgren]

* Nishanth Menon n...@ti.com [140822 07:08]:
 Provide OMAP3, 4 and OMAP5 with interrupt number for PRM
 
 And for DRA7, provide crossbar number for prm interrupt.
 
 Signed-off-by: Nishanth Menon n...@ti.com

I've picked this patch only into omap-for-v3.18/soc as
this is needed for Felipe's intc related changes to work
properly with the wake-up interrupts for DT based booting
for off-idle.

So please don't include this patch into your pull request
for the other dts changes you have.

Regards,

Tony

 ---
  arch/arm/boot/dts/dra7.dtsi  |1 +
  arch/arm/boot/dts/omap3.dtsi |1 +
  arch/arm/boot/dts/omap4.dtsi |1 +
  arch/arm/boot/dts/omap5.dtsi |1 +
  4 files changed, 4 insertions(+)
 
 diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
 index 97f603c..7a3e011 100644
 --- a/arch/arm/boot/dts/dra7.dtsi
 +++ b/arch/arm/boot/dts/dra7.dtsi
 @@ -89,6 +89,7 @@
   prm: prm@4ae06000 {
   compatible = ti,dra7-prm;
   reg = 0x4ae06000 0x3000;
 + interrupts = GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH;
  
   prm_clocks: clocks {
   #address-cells = 1;
 diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
 index 575a49b..3136ed1 100644
 --- a/arch/arm/boot/dts/omap3.dtsi
 +++ b/arch/arm/boot/dts/omap3.dtsi
 @@ -97,6 +97,7 @@
   prm: prm@48306000 {
   compatible = ti,omap3-prm;
   reg = 0x48306000 0x4000;
 + interrupts = 11;
  
   prm_clocks: clocks {
   #address-cells = 1;
 diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
 index 69408b5..7375d44 100644
 --- a/arch/arm/boot/dts/omap4.dtsi
 +++ b/arch/arm/boot/dts/omap4.dtsi
 @@ -129,6 +129,7 @@
   prm: prm@4a306000 {
   compatible = ti,omap4-prm;
   reg = 0x4a306000 0x3000;
 + interrupts = GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH;
  
   prm_clocks: clocks {
   #address-cells = 1;
 diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
 index fc8df17..df0a09b 100644
 --- a/arch/arm/boot/dts/omap5.dtsi
 +++ b/arch/arm/boot/dts/omap5.dtsi
 @@ -131,6 +131,7 @@
   prm: prm@4ae06000 {
   compatible = ti,omap5-prm;
   reg = 0x4ae06000 0x3000;
 + interrupts = GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH;
  
   prm_clocks: clocks {
   #address-cells = 1;
 -- 
 1.7.9.5
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/35] arm: omap: move intc to drivers/irqchip/

[Tony Lindgren]

* Felipe Balbi ba...@ti.com [140728 14:19]:
 Hi folks,
 
 here's another rebase of the original series moving INTC
 to drivers.
 
 There aren't many changes, only some fixes here and there
 because of recent changes to irq_domain and irqchip.
 
 I have also added a patch to enable INTC address space
 protection so that only privileged modes can access
 INTC's address space.
 
 Patches tested on top of v3.17-rc7 with a beagle bone black,
 the only plataform I have which still uses INTC.
 
 Tony, if you can run your PM test cases on your side, I'd
 be really glad.

With Nishants changes for the omap3 PRCM interrupt and the
related .dts changes the PM works for me now with this series.

So I'm applying these into omap-for-v3.18/intc on top of
Nishant's changes in omap-for-v3.18/soc thanks.

Regards,

Tony
 
 cheers
 
 Felipe Balbi (35):
   arm: omap: irq: make omap_irq_base global
   arm: omap: irq: define INTC_ILR0 register
   arm: omap: irq: start to remove irq_banks array
   arm: omap: irq: add a global omap_nr_irqs variable
   arm: omap: irq: remove rest of irq_banks usage
   arm: omap: irq: remove unused macro
   arm: omap: irq: switch over to intc_readl on omap_intc_handle_irq
   arm: omap: irq: remove unnecessary base_addr argument
   arm: omap: irq: rename omap3_intc_regs
   arm: omap: irq: always define omap3 support
   arm: omap: irq: reorganize code a little bit
   arm: omap: irq: make intc_of_init static
   arm: omap: irq: call set_handle_irq() from intc_of_init
   arm: omap: irq: use IRQCHIP_DECLARE macro
   arm: omap: irq: drop .handle_irq and .init_irq fields
   arm: omap: irq: add specific compatibles for omap3 and am33xx devices
   arm: omap: irq: use compatible flag to figure out number of IRQ lines
   arm: boot: dts: am33xx/omap3: fix intc compatible flag
   arm: omap: irq: drop ti,intc-size support
   arm: boot: dts: omap2/3/am33xx: drop ti,intc-size
   arm: omap: irq: move some more code around
   arm: omap: irq: call set_handle_irq() from .init_irq
   arm: omap: irq: drop omap3_intc_handle_irq()
   arm: omap: irq: drop omap2_intc_handle_irq()
   arm: omap: irq: remove unnecessary header
   arm: omap: irq: remove nr_irqs argument
   arm: omap: irq: introduce omap_nr_pending
   arm: omap: irq: get rid of ifdef hack
   arm: omap: intc: switch over to linear irq domain
   irqchip: add irq-omap-intc.h header
   arm: omap: irq: move irq.c to drivers/irqchip/
   irq: intc: minor improvement to omap_irq_pending()
   irq: intc: comment style cleanup
   irq: intc: remove unnecesary of_address_to_resource() call
   irq: intc: enable IP protection
 
  arch/arm/boot/dts/am33xx.dtsi  |   3 +-
  arch/arm/boot/dts/omap2.dtsi   |   1 -
  arch/arm/boot/dts/omap3.dtsi   |   3 +-
  arch/arm/mach-omap2/Kconfig|   1 +
  arch/arm/mach-omap2/Makefile   |   3 +-
  arch/arm/mach-omap2/board-3430sdp.c|   2 +-
  arch/arm/mach-omap2/board-am3517crane.c|   2 +-
  arch/arm/mach-omap2/board-am3517evm.c  |   2 +-
  arch/arm/mach-omap2/board-cm-t35.c |   3 +-
  arch/arm/mach-omap2/board-cm-t3517.c   |   2 +-
  arch/arm/mach-omap2/board-devkit8000.c |   2 +-
  arch/arm/mach-omap2/board-generic.c|  14 -
  arch/arm/mach-omap2/board-ldp.c|   2 +-
  arch/arm/mach-omap2/board-omap3beagle.c|   2 +-
  arch/arm/mach-omap2/board-omap3logic.c |   3 +-
  arch/arm/mach-omap2/board-omap3pandora.c   |   2 +-
  arch/arm/mach-omap2/board-omap3stalker.c   |   2 +-
  arch/arm/mach-omap2/board-omap3touchbook.c |   2 +-
  arch/arm/mach-omap2/board-overo.c  |   2 +-
  arch/arm/mach-omap2/board-rx51.c   |   2 +-
  arch/arm/mach-omap2/board-ti8168evm.c  |   1 +
  arch/arm/mach-omap2/common.h   |  22 --
  arch/arm/mach-omap2/cpuidle34xx.c  |   1 +
  arch/arm/mach-omap2/irq.c  | 380 ---
  arch/arm/mach-omap2/pm24xx.c   |   1 +
  arch/arm/mach-omap2/pm34xx.c   |   1 +
  drivers/irqchip/Kconfig|   5 +
  drivers/irqchip/Makefile   |   1 +
  drivers/irqchip/irq-omap-intc.c| 408 
 +
  include/linux/irqchip/irq-omap-intc.h  |  32 +++
  30 files changed, 468 insertions(+), 439 deletions(-)
  delete mode 100644 arch/arm/mach-omap2/irq.c
  create mode 100644 drivers/irqchip/irq-omap-intc.c
  create mode 100644 include/linux/irqchip/irq-omap-intc.h
 
 -- 
 2.0.1.563.g66f467c
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 0/5] OMAP Mailbox framework adoption DT support

[Tony Lindgren]

* Tony Lindgren t...@atomide.com [140908 16:21]:
 * Suman Anna s-a...@ti.com [140729 17:37]:
  Hi,
  
  This is an updated version of the OMAP Mailbox framework adoption 
  DT support series, refreshed to work with the v9 version of the mailbox
  framework [1] from Jassi Brar while also addressing some minor review
  comments. Detailed changes are summarized below. Patches are based on
  3.16-rc2.
 
 Sorry for the delay, just noticed that I'm supposed to queue
 these too. I'll queue these into omap-for-v3.18/mailbox against
 v3.17-rc1 and will probably also merge it into omap-for-v3.18/dt
 as well.

Actually this is not compiling and seems to probably miss
the dependencies from Jassi, so dropping the branch.

Anyways, since it seems you need to repost this again, please
repost the DT changes separately from the driver changes.

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