from:"Franklin S Cooper Jr."

Re: [PATCH v2 0/5] mtd: nand: Fix support for NAND DMA prefetch

2015-12-30 Thread Franklin S Cooper Jr.



On 12/18/2015 12:04 PM, Brian Norris wrote:
> On Thu, Oct 15, 2015 at 12:37:23PM -0500, Franklin S Cooper Jr wrote:
>> NAND DMA prefetch has been broken for awhile and seems to have only
>> worked for SDMA based devices
>>
>> This patchset fixes DMA prefetch to work on both EDMA and SDMA devices
>>
>> Test on:
>> am335x gp evm
>> am437x gp evm
>> am37x gp evm
>>
>> This patchset depends on Roger Quadros recent v4 GPMC/NAND patchset
>> https://github.com/rogerq/linux.git
>> branch: for-v4.4/gpmc-v4
> In what way does this depend on the other series? Can any of this be
> taken without it? If not, then perhaps it'd be good if Roger can roll
> this into his series? Just throwing out ideas. If you want to wait on
> Roger's series, that's fine.
>
> FWIW, the MTD stuff all looks OK to me:
>
> Acked-by: Brian Norris <computersforpe...@gmail.com>

Patches 2 and 3 doesn't have any dependencies on Roger's
patchset so they should be fine to pull in.

I'll leave it up to Roger if he would like to roll my
patches into his patchset or I can submit the other 3
patches again once he sends out his new patchset.

>> Franklin S Cooper Jr (5):
>>   mtd: nand: omap2: Support parsing dma channel information from DT
>>   mtd: nand: omap2: Start dma request before enabling prefetch
>>   mtd: nand: omap2: Fix high memory dma prefetch transfer
>>   ARM: dts: am437x/am33xx/omap/dm816x: Add gpmc dma channel
>>   ARM: OMAP2+: Update GPMC and NAND DT binding documentation
>>
>>  .../bindings/memory-controllers/omap-gpmc.txt  |  7 +-
>>  .../devicetree/bindings/mtd/gpmc-nand.txt  |  2 ++
>>  arch/arm/boot/dts/am33xx.dtsi  |  2 ++
>>  arch/arm/boot/dts/am4372.dtsi  |  2 ++
>>  arch/arm/boot/dts/dm816x.dtsi  |  2 ++
>>  arch/arm/boot/dts/omap3.dtsi   |  2 ++
>>  arch/arm/boot/dts/omap4.dtsi   |  2 ++
>>  arch/arm/boot/dts/omap5.dtsi   |  2 ++
>>  drivers/mtd/nand/omap2.c   | 27 
>> +-
>>  9 files changed, 31 insertions(+), 17 deletions(-)
>>
>> -- 
>> 2.6.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 0/2] Remove elm address space from omap4 hwmod

2015-10-28 Thread Franklin S Cooper Jr

This patchset removes elm address entry from omap4 hwmod and adds
an elm DT node to omap4.dtsi.

Since no omap4 supports nand in mainline this patchset was boot
tested on a pandaboard.

Franklin S Cooper Jr (2):
  ARM: dts: omap4: Add elm node
  ARM: omap4: hwmod: Remove elm address space from hwmod data

 arch/arm/boot/dts/omap4.dtsi   |  8 
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 --
 2 files changed, 8 insertions(+), 10 deletions(-)

-- 
2.6.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 1/2] ARM: dts: omap4: Add elm node

2015-10-28 Thread Franklin S Cooper Jr

Add device tree entry for the error location module.

Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
 arch/arm/boot/dts/omap4.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 5a206c1..a40eb23 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -348,6 +348,14 @@
#interrupt-cells = <2>;
};
 
+   elm: elm@48078000 {
+   compatible = "ti,am3352-elm";
+   reg = <0x48078000 0x2000>;
+   interrupts = <4>;
+   ti,hwmods = "elm";
+   status = "disabled";
+   };
+
gpmc: gpmc@5000 {
compatible = "ti,omap4430-gpmc";
reg = <0x5000 0x1000>;
-- 
2.6.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 2/2] ARM: omap4: hwmod: Remove elm address space from hwmod data

2015-10-28 Thread Franklin S Cooper Jr

ELM address information is provided by device tree. No longer need
to include this information within hwmod.

This patch has only been boot tested.

Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 43eebf2..8f13f4a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -3915,21 +3915,11 @@ static struct omap_hwmod_ocp_if 
omap44xx_l4_per__dss_venc = {
.user   = OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space omap44xx_elm_addrs[] = {
-   {
-   .pa_start   = 0x48078000,
-   .pa_end = 0x48078fff,
-   .flags  = ADDR_TYPE_RT
-   },
-   { }
-};
-
 /* l4_per -> elm */
 static struct omap_hwmod_ocp_if omap44xx_l4_per__elm = {
.master = _l4_per_hwmod,
.slave  = _elm_hwmod,
.clk= "l4_div_ck",
-   .addr   = omap44xx_elm_addrs,
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-- 
2.6.1

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

Re: [PATCH 1/2 v2] ARM: DRA7/335x/437x/OMAP4: hwmod: Remove elm address space from hwmod data

2015-10-26 Thread Franklin S Cooper Jr.



On 10/23/2015 02:00 PM, Paul Walmsley wrote:
> On Thu, 15 Oct 2015, Franklin S Cooper Jr wrote:
>
>> ELM address information is provided by device tree. No longer need
>> to include this information within hwmod.
>>
>> Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
> The OMAP4 DTS files don't have the ELM address space declared.  I'm going 
> to drop that portion of your patch.  Could you please send a two-patch 
> series that first adds the ELM address space to the OMAP4 DTS file and 
> then subsequently drops it from the OMAP4 hwmod data file?
Hi Paul,

Sorry about that. I can create the patches but I don't see any board omap4
board that has nand support. So I'm not going to be able to test to insure if
omap_elm.c will work as is.

Should I just drop omap4 from this patchset or should I just add the elm node
to omap4.dtsi and if people report an issue with omap_elm then we can fix it?


>
>
> - Paul

--
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/5] mtd: nand: omap2: Support parsing dma channel information from DT

2015-10-15 Thread Franklin S Cooper Jr.



On 10/15/2015 02:35 AM, Roger Quadros wrote:
> On 14/10/15 23:03, Franklin S Cooper Jr. wrote:
>>
>> On 10/14/2015 01:13 PM, Tony Lindgren wrote:
>>> * Franklin S Cooper Jr. <fcoo...@ti.com> [151014 09:27]:
>>>> On 10/14/2015 11:18 AM, Tony Lindgren wrote:
>>>>> * Franklin S Cooper Jr. <fcoo...@ti.com> [151014 07:37]:
>>>>>> On 10/14/2015 09:11 AM, Roger Quadros wrote:
>>>>>>> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>>>>>>>> On 10/14/2015 06:52 AM, Roger Quadros wrote:
>>>>>>>>> Franklin,
>>>>>>>>>
>>>>>>>>> On 14/10/15 14:36, Roger Quadros wrote:
>>>>>>>>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>>>>>>>>>> Switch from dma_request_channel to allow passing dma channel
>>>>>>>>>>> information from DT rather than hardcoding a value.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
>>>>>>>>>> Acked-by: Roger Quadros <rog...@ti.com>
>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>>>>>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>>>>>>>> index d0f2620..957c32f 100644
>>>>>>>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>>>>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>>>>>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct 
>>>>>>>>>>> platform_device *pdev)
>>>>>>>>>>> dma_cap_zero(mask);
>>>>>>>>>>> dma_cap_set(DMA_SLAVE, mask);
>>>>>>>>>>> sig = OMAP24XX_DMA_GPMC;
>>>>>>>>>>> -   info->dma = dma_request_channel(mask, 
>>>>>>>>>>> omap_dma_filter_fn, );
>>>>>>>>>>> +   info->dma = dma_request_slave_channel_compat(mask,
>>>>>>>>>>> +   omap_dma_filter_fn, , pdev->dev.parent, 
>>>>>>>>>>> "rxtx");
>>>>>>>>>>> +
>>>>>>>>> Just discovered that you are using the parent device node.
>>>>>>>>>
>>>>>>>>> How about moving the dma bindings to the nand node instead and using
>>>>>>>>> pdev->dev here?
>>>>>>>> Roger,
>>>>>>>>
>>>>>>>> From what I can tell the interrupt number and the dma channel will 
>>>>>>>> always be
>>>>>>>> the same no matter what. Doesn't matter if you have multiple nands or a
>>>>>>>> combination of nands and nors. Since that is the case I think it just 
>>>>>>>> makes
>>>>>>>> sense to leave it in the gpmc parent node and define it once.
>>>>>>> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
>>>>>>> or only for NAND?
>>>>>> The dma seems tied to the prefetch. From what I can tell the prefetch is 
>>>>>> only
>>>>>> used by nand.
>>>>>>> Let's also get Tony's inputs on this.
>>>>>> Sure.
>>>>> Hmm so what would keep other devices from using the prefetch
>>>> Looking at the TRM any references to the prefetch are always with respect 
>>>> to
>>>> NAND.
>>>>
>>>> I also see the below mentioned in the TRM.
>>>> Pre-fetch and write posting engine associated with system DMA to get full 
>>>> performance from NAND
>>>> device with minimum impact on NOR/SRAM concurrent access.
>>> OK up to you guys to figure out if it may be usable in a generic way then :)
>> Ok I just got clarification from hw folks. DMA for GPMC can be used for any 
>> of the
>> various modes. But the prefetch is specific to NAND.
> In that case the dma information must be in the GPMC node.
Ok I'll be sending a v2 patchset soon but I'll be leaving this as is.
>
> 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

[PATCH 2/2 v2] ARM: DRA7/335x/437x: hwmod: Remove gpmc address space from hwmod data

2015-10-15 Thread Franklin S Cooper Jr

GPMC address information is provided by device tree. No longer need
to include this information within hwmod.

Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
Version 2 changes:
None

 arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c | 10 --
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c| 10 --
 2 files changed, 20 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c 
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
index 9ba431c..1c210cb 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
@@ -275,20 +275,10 @@ struct omap_hwmod_ocp_if am33xx_epwmss2__ehrpwm2 = {
 };
 
 /* l3s cfg -> gpmc */
-static struct omap_hwmod_addr_space am33xx_gpmc_addr_space[] = {
-   {
-   .pa_start   = 0x5000,
-   .pa_end = 0x5000 + SZ_8K - 1,
-   .flags  = ADDR_TYPE_RT,
-   },
-   { }
-};
-
 struct omap_hwmod_ocp_if am33xx_l3_s__gpmc = {
.master = _l3_s_hwmod,
.slave  = _gpmc_hwmod,
.clk= "l3s_gclk",
-   .addr   = am33xx_gpmc_addr_space,
.user   = OCP_USER_MPU,
 };
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index ad2cc7a..7bf106a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -2638,21 +2638,11 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per1__gpio8 = 
{
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-static struct omap_hwmod_addr_space dra7xx_gpmc_addrs[] = {
-   {
-   .pa_start   = 0x5000,
-   .pa_end = 0x53ff,
-   .flags  = ADDR_TYPE_RT
-   },
-   { }
-};
-
 /* l3_main_1 -> gpmc */
 static struct omap_hwmod_ocp_if dra7xx_l3_main_1__gpmc = {
.master = _l3_main_1_hwmod,
.slave  = _gpmc_hwmod,
.clk= "l3_iclk_div",
-   .addr   = dra7xx_gpmc_addrs,
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-- 
2.6.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/5] mtd: nand: Fix support for NAND DMA prefetch

2015-10-15 Thread Franklin S Cooper Jr

NAND DMA prefetch has been broken for awhile and seems to have only
worked for SDMA based devices

This patchset fixes DMA prefetch to work on both EDMA and SDMA devices

Test on:
am335x gp evm
am437x gp evm
am37x gp evm

This patchset depends on Roger Quadros recent v4 GPMC/NAND patchset
https://github.com/rogerq/linux.git
branch: for-v4.4/gpmc-v4

Franklin S Cooper Jr (5):
  mtd: nand: omap2: Support parsing dma channel information from DT
  mtd: nand: omap2: Start dma request before enabling prefetch
  mtd: nand: omap2: Fix high memory dma prefetch transfer
  ARM: dts: am437x/am33xx/omap/dm816x: Add gpmc dma channel
  ARM: OMAP2+: Update GPMC and NAND DT binding documentation

 .../bindings/memory-controllers/omap-gpmc.txt  |  7 +-
 .../devicetree/bindings/mtd/gpmc-nand.txt  |  2 ++
 arch/arm/boot/dts/am33xx.dtsi  |  2 ++
 arch/arm/boot/dts/am4372.dtsi  |  2 ++
 arch/arm/boot/dts/dm816x.dtsi  |  2 ++
 arch/arm/boot/dts/omap3.dtsi   |  2 ++
 arch/arm/boot/dts/omap4.dtsi   |  2 ++
 arch/arm/boot/dts/omap5.dtsi   |  2 ++
 drivers/mtd/nand/omap2.c   | 27 +-
 9 files changed, 31 insertions(+), 17 deletions(-)

-- 
2.6.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 3/5] mtd: nand: omap2: Fix high memory dma prefetch transfer

2015-10-15 Thread Franklin S Cooper Jr

Based on DMA documentation and testing using high memory buffer when
doing dma transfers can lead to various issues including kernel
panics.

To workaround this simply use cpu copy. The amount of high memory
buffers used are very uncommon so no noticeable performance hit should
be seen.

Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
V2 Changes:
None

 drivers/mtd/nand/omap2.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 1f58420..0d2cbb0 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -479,17 +479,8 @@ static inline int omap_nand_dma_transfer(struct mtd_info 
*mtd, void *addr,
int ret;
u32 val;
 
-   if (addr >= high_memory) {
-   struct page *p1;
-
-   if (((size_t)addr & PAGE_MASK) !=
-   ((size_t)(addr + len - 1) & PAGE_MASK))
-   goto out_copy;
-   p1 = vmalloc_to_page(addr);
-   if (!p1)
-   goto out_copy;
-   addr = page_address(p1) + ((size_t)addr & ~PAGE_MASK);
-   }
+   if (addr >= high_memory)
+   goto out_copy;
 
sg_init_one(, addr, len);
n = dma_map_sg(info->dma->device->dev, , 1, dir);
@@ -546,6 +537,7 @@ out_copy:
else
is_write == 0 ? omap_read_buf8(mtd, (u_char *) addr, len)
: omap_write_buf8(mtd, (u_char *) addr, len);
+
return 0;
 }
 
-- 
2.6.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/5] mtd: nand: omap2: Start dma request before enabling prefetch

2015-10-15 Thread Franklin S Cooper Jr

The prefetch engine sends a dma request once a FIFO threshold has
been met. No other requests are received until the previous request
is handled.

Starting an edma transfer (dma_async_issue_pending) results in any
previous event for the dma channel to be cleared. Therefore, starting
the prefetch engine before initiating the dma transfer may result in
the prefetch triggering a dma request but instead of it being handled
it can end up being cleared. This will result in a hang since the code
will continue to wait for the dma request to complete.

By initiating the dma request before enabling the prefetch engine this
race condition is avoided and no dma request are missed/cleared.

Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
V2 Changes:
Moved comment

 drivers/mtd/nand/omap2.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 957c32f..1f58420 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -509,6 +509,11 @@ static inline int omap_nand_dma_transfer(struct mtd_info 
*mtd, void *addr,
tx->callback_param = >comp;
dmaengine_submit(tx);
 
+   init_completion(>comp);
+
+   /* setup and start DMA using dma_addr */
+   dma_async_issue_pending(info->dma);
+
/*  configure and start prefetch transfer */
ret = omap_prefetch_enable(info->gpmc_cs,
PREFETCH_FIFOTHRESHOLD_MAX, 0x1, len, is_write, info);
@@ -516,10 +521,6 @@ static inline int omap_nand_dma_transfer(struct mtd_info 
*mtd, void *addr,
/* PFPW engine is busy, use cpu copy method */
goto out_copy_unmap;
 
-   init_completion(>comp);
-   dma_async_issue_pending(info->dma);
-
-   /* setup and start DMA using dma_addr */
wait_for_completion(>comp);
tim = 0;
limit = (loops_per_jiffy * msecs_to_jiffies(OMAP_NAND_TIMEOUT_MS));
-- 
2.6.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 4/5] ARM: dts: am437x/am33xx/omap/dm816x: Add gpmc dma channel

2015-10-15 Thread Franklin S Cooper Jr

Add dma channel information to the gpmc. Although not enabled by
default this will allow prefetch-dma to be used.

Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
V2 Changes:
Added DMA entry for OMAP4 and OMAP5

 arch/arm/boot/dts/am33xx.dtsi | 2 ++
 arch/arm/boot/dts/am4372.dtsi | 2 ++
 arch/arm/boot/dts/dm816x.dtsi | 2 ++
 arch/arm/boot/dts/omap3.dtsi  | 2 ++
 arch/arm/boot/dts/omap4.dtsi  | 2 ++
 arch/arm/boot/dts/omap5.dtsi  | 2 ++
 6 files changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index e065f21..f2d8eed 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -819,6 +819,8 @@
ti,no-idle-on-init;
reg = <0x5000 0x2000>;
interrupts = <100>;
+   dmas = < 52>;
+   dma-names = "rxtx";
gpmc,num-cs = <7>;
gpmc,num-waitpins = <2>;
#address-cells = <2>;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ec8b7a3..c02061b 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -841,6 +841,8 @@
gpmc: gpmc@5000 {
compatible = "ti,am3352-gpmc";
ti,hwmods = "gpmc";
+   dmas = < 52>;
+   dma-names = "rxtx";
clocks = <_gclk>;
clock-names = "fck";
reg = <0x5000 0x2000>;
diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index 68fb444..d2e5d31 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -180,6 +180,8 @@
#address-cells = <2>;
#size-cells = <1>;
interrupts = <100>;
+   dmas = < 52>;
+   dma-names = "rxtx";
gpmc,num-cs = <6>;
gpmc,num-waitpins = <2>;
gpio-controller;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 7f212b6..9dbbcf6 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -717,6 +717,8 @@
ti,hwmods = "gpmc";
reg = <0x6e00 0x02d0>;
interrupts = <20>;
+   dmas = < 4>;
+   dma-names = "rxtx";
gpmc,num-cs = <8>;
gpmc,num-waitpins = <4>;
#address-cells = <2>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 5a206c1..32b65be 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -354,6 +354,8 @@
#address-cells = <2>;
#size-cells = <1>;
interrupts = ;
+   dmas = < 4>;
+   dma-names = "rxtx";
gpmc,num-cs = <8>;
gpmc,num-waitpins = <4>;
ti,hwmods = "gpmc";
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 4c04389..ca3c17f 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -391,6 +391,8 @@
#address-cells = <2>;
#size-cells = <1>;
interrupts = ;
+   dmas = < 4>;
+   dma-names = "rxtx";
gpmc,num-cs = <8>;
gpmc,num-waitpins = <4>;
ti,hwmods = "gpmc";
-- 
2.6.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 1/2 v2] ARM: DRA7/335x/437x/OMAP4: hwmod: Remove elm address space from hwmod data

2015-10-15 Thread Franklin S Cooper Jr

ELM address information is provided by device tree. No longer need
to include this information within hwmod.

Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
Version 2 changes:
Removing elm addr entries also for 335x,437x and omap4 hwmod

 arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c | 10 --
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c   | 10 --
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c| 10 --
 3 files changed, 30 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c 
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
index 8f5989d..9ba431c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
@@ -152,20 +152,10 @@ struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
.user   = OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
-   {
-   .pa_start   = 0x4808,
-   .pa_end = 0x4808 + SZ_8K - 1,
-   .flags  = ADDR_TYPE_RT
-   },
-   { }
-};
-
 struct omap_hwmod_ocp_if am33xx_l4_ls__elm = {
.master = _l4_ls_hwmod,
.slave  = _elm_hwmod,
.clk= "l4ls_gclk",
-   .addr   = am33xx_elm_addr_space,
.user   = OCP_USER_MPU,
 };
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 43eebf2..8f13f4a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -3915,21 +3915,11 @@ static struct omap_hwmod_ocp_if 
omap44xx_l4_per__dss_venc = {
.user   = OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space omap44xx_elm_addrs[] = {
-   {
-   .pa_start   = 0x48078000,
-   .pa_end = 0x48078fff,
-   .flags  = ADDR_TYPE_RT
-   },
-   { }
-};
-
 /* l4_per -> elm */
 static struct omap_hwmod_ocp_if omap44xx_l4_per__elm = {
.master = _l4_per_hwmod,
.slave  = _elm_hwmod,
.clk= "l4_div_ck",
-   .addr   = omap44xx_elm_addrs,
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 562247b..ad2cc7a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -2566,21 +2566,11 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__hdmi 
= {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-static struct omap_hwmod_addr_space dra7xx_elm_addrs[] = {
-   {
-   .pa_start   = 0x48078000,
-   .pa_end = 0x48078fff,
-   .flags  = ADDR_TYPE_RT
-   },
-   { }
-};
-
 /* l4_per1 -> elm */
 static struct omap_hwmod_ocp_if dra7xx_l4_per1__elm = {
.master = _l4_per1_hwmod,
.slave  = _elm_hwmod,
.clk= "l3_iclk_div",
-   .addr   = dra7xx_elm_addrs,
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-- 
2.6.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 5/5] ARM: OMAP2+: Update GPMC and NAND DT binding documentation

2015-10-15 Thread Franklin S Cooper Jr

Add additional details to the GPMC NAND documentation to clarify
what is needed to enable NAND DMA prefetch.

Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
V2 Changes:
Replace nand and Nand with NAND
Specify the value dma-names should be set to

 Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt | 7 ++-
 Documentation/devicetree/bindings/mtd/gpmc-nand.txt| 2 ++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt 
b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
index 704be93..afae4b3 100644
--- a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
@@ -33,6 +33,10 @@ Required properties:
As this will change in the future, filling correct
values here is a requirement.
 
+GPMC DMA information.
+ - dmasGPMC NAND prefetch dma channel
+ - dma-names   Must be set to "rxtx"
+
 Timing properties for child nodes. All are optional and default to 0.
 
  - gpmc,sync-clk-ps:   Minimum clock period for synchronous mode, in 
picoseconds
@@ -119,7 +123,8 @@ Example for an AM33xx board:
ti,hwmods = "gpmc";
reg = <0x5000 0x2000>;
interrupts = <100>;
-
+   dmas = < 52>;
+   dma-names = "rxtx";
gpmc,num-cs = <8>;
gpmc,num-waitpins = <2>;
#address-cells = <2>;
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt 
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index 253e6de..4b0c240 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -61,6 +61,8 @@ Example for an AM33xx board:
ti,hwmods = "gpmc";
reg = <0x5000 0x36c>;
interrupts = <100>;
+   dmas = < 52>;
+   dma-names = "rxtx";
gpmc,num-cs = <8>;
gpmc,num-waitpins = <2>;
#address-cells = <2>;
-- 
2.6.1

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

Re: [PATCH 5/5] ARM: OMAP2+: Update gpmc and nand DT binding documentation

2015-10-15 Thread Franklin S Cooper Jr.



On 10/14/2015 06:50 AM, Roger Quadros wrote:
> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>> Add additional details to the gpmc and nand documentation to clarify
>> what is needed to enable nand dma prefetch.
>>
>> Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
>> ---
>>  Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt | 7 
>> ++-
>>  Documentation/devicetree/bindings/mtd/gpmc-nand.txt| 2 ++
>>  2 files changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt 
>> b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
>> index 704be93..b1e2802 100644
>> --- a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
>> +++ b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
>> @@ -33,6 +33,10 @@ Required properties:
>>  As this will change in the future, filling correct
>>  values here is a requirement.
>>  
>> +GPMC DMA information. Required only when GPMC nand prefetch is enabled.
>> + - dmas GPMC nand prefetch dma channel
> s/nand/NAND
>
>> + - dma-namesDMA channel name use as a reference within the 
>> Nand driver
> s/Nand/NAND
>
> This is inevitably going to be "rxtx". So why not say that it should be "rxtx"
I'll fix all three of these
>
> Should these bindings go in bindings/mtd/gpmc-nand.txt instead?
>
>> +
>>  Timing properties for child nodes. All are optional and default to 0.
>>  
>>   - gpmc,sync-clk-ps:Minimum clock period for synchronous mode, in 
>> picoseconds
>> @@ -119,7 +123,8 @@ Example for an AM33xx board:
>>  ti,hwmods = "gpmc";
>>  reg = <0x5000 0x2000>;
>>  interrupts = <100>;
>> -
>> +dmas = < 52>;
>> +dma-names = "rxtx";
> Why not define these in the NAND node instead of gpmc node?
Since we decided that the dma entry will stay in the GPMC node I'll leave these 
as is.
>
>>  gpmc,num-cs = <8>;
>>  gpmc,num-waitpins = <2>;
>>  #address-cells = <2>;
>> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt 
>> b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>> index 253e6de..4b0c240 100644
>> --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>> @@ -61,6 +61,8 @@ Example for an AM33xx board:
>>  ti,hwmods = "gpmc";
>>  reg = <0x5000 0x36c>;
>>  interrupts = <100>;
>> +dmas = < 52>;
>> +dma-names = "rxtx";
>>  gpmc,num-cs = <8>;
>>  gpmc,num-waitpins = <2>;
>>  #address-cells = <2>;
>>
> 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

[PATCH v2 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

2015-10-15 Thread Franklin S Cooper Jr

Switch from dma_request_channel to allow passing dma channel
information from DT rather than hardcoding a value.

Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
V2 Changes:
None

 drivers/mtd/nand/omap2.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index d0f2620..957c32f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
sig = OMAP24XX_DMA_GPMC;
-   info->dma = dma_request_channel(mask, omap_dma_filter_fn, );
+   info->dma = dma_request_slave_channel_compat(mask,
+   omap_dma_filter_fn, , pdev->dev.parent, "rxtx");
+
if (!info->dma) {
dev_err(>dev, "DMA engine request failed\n");
err = -ENXIO;
-- 
2.6.1

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

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

2015-10-14 Thread Franklin S Cooper Jr.



On 10/14/2015 09:11 AM, Roger Quadros wrote:
> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>>
>> On 10/14/2015 06:52 AM, Roger Quadros wrote:
>>> Franklin,
>>>
>>> On 14/10/15 14:36, Roger Quadros wrote:
>>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>>>> Switch from dma_request_channel to allow passing dma channel
>>>>> information from DT rather than hardcoding a value.
>>>>>
>>>>> Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
>>>> Acked-by: Roger Quadros <rog...@ti.com>
>>>>
>>>>> ---
>>>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>> index d0f2620..957c32f 100644
>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device 
>>>>> *pdev)
>>>>>   dma_cap_zero(mask);
>>>>>   dma_cap_set(DMA_SLAVE, mask);
>>>>>   sig = OMAP24XX_DMA_GPMC;
>>>>> - info->dma = dma_request_channel(mask, omap_dma_filter_fn, );
>>>>> + info->dma = dma_request_slave_channel_compat(mask,
>>>>> + omap_dma_filter_fn, , pdev->dev.parent, "rxtx");
>>>>> +
>>> Just discovered that you are using the parent device node.
>>>
>>> How about moving the dma bindings to the nand node instead and using
>>> pdev->dev here?
>> Roger,
>>
>> From what I can tell the interrupt number and the dma channel will always be
>> the same no matter what. Doesn't matter if you have multiple nands or a
>> combination of nands and nors. Since that is the case I think it just makes
>> sense to leave it in the gpmc parent node and define it once.
> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
> or only for NAND?
The dma seems tied to the prefetch. From what I can tell the prefetch is only
used by nand.
>
> Let's also get Tony's inputs on this.
Sure.
>
>>>>>   if (!info->dma) {
>>>>>   dev_err(>dev, "DMA engine request failed\n");
>>>>>   err = -ENXIO;
>>>>>
> --
> 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 v3 20/27] ARM: dts: dra7: Fix NAND device nodes.

2015-10-14 Thread Franklin S Cooper Jr.



On 10/14/2015 09:17 AM, Roger Quadros wrote:
> On 14/10/15 16:34, Franklin S Cooper Jr. wrote:
>>
>> On 09/18/2015 09:53 AM, Roger Quadros wrote:
>>> Add compatible id, GPMC register resource and interrupt
>>> resource to NAND controller nodes.
>>>
>>> The GPMC driver now implements gpiochip and irqchip so
>>> enable gpio-controller and interrupt-controller properties.
>>>
>>> With this the interrupt parent of NAND node changes so fix it
>>> accordingly.
>>>
>>> Signed-off-by: Roger Quadros <rog...@ti.com>
>>> ---
>>>  arch/arm/boot/dts/dra7-evm.dts  | 5 -
>>>  arch/arm/boot/dts/dra7.dtsi | 4 
>>>  arch/arm/boot/dts/dra72-evm.dts | 5 -
>>>  3 files changed, 12 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
>>> index a6c82e5..8a31161 100644
>>> --- a/arch/arm/boot/dts/dra7-evm.dts
>>> +++ b/arch/arm/boot/dts/dra7-evm.dts
>>> @@ -585,9 +585,12 @@
>>> status = "okay";
>>> pinctrl-names = "default";
>>> pinctrl-0 = <_flash_x16>;
>>> -   ranges = <0 0 0 0x0100>;/* minimum GPMC partition = 16MB */
>>> +   ranges = <0 0 0x0800 0x0100>;   /* minimum GPMC partition = 
>>> 16MB */
>>> nand@0,0 {
>>> +   compatible = "ti,omap2-nand";
>>> reg = <0 0 4>;  /* device IO registers */
>>> +   interrupt-parent = <_mpu>;
>>> +   interrupts = ;
>>> ti,nand-ecc-opt = "bch8";
>>> ti,elm-id = <>;
>>> nand-bus-width = <16>;
>>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>>> index 5d65db9..f0a3616 100644
>>> --- a/arch/arm/boot/dts/dra7.dtsi
>>> +++ b/arch/arm/boot/dts/dra7.dtsi
>>> @@ -1389,6 +1389,10 @@
>>> gpmc,num-waitpins = <2>;
>>> #address-cells = <2>;
>>> #size-cells = <1>;
>>> +   gpio-controller;
>>> +   #gpio-cells = <2>;
>>> +   interrupt-controller;
>>> +   #interrupt-cells = <2>;
>>> status = "disabled";
>>> };
>> Based on the discussion on my patchset I noticed that the nand node defines 
>> the
>> interrupt but it is also defined in the parent node. Similar to the dma 
>> channel we
>> should conclude where the best place for it to be defined.  But to me it 
>> seems at
>> least it should only be defined once.
> The interrupt is defined at both places because it is used at both places.
> It is used as a shared interrupt. Wait_pin interrupts are managed by the
> gpmc driver and NAND specific interrupts are managed by the NAND driver.
>
> If GPMC dma channel is going to be used only by the NAND driver then
> we should define the channel in the NAND node.
>
>> This is true for your other patches making similar changes to the dt.
> Yes, GPMC IRQ is defined in both GPMC and NAND nodes.
Ok. I would still think you would just reuse the entry from the
parent since you know it will always be the same. But we can
go with what Tony thinks is best.
>
> --
> 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 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

2015-10-14 Thread Franklin S Cooper Jr.



On 10/14/2015 11:18 AM, Tony Lindgren wrote:
> * Franklin S Cooper Jr. <fcoo...@ti.com> [151014 07:37]:
>>
>> On 10/14/2015 09:11 AM, Roger Quadros wrote:
>>> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>>>> On 10/14/2015 06:52 AM, Roger Quadros wrote:
>>>>> Franklin,
>>>>>
>>>>> On 14/10/15 14:36, Roger Quadros wrote:
>>>>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>>>>>> Switch from dma_request_channel to allow passing dma channel
>>>>>>> information from DT rather than hardcoding a value.
>>>>>>>
>>>>>>> Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
>>>>>> Acked-by: Roger Quadros <rog...@ti.com>
>>>>>>
>>>>>>> ---
>>>>>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>>>> index d0f2620..957c32f 100644
>>>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device 
>>>>>>> *pdev)
>>>>>>> dma_cap_zero(mask);
>>>>>>> dma_cap_set(DMA_SLAVE, mask);
>>>>>>> sig = OMAP24XX_DMA_GPMC;
>>>>>>> -   info->dma = dma_request_channel(mask, 
>>>>>>> omap_dma_filter_fn, );
>>>>>>> +   info->dma = dma_request_slave_channel_compat(mask,
>>>>>>> +   omap_dma_filter_fn, , pdev->dev.parent, 
>>>>>>> "rxtx");
>>>>>>> +
>>>>> Just discovered that you are using the parent device node.
>>>>>
>>>>> How about moving the dma bindings to the nand node instead and using
>>>>> pdev->dev here?
>>>> Roger,
>>>>
>>>> From what I can tell the interrupt number and the dma channel will always 
>>>> be
>>>> the same no matter what. Doesn't matter if you have multiple nands or a
>>>> combination of nands and nors. Since that is the case I think it just makes
>>>> sense to leave it in the gpmc parent node and define it once.
>>> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
>>> or only for NAND?
>> The dma seems tied to the prefetch. From what I can tell the prefetch is only
>> used by nand.
>>> Let's also get Tony's inputs on this.
>> Sure.
> Hmm so what would keep other devices from using the prefetch
Looking at the TRM any references to the prefetch are always with respect to
NAND.

I also see the below mentioned in the TRM.
Pre-fetch and write posting engine associated with system DMA to get full 
performance from NAND
device with minimum impact on NOR/SRAM concurrent access.
>
> 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 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

2015-10-14 Thread Franklin S Cooper Jr.



On 10/14/2015 01:13 PM, Tony Lindgren wrote:
> * Franklin S Cooper Jr. <fcoo...@ti.com> [151014 09:27]:
>>
>> On 10/14/2015 11:18 AM, Tony Lindgren wrote:
>>> * Franklin S Cooper Jr. <fcoo...@ti.com> [151014 07:37]:
>>>> On 10/14/2015 09:11 AM, Roger Quadros wrote:
>>>>> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>>>>>> On 10/14/2015 06:52 AM, Roger Quadros wrote:
>>>>>>> Franklin,
>>>>>>>
>>>>>>> On 14/10/15 14:36, Roger Quadros wrote:
>>>>>>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>>>>>>>> Switch from dma_request_channel to allow passing dma channel
>>>>>>>>> information from DT rather than hardcoding a value.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
>>>>>>>> Acked-by: Roger Quadros <rog...@ti.com>
>>>>>>>>
>>>>>>>>> ---
>>>>>>>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>>>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>>>>>> index d0f2620..957c32f 100644
>>>>>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>>>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct 
>>>>>>>>> platform_device *pdev)
>>>>>>>>>   dma_cap_zero(mask);
>>>>>>>>>   dma_cap_set(DMA_SLAVE, mask);
>>>>>>>>>   sig = OMAP24XX_DMA_GPMC;
>>>>>>>>> - info->dma = dma_request_channel(mask, 
>>>>>>>>> omap_dma_filter_fn, );
>>>>>>>>> + info->dma = dma_request_slave_channel_compat(mask,
>>>>>>>>> + omap_dma_filter_fn, , pdev->dev.parent, 
>>>>>>>>> "rxtx");
>>>>>>>>> +
>>>>>>> Just discovered that you are using the parent device node.
>>>>>>>
>>>>>>> How about moving the dma bindings to the nand node instead and using
>>>>>>> pdev->dev here?
>>>>>> Roger,
>>>>>>
>>>>>> From what I can tell the interrupt number and the dma channel will 
>>>>>> always be
>>>>>> the same no matter what. Doesn't matter if you have multiple nands or a
>>>>>> combination of nands and nors. Since that is the case I think it just 
>>>>>> makes
>>>>>> sense to leave it in the gpmc parent node and define it once.
>>>>> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
>>>>> or only for NAND?
>>>> The dma seems tied to the prefetch. From what I can tell the prefetch is 
>>>> only
>>>> used by nand.
>>>>> Let's also get Tony's inputs on this.
>>>> Sure.
>>> Hmm so what would keep other devices from using the prefetch
>> Looking at the TRM any references to the prefetch are always with respect to
>> NAND.
>>
>> I also see the below mentioned in the TRM.
>> Pre-fetch and write posting engine associated with system DMA to get full 
>> performance from NAND
>> device with minimum impact on NOR/SRAM concurrent access.
> OK up to you guys to figure out if it may be usable in a generic way then :)
Ok I just got clarification from hw folks. DMA for GPMC can be used for any of 
the
various modes. But the prefetch is specific to NAND.
>
> 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 v3 20/27] ARM: dts: dra7: Fix NAND device nodes.

2015-10-14 Thread Franklin S Cooper Jr.



On 09/18/2015 09:53 AM, Roger Quadros wrote:
> Add compatible id, GPMC register resource and interrupt
> resource to NAND controller nodes.
>
> The GPMC driver now implements gpiochip and irqchip so
> enable gpio-controller and interrupt-controller properties.
>
> With this the interrupt parent of NAND node changes so fix it
> accordingly.
>
> Signed-off-by: Roger Quadros 
> ---
>  arch/arm/boot/dts/dra7-evm.dts  | 5 -
>  arch/arm/boot/dts/dra7.dtsi | 4 
>  arch/arm/boot/dts/dra72-evm.dts | 5 -
>  3 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
> index a6c82e5..8a31161 100644
> --- a/arch/arm/boot/dts/dra7-evm.dts
> +++ b/arch/arm/boot/dts/dra7-evm.dts
> @@ -585,9 +585,12 @@
>   status = "okay";
>   pinctrl-names = "default";
>   pinctrl-0 = <_flash_x16>;
> - ranges = <0 0 0 0x0100>;/* minimum GPMC partition = 16MB */
> + ranges = <0 0 0x0800 0x0100>;   /* minimum GPMC partition = 
> 16MB */
>   nand@0,0 {
> + compatible = "ti,omap2-nand";
>   reg = <0 0 4>;  /* device IO registers */
> + interrupt-parent = <_mpu>;
> + interrupts = ;
>   ti,nand-ecc-opt = "bch8";
>   ti,elm-id = <>;
>   nand-bus-width = <16>;
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index 5d65db9..f0a3616 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -1389,6 +1389,10 @@
>   gpmc,num-waitpins = <2>;
>   #address-cells = <2>;
>   #size-cells = <1>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
>   status = "disabled";
>   };
Based on the discussion on my patchset I noticed that the nand node defines the
interrupt but it is also defined in the parent node. Similar to the dma channel 
we
should conclude where the best place for it to be defined.  But to me it seems 
at
least it should only be defined once.

This is true for your other patches making similar changes to the dt.
>  
> diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
> index 6f6bd98..245f5f9 100644
> --- a/arch/arm/boot/dts/dra72-evm.dts
> +++ b/arch/arm/boot/dts/dra72-evm.dts
> @@ -395,13 +395,16 @@
>   status = "okay";
>   pinctrl-names = "default";
>   pinctrl-0 = <_default>;
> - ranges = <0 0 0 0x0100>;/* minimum GPMC partition = 16MB */
> + ranges = <0 0 0x0800 0x0100>;   /* minimum GPMC partition = 
> 16MB */
>   nand@0,0 {
>   /* To use NAND, DIP switch SW5 must be set like so:
>* SW5.1 (NAND_SELn) = ON (LOW)
>* SW5.9 (GPMC_WPN) = OFF (HIGH)
>*/
> + compatible = "ti,omap2-nand";
>   reg = <0 0 4>;  /* device IO registers */
> + interrupt-parent = <_mpu>;
> + interrupts = ;
>   ti,nand-ecc-opt = "bch8";
>   ti,elm-id = <>;
>   nand-bus-width = <16>;

--
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/5] mtd: nand: omap2: Start dma request before enabling prefetch

2015-10-14 Thread Franklin S Cooper Jr.



On 10/14/2015 06:41 AM, Roger Quadros wrote:
> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>> The prefetch engine sends a dma request once a FIFO threshold has
>> been met. No other requests are received until the previous request
>> is handled.
>>
>> Starting an edma transfer (dma_async_issue_pending) results in any
>> previous event for the dma channel to be cleared. Therefore, starting
>> the prefetch engine before initiating the dma transfer may result in
>> the prefetch triggering a dma request but instead of it being handled
>> it can end up being cleared. This will result in a hang since the code
>> will continue to wait for the dma request to complete.
>>
>> By initiating the dma request before enabling the prefetch engine this
>> race condition is avoided and no dma request are missed/cleared.
>>
>> Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
>> ---
>>  drivers/mtd/nand/omap2.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>> index 957c32f..94d11de 100644
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -509,6 +509,9 @@ static inline int omap_nand_dma_transfer(struct mtd_info 
>> *mtd, void *addr,
>>  tx->callback_param = >comp;
>>  dmaengine_submit(tx);
>>  
>> +init_completion(>comp);
>> +dma_async_issue_pending(info->dma);
>> +
>>  /*  configure and start prefetch transfer */
>>  ret = omap_prefetch_enable(info->gpmc_cs,
>>  PREFETCH_FIFOTHRESHOLD_MAX, 0x1, len, is_write, info);
>> @@ -516,9 +519,6 @@ static inline int omap_nand_dma_transfer(struct mtd_info 
>> *mtd, void *addr,
>>  /* PFPW engine is busy, use cpu copy method */
>>  goto out_copy_unmap;
>>  
>> -init_completion(>comp);
>> -dma_async_issue_pending(info->dma);
>> -
>>  /* setup and start DMA using dma_addr */
> Is the above comment misplaced after this change?
Yup you right.
>
>>  wait_for_completion(>comp);
>>  tim = 0;
>>
> 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] ARM: DRA7: hwmod: Remove elm address space from hwmod data

2015-10-14 Thread Franklin S Cooper Jr.



On 10/14/2015 01:58 AM, Roger Quadros wrote:
> On 13/10/15 16:44, Franklin S Cooper Jr wrote:
>> ELM address information is provided by device tree. No longer need
>> to include this information within hwmod.
>>
>> Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
> Acked-by: Roger Quadros <rog...@ti.com>
>
> Franklin,
>
> Can you please do the same for gpmc_addr as well?
>
> And looks like elm_addr needs to be removed from
> omap_hwmod_33xx_43xx_interconnect_data.c and omap_hwmod_44xx_data.c as well, 
> no?
Sure I'll combine the 335x and 44x elm removal with this patch and then create 
a separate patch for the gpmc version.
>
> cheers,
> -roger
>
>> ---
>>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 10 --
>>  1 file changed, 10 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
>> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> index 562247b..ad2cc7a 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> @@ -2566,21 +2566,11 @@ static struct omap_hwmod_ocp_if 
>> dra7xx_l3_main_1__hdmi = {
>>  .user   = OCP_USER_MPU | OCP_USER_SDMA,
>>  };
>>  
>> -static struct omap_hwmod_addr_space dra7xx_elm_addrs[] = {
>> -{
>> -.pa_start   = 0x48078000,
>> -.pa_end = 0x48078fff,
>> -.flags  = ADDR_TYPE_RT
>> -},
>> -{ }
>> -};
>> -
>>  /* l4_per1 -> elm */
>>  static struct omap_hwmod_ocp_if dra7xx_l4_per1__elm = {
>>  .master = _l4_per1_hwmod,
>>  .slave  = _elm_hwmod,
>>  .clk= "l3_iclk_div",
>> -.addr   = dra7xx_elm_addrs,
>>  .user   = OCP_USER_MPU | OCP_USER_SDMA,
>>  };
>>  
>>

--
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/5] mtd: nand: omap2: Support parsing dma channel information from DT

2015-10-14 Thread Franklin S Cooper Jr.



On 10/14/2015 06:52 AM, Roger Quadros wrote:
> Franklin,
>
> On 14/10/15 14:36, Roger Quadros wrote:
>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>> Switch from dma_request_channel to allow passing dma channel
>>> information from DT rather than hardcoding a value.
>>>
>>> Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
>> Acked-by: Roger Quadros <rog...@ti.com>
>>
>>> ---
>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>> index d0f2620..957c32f 100644
>>> --- a/drivers/mtd/nand/omap2.c
>>> +++ b/drivers/mtd/nand/omap2.c
>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device 
>>> *pdev)
>>> dma_cap_zero(mask);
>>> dma_cap_set(DMA_SLAVE, mask);
>>> sig = OMAP24XX_DMA_GPMC;
>>> -   info->dma = dma_request_channel(mask, omap_dma_filter_fn, );
>>> +   info->dma = dma_request_slave_channel_compat(mask,
>>> +   omap_dma_filter_fn, , pdev->dev.parent, "rxtx");
>>> +
> Just discovered that you are using the parent device node.
>
> How about moving the dma bindings to the nand node instead and using
> pdev->dev here?
Roger,

>From what I can tell the interrupt number and the dma channel will always be
the same no matter what. Doesn't matter if you have multiple nands or a
combination of nands and nors. Since that is the case I think it just makes
sense to leave it in the gpmc parent node and define it once.
>>> if (!info->dma) {
>>> dev_err(>dev, "DMA engine request failed\n");
>>> err = -ENXIO;
>>>
> 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 4/5] ARM: dts: am437x/am33xx/omap3/dm816x: Add gpmc dma channel

2015-10-14 Thread Franklin S Cooper Jr.



On 10/14/2015 06:44 AM, Roger Quadros wrote:
> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>> Add dma channel information to the gpmc. Although not enabled by
>> default this will allow prefetch-dma to be used.
>>
>> Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
>> ---
>>  arch/arm/boot/dts/am33xx.dtsi | 2 ++
>>  arch/arm/boot/dts/am4372.dtsi | 2 ++
>>  arch/arm/boot/dts/dm816x.dtsi | 2 ++
>>  arch/arm/boot/dts/omap3.dtsi  | 2 ++
> How about fixing up omap4/5 and dra7 as well?

Shouldn't be a problem for omap4 and omap5.

Dra7 with sdma can't support this feature. With edma it works fine. So I'll
wait until edma support for dra7 makes it into mainline and then I can send
a new patch adding support.
>
> cheers,
> -roger
>
>>  4 files changed, 8 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>> index e065f21..f2d8eed 100644
>> --- a/arch/arm/boot/dts/am33xx.dtsi
>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>> @@ -819,6 +819,8 @@
>>  ti,no-idle-on-init;
>>  reg = <0x5000 0x2000>;
>>  interrupts = <100>;
>> +dmas = < 52>;
>> +dma-names = "rxtx";
>>  gpmc,num-cs = <7>;
>>  gpmc,num-waitpins = <2>;
>>  #address-cells = <2>;
>> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
>> index ec8b7a3..c02061b 100644
>> --- a/arch/arm/boot/dts/am4372.dtsi
>> +++ b/arch/arm/boot/dts/am4372.dtsi
>> @@ -841,6 +841,8 @@
>>  gpmc: gpmc@5000 {
>>  compatible = "ti,am3352-gpmc";
>>  ti,hwmods = "gpmc";
>> +dmas = < 52>;
>> +dma-names = "rxtx";
>>  clocks = <_gclk>;
>>  clock-names = "fck";
>>  reg = <0x5000 0x2000>;
>> diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
>> index 68fb444..d2e5d31 100644
>> --- a/arch/arm/boot/dts/dm816x.dtsi
>> +++ b/arch/arm/boot/dts/dm816x.dtsi
>> @@ -180,6 +180,8 @@
>>  #address-cells = <2>;
>>  #size-cells = <1>;
>>  interrupts = <100>;
>> +dmas = < 52>;
>> +dma-names = "rxtx";
>>  gpmc,num-cs = <6>;
>>  gpmc,num-waitpins = <2>;
>>  gpio-controller;
>> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
>> index 7f212b6..9dbbcf6 100644
>> --- a/arch/arm/boot/dts/omap3.dtsi
>> +++ b/arch/arm/boot/dts/omap3.dtsi
>> @@ -717,6 +717,8 @@
>>  ti,hwmods = "gpmc";
>>  reg = <0x6e00 0x02d0>;
>>  interrupts = <20>;
>> +dmas = < 4>;
>> +dma-names = "rxtx";
>>  gpmc,num-cs = <8>;
>>  gpmc,num-waitpins = <4>;
>>  #address-cells = <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] ARM: DRA7: hwmod: Remove elm address space from hwmod data

2015-10-13 Thread Franklin S Cooper Jr

ELM address information is provided by device tree. No longer need
to include this information within hwmod.

Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 562247b..ad2cc7a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -2566,21 +2566,11 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__hdmi 
= {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-static struct omap_hwmod_addr_space dra7xx_elm_addrs[] = {
-   {
-   .pa_start   = 0x48078000,
-   .pa_end = 0x48078fff,
-   .flags  = ADDR_TYPE_RT
-   },
-   { }
-};
-
 /* l4_per1 -> elm */
 static struct omap_hwmod_ocp_if dra7xx_l4_per1__elm = {
.master = _l4_per1_hwmod,
.slave  = _elm_hwmod,
.clk= "l3_iclk_div",
-   .addr   = dra7xx_elm_addrs,
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-- 
2.6.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 4/5] ARM: dts: am437x/am33xx/omap3/dm816x: Add gpmc dma channel

2015-10-12 Thread Franklin S Cooper Jr

Add dma channel information to the gpmc. Although not enabled by
default this will allow prefetch-dma to be used.

Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
 arch/arm/boot/dts/am33xx.dtsi | 2 ++
 arch/arm/boot/dts/am4372.dtsi | 2 ++
 arch/arm/boot/dts/dm816x.dtsi | 2 ++
 arch/arm/boot/dts/omap3.dtsi  | 2 ++
 4 files changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index e065f21..f2d8eed 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -819,6 +819,8 @@
ti,no-idle-on-init;
reg = <0x5000 0x2000>;
interrupts = <100>;
+   dmas = < 52>;
+   dma-names = "rxtx";
gpmc,num-cs = <7>;
gpmc,num-waitpins = <2>;
#address-cells = <2>;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ec8b7a3..c02061b 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -841,6 +841,8 @@
gpmc: gpmc@5000 {
compatible = "ti,am3352-gpmc";
ti,hwmods = "gpmc";
+   dmas = < 52>;
+   dma-names = "rxtx";
clocks = <_gclk>;
clock-names = "fck";
reg = <0x5000 0x2000>;
diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index 68fb444..d2e5d31 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -180,6 +180,8 @@
#address-cells = <2>;
#size-cells = <1>;
interrupts = <100>;
+   dmas = < 52>;
+   dma-names = "rxtx";
gpmc,num-cs = <6>;
gpmc,num-waitpins = <2>;
gpio-controller;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 7f212b6..9dbbcf6 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -717,6 +717,8 @@
ti,hwmods = "gpmc";
reg = <0x6e00 0x02d0>;
interrupts = <20>;
+   dmas = < 4>;
+   dma-names = "rxtx";
gpmc,num-cs = <8>;
gpmc,num-waitpins = <4>;
#address-cells = <2>;
-- 
2.6.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 5/5] ARM: OMAP2+: Update gpmc and nand DT binding documentation

2015-10-12 Thread Franklin S Cooper Jr

Add additional details to the gpmc and nand documentation to clarify
what is needed to enable nand dma prefetch.

Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
 Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt | 7 ++-
 Documentation/devicetree/bindings/mtd/gpmc-nand.txt| 2 ++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt 
b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
index 704be93..b1e2802 100644
--- a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
@@ -33,6 +33,10 @@ Required properties:
As this will change in the future, filling correct
values here is a requirement.
 
+GPMC DMA information. Required only when GPMC nand prefetch is enabled.
+ - dmasGPMC nand prefetch dma channel
+ - dma-names   DMA channel name use as a reference within the Nand 
driver
+
 Timing properties for child nodes. All are optional and default to 0.
 
  - gpmc,sync-clk-ps:   Minimum clock period for synchronous mode, in 
picoseconds
@@ -119,7 +123,8 @@ Example for an AM33xx board:
ti,hwmods = "gpmc";
reg = <0x5000 0x2000>;
interrupts = <100>;
-
+   dmas = < 52>;
+   dma-names = "rxtx";
gpmc,num-cs = <8>;
gpmc,num-waitpins = <2>;
#address-cells = <2>;
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt 
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index 253e6de..4b0c240 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -61,6 +61,8 @@ Example for an AM33xx board:
ti,hwmods = "gpmc";
reg = <0x5000 0x36c>;
interrupts = <100>;
+   dmas = < 52>;
+   dma-names = "rxtx";
gpmc,num-cs = <8>;
gpmc,num-waitpins = <2>;
#address-cells = <2>;
-- 
2.6.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 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

2015-10-12 Thread Franklin S Cooper Jr

Switch from dma_request_channel to allow passing dma channel
information from DT rather than hardcoding a value.

Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
 drivers/mtd/nand/omap2.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index d0f2620..957c32f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
sig = OMAP24XX_DMA_GPMC;
-   info->dma = dma_request_channel(mask, omap_dma_filter_fn, );
+   info->dma = dma_request_slave_channel_compat(mask,
+   omap_dma_filter_fn, , pdev->dev.parent, "rxtx");
+
if (!info->dma) {
dev_err(>dev, "DMA engine request failed\n");
err = -ENXIO;
-- 
2.6.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 2/5] mtd: nand: omap2: Start dma request before enabling prefetch

2015-10-12 Thread Franklin S Cooper Jr

The prefetch engine sends a dma request once a FIFO threshold has
been met. No other requests are received until the previous request
is handled.

Starting an edma transfer (dma_async_issue_pending) results in any
previous event for the dma channel to be cleared. Therefore, starting
the prefetch engine before initiating the dma transfer may result in
the prefetch triggering a dma request but instead of it being handled
it can end up being cleared. This will result in a hang since the code
will continue to wait for the dma request to complete.

By initiating the dma request before enabling the prefetch engine this
race condition is avoided and no dma request are missed/cleared.

Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
 drivers/mtd/nand/omap2.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 957c32f..94d11de 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -509,6 +509,9 @@ static inline int omap_nand_dma_transfer(struct mtd_info 
*mtd, void *addr,
tx->callback_param = >comp;
dmaengine_submit(tx);
 
+   init_completion(>comp);
+   dma_async_issue_pending(info->dma);
+
/*  configure and start prefetch transfer */
ret = omap_prefetch_enable(info->gpmc_cs,
PREFETCH_FIFOTHRESHOLD_MAX, 0x1, len, is_write, info);
@@ -516,9 +519,6 @@ static inline int omap_nand_dma_transfer(struct mtd_info 
*mtd, void *addr,
/* PFPW engine is busy, use cpu copy method */
goto out_copy_unmap;
 
-   init_completion(>comp);
-   dma_async_issue_pending(info->dma);
-
/* setup and start DMA using dma_addr */
wait_for_completion(>comp);
tim = 0;
-- 
2.6.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 3/5] mtd: nand: omap2: Fix high memory dma prefetch transfer

2015-10-12 Thread Franklin S Cooper Jr

Based on DMA documentation and testing using high memory buffer when
doing dma transfers can lead to various issues including kernel
panics.

To workaround this simply use cpu copy. The amount of high memory
buffers used are very uncommon so no noticeable performance hit should
be seen.

Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
---
 drivers/mtd/nand/omap2.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 94d11de..537be2f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -479,17 +479,8 @@ static inline int omap_nand_dma_transfer(struct mtd_info 
*mtd, void *addr,
int ret;
u32 val;
 
-   if (addr >= high_memory) {
-   struct page *p1;
-
-   if (((size_t)addr & PAGE_MASK) !=
-   ((size_t)(addr + len - 1) & PAGE_MASK))
-   goto out_copy;
-   p1 = vmalloc_to_page(addr);
-   if (!p1)
-   goto out_copy;
-   addr = page_address(p1) + ((size_t)addr & ~PAGE_MASK);
-   }
+   if (addr >= high_memory)
+   goto out_copy;
 
sg_init_one(, addr, len);
n = dma_map_sg(info->dma->device->dev, , 1, dir);
@@ -545,6 +536,7 @@ out_copy:
else
is_write == 0 ? omap_read_buf8(mtd, (u_char *) addr, len)
: omap_write_buf8(mtd, (u_char *) addr, len);
+
return 0;
 }
 
-- 
2.6.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 0/5] mtd: nand: Fix support for NAND DMA Prefetch

2015-10-12 Thread Franklin S Cooper Jr

NAND dma prefetch has been broken for awhile and seems to have only
worked for sdma based devices.

This patchset fixes DMA prefetch to work on both edma and sdma devices

Tested on:
am335x general purpose evm
am437x general purpose evm
am37x general purpose evm

This patchset depends on Roger Quadros recent v4 GPMC/NAND patchset

https://github.com/rogerq/linux.git
branch: for-v4.4/gpmc-v4

Franklin S Cooper Jr (5):
  mtd: nand: omap2: Support parsing dma channel information from DT
  mtd: nand: omap2: Start dma request before enabling prefetch
  mtd: nand: omap2: Fix high memory dma prefetch transfer
  ARM: dts: am437x/am33xx/omap3/dm816x: Add gpmc dma channel
  ARM: OMAP2+: Update gpmc and nand DT binding documentation

 .../bindings/memory-controllers/omap-gpmc.txt  |  7 ++-
 .../devicetree/bindings/mtd/gpmc-nand.txt  |  2 ++
 arch/arm/boot/dts/am33xx.dtsi  |  2 ++
 arch/arm/boot/dts/am4372.dtsi  |  2 ++
 arch/arm/boot/dts/dm816x.dtsi  |  2 ++
 arch/arm/boot/dts/omap3.dtsi   |  2 ++
 drivers/mtd/nand/omap2.c   | 24 --
 7 files changed, 25 insertions(+), 16 deletions(-)

-- 
2.6.1

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

Re: [PATCH] mmc: omap_hsmmc: Update driver to support without regulators

2015-07-22 Thread Franklin S Cooper Jr.



On 07/21/2015 02:39 PM, Franklin S Cooper Jr. wrote:

 On 07/21/2015 06:40 AM, Ulf Hansson wrote:
 On 14 July 2015 at 21:29, Franklin S Cooper Jr fcoo...@ti.com wrote:
 From: Roger Quadros rog...@ti.com

 Update driver to support without regulators.

 Without this patch boards that do not enable regulator config options will
 fail to boot with a kernel panic.
 I guess that's because the rootfs is mounted on the card that doesn't
 get detected, right?
 No at ramfs was used to validate this and was loaded via ethernet in U-boot.
 Signed-off-by: Roger Quadros rog...@ti.com
 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
 Signed-off-by: Murali Karicheri m-kariche...@ti.com
 Signed-off-by: Franklin S Cooper Jr fcoo...@ti.com
 ---
  Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt |  2 ++
  drivers/mmc/host/omap_hsmmc.c   | 14 ++
  2 files changed, 12 insertions(+), 4 deletions(-)

 diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
 b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 index 76bf087..2408e87 100644
 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 @@ -22,6 +22,8 @@ ti,dual-volt: boolean, supports dual voltage cards
  ti,non-removable: non-removable slot (like eMMC)
  ti,needs-special-reset: Requires a special softreset sequence
  ti,needs-special-hs-handling: HSMMC IP needs special setting for handling 
 High Speed
 +voltage-ranges: Specify the voltage range supported if regulator framework
 +isn't enabled.
  dmas: List of DMA specifiers with the controller specific format
  as described in the generic DMA client binding. A tx and rx
  specifier is required.
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index b2b411d..16c870f 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -1551,10 +1551,13 @@ static void omap_hsmmc_set_ios(struct mmc_host 
 *mmc, struct mmc_ios *ios)
 if (ios-power_mode != host-power_mode) {
 switch (ios-power_mode) {
 case MMC_POWER_OFF:
 -   mmc_pdata(host)-set_power(host-dev, 0, 0);
 +   if (host-use_reg)
 +   mmc_pdata(host)-set_power(host-dev, 0, 0);
 break;
 case MMC_POWER_UP:
 -   mmc_pdata(host)-set_power(host-dev, 1, ios-vdd);
 +   if (host-use_reg)
 +   mmc_pdata(host)-set_power(host-dev, 1,
 +  ios-vdd);
 break;
 case MMC_POWER_ON:
 do_send_init_stream = 1;
 @@ -2082,10 +2085,13 @@ static int omap_hsmmc_probe(struct platform_device 
 *pdev)
 if (ret)
 goto err_irq;
 host-use_reg = 1;
 +   mmc-ocr_avail = mmc_pdata(host)-ocr_mask;
 +   } else {
 +   ret = mmc_of_parse_voltage(pdev-dev.of_node, 
 mmc-ocr_avail);
 +   if (ret)
 +   goto err_irq;
 }

 -   mmc-ocr_avail = mmc_pdata(host)-ocr_mask;
 -
 omap_hsmmc_disable_irq(host);

 /*
 --
 1.9.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-mmc in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 No, I don't like this patch. If your board have regulators which can
 be used to find out the voltage levels, we shall use them. We shall
 not use DT to workaround this.

 So, perhaps the Kconfig section for omap_hsmmc should select
 CONFIG_REGULATOR (and friends)?
 Looking at the code the ifdefCONFIG_REGULATOR and the usage of use_reg
 (use regulator) shows that this driver is suppose to support boards that
 don't have the regulator framework enabled.

 This patches insures that this driver can work without the regulator framework
 which is currently broken.
Hi Ulf,

Just to clarify do you have an issue with this patch or in general
you rather nothave !CONFIG_REGULATOR supported? If its the latter
then wouldit be better to remove the !CONFIG_REGULATOR portion from
this driver all together.
 Kind regards
 Uffe
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Re: [PATCH] mmc: omap_hsmmc: Update driver to support without regulators

2015-07-21 Thread Franklin S Cooper Jr.



On 07/21/2015 06:40 AM, Ulf Hansson wrote:
 On 14 July 2015 at 21:29, Franklin S Cooper Jr fcoo...@ti.com wrote:
 From: Roger Quadros rog...@ti.com

 Update driver to support without regulators.

 Without this patch boards that do not enable regulator config options will
 fail to boot with a kernel panic.
 I guess that's because the rootfs is mounted on the card that doesn't
 get detected, right?
No at ramfs was used to validate this and was loaded via ethernet in U-boot.

 Signed-off-by: Roger Quadros rog...@ti.com
 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
 Signed-off-by: Murali Karicheri m-kariche...@ti.com
 Signed-off-by: Franklin S Cooper Jr fcoo...@ti.com
 ---
  Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt |  2 ++
  drivers/mmc/host/omap_hsmmc.c   | 14 ++
  2 files changed, 12 insertions(+), 4 deletions(-)

 diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
 b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 index 76bf087..2408e87 100644
 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 @@ -22,6 +22,8 @@ ti,dual-volt: boolean, supports dual voltage cards
  ti,non-removable: non-removable slot (like eMMC)
  ti,needs-special-reset: Requires a special softreset sequence
  ti,needs-special-hs-handling: HSMMC IP needs special setting for handling 
 High Speed
 +voltage-ranges: Specify the voltage range supported if regulator framework
 +isn't enabled.
  dmas: List of DMA specifiers with the controller specific format
  as described in the generic DMA client binding. A tx and rx
  specifier is required.
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index b2b411d..16c870f 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -1551,10 +1551,13 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc, 
 struct mmc_ios *ios)
 if (ios-power_mode != host-power_mode) {
 switch (ios-power_mode) {
 case MMC_POWER_OFF:
 -   mmc_pdata(host)-set_power(host-dev, 0, 0);
 +   if (host-use_reg)
 +   mmc_pdata(host)-set_power(host-dev, 0, 0);
 break;
 case MMC_POWER_UP:
 -   mmc_pdata(host)-set_power(host-dev, 1, ios-vdd);
 +   if (host-use_reg)
 +   mmc_pdata(host)-set_power(host-dev, 1,
 +  ios-vdd);
 break;
 case MMC_POWER_ON:
 do_send_init_stream = 1;
 @@ -2082,10 +2085,13 @@ static int omap_hsmmc_probe(struct platform_device 
 *pdev)
 if (ret)
 goto err_irq;
 host-use_reg = 1;
 +   mmc-ocr_avail = mmc_pdata(host)-ocr_mask;
 +   } else {
 +   ret = mmc_of_parse_voltage(pdev-dev.of_node, 
 mmc-ocr_avail);
 +   if (ret)
 +   goto err_irq;
 }

 -   mmc-ocr_avail = mmc_pdata(host)-ocr_mask;
 -
 omap_hsmmc_disable_irq(host);

 /*
 --
 1.9.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-mmc in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 No, I don't like this patch. If your board have regulators which can
 be used to find out the voltage levels, we shall use them. We shall
 not use DT to workaround this.

 So, perhaps the Kconfig section for omap_hsmmc should select
 CONFIG_REGULATOR (and friends)?
Looking at the code the ifdefCONFIG_REGULATOR and the usage of use_reg
(use regulator) shows that this driver is suppose to support boards that
don't have the regulator framework enabled.

This patches insures that this driver can work without the regulator framework
which is currently broken.


 Kind regards
 Uffe

--
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] mmc: omap_hsmmc: Update driver to support without regulators

2015-07-21 Thread Franklin S Cooper Jr.



On 07/21/2015 02:57 PM, Felipe Balbi wrote:
 On Tue, Jul 14, 2015 at 02:29:46PM -0500, Franklin S Cooper Jr wrote:
 From: Roger Quadros rog...@ti.com

 Update driver to support without regulators.

 Without this patch boards that do not enable regulator config options will
 fail to boot with a kernel panic.

 Signed-off-by: Roger Quadros rog...@ti.com
 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
 Signed-off-by: Murali Karicheri m-kariche...@ti.com
 Signed-off-by: Franklin S Cooper Jr fcoo...@ti.com
 ---
  Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt |  2 ++
  drivers/mmc/host/omap_hsmmc.c   | 14 ++
  2 files changed, 12 insertions(+), 4 deletions(-)

 diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
 b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 index 76bf087..2408e87 100644
 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
 @@ -22,6 +22,8 @@ ti,dual-volt: boolean, supports dual voltage cards
  ti,non-removable: non-removable slot (like eMMC)
  ti,needs-special-reset: Requires a special softreset sequence
  ti,needs-special-hs-handling: HSMMC IP needs special setting for handling 
 High Speed
 +voltage-ranges: Specify the voltage range supported if regulator framework
 +isn't enabled.
  dmas: List of DMA specifiers with the controller specific format
  as described in the generic DMA client binding. A tx and rx
  specifier is required.
 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index b2b411d..16c870f 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -1551,10 +1551,13 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc, 
 struct mmc_ios *ios)
  if (ios-power_mode != host-power_mode) {
  switch (ios-power_mode) {
  case MMC_POWER_OFF:
 -mmc_pdata(host)-set_power(host-dev, 0, 0);
 +if (host-use_reg)
 +mmc_pdata(host)-set_power(host-dev, 0, 0);
 looks like this driver should just be use regulator_get_optional(), then
 -set_power() would still work, no ?
Wouldn't there still be a dependency on the regulator framework to get that to 
work?

I guess my intention was to fix not having the regulator framework. But I'm 
sure there are
other ways to support not having a regulator defined as long as 
CONFIG_REGULATOR is enabled.
For example dummy regulator worked fine when I tried it.


--
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] mmc: omap_hsmmc: Update driver to support without regulators

2015-07-14 Thread Franklin S Cooper Jr

From: Roger Quadros rog...@ti.com

Update driver to support without regulators.

Without this patch boards that do not enable regulator config options will
fail to boot with a kernel panic.

Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Murali Karicheri m-kariche...@ti.com
Signed-off-by: Franklin S Cooper Jr fcoo...@ti.com
---
 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt |  2 ++
 drivers/mmc/host/omap_hsmmc.c   | 14 ++
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 76bf087..2408e87 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -22,6 +22,8 @@ ti,dual-volt: boolean, supports dual voltage cards
 ti,non-removable: non-removable slot (like eMMC)
 ti,needs-special-reset: Requires a special softreset sequence
 ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High 
Speed
+voltage-ranges: Specify the voltage range supported if regulator framework
+isn't enabled.
 dmas: List of DMA specifiers with the controller specific format
 as described in the generic DMA client binding. A tx and rx
 specifier is required.
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b2b411d..16c870f 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1551,10 +1551,13 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc, 
struct mmc_ios *ios)
if (ios-power_mode != host-power_mode) {
switch (ios-power_mode) {
case MMC_POWER_OFF:
-   mmc_pdata(host)-set_power(host-dev, 0, 0);
+   if (host-use_reg)
+   mmc_pdata(host)-set_power(host-dev, 0, 0);
break;
case MMC_POWER_UP:
-   mmc_pdata(host)-set_power(host-dev, 1, ios-vdd);
+   if (host-use_reg)
+   mmc_pdata(host)-set_power(host-dev, 1,
+  ios-vdd);
break;
case MMC_POWER_ON:
do_send_init_stream = 1;
@@ -2082,10 +2085,13 @@ static int omap_hsmmc_probe(struct platform_device 
*pdev)
if (ret)
goto err_irq;
host-use_reg = 1;
+   mmc-ocr_avail = mmc_pdata(host)-ocr_mask;
+   } else {
+   ret = mmc_of_parse_voltage(pdev-dev.of_node, mmc-ocr_avail);
+   if (ret)
+   goto err_irq;
}
 
-   mmc-ocr_avail = mmc_pdata(host)-ocr_mask;
-
omap_hsmmc_disable_irq(host);
 
/*
-- 
1.9.1

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

Re: [PATCH v2 0/5] mtd: nand: Fix support for NAND DMA prefetch

[PATCH 0/2] Remove elm address space from omap4 hwmod

[PATCH 1/2] ARM: dts: omap4: Add elm node

[PATCH 2/2] ARM: omap4: hwmod: Remove elm address space from hwmod data

Re: [PATCH 1/2 v2] ARM: DRA7/335x/437x/OMAP4: hwmod: Remove elm address space from hwmod data

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[PATCH 2/2 v2] ARM: DRA7/335x/437x: hwmod: Remove gpmc address space from hwmod data

[PATCH v2 0/5] mtd: nand: Fix support for NAND DMA prefetch

[PATCH v2 3/5] mtd: nand: omap2: Fix high memory dma prefetch transfer

[PATCH v2 2/5] mtd: nand: omap2: Start dma request before enabling prefetch

[PATCH v2 4/5] ARM: dts: am437x/am33xx/omap/dm816x: Add gpmc dma channel

[PATCH 1/2 v2] ARM: DRA7/335x/437x/OMAP4: hwmod: Remove elm address space from hwmod data

[PATCH v2 5/5] ARM: OMAP2+: Update GPMC and NAND DT binding documentation

Re: [PATCH 5/5] ARM: OMAP2+: Update gpmc and nand DT binding documentation

[PATCH v2 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

Re: [PATCH v3 20/27] ARM: dts: dra7: Fix NAND device nodes.

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

Re: [PATCH v3 20/27] ARM: dts: dra7: Fix NAND device nodes.

Re: [PATCH 2/5] mtd: nand: omap2: Start dma request before enabling prefetch

Re: [PATCH] ARM: DRA7: hwmod: Remove elm address space from hwmod data

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

Re: [PATCH 4/5] ARM: dts: am437x/am33xx/omap3/dm816x: Add gpmc dma channel

[PATCH] ARM: DRA7: hwmod: Remove elm address space from hwmod data

[PATCH 4/5] ARM: dts: am437x/am33xx/omap3/dm816x: Add gpmc dma channel

[PATCH 5/5] ARM: OMAP2+: Update gpmc and nand DT binding documentation

[PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[PATCH 2/5] mtd: nand: omap2: Start dma request before enabling prefetch

[PATCH 3/5] mtd: nand: omap2: Fix high memory dma prefetch transfer

[PATCH 0/5] mtd: nand: Fix support for NAND DMA Prefetch

Re: [PATCH] mmc: omap_hsmmc: Update driver to support without regulators

Re: [PATCH] mmc: omap_hsmmc: Update driver to support without regulators

Re: [PATCH] mmc: omap_hsmmc: Update driver to support without regulators

[PATCH] mmc: omap_hsmmc: Update driver to support without regulators

35 matches

Site Navigation

Mail list logo

Footer information