Re: [PATCH] ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory

[Tony Lindgren]

* Lokesh Vutla  [151013 20:53]:
> Hi Tony,
> 
> On Wednesday 14 October 2015 04:43 AM, Tony Lindgren wrote:
> > On boards with more than 2GB of RAM booting goes wrong with things not 
> > working
> > and we're getting lots of l3 warnings:
> > 
> > WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 
> > l3_interrupt_handler+0x260/0x384()
> > 4400.ocp:L3 Custom Error: MASTER MMC6 TARGET DMM1 (Idle): Data Access 
> > in User mode during Functional access
> > ...
> > [] (scsi_add_host_with_dma) from [] 
> > (ata_scsi_add_hosts+0x5c/0x18c)
> > [] (ata_scsi_add_hosts) from [] 
> > (ata_host_register+0x150/0x2cc)
> > [] (ata_host_register) from [] 
> > (ata_host_activate+0xd4/0x124)
> > [] (ata_host_activate) from [] 
> > (ahci_host_activate+0x5c/0x194)
> > [] (ahci_host_activate) from [] 
> > (ahci_platform_init_host+0x1f0/0x3f0)
> > [] (ahci_platform_init_host) from [] 
> > (ahci_probe+0x70/0x98)
> > [] (ahci_probe) from [] (platform_drv_probe+0x54/0xb4)
> > 
> > Let's fix the issue by enabling ZONE_DMA for LPAE.
> 
> May I know on which platform you have reproduced this?

This is on the 4GB version of isee igepv5 GEP0050-RB10

https://isee.biz/products/igep-processor-boards/igepv5-omap5432

> Just wondering what other changes you made for booting a OMAP5+ based
> board with more than 2GB.

Just the minimal dts changes I posted yesterday to use shared dtsi file
for omap5-uevm variants. Then boot with something like this in the kernel
cmdline:

mem=2032M@0x8000 mem=2048M@0x3

Regards,

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

Re: [PATCH 10/13] dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx

[Vinod Koul]

On Wed, Oct 14, 2015 at 04:12:21PM +0300, Peter Ujfalusi wrote:
> The DMA event crossbar on AM33xx/AM43xx is different from the one found in
> DRA7x family.
> Instead of a single event crossbar it has 64 identical mux attached to each
> eDMA event line. When the 0 event mux is selected, the default mapped event
> is going to be routed to the corresponding eDMA event line. If different
> mux is selected, then the selected event is going to be routed to the given
> eDMA event.

Why is crossbar patch in edma series?

> +static void ti_am335x_xbar_free(struct device *dev, void *route_data)
> +{
> + struct ti_am335x_xbar_data *xbar = dev_get_drvdata(dev);
> + struct ti_am335x_xbar_map *map = route_data;
> +
> + dev_err(dev, "Unmapping XBAR event %u on channel %u\n",
> + map->mux_val, map->dma_line);

Err ?

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

Re: [PATCH 02/13] dmaengine: edma: Optimize memcpy operation

[Vinod Koul]

On Wed, Oct 14, 2015 at 04:12:13PM +0300, Peter Ujfalusi wrote:
> @@ -1320,41 +1317,92 @@ static struct dma_async_tx_descriptor 
> *edma_prep_dma_memcpy(
>   struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
>   size_t len, unsigned long tx_flags)
>  {
> - int ret;
> + int ret, nslots;
>   struct edma_desc *edesc;
>   struct device *dev = chan->device->dev;
>   struct edma_chan *echan = to_edma_chan(chan);
> - unsigned int width;
> + unsigned int width, pset_len;
>  
>   if (unlikely(!echan || !len))
>   return NULL;
>  
> - edesc = kzalloc(sizeof(*edesc) + sizeof(edesc->pset[0]), GFP_ATOMIC);
> + if (len < SZ_64K) {
> + /*
> +  * Transfer size less than 64K can be handled with one paRAM
> +  * slot. ACNT = length
> +  */
> + width = len;
> + pset_len = len;
> + nslots = 1;
> + } else {
> + /*
> +  * Transfer size bigger than 64K will be handled with maximum of
> +  * two paRAM slots.
> +  * slot1: ACNT = 32767, length1: (length / 32767)
> +  * slot2: the remaining amount of data.
> +  */
> + width = SZ_32K - 1;
> + pset_len = rounddown(len, width);
> + /* One slot is enough for lengths multiple of (SZ_32K -1) */

Hmm so does this mean if I have 140K transfer, it will do two 64K for 1st
slot and 12K in second slot ?

Is there a limit on 'blocks' of 64K we can do here?

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

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

[Roger Quadros]

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

--
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: musb: communication issue with more than 12 FTDI ports

[Felipe Balbi]

Hi,

Bin Liu  writes:
> Hi,
>
> On 10/13/2015 01:22 PM, Felipe Balbi wrote:
>> Yegor Yefremov  writes:
>>> On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov
>>>  wrote:
 We have a problem, when using more than 12 FTDI ports. Kernels tried:
 3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz

 Below the USB topology:

 # lsusb -t
 /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
 /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
  |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
  |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M
  |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M
  |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M
  |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M
  |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M
  |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M
  |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M
  |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M
  |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M
  |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M
  |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
  |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
  |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
  |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
  |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M
  |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M
  |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M
  |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M
>
> How many EPs does each FTDI device require? at least one INT EP, right? 
> If I read it right, the topology above has 2 hubs, and 16 high-speed 
> FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT 
> EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP 
> configuration used by default. I am wondering how those devices got 
> enumerated properly.

dynamic EP allocation, but that has its own limitations.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 10/13] dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx

[Peter Ujfalusi]

On 10/14/2015 05:48 PM, Vinod Koul wrote:
> On Wed, Oct 14, 2015 at 04:12:21PM +0300, Peter Ujfalusi wrote:
>> The DMA event crossbar on AM33xx/AM43xx is different from the one found in
>> DRA7x family.
>> Instead of a single event crossbar it has 64 identical mux attached to each
>> eDMA event line. When the 0 event mux is selected, the default mapped event
>> is going to be routed to the corresponding eDMA event line. If different
>> mux is selected, then the selected event is going to be routed to the given
>> eDMA event.
> 
> Why is crossbar patch in edma series?

The old eDMA binding had xbar support which is not supported by the new
binding since it does not belong to the eDMA driver at all.
We have couple of boards where the crossbar is in use so I included the
crossbar support in this series.

>> +static void ti_am335x_xbar_free(struct device *dev, void *route_data)
>> +{
>> +struct ti_am335x_xbar_data *xbar = dev_get_drvdata(dev);
>> +struct ti_am335x_xbar_map *map = route_data;
>> +
>> +dev_err(dev, "Unmapping XBAR event %u on channel %u\n",
>> +map->mux_val, map->dma_line);
> 
> Err ?

Aargh, leftover from debugging.

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

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

[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 
 Acked-by: Roger Quadros 

> ---
>  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: musb: communication issue with more than 12 FTDI ports

[Bin Liu]

Hi,

On 10/13/2015 01:22 PM, Felipe Balbi wrote:

Yegor Yefremov  writes:

On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov
 wrote:

We have a problem, when using more than 12 FTDI ports. Kernels tried:
3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz

Below the USB topology:

# lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
 |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
 |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M
 |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M
 |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M
 |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M
 |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M
 |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M
 |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M
 |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M
 |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M
 |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M
 |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
 |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
 |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
 |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
 |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M
 |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M
 |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M
 |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M


How many EPs does each FTDI device require? at least one INT EP, right? 
If I read it right, the topology above has 2 hubs, and 16 high-speed 
FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT 
EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP 
configuration used by default. I am wondering how those devices got 
enumerated properly.




When using 12 ports and performing serial test (a pair of ports is
connected via null-modem cable and a rather short string ca. 90
characters will be sent alternating at 1200 and 115200b/s, testing
scripts are written in Python and running as own processes per a pair
of ports) there are no timeouts, i.e. all sent characters will be
received. As soon as I open ports 13 and 14 I start to get arbitrary
timeouts  (from test software point of view) on all ports.

In order to check, if ftdi_sio has primary to do with this issue, I've
performed the same test on a PC and PandaBoard Rev. A2 (EHCI port) and
there were no issues with 16 ports. So it seems to have something to
do with am335x + musb + number of end points.

Any idea? Let me know, if you need our test script.


 From time to time I get following warnings (4.3.0-rc5):

musb_host_rx 1915: RX1 dma busy, csr 2020
musb_host_rx 1915: RX4 dma busy, csr 2020
musb_host_rx 1915: RX7 dma busy, csr 2220
musb_host_rx 1915: RX1 dma busy, csr 2020

Though they are not timely related to serial test timeouts.


yeah, I don't think MUSB can easily handle that. IIRC, endpoint
scheduling in MUSB is rather bad. While we have enough endpoints to
handle this case, you might be running into some IP (or driver) issues.

Bin, have you ever tested this many serial devices on AM335x ?


No, I never tested this many devices. It could be resource limitation, 
but the log above is about CPPI, so I recommend to test with CPPI 
disabled to isolate if this is MUSB issue or CPPI.


Regards,
-Bin.




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

[Tony Lindgren]

* Franklin S Cooper Jr.  [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 
>  Acked-by: Roger Quadros 
> 
> > ---
> >  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?

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: OMAP2+: Fix oops with LPAE and more than 2GB of memory

[Tony Lindgren]

* Arnd Bergmann  [151014 02:20]:
> On Tuesday 13 October 2015 16:13:20 Tony Lindgren wrote:
> > On boards with more than 2GB of RAM booting goes wrong with things not 
> > working
> > and we're getting lots of l3 warnings:
> > 
> > WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 
> > l3_interrupt_handler+0x260/0x384()
> > 4400.ocp:L3 Custom Error: MASTER MMC6 TARGET DMM1 (Idle): Data Access 
> > in User mode during Functional access
> > ...
> > [] (scsi_add_host_with_dma) from [] 
> > (ata_scsi_add_hosts+0x5c/0x18c)
> > [] (ata_scsi_add_hosts) from [] 
> > (ata_host_register+0x150/0x2cc)
> > [] (ata_host_register) from [] 
> > (ata_host_activate+0xd4/0x124)
> > [] (ata_host_activate) from [] 
> > (ahci_host_activate+0x5c/0x194)
> > [] (ahci_host_activate) from [] 
> > (ahci_platform_init_host+0x1f0/0x3f0)
> > [] (ahci_platform_init_host) from [] 
> > (ahci_probe+0x70/0x98)
> > [] (ahci_probe) from [] (platform_drv_probe+0x54/0xb4)
> > 
> > Let's fix the issue by enabling ZONE_DMA for LPAE.
> > 
> > Signed-off-by: Tony Lindgren 
> > 
> 
> I suspect this is not the correct fix, even if it works around the problem.
> 
> Am I right that the AHCI device can access the first 4GB of address space
> using 32-bit DMA, and that any RAM beyond 2GB is above that limit?

Yes the memory above 2GB is at 0x3. The same problem is there at least
with MMC too.

> Does the ZONE_DMA have the same size? If not, you get more bounce buffers
> than you want, which is bad for performance/

Hmm good question. I guess we should set .dma_zone_size  = SZ_2G in this
case then as only 2GB of RAM can directly be accessed.

> Another problem here is that it only works with the SCSI and net subsystems
> that have a hack in there to create manual bounce buffers, but other drivers
> that can do DMA to high addresses will not know about this.

OK good to know.

> The right solution would be to force the use of an IOMMU, and if that not
> works, add support for SWIOTLB on ARM.

Suman might have some accelerators in mind we could use for DMA.

For SWIOTLB, It seems we have it for arm64 but not for arm?

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 v5 00/24] dmaengine/ARM: Merge the edma drivers into one

[Vinod Koul]

On Wed, Oct 14, 2015 at 02:42:42PM +0300, Peter Ujfalusi wrote:
> Hi,
> 
> Cover letter:
> 
> with this series the edma two driver setup will be changed to have only one
> driver to support eDMA3. The legacy edma interface will be removed and eDMA 
> can
> only be used via dmaengine API from this point on.
> In order to do the merge the following improvements has been done:
> - One driver instance per eDMA:
>  - Any number of eDMA instances are supported (both legacy and DT boot)
> - Not relying on global variables, arrays, etc
> - Code simplification and optimizations in several places
> 
> This change will also help us to do bigger changes in the eDMA driver since,
> since now we have only one driver to work with.

I have applied this now. I got a conlfict on 3rd one while applying and also
I got conflict while merging to next

Pls verify all is well!

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

Re: musb: communication issue with more than 12 FTDI ports

[Bin Liu]

On 10/14/2015 10:56 AM, Felipe Balbi wrote:


Hi,

Bin Liu  writes:

Hi,

On 10/13/2015 01:22 PM, Felipe Balbi wrote:

Yegor Yefremov  writes:

On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov
 wrote:

We have a problem, when using more than 12 FTDI ports. Kernels tried:
3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz

Below the USB topology:

# lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
  |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
  |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M
  |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M
  |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M
  |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M
  |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M
  |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M
  |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M
  |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M
  |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M
  |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M
  |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
  |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
  |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
  |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
  |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M
  |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M
  |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M
  |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M


How many EPs does each FTDI device require? at least one INT EP, right?
If I read it right, the topology above has 2 hubs, and 16 high-speed
FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT
EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP
configuration used by default. I am wondering how those devices got
enumerated properly.


dynamic EP allocation, but that has its own limitations.


MUSB does not support dynamic EP allocation for INT/ISOCH.
--
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.

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

[PATCH 0/4] ARM: handle imprecise aborts from firmware in common code

[Lucas Stach]

This series implements the handling of a pending imprecise abort left behind
by the bootloader/firmware running before Linux in the common ARM startup code.

It turns pending imprecise aborts that may signal during the first unmasking
of such aborts on the boot CPU into a non-faulting event and warns the user
that the firmware of the machine might be buggy.

Handling this in the common code makes sure that we only ignore already pending
aborts and not those that may happen later during system boot/usage. It also
allows to remove the custom fault handler from the 3 architectures that are
known to have bad firmware/bootloaders.

The patches changing OMAP, MVEBU and BCM5301X are only build tested as I have
no hardware to test on. So I would appreciate a tested-by for those.

Regards,
Lucas

Lucas Stach (4):
  ARM: catch pending imprecise abort on unmask
  ARM: OMAP2+: remove custom abort handler for t410
  ARM: mvebu: remove the workaround imprecise abort fault handler
  ARM: BCM5301X: remove workaround imprecise abort fault handler

 arch/arm/mach-bcm/bcm_5301x.c  | 35 ---
 arch/arm/mach-mvebu/board-v7.c | 35 ---
 arch/arm/mach-omap2/pdata-quirks.c | 29 -
 arch/arm/mm/fault.c| 15 +++
 arch/arm/mm/fault.h|  2 ++
 arch/arm/mm/mmu.c  | 19 ++-
 6 files changed, 35 insertions(+), 100 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/4] ARM: catch pending imprecise abort on unmask

[Lucas Stach]

Install a non-faulting handler just before unmasking imprecise aborts
and switch back to the regular one after unmasking is done.

This catches any pending imprecise abort that the firmware/bootloader
may have left behind that would normally crash the kernel at that point.
As there are apparently a lot of bootlaoders out there that do such a
thing it makes sense to handle it in the common startup code.

Signed-off-by: Lucas Stach 
---
 arch/arm/mm/fault.c | 15 +++
 arch/arm/mm/fault.h |  2 ++
 arch/arm/mm/mmu.c   | 19 ++-
 3 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 0d629b8f973f..519f694ec9db 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -538,6 +538,21 @@ hook_fault_code(int nr, int (*fn)(unsigned long, unsigned 
int, struct pt_regs *)
fsr_info[nr].name = name;
 }
 
+void * __init
+swap_fault_function(int nr,
+   int (*fn)(unsigned long, unsigned int, struct pt_regs *))
+{
+   void *old_fn;
+
+   if (nr < 0 || nr >= ARRAY_SIZE(fsr_info))
+   BUG();
+
+   old_fn = fsr_info[nr].fn;
+   fsr_info[nr].fn = fn;
+
+   return old_fn;
+}
+
 /*
  * Dispatch a data abort to the relevant handler.
  */
diff --git a/arch/arm/mm/fault.h b/arch/arm/mm/fault.h
index cf08bdfbe0d6..2deb7494d84f 100644
--- a/arch/arm/mm/fault.h
+++ b/arch/arm/mm/fault.h
@@ -24,5 +24,7 @@ static inline int fsr_fs(unsigned int fsr)
 
 void do_bad_area(unsigned long addr, unsigned int fsr, struct pt_regs *regs);
 unsigned long search_exception_table(unsigned long addr);
+void *swap_fault_function(int nr,
+   int (*fn)(unsigned long, unsigned int, struct pt_regs *));
 
 #endif /* __ARCH_ARM_FAULT_H */
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index f65a6f344b6d..78c420776f4c 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 
+#include "fault.h"
 #include "mm.h"
 #include "tcm.h"
 
@@ -1259,6 +1260,20 @@ void __init arm_mm_memblock_reserve(void)
 }
 
 /*
+ * Abort handler to be used only during unmasking of imprecise aborts. This
+ * makes sure that the machine will not die if the firmware/bootloader left an
+ * imprecise abort pending for us to trip over.
+ */
+static int __init early_abort_handler(unsigned long addr, unsigned int fsr,
+ struct pt_regs *regs)
+{
+   pr_warn("Hit pending imprecise external abort during first unmask, "
+   "this is most likely caused by a firmware/bootloader bug.\n");
+
+   return 0;
+}
+
+/*
  * Set up the device mappings.  Since we clear out the page tables for all
  * mappings above VMALLOC_START, except early fixmap, we might remove debug
  * device mappings.  This means earlycon can be used to debug this function
@@ -1269,7 +1284,7 @@ static void __init devicemaps_init(const struct 
machine_desc *mdesc)
 {
struct map_desc map;
unsigned long addr;
-   void *vectors;
+   void *vectors, *saved_fault_fn;
 
/*
 * Allocate the vector page early.
@@ -1365,7 +1380,9 @@ static void __init devicemaps_init(const struct 
machine_desc *mdesc)
flush_cache_all();
 
/* Enable asynchronous aborts */
+   saved_fault_fn = swap_fault_function(22, early_abort_handler);
local_abt_enable();
+   swap_fault_function(22, saved_fault_fn);
 }
 
 static void __init kmap_init(void)
-- 
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/4] ARM: BCM5301X: remove workaround imprecise abort fault handler

[Lucas Stach]

This is not needed anymore. Handling a potentially pending imprecise external
abort left behind by the bootloader is now done in a slightly safer way inside
the common ARM startup code.

Signed-off-by: Lucas Stach 
---
 arch/arm/mach-bcm/bcm_5301x.c | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/arch/arm/mach-bcm/bcm_5301x.c b/arch/arm/mach-bcm/bcm_5301x.c
index 5478fe6bcce6..c8830a2b0d60 100644
--- a/arch/arm/mach-bcm/bcm_5301x.c
+++ b/arch/arm/mach-bcm/bcm_5301x.c
@@ -9,40 +9,6 @@
 #include 
 
 #include 
-#include 
-#include 
-
-
-static bool first_fault = true;
-
-static int bcm5301x_abort_handler(unsigned long addr, unsigned int fsr,
-struct pt_regs *regs)
-{
-   if ((fsr == 0x1406 || fsr == 0x1c06) && first_fault) {
-   first_fault = false;
-
-   /*
-* These faults with codes 0x1406 (BCM4709) or 0x1c06 happens
-* for no good reason, possibly left over from the CFE boot
-* loader.
-*/
-   pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x 
ignored.\n",
-   addr, fsr);
-
-   /* Returning non-zero causes fault display and panic */
-   return 0;
-   }
-
-   /* Others should cause a fault */
-   return 1;
-}
-
-static void __init bcm5301x_init_early(void)
-{
-   /* Install our hook */
-   hook_fault_code(16 + 6, bcm5301x_abort_handler, SIGBUS, BUS_OBJERR,
-   "imprecise external abort");
-}
 
 static const char *const bcm5301x_dt_compat[] __initconst = {
"brcm,bcm4708",
@@ -52,6 +18,5 @@ static const char *const bcm5301x_dt_compat[] __initconst = {
 DT_MACHINE_START(BCM5301X, "BCM5301X")
.l2c_aux_val= 0,
.l2c_aux_mask   = ~0,
-   .init_early = bcm5301x_init_early,
.dt_compat  = bcm5301x_dt_compat,
 MACHINE_END
-- 
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/4] ARM: OMAP2+: remove custom abort handler for t410

[Lucas Stach]

This is not needed anymore. Handling a potentially pending imprecise external
abort left behind by the bootloader is now done in a slightly safer way inside
the common ARM startup code.

Signed-off-by: Lucas Stach 
---
 arch/arm/mach-omap2/pdata-quirks.c | 29 -
 1 file changed, 29 deletions(-)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index ea56397599c2..3a2bc2a88db4 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -24,9 +24,6 @@
 #include 
 #include 
 
-#include 
-#include 
-
 #include "common.h"
 #include "common-board-devices.h"
 #include "dss-common.h"
@@ -385,29 +382,6 @@ static void __init omap3_pandora_legacy_init(void)
 }
 #endif /* CONFIG_ARCH_OMAP3 */
 
-#ifdef CONFIG_SOC_TI81XX
-static int fault_fixed_up;
-
-static int t410_abort_handler(unsigned long addr, unsigned int fsr,
- struct pt_regs *regs)
-{
-   if ((fsr == 0x406 || fsr == 0xc06) && !fault_fixed_up) {
-   pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x 
ignored.\n",
-   addr, fsr);
-   fault_fixed_up = 1;
-   return 0;
-   }
-
-   return 1;
-}
-
-static void __init t410_abort_init(void)
-{
-   hook_fault_code(16 + 6, t410_abort_handler, SIGBUS, BUS_OBJERR,
-   "imprecise external abort");
-}
-#endif
-
 #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
 static struct iommu_platform_data omap4_iommu_pdata = {
.reset_name = "mmu_cache",
@@ -536,9 +510,6 @@ static struct pdata_init pdata_quirks[] __initdata = {
{ "openpandora,omap3-pandora-600mhz", omap3_pandora_legacy_init, },
{ "openpandora,omap3-pandora-1ghz", omap3_pandora_legacy_init, },
 #endif
-#ifdef CONFIG_SOC_TI81XX
-   { "hp,t410", t410_abort_init, },
-#endif
 #ifdef CONFIG_SOC_OMAP5
{ "ti,omap5-uevm", omap5_uevm_legacy_init, },
 #endif
-- 
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/4] ARM: mvebu: remove the workaround imprecise abort fault handler

[Lucas Stach]

This is not needed anymore. Handling a potentially pending imprecise external
abort left behind by the bootloader is now done in a slightly safer way inside
the common ARM startup code.

Signed-off-by: Lucas Stach 
---
 arch/arm/mach-mvebu/board-v7.c | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index 9f739f3cad4c..1648edd515a2 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -105,27 +104,6 @@ static void __init mvebu_memblock_reserve(void)
 static void __init mvebu_memblock_reserve(void) {}
 #endif
 
-/*
- * Early versions of Armada 375 SoC have a bug where the BootROM
- * leaves an external data abort pending. The kernel is hit by this
- * data abort as soon as it enters userspace, because it unmasks the
- * data aborts at this moment. We register a custom abort handler
- * below to ignore the first data abort to work around this
- * problem.
- */
-static int armada_375_external_abort_wa(unsigned long addr, unsigned int fsr,
-   struct pt_regs *regs)
-{
-   static int ignore_first;
-
-   if (!ignore_first && fsr == 0x1406) {
-   ignore_first = 1;
-   return 0;
-   }
-
-   return 1;
-}
-
 static void __init mvebu_init_irq(void)
 {
irqchip_init();
@@ -134,17 +112,6 @@ static void __init mvebu_init_irq(void)
BUG_ON(mvebu_mbus_dt_init(coherency_available()));
 }
 
-static void __init external_abort_quirk(void)
-{
-   u32 dev, rev;
-
-   if (mvebu_get_soc_id(, ) == 0 && rev > ARMADA_375_Z1_REV)
-   return;
-
-   hook_fault_code(16 + 6, armada_375_external_abort_wa, SIGBUS, 0,
-   "imprecise external abort");
-}
-
 static void __init i2c_quirk(void)
 {
struct device_node *np;
@@ -177,8 +144,6 @@ static void __init mvebu_dt_init(void)
 {
if (of_machine_is_compatible("marvell,armadaxp"))
i2c_quirk();
-   if (of_machine_is_compatible("marvell,a375-db"))
-   external_abort_quirk();
 
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
-- 
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 02/13] dmaengine: edma: Optimize memcpy operation

[Peter Ujfalusi]

On 10/14/2015 05:41 PM, Vinod Koul wrote:
> On Wed, Oct 14, 2015 at 04:12:13PM +0300, Peter Ujfalusi wrote:
>> @@ -1320,41 +1317,92 @@ static struct dma_async_tx_descriptor 
>> *edma_prep_dma_memcpy(
>>  struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
>>  size_t len, unsigned long tx_flags)
>>  {
>> -int ret;
>> +int ret, nslots;
>>  struct edma_desc *edesc;
>>  struct device *dev = chan->device->dev;
>>  struct edma_chan *echan = to_edma_chan(chan);
>> -unsigned int width;
>> +unsigned int width, pset_len;
>>  
>>  if (unlikely(!echan || !len))
>>  return NULL;
>>  
>> -edesc = kzalloc(sizeof(*edesc) + sizeof(edesc->pset[0]), GFP_ATOMIC);
>> +if (len < SZ_64K) {
>> +/*
>> + * Transfer size less than 64K can be handled with one paRAM
>> + * slot. ACNT = length
>> + */
>> +width = len;
>> +pset_len = len;
>> +nslots = 1;
>> +} else {
>> +/*
>> + * Transfer size bigger than 64K will be handled with maximum of
>> + * two paRAM slots.
>> + * slot1: ACNT = 32767, length1: (length / 32767)
>> + * slot2: the remaining amount of data.
>> + */
>> +width = SZ_32K - 1;
>> +pset_len = rounddown(len, width);
>> +/* One slot is enough for lengths multiple of (SZ_32K -1) */
> 
> Hmm so does this mean if I have 140K transfer, it will do two 64K for 1st
> slot and 12K in second slot ?

Not exactly. If the size is less than 64K it can be done with one 'burst' but
if it is bigger we need to have two sets of transfer:
1. 32K blocks
2. the remaining data

so in case of 140K:
4 x 32K followed by 12K

> 
> Is there a limit on 'blocks' of 64K we can do here?

32767 32K blocks is the limit.

The 64K burst is only possible if the whole transfer is less less than 64K.
With the ACNT counter we can transfer 64K - 1 bytes, but if this is not enough
we need to use the BCNT counter and for that to work the the distance between
the start of 'slot n' and the start of 'slot n+1' need to be less than 32K,
this is the reason why we have 32K 'blocks' to transfer first followed by the
remaining.

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

Re: [PATCH v3 1/2] Trace: PM: promote event 'power_domain_target' to generic power domains.

[Rafael J. Wysocki]

On Wednesday, October 14, 2015 10:18:27 AM Marc Titinger wrote:
> On 14/10/2015 02:55, Rafael J. Wysocki wrote:
> > On Monday, September 28, 2015 03:20:44 PM Marc Titinger wrote:
> >> - change arg3 to a state name string: we got the current CPU rom the trace
> >> backend already. This also prepares for multiple/named states in the power
> >> domain, consistent with idle-states. states in the domain may match given
> >> CPU states in this case, we will trace them by their name, and potentially
> >> use arg2 as a link to their index for the cpuidle driver.
> >>
> >> - tested with Juno DP
> >>
> >> -0 [000]42.395510: power_domain_target:  a53_pd index=0 
> >> 'cluster-sleep-0'
> >> -0 [000]42.395528: cpu_idle: state=4294967295 
> >> cpu_id=0
> >> -0 [000]42.395668: cpu_idle: state=2 cpu_id=0
> >>
> >> - compiled for Omap2+
> >>
> >> Signed-off-by: Marc Titinger 
> >
> > Hi,
> >
> > What's your intent regarding this series?  Do you want it to be applied
> > separately, or is it going to be part of a larger series?
> 
> Hi Rafael,
> 
> v3 is a missed attempt to rebase this on the current head, but I did not 
> fix v3 because thinking twice it's not that useful until Axel Haslam's 
> multiple genpd states stuff is merged in. I'm finding v2 useful, shall I 
> re-post v2 as v4 for clarity then ?

That's up to you mostly.

If I get ACKs from all of the appropriate people on those, I can easily apply 
them.

Thanks,
Rafael

--
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: musb: communication issue with more than 12 FTDI ports

[Felipe Balbi]

Hi,

Bin Liu  writes:
> On 10/14/2015 10:56 AM, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Bin Liu  writes:
>>> Hi,
>>>
>>> On 10/13/2015 01:22 PM, Felipe Balbi wrote:
 Yegor Yefremov  writes:
> On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov
>  wrote:
>> We have a problem, when using more than 12 FTDI ports. Kernels tried:
>> 3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz
>>
>> Below the USB topology:
>>
>> # lsusb -t
>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>>   |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
>>   |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M
>>   |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M
>>   |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M
>>   |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M
>>   |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M
>>   |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M
>>   |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M
>>   |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M
>>   |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M
>>   |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M
>>   |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
>>   |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
>>   |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
>>   |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
>>   |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M
>>   |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M
>>   |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M
>>   |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M
>>>
>>> How many EPs does each FTDI device require? at least one INT EP, right?
>>> If I read it right, the topology above has 2 hubs, and 16 high-speed
>>> FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT
>>> EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP
>>> configuration used by default. I am wondering how those devices got
>>> enumerated properly.
>>
>> dynamic EP allocation, but that has its own limitations.
>>
> MUSB does not support dynamic EP allocation for INT/ISOCH.

I remember isoc doesn't, not sure about int. Do you remember where that
part of the code is off the top of your head ?

-- 
balbi


signature.asc
Description: PGP signature

Re: musb: communication issue with more than 12 FTDI ports

[Felipe Balbi]

Hi,

Bin Liu  writes:
> On 10/14/2015 12:05 PM, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Bin Liu  writes:
>>> Felipe,
>>>
>>> On 10/14/2015 11:25 AM, Felipe Balbi wrote:

 Hi,

 Bin Liu  writes:
> On 10/14/2015 10:56 AM, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Bin Liu  writes:
>>> Hi,
>>>
>>> On 10/13/2015 01:22 PM, Felipe Balbi wrote:
 Yegor Yefremov  writes:
> On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov
>  wrote:
>> We have a problem, when using more than 12 FTDI ports. Kernels tried:
>> 3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz
>>
>> Below the USB topology:
>>
>> # lsusb -t
>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
>> |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M
>> |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 
>> 12M
>> |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 
>> 480M
>> |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 
>> 480M
>> |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 
>> 480M
>> |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 
>> 480M
>> |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 
>> 480M
>> |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 
>> 480M
>> |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 
>> 480M
>> |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 
>> 480M
>> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M
>>>
>>> How many EPs does each FTDI device require? at least one INT EP, right?
>>> If I read it right, the topology above has 2 hubs, and 16 high-speed
>>> FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT
>>> EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP
>>> configuration used by default. I am wondering how those devices got
>>> enumerated properly.
>>
>> dynamic EP allocation, but that has its own limitations.
>>
> MUSB does not support dynamic EP allocation for INT/ISOCH.

 I remember isoc doesn't, not sure about int. Do you remember where that
 part of the code is off the top of your head ?

>>>
>>> The MUSB EP allocation is in musb_schedule() in musb_host.c.
>>>
>>> It does not have specific policy for INT/ISOCH, but the issue is that
>>> for periodic EP, it got allocated during device enumeration but freed
>>> only when the device is disconnected. So practically there is no dynamic
>>> EP allocation for INT/ISOCH.
>>
>> This is not exactly what I can see when trying things out:
>>
>> minicom.cap:56:[   90.909917] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
>> dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
>> minicom.cap:66:[   91.175860] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
>> dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
>> minicom.cap:100:[   91.697827] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
>> dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
>> minicom.cap:106:[   91.818066] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb 
>> df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1
>> minicom.cap:149:[   92.475792] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
>> dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
>> minicom.cap:162:[   92.736808] musb-hdrc musb-hdrc.1.auto: qh dc07d5c0 urb 
>> dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
>> minicom.cap:207:[   93.703046] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb 
>> df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1
>> minicom.cap:215:[   93.977574] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb 
>> df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1
>> minicom.cap:240:[   94.388472] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb 
>> df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1
>> minicom.cap:289:[   95.422325] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb 
>> df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1
>> 

Re: [PATCH] arm, omap2, sram: On HS/EMU devices, only 64K internal SRAM is available.

[Tony Lindgren]

* Heiko Schocher  [151012 22:58]:
> Of this, secure content (including PPA) uses initial
> portion of the SRAM. This chunk is not (and shouldn't
> be) accessible from the public code.
> 
> The minimum size of this chunk (0x350) is used in this
> patch. Available size is rounded off to 63K.
> 
> Both values would require a change if size of secure
> content grows beyond 0x350.

Makes sense to me. And something similar is needed at least for
dm814x to get rid of the imprecise abort during boot with
commit bbeb92095159 ("ARM: 8422/1: enable imprecise aborts during
early kernel startup") applied.

Is this needed as a fix to the -rc cycle, or can this wait for
v4.4?

Regards,

Tony


> Signed-off-by: Heiko Schocher 
> Signed-off-by: Ayoub Zaki 
> ---
> 
>  arch/arm/mach-omap2/sram.c | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/sram.c b/arch/arm/mach-omap2/sram.c
> index cd488b8..2e7c00f 100644
> --- a/arch/arm/mach-omap2/sram.c
> +++ b/arch/arm/mach-omap2/sram.c
> @@ -47,6 +47,28 @@
>  
>  #define GP_DEVICE0x300
>  
> +/**
> + * Size of chunk used by secure content in the HS/EMU devices.
> + *
> + * This size is not fixed. It depends upon the implementation of PPA.
> + * May need to be modified if the size grows.
> + */
> +#define AM33XX_HS_HEADER_SIZE   0x0350
> +
> +/**
> + * Start of public SRAM on HS/EMU devices.
> + */
> +#define AM33XX_SRAM_PA   0x4030
> +#define AM33XX_SRAM_PUB_PA   (AM33XX_SRAM_PA + AM33XX_HS_HEADER_SIZE)
> +
> +/**
> + * Size of public SRAM available on HS/EMU devices.
> + *
> + * This size also depends upon AM33XX_HS_HEADER_SIZE.
> + * Current value is derived from nearest round-off.
> + */
> +#define AM33XX_SRAM_PUB_SIZE 0xfc00  /* 63K */
> +
>  #define ROUND_DOWN(value,boundary)   ((value) & (~((boundary)-1)))
>  
>  static unsigned long omap_sram_start;
> @@ -99,6 +121,9 @@ static void __init omap_detect_sram(void)
>   } else {
>   omap_sram_size = 0x8000; /* 32K */
>   }
> + } else if (soc_is_am33xx()) {
> + omap_sram_start = AM33XX_SRAM_PUB_PA;
> + omap_sram_size  = AM33XX_SRAM_PUB_SIZE;
>   } else {
>   omap_sram_start = OMAP2_SRAM_PUB_PA;
>   omap_sram_size = 0x800; /* 2K */
> -- 
> 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: musb: communication issue with more than 12 FTDI ports

[Bin Liu]

On 10/14/2015 12:19 PM, Felipe Balbi wrote:


Hi,

Bin Liu  writes:

On 10/14/2015 12:05 PM, Felipe Balbi wrote:


Hi,

Bin Liu  writes:

Felipe,

On 10/14/2015 11:25 AM, Felipe Balbi wrote:


Hi,

Bin Liu  writes:

On 10/14/2015 10:56 AM, Felipe Balbi wrote:


Hi,

Bin Liu  writes:

Hi,

On 10/13/2015 01:22 PM, Felipe Balbi wrote:

Yegor Yefremov  writes:

On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov
 wrote:

We have a problem, when using more than 12 FTDI ports. Kernels tried:
3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz

Below the USB topology:

# lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
 |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
 |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M
 |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M
 |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M
 |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M
 |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M
 |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M
 |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M
 |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M
 |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M
 |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M
 |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
 |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
 |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
 |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
 |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M
 |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M
 |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M
 |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M


How many EPs does each FTDI device require? at least one INT EP, right?
If I read it right, the topology above has 2 hubs, and 16 high-speed
FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT
EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP
configuration used by default. I am wondering how those devices got
enumerated properly.


dynamic EP allocation, but that has its own limitations.


MUSB does not support dynamic EP allocation for INT/ISOCH.


I remember isoc doesn't, not sure about int. Do you remember where that
part of the code is off the top of your head ?



The MUSB EP allocation is in musb_schedule() in musb_host.c.

It does not have specific policy for INT/ISOCH, but the issue is that
for periodic EP, it got allocated during device enumeration but freed
only when the device is disconnected. So practically there is no dynamic
EP allocation for INT/ISOCH.


This is not exactly what I can see when trying things out:

minicom.cap:56:[   90.909917] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:66:[   91.175860] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:100:[   91.697827] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:106:[   91.818066] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb 
df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1
minicom.cap:149:[   92.475792] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:162:[   92.736808] musb-hdrc musb-hdrc.1.auto: qh dc07d5c0 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:207:[   93.703046] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb 
df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1
minicom.cap:215:[   93.977574] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb 
df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1
minicom.cap:240:[   94.388472] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb 
df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1
minicom.cap:289:[   95.422325] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb 
df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1
minicom.cap:305:[   95.688207] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb 
df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1
minicom.cap:335:[   96.291453] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb 
df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1
minicom.cap:410:[   97.696976] musb-hdrc musb-hdrc.1.auto: qh df6b70c0 urb 
dc011f40 dev11 ep1in-intr, hw_ep 2, dd842080/8
minicom.cap:56:[   90.909917] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:66:[   91.175860] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:100:[   

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

[Franklin S Cooper Jr.]

On 10/14/2015 11:18 AM, Tony Lindgren wrote:
> * Franklin S Cooper Jr.  [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 
>> Acked-by: Roger Quadros 
>>
>>> ---
>>>  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: musb: communication issue with more than 12 FTDI ports

[Bin Liu]

On 10/14/2015 12:05 PM, Felipe Balbi wrote:


Hi,

Bin Liu  writes:

Felipe,

On 10/14/2015 11:25 AM, Felipe Balbi wrote:


Hi,

Bin Liu  writes:

On 10/14/2015 10:56 AM, Felipe Balbi wrote:


Hi,

Bin Liu  writes:

Hi,

On 10/13/2015 01:22 PM, Felipe Balbi wrote:

Yegor Yefremov  writes:

On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov
 wrote:

We have a problem, when using more than 12 FTDI ports. Kernels tried:
3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz

Below the USB topology:

# lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
|__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
|__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M
|__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M
|__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M


How many EPs does each FTDI device require? at least one INT EP, right?
If I read it right, the topology above has 2 hubs, and 16 high-speed
FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT
EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP
configuration used by default. I am wondering how those devices got
enumerated properly.


dynamic EP allocation, but that has its own limitations.


MUSB does not support dynamic EP allocation for INT/ISOCH.


I remember isoc doesn't, not sure about int. Do you remember where that
part of the code is off the top of your head ?



The MUSB EP allocation is in musb_schedule() in musb_host.c.

It does not have specific policy for INT/ISOCH, but the issue is that
for periodic EP, it got allocated during device enumeration but freed
only when the device is disconnected. So practically there is no dynamic
EP allocation for INT/ISOCH.


This is not exactly what I can see when trying things out:

minicom.cap:56:[   90.909917] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:66:[   91.175860] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:100:[   91.697827] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:106:[   91.818066] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb 
df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1
minicom.cap:149:[   92.475792] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:162:[   92.736808] musb-hdrc musb-hdrc.1.auto: qh dc07d5c0 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:207:[   93.703046] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb 
df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1
minicom.cap:215:[   93.977574] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb 
df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1
minicom.cap:240:[   94.388472] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb 
df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1
minicom.cap:289:[   95.422325] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb 
df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1
minicom.cap:305:[   95.688207] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb 
df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1
minicom.cap:335:[   96.291453] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb 
df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1
minicom.cap:410:[   97.696976] musb-hdrc musb-hdrc.1.auto: qh df6b70c0 urb 
dc011f40 dev11 ep1in-intr, hw_ep 2, dd842080/8
minicom.cap:56:[   90.909917] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:66:[   91.175860] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:100:[   91.697827] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1

Re: [PATCH 2/4] ARM: OMAP2+: remove custom abort handler for t410

[Tony Lindgren]

Hi,

* Lucas Stach  [151014 07:52]:
> This is not needed anymore. Handling a potentially pending imprecise external
> abort left behind by the bootloader is now done in a slightly safer way inside
> the common ARM startup code.

With commit bbeb92095159 ("ARM: 8422/1: enable imprecise aborts during early
kernel startup") we now see where it breaks :) It seems to be related to
misconfigured SRAM size or something in the t410 case:

[0.363485] Unhandled fault: imprecise external abort (0xc06) at 0xc08b156c
[0.370732] pgd = c0004000
[0.373598] [c08b156c] *pgd=8080040e(bad)
[0.377817] Internal error: : c06 [#1] SMP ARM
[0.382470] Modules linked in:
[0.385702] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW   
4.3.0-rc5-1-g3b6348b #1672
[0.394999] Hardware name: Generic ti814x (Flattened Device Tree)
[0.401348] task: ee08ed40 ti: ee09 task.ti: ee09
[0.406988] PC is at omap_rev+0x0/0x10
[0.410930] LR is at omap_sram_init+0xf8/0x3e0
[0.415586] pc : []lr : []psr: 6013
[0.415586] sp : ee091eb0  ip : f004a800  fp : 0099
[0.427563] r10: c08f1858  r9 :   r8 : c08a57c4
[0.433019] r7 : c09d  r6 : ee0e8980  r5 :   r4 : c09d08dc
[0.439812] r3 :   r2 :   r1 :   r0 : f004a000
[0.446609] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[0.454030] Control: 10c5387d  Table: 80004019  DAC: 0051
[0.460024] Process swapper/0 (pid: 1, stack limit = 0xee090218)
[0.466283] Stack: (0xee091eb0 to 0xee092000)
[0.470849] 1ea0: c08efa48  
 ee0e8980
[0.479347] 1ec0: c09d c08aca0c c08efa48 c08faf44 c0904844 c08b581c 
c08efa48 c091a3b0
[0.487847] 1ee0: c091a3b0 c08b5478 c08efa48 c08a57e0  c00098a4 
ee08ed40 c0951e2c
[0.496346] 1f00: ee08f280  ee08ed00 0004 0006  
ef7fcb3d c066c6b8
[0.504843] 1f20: 0099 c005eba0 0001  c086e2b4 ef7fcb51 
0003 0003
[0.513340] 1f40: c090ab00 c090ac0c c090ac14 0003 c09d c09d 
c08f1840 
[0.521841] 1f60: c08f1858 c08a2ec4 0003 0003  c08a2594 
 
[0.530340] 1f80: c063a54c  c063a54c    
 
[0.538837] 1fa0:  c063a554  c000f890   
 
[0.547333] 1fc0:       
 
[0.555832] 1fe0:     0013  
 
[0.564333] [] (omap_rev) from [] 
(omap_sram_init+0xf8/0x3e0)
[0.572118] [] (omap_sram_init) from [] 
(omap_sdrc_init+0x10/0xb0)
[0.580349] [] (omap_sdrc_init) from [] 
(pdata_quirks_init+0x18/0x44)
[0.588850] [] (pdata_quirks_init) from [] 
(omap_generic_init+0x10/0x1c)
[0.597619] [] (omap_generic_init) from [] 
(customize_machine+0x1c/0x40)
[0.606390] [] (customize_machine) from [] 
(do_one_initcall+0x80/0x1dc)
[0.615068] [] (do_one_initcall) from [] 
(kernel_init_freeable+0x218/0x2e8)
[0.624107] [] (kernel_init_freeable) from [] 
(kernel_init+0x8/0xec)
[0.632522] [] (kernel_init) from [] 
(ret_from_fork+0x14/0x24)
[0.640397] Code: e3a03000 e5843064 e8bd8010 c0959e3c (e59f3004)
[0.646756] ---[ end trace cb88537fdc8fa202 ]---

Your patch does not affect this, I need to fix up things for t410 anyways. So
please feel free to add:

Acked-by: Tony Lindgren 

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: musb: communication issue with more than 12 FTDI ports

[Felipe Balbi]

Hi,

Bin Liu  writes:
> Felipe,
>
> On 10/14/2015 11:25 AM, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Bin Liu  writes:
>>> On 10/14/2015 10:56 AM, Felipe Balbi wrote:

 Hi,

 Bin Liu  writes:
> Hi,
>
> On 10/13/2015 01:22 PM, Felipe Balbi wrote:
>> Yegor Yefremov  writes:
>>> On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov
>>>  wrote:
 We have a problem, when using more than 12 FTDI ports. Kernels tried:
 3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz

 Below the USB topology:

 # lsusb -t
 /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
 /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
|__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
|__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M
|__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M
|__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
|__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M
|__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M
>
> How many EPs does each FTDI device require? at least one INT EP, right?
> If I read it right, the topology above has 2 hubs, and 16 high-speed
> FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT
> EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP
> configuration used by default. I am wondering how those devices got
> enumerated properly.

 dynamic EP allocation, but that has its own limitations.

>>> MUSB does not support dynamic EP allocation for INT/ISOCH.
>>
>> I remember isoc doesn't, not sure about int. Do you remember where that
>> part of the code is off the top of your head ?
>>
>
> The MUSB EP allocation is in musb_schedule() in musb_host.c.
>
> It does not have specific policy for INT/ISOCH, but the issue is that 
> for periodic EP, it got allocated during device enumeration but freed 
> only when the device is disconnected. So practically there is no dynamic 
> EP allocation for INT/ISOCH.

This is not exactly what I can see when trying things out:

minicom.cap:56:[   90.909917] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:66:[   91.175860] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:100:[   91.697827] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:106:[   91.818066] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb 
df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1
minicom.cap:149:[   92.475792] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:162:[   92.736808] musb-hdrc musb-hdrc.1.auto: qh dc07d5c0 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:207:[   93.703046] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb 
df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1
minicom.cap:215:[   93.977574] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb 
df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1
minicom.cap:240:[   94.388472] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb 
df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1
minicom.cap:289:[   95.422325] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb 
df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1
minicom.cap:305:[   95.688207] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb 
df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1
minicom.cap:335:[   96.291453] musb-hdrc musb-hdrc.1.auto: qh df551cc0 urb 
df65ee40 dev7 ep1in-intr, hw_ep 12, df6a2bc0/1
minicom.cap:410:[   97.696976] musb-hdrc musb-hdrc.1.auto: qh df6b70c0 urb 
dc011f40 dev11 ep1in-intr, hw_ep 2, dd842080/8
minicom.cap:56:[   90.909917] musb-hdrc 

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

[Roger Quadros]

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 

Acked-by: Roger Quadros 

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?

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] ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory

[Arnd Bergmann]

On Tuesday 13 October 2015 16:13:20 Tony Lindgren wrote:
> On boards with more than 2GB of RAM booting goes wrong with things not working
> and we're getting lots of l3 warnings:
> 
> WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 
> l3_interrupt_handler+0x260/0x384()
> 4400.ocp:L3 Custom Error: MASTER MMC6 TARGET DMM1 (Idle): Data Access in 
> User mode during Functional access
> ...
> [] (scsi_add_host_with_dma) from [] 
> (ata_scsi_add_hosts+0x5c/0x18c)
> [] (ata_scsi_add_hosts) from [] 
> (ata_host_register+0x150/0x2cc)
> [] (ata_host_register) from [] 
> (ata_host_activate+0xd4/0x124)
> [] (ata_host_activate) from [] 
> (ahci_host_activate+0x5c/0x194)
> [] (ahci_host_activate) from [] 
> (ahci_platform_init_host+0x1f0/0x3f0)
> [] (ahci_platform_init_host) from [] 
> (ahci_probe+0x70/0x98)
> [] (ahci_probe) from [] (platform_drv_probe+0x54/0xb4)
> 
> Let's fix the issue by enabling ZONE_DMA for LPAE.
> 
> Signed-off-by: Tony Lindgren 
> 

I suspect this is not the correct fix, even if it works around the problem.

Am I right that the AHCI device can access the first 4GB of address space
using 32-bit DMA, and that any RAM beyond 2GB is above that limit?

Does the ZONE_DMA have the same size? If not, you get more bounce buffers
than you want, which is bad for performance/

Another problem here is that it only works with the SCSI and net subsystems
that have a hack in there to create manual bounce buffers, but other drivers
that can do DMA to high addresses will not know about this.

The right solution would be to force the use of an IOMMU, and if that not
works, add support for SWIOTLB on ARM.

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

[PATCH v2 1/2] ARM: OMAP2+: hwmod: Add hwmod flag for HWMOD_OPT_CLKS_NEEDED

[Peter Ujfalusi]

Some module needs more than one functional clock in order to be accessible,
like the McASPs found in DRA7xx family.
This flag will indicate that the opt_clks need to be handled at the same
time as the main_clk for the given hwmod, ensuring that all needed clocks
are enabled before we try to access the module's address space.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-omap2/omap_hwmod.c | 66 ++--
 arch/arm/mach-omap2/omap_hwmod.h |  3 ++
 2 files changed, 39 insertions(+), 30 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index cc8a987149e2..48495ad82aba 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -890,6 +890,36 @@ static int _init_opt_clks(struct omap_hwmod *oh)
return ret;
 }
 
+static void _enable_optional_clocks(struct omap_hwmod *oh)
+{
+   struct omap_hwmod_opt_clk *oc;
+   int i;
+
+   pr_debug("omap_hwmod: %s: enabling optional clocks\n", oh->name);
+
+   for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++)
+   if (oc->_clk) {
+   pr_debug("omap_hwmod: enable %s:%s\n", oc->role,
+__clk_get_name(oc->_clk));
+   clk_enable(oc->_clk);
+   }
+}
+
+static void _disable_optional_clocks(struct omap_hwmod *oh)
+{
+   struct omap_hwmod_opt_clk *oc;
+   int i;
+
+   pr_debug("omap_hwmod: %s: disabling optional clocks\n", oh->name);
+
+   for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++)
+   if (oc->_clk) {
+   pr_debug("omap_hwmod: disable %s:%s\n", oc->role,
+__clk_get_name(oc->_clk));
+   clk_disable(oc->_clk);
+   }
+}
+
 /**
  * _enable_clocks - enable hwmod main clock and interface clocks
  * @oh: struct omap_hwmod *
@@ -917,6 +947,9 @@ static int _enable_clocks(struct omap_hwmod *oh)
clk_enable(os->_clk);
}
 
+   if (oh->flags & HWMOD_OPT_CLKS_NEEDED)
+   _enable_optional_clocks(oh);
+
/* The opt clocks are controlled by the device driver. */
 
return 0;
@@ -948,41 +981,14 @@ static int _disable_clocks(struct omap_hwmod *oh)
clk_disable(os->_clk);
}
 
+   if (oh->flags & HWMOD_OPT_CLKS_NEEDED)
+   _disable_optional_clocks(oh);
+
/* The opt clocks are controlled by the device driver. */
 
return 0;
 }
 
-static void _enable_optional_clocks(struct omap_hwmod *oh)
-{
-   struct omap_hwmod_opt_clk *oc;
-   int i;
-
-   pr_debug("omap_hwmod: %s: enabling optional clocks\n", oh->name);
-
-   for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++)
-   if (oc->_clk) {
-   pr_debug("omap_hwmod: enable %s:%s\n", oc->role,
-__clk_get_name(oc->_clk));
-   clk_enable(oc->_clk);
-   }
-}
-
-static void _disable_optional_clocks(struct omap_hwmod *oh)
-{
-   struct omap_hwmod_opt_clk *oc;
-   int i;
-
-   pr_debug("omap_hwmod: %s: disabling optional clocks\n", oh->name);
-
-   for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++)
-   if (oc->_clk) {
-   pr_debug("omap_hwmod: disable %s:%s\n", oc->role,
-__clk_get_name(oc->_clk));
-   clk_disable(oc->_clk);
-   }
-}
-
 /**
  * _omap4_enable_module - enable CLKCTRL modulemode on OMAP4
  * @oh: struct omap_hwmod *
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index ca6df1a73475..76bce11c85a4 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -523,6 +523,8 @@ struct omap_hwmod_omap4_prcm {
  * HWMOD_RECONFIG_IO_CHAIN: omap_hwmod code needs to reconfigure wake-up 
  * events by calling _reconfigure_io_chain() when a device is enabled
  * or idled.
+ * HWMOD_OPT_CLKS_NEEDED: The optional clocks are needed for the module to
+ * operate and they need to be handled at the same time as the main_clk.
  */
 #define HWMOD_SWSUP_SIDLE  (1 << 0)
 #define HWMOD_SWSUP_MSTANDBY   (1 << 1)
@@ -538,6 +540,7 @@ struct omap_hwmod_omap4_prcm {
 #define HWMOD_FORCE_MSTANDBY   (1 << 11)
 #define HWMOD_SWSUP_SIDLE_ACT  (1 << 12)
 #define HWMOD_RECONFIG_IO_CHAIN(1 << 13)
+#define HWMOD_OPT_CLKS_NEEDED  (1 << 14)
 
 /*
  * omap_hwmod._int_flags definitions
-- 
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/2] ARM: OMAP2+ McASP(3) support for DRA7xx family

[Peter Ujfalusi]

Hi Paul,

This is the followup series for the hwmod changes needed to get audio working
on DRA7xx family based boards.
The DTS patches has been applied by Tony from the original series:
http://www.spinics.net/lists/linux-omap/msg121473.html

I have addressed your comments in the hwmod data and did some research also
regarding to the use of ahclkx as fclk in the original submission.
It turned out that McASP _needs_ all clocks to be enabled (fclk, iclk and
ahclkx/r) to be able to access registers. The original patch where we handled
the ahclkx as fclk worked, because the fclk clock got enabled in the HW w/o
any SW interaction.
All in all, the McASP found in DRA7 needs all clocks to be enabled.
To satisfy this I have introduced a new flag to hwmod, which means that the
listed optional clocks need to be handled alongside with the fclk clock.

Regards,
Peter
---
Peter Ujfalusi (2):
  ARM: OMAP2+: hwmod: Add hwmod flag for HWMOD_OPT_CLKS_NEEDED
  ARM: OMAP: DRA7: hwmod: Add data for McASP3

 arch/arm/mach-omap2/omap_hwmod.c  | 66 +--
 arch/arm/mach-omap2/omap_hwmod.h  |  3 ++
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 56 ++
 3 files changed, 95 insertions(+), 30 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 v3 1/2] Trace: PM: promote event 'power_domain_target' to generic power domains.

[Marc Titinger]

On 14/10/2015 02:55, Rafael J. Wysocki wrote:

On Monday, September 28, 2015 03:20:44 PM Marc Titinger wrote:

- change arg3 to a state name string: we got the current CPU rom the trace
backend already. This also prepares for multiple/named states in the power
domain, consistent with idle-states. states in the domain may match given
CPU states in this case, we will trace them by their name, and potentially
use arg2 as a link to their index for the cpuidle driver.

- tested with Juno DP

-0 [000]42.395510: power_domain_target:  a53_pd index=0 
'cluster-sleep-0'
-0 [000]42.395528: cpu_idle: state=4294967295 cpu_id=0
-0 [000]42.395668: cpu_idle: state=2 cpu_id=0

- compiled for Omap2+

Signed-off-by: Marc Titinger 


Hi,

What's your intent regarding this series?  Do you want it to be applied
separately, or is it going to be part of a larger series?


Hi Rafael,

v3 is a missed attempt to rebase this on the current head, but I did not 
fix v3 because thinking twice it's not that useful until Axel Haslam's 
multiple genpd states stuff is merged in. I'm finding v2 useful, shall I 
re-post v2 as v4 for clarity then ?


Thanks,
Marc.




Thanks,
Rafael



--
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/2] ARM: OMAP: DRA7: hwmod: Add data for McASP3

[Peter Ujfalusi]

McASP3 is used by default on DRA7x based boards for audio.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 56 +++
 1 file changed, 56 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 562247bced49..d798ebe218b2 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1298,6 +1298,44 @@ static struct omap_hwmod dra7xx_mcspi4_hwmod = {
 };
 
 /*
+ * 'mcasp' class
+ *
+ */
+static struct omap_hwmod_class_sysconfig dra7xx_mcasp_sysc = {
+   .sysc_offs  = 0x0004,
+   .sysc_flags = SYSC_HAS_SIDLEMODE,
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .sysc_fields= _hwmod_sysc_type3,
+};
+
+static struct omap_hwmod_class dra7xx_mcasp_hwmod_class = {
+   .name   = "mcasp",
+   .sysc   = _mcasp_sysc,
+};
+
+/* mcasp3 */
+static struct omap_hwmod_opt_clk mcasp3_opt_clks[] = {
+   { .role = "ahclkx", .clk = "mcasp3_ahclkx_mux" },
+};
+
+static struct omap_hwmod dra7xx_mcasp3_hwmod = {
+   .name   = "mcasp3",
+   .class  = _mcasp_hwmod_class,
+   .clkdm_name = "l4per2_clkdm",
+   .main_clk   = "mcasp3_aux_gfclk_mux",
+   .flags  = HWMOD_OPT_CLKS_NEEDED,
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_L4PER2_MCASP3_CLKCTRL_OFFSET,
+   .context_offs = DRA7XX_RM_L4PER2_MCASP3_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_SWCTRL,
+   },
+   },
+   .opt_clks   = mcasp3_opt_clks,
+   .opt_clks_cnt   = ARRAY_SIZE(mcasp3_opt_clks),
+};
+
+/*
  * 'mmc' class
  *
  */
@@ -2566,6 +2604,22 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__hdmi = 
{
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l4_per2 -> mcasp3 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per2__mcasp3 = {
+   .master = _l4_per2_hwmod,
+   .slave  = _mcasp3_hwmod,
+   .clk= "l4_root_clk_div",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 -> mcasp3 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__mcasp3 = {
+   .master = _l3_main_1_hwmod,
+   .slave  = _mcasp3_hwmod,
+   .clk= "l3_iclk_div",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_addr_space dra7xx_elm_addrs[] = {
{
.pa_start   = 0x48078000,
@@ -3338,6 +3392,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] 
__initdata = {
_l4_wkup__dcan1,
_l4_per2__dcan2,
_l4_per2__cpgmac0,
+   _l4_per2__mcasp3,
+   _l3_main_1__mcasp3,
_gmac__mdio,
_l4_cfg__dma_system,
_l3_main_1__dss,
-- 
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] ARM: dts: am437x-gp-evm: Add wakeup interrupt source for pixcir_i2c_ts

[Roger Quadros]

+Dave

On 14/10/15 08:52, Vignesh R wrote:
> On am437x-gp-evm, pixcir_i2c_ts can wakeup the system from lower power
> state via pinctrl and IO daisy chain using generic wakeirq framework.
> With commit 3fffd1283927 ("i2c: allow specifying separate wakeup
> interrupt in device tree") i2c core allows optional wakeirq to be
> specified via device tree. Add wakeup irq entry to enable pixcir_i2c_ts
> to wake the system from low power state.
> 
> Signed-off-by: Vignesh R 
> ---
>  arch/arm/boot/dts/am437x-gp-evm.dts | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
> b/arch/arm/boot/dts/am437x-gp-evm.dts
> index 22038f21f228..69e93af7df0d 100644
> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
> @@ -581,8 +581,13 @@
>  
>   attb-gpio = < 22 GPIO_ACTIVE_HIGH>;
>  
> + interrupts-extended = < 22 GPIO_ACTIVE_HIGH>,
> +   <_pinmux 0x264>;

How does this work?

interrupts-extended property must have
1) interrupt parent
2) interrupt number
3) interrupt flags

Your change doesn't seem to comply with those requirements.

> + interrupt-names = "tsc", "wakeup";
> +
>   touchscreen-size-x = <1024>;
>   touchscreen-size-y = <600>;
> + wakeup-source;
>   };
>  
>   ov2659@30 {
> 

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 27/27] ARM: dts: omap3: Fix gpmc and NAND nodes

[Roger Quadros]

Tony,

On 13/10/15 18:18, Tony Lindgren wrote:
> * Roger Quadros  [151012 23:33]:
>> On 13/10/15 03:43, Tony Lindgren wrote:
>>> * Roger Quadros  [150918 08:00]:
 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.
>>> ...
 --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
 +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
 @@ -35,11 +35,14 @@
  };
  
   {
 -  ranges = <0 0 0x 0x100>;/* CS0: 16MB for NAND */
 +  ranges = <0 0 0x0800 0x100>;/* CS0: 16MB for NAND */
  
nand@0,0 {
 -  linux,mtd-name = "micron,mt29f4g16abbda3w";
 +  compatible = "ti,omap2-nand";
reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
 +  interrupt-parent = <>;
 +  interrupts = <20>;
 +  linux,mtd-name = "micron,mt29f4g16abbda3w";
nand-bus-width = <16>;
ti,nand-ecc-opt = "bch8";
gpmc,sync-clk-ps = <0>;
>>>
>>> At least torpedo breaks for NFSroot as NAND now overlaps with
>>> Ethernet.. What's the policy you have for moving the addresses
>>> around?
>>
>> For OMAP3 I intended to use 0x3000 for NAND but incorrectly
>> used 0x0800 for the torpedo.
> 
> Might be worth adding some documentation of suggested standardized
> mappings.. For most of theme we could just add them as 16MB chunks,
> then reserve some larger area for NOR?

As GPMC peripherals are not plug and play the GPMC map is specific to
the board and need not necessarily apply to all boards.
So I don't think we need to have any standardized mappings.

> 
>> Does setting it to 0x3000 work? If not what is the original
>> NAND address for this board?
> 
> The u-boot addresses are probably what were used in the .dts* files.
> Setting NAND to 0x3000 is not enough though, looks like there's
> a bug where the logicpd-torpedo-37xx-devkit.dts ranges is missing
> the NAND range in logicpd-torpedo-som.dtsi. Something like the
> patch below seems to make things work again, might be worth
> checking what ranges make sense to standardize on though. Please
> feel free to fold it into your patches.

Thanks. I'll post a revised patch.

> 
>>> There may be other similar cases to check too.
>>
>> Just checked that all other OMAP3 boards I've set to 0x3000
>> if they were 0x0.
> 
> Do you want to reserve a large chunk for NOR at cs0 or what's
> the reason for picking 0x3000 for NAND?

All of the OMAP3 boards were using 0x3000. Probably copy paste effect? :)
What's the point of reserving anything for NOR. If the board doesn't already
have NOR it never will. Future board having NOR can have its own GPMC map.
> 
> I guess NOR can be also on other chipselects.. Not sure we can
> standardize on any specific partition scheme?

Exactly.

cheers,
-roger

> 
> Regards,
> 
> Tony
> 
> 8< 
> --- a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
> +++ b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
> @@ -73,7 +73,8 @@
>  };
>  
>   {
> - ranges = <1 0 0x0800 0x100>;/* CS1: 16MB for LAN9221 */
> + ranges = <0 0 0x3000 0x100  /* CS0: 16MB for NAND */
> +   1 0 0x2c00 0x100>;/* CS1: 16MB for LAN9221 */
>  
>   ethernet@gpmc {
>   pinctrl-names = "default";
> --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> @@ -35,7 +35,7 @@
>  };
>  
>   {
> - ranges = <0 0 0x0800 0x100>;/* CS0: 16MB for NAND */
> + ranges = <0 0 0x3000 0x100>;/* CS0: 16MB for NAND */
>  
>   nand@0,0 {
>   compatible = "ti,omap2-nand";
> 
--
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 v4 27/27] ARM: dts: omap3: Fix gpmc and NAND nodes

[Roger Quadros]

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

v4: Applied Tony's patch to fix broken ethernet on torpedo.

updated v4 series available at

g...@github.com:rogerq/linux.git
 * [branch]  for-v4.4/gpmc-v4

 arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts | 3 ++-
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi| 7 +--
 arch/arm/boot/dts/omap3-beagle.dts| 2 ++
 arch/arm/boot/dts/omap3-cm-t3x.dtsi   | 5 -
 arch/arm/boot/dts/omap3-devkit8000-common.dtsi| 3 +++
 arch/arm/boot/dts/omap3-evm-37xx.dts  | 7 +--
 arch/arm/boot/dts/omap3-gta04.dtsi| 3 +++
 arch/arm/boot/dts/omap3-igep.dtsi | 5 -
 arch/arm/boot/dts/omap3-igep0020-common.dtsi  | 4 ++--
 arch/arm/boot/dts/omap3-igep0030-common.dtsi  | 4 
 arch/arm/boot/dts/omap3-ldp.dts   | 9 ++---
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi   | 5 -
 arch/arm/boot/dts/omap3-pandora-common.dtsi   | 3 +++
 arch/arm/boot/dts/omap3-tao3530.dtsi  | 5 -
 arch/arm/boot/dts/omap3.dtsi  | 4 
 arch/arm/boot/dts/omap3430-sdp.dts| 5 -
 16 files changed, 59 insertions(+), 15 deletions(-)

diff --git a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts 
b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
index 91146c3..20e157d 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
+++ b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
@@ -73,7 +73,8 @@
 };
 
  {
-   ranges = <1 0 0x0800 0x100>;/* CS1: 16MB for LAN9221 */
+   ranges = <0 0 0x3000 0x100  /* CS0: 16MB for NAND */
+ 1 0 0x2c00 0x100>;/* CS1: 16MB for LAN9221 */
 
ethernet@gpmc {
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi 
b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
index 36387b1..f108e55 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
+++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
@@ -35,11 +35,14 @@
 };
 
  {
-   ranges = <0 0 0x 0x100>;/* CS0: 16MB for NAND */
+   ranges = <0 0 0x3000 0x100>;/* CS0: 16MB for NAND */
 
nand@0,0 {
-   linux,mtd-name = "micron,mt29f4g16abbda3w";
+   compatible = "ti,omap2-nand";
reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
+   interrupt-parent = <>;
+   interrupts = <20>;
+   linux,mtd-name = "micron,mt29f4g16abbda3w";
nand-bus-width = <16>;
ti,nand-ecc-opt = "bch8";
gpmc,sync-clk-ps = <0>;
diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index 67659a0..9b145dd 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -384,7 +384,9 @@
 
/* Chip select 0 */
nand@0,0 {
+   compatible = "ti,omap2-nand";
reg = <0 0 4>;  /* NAND I/O window, 4 bytes */
+   interrupt-parent = <>;
interrupts = <20>;
ti,nand-ecc-opt = "ham1";
nand-bus-width = <16>;
diff --git a/arch/arm/boot/dts/omap3-cm-t3x.dtsi 
b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
index 4d091ca..e9d7e28 100644
--- a/arch/arm/boot/dts/omap3-cm-t3x.dtsi
+++ b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
@@ -261,10 +261,13 @@
 };
 
  {
-   ranges = <0 0 0x 0x0100>;
+   ranges = <0 0 0x3000 0x0100>;   /* CS0: 16MB for NAND */
 
nand@0,0 {
+   compatible = "ti,omap2-nand";
reg = <0 0 4>;  /* CS0, offset 0, IO size 4 */
+   interrupt-parent = <>;
+   interrupts = <20>;
nand-bus-width = <8>;
gpmc,device-width = <1>;
ti,nand-ecc-opt = "sw";
diff --git a/arch/arm/boot/dts/omap3-devkit8000-common.dtsi 
b/arch/arm/boot/dts/omap3-devkit8000-common.dtsi
index 9ca2865..e7b46ad 100644
--- a/arch/arm/boot/dts/omap3-devkit8000-common.dtsi
+++ b/arch/arm/boot/dts/omap3-devkit8000-common.dtsi
@@ -204,7 +204,10 @@
ranges = <0 0 0x3000 0x100>;   /* CS0: 16MB for NAND */
 
nand@0,0 {
+   compatible = "ti,omap2-nand";
reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
+   interrupt-parent = <>;
+   interrupts = <20>;
nand-bus-width = <16>;
gpmc,device-width = <2>;
ti,nand-ecc-opt = "sw";
diff --git a/arch/arm/boot/dts/omap3-evm-37xx.dts 
b/arch/arm/boot/dts/omap3-evm-37xx.dts
index 16e8ce3..7081e07 100644
--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ 

Re: [PATCH] ARM: dts: am437x-gp-evm: Add wakeup interrupt source for pixcir_i2c_ts

[Vignesh R]

On 10/14/2015 02:16 PM, Roger Quadros wrote:

> 
> On 14/10/15 08:52, Vignesh R wrote:
>> On am437x-gp-evm, pixcir_i2c_ts can wakeup the system from lower power
>> state via pinctrl and IO daisy chain using generic wakeirq framework.
>> With commit 3fffd1283927 ("i2c: allow specifying separate wakeup
>> interrupt in device tree") i2c core allows optional wakeirq to be
>> specified via device tree. Add wakeup irq entry to enable pixcir_i2c_ts
>> to wake the system from low power state.
>>
>> Signed-off-by: Vignesh R 
>> ---
>>  arch/arm/boot/dts/am437x-gp-evm.dts | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
>> b/arch/arm/boot/dts/am437x-gp-evm.dts
>> index 22038f21f228..69e93af7df0d 100644
>> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
>> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
>> @@ -581,8 +581,13 @@
>>  
>>  attb-gpio = < 22 GPIO_ACTIVE_HIGH>;
>>  
>> +interrupts-extended = < 22 GPIO_ACTIVE_HIGH>,
>> +  <_pinmux 0x264>;
> 
> How does this work?
> 
> interrupts-extended property must have
> 1) interrupt parent
> 2) interrupt number
> 3) interrupt flags
> 
> Your change doesn't seem to comply with those requirements.

AFAIU, interrupts-extended has two parts: interrupt parent phandle and
interrupt specifier.
The number of cells in interrupt specifier is determined by
interrupt-cells property of interrupt parent node.
In above case, gpio3 has interrupt-cells = 2 hence interrupt specifier
has interrupt number and interrupt flag field.
But in case am43xx_pinmux node, interrupt-cells is 1 hence has no
interrupt flag field.

-- 
Regards
Vignesh
--
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: OMAP2+: Update Javier Martinez Canillas's email

[Javier Martinez Canillas]

I see that people are still sending emails to my old address (that no
longer exists) since is the one mentioned in the IGEP DTS. Replace it
with my current email address to avoid this.

Signed-off-by: Javier Martinez Canillas 

---

 arch/arm/boot/dts/omap3-igep.dtsi| 2 +-
 arch/arm/boot/dts/omap3-igep0020-common.dtsi | 2 +-
 arch/arm/boot/dts/omap3-igep0020-rev-f.dts   | 2 +-
 arch/arm/boot/dts/omap3-igep0020.dts | 2 +-
 arch/arm/boot/dts/omap3-igep0030-common.dtsi | 2 +-
 arch/arm/boot/dts/omap3-igep0030-rev-g.dts   | 2 +-
 arch/arm/boot/dts/omap3-igep0030.dts | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep.dtsi 
b/arch/arm/boot/dts/omap3-igep.dtsi
index 2230e1c03320..08f00bee8b86 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -1,7 +1,7 @@
 /*
  * Common device tree for IGEP boards based on AM/DM37x
  *
- * Copyright (C) 2012 Javier Martinez Canillas 
+ * Copyright (C) 2012 Javier Martinez Canillas 
  * Copyright (C) 2012 Enric Balletbo i Serra 
  *
  * This program is free software; you can redistribute it and/or modify
diff --git a/arch/arm/boot/dts/omap3-igep0020-common.dtsi 
b/arch/arm/boot/dts/omap3-igep0020-common.dtsi
index 5ad688c57a00..441999817285 100644
--- a/arch/arm/boot/dts/omap3-igep0020-common.dtsi
+++ b/arch/arm/boot/dts/omap3-igep0020-common.dtsi
@@ -1,7 +1,7 @@
 /*
  * Common Device Tree Source for IGEPv2
  *
- * Copyright (C) 2014 Javier Martinez Canillas 
+ * Copyright (C) 2014 Javier Martinez Canillas 
  * Copyright (C) 2014 Enric Balletbo i Serra 
  *
  * This program is free software; you can redistribute it and/or modify
diff --git a/arch/arm/boot/dts/omap3-igep0020-rev-f.dts 
b/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
index 72f7cdc091fb..321c2b7a4e9f 100644
--- a/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
+++ b/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
@@ -1,7 +1,7 @@
 /*
  * Device Tree Source for IGEPv2 Rev. F (TI OMAP AM/DM37x)
  *
- * Copyright (C) 2012 Javier Martinez Canillas 
+ * Copyright (C) 2012 Javier Martinez Canillas 
  * Copyright (C) 2012 Enric Balletbo i Serra 
  *
  * This program is free software; you can redistribute it and/or modify
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
b/arch/arm/boot/dts/omap3-igep0020.dts
index fea7f7edb45d..dbff1efd7fec 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -1,7 +1,7 @@
 /*
  * Device Tree Source for IGEPv2 Rev. C (TI OMAP AM/DM37x)
  *
- * Copyright (C) 2012 Javier Martinez Canillas 
+ * Copyright (C) 2012 Javier Martinez Canillas 
  * Copyright (C) 2012 Enric Balletbo i Serra 
  *
  * This program is free software; you can redistribute it and/or modify
diff --git a/arch/arm/boot/dts/omap3-igep0030-common.dtsi 
b/arch/arm/boot/dts/omap3-igep0030-common.dtsi
index 0cb1527c39d4..640f06603966 100644
--- a/arch/arm/boot/dts/omap3-igep0030-common.dtsi
+++ b/arch/arm/boot/dts/omap3-igep0030-common.dtsi
@@ -1,7 +1,7 @@
 /*
  * Common Device Tree Source for IGEP COM MODULE
  *
- * Copyright (C) 2014 Javier Martinez Canillas 
+ * Copyright (C) 2014 Javier Martinez Canillas 
  * Copyright (C) 2014 Enric Balletbo i Serra 
  *
  * This program is free software; you can redistribute it and/or modify
diff --git a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts 
b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
index b899e341874a..76dc08868bfb 100644
--- a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
+++ b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
@@ -1,7 +1,7 @@
 /*
  * Device Tree Source for IGEP COM MODULE Rev. G (TI OMAP AM/DM37x)
  *
- * Copyright (C) 2014 Javier Martinez Canillas 
+ * Copyright (C) 2014 Javier Martinez Canillas 
  * Copyright (C) 2014 Enric Balletbo i Serra 
  *
  * This program is free software; you can redistribute it and/or modify
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts 
b/arch/arm/boot/dts/omap3-igep0030.dts
index 8150f47ccdf5..468608dab30a 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -1,7 +1,7 @@
 /*
  * Device Tree Source for IGEP COM MODULE Rev. E (TI OMAP AM/DM37x)
  *
- * Copyright (C) 2012 Javier Martinez Canillas 
+ * Copyright (C) 2012 Javier Martinez Canillas 
  * Copyright (C) 2012 Enric Balletbo i Serra 
  *
  * This program is free software; you can redistribute it and/or modify
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body 

Re: [PATCH] ARM: dts: omap3-igep: Use OMAP3_CORE1_IOPAD pinmux macro

[Tony Lindgren]

* Javier Martinez Canillas  [151013 10:43]:
> Hello Laurent,
> 
> Thanks a lot for the patch.
> 
> On Tue, Oct 13, 2015 at 7:31 PM, Laurent Pinchart
>  wrote:
> > Use the macro instead of absolute register offsets to make the code more
> > readable as the values now match register addresses from the datasheet.
> >
> > Signed-off-by: Laurent Pinchart 
> > ---
> 
> Agreed with the patch and in fact I had the same change in my TODO list.
> 
> I didn't double check the values against the TRM but I trust you ;-)
> 
> Acked-by: Javier Martinez Canillas 

Applying into omap-for-v4.4/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

[GIT PULL] omap fixes against v4.3-rc5

[Tony Lindgren]

The following changes since commit 25cb62b76430a91cc6195f902e61c2cb84ade622:

  Linux 4.3-rc5 (2015-10-11 11:09:45 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v4.3/fixes-rc5

for you to fetch changes up to d8e1f5ed11a39a68da00f05000466c4f6db4456e:

  Documentation: ARM: List new omap MMC requirements (2015-10-12 16:23:34 -0700)


Fixes for omap against v4.3-rc5:

- Regulator fix for beagle-x15 to fix HDMI without a SD card being
  inserted

- GPMC fix for showing proper timings and to allow enabling debug
  options that somehow was unselectable earlier

- Add minimal documentation for new MMC1 dependency on
  REGULATOR_PBIAS as it may not be obvious for people with
  targeted .config files


Tomi Valkeinen (1):
  ARM: dts: am57xx-beagle-x15: set VDD_SD to always-on

Tony Lindgren (2):
  memory: omap-gpmc: Fix unselectable debug option for GPMC
  Documentation: ARM: List new omap MMC requirements

Uwe Kleine-König (1):
  memory: omap-gpmc: dump "before" state before first modification

 Documentation/arm/OMAP/README   |  7 +++
 arch/arm/boot/dts/am57xx-beagle-x15.dts |  3 ++-
 drivers/memory/Kconfig  | 12 +---
 drivers/memory/omap-gpmc.c  |  2 +-
 4 files changed, 19 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/arm/OMAP/README
--
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

[Franklin S Cooper Jr.]

On 10/14/2015 01:13 PM, Tony Lindgren wrote:
> * Franklin S Cooper Jr.  [151014 09:27]:
>>
>> On 10/14/2015 11:18 AM, Tony Lindgren wrote:
>>> * Franklin S Cooper Jr.  [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 
 Acked-by: Roger Quadros 

> ---
>  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] ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory

[Arnd Bergmann]

On Wednesday 14 October 2015 09:17:56 Tony Lindgren wrote:
> * Arnd Bergmann  [151014 02:20]:
> > On Tuesday 13 October 2015 16:13:20 Tony Lindgren wrote:
> > > On boards with more than 2GB of RAM booting goes wrong with things not 
> > > working
> > > and we're getting lots of l3 warnings:
> > > 
> > > WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 
> > > l3_interrupt_handler+0x260/0x384()
> > > 4400.ocp:L3 Custom Error: MASTER MMC6 TARGET DMM1 (Idle): Data Access 
> > > in User mode during Functional access
> > > ...
> > > [] (scsi_add_host_with_dma) from [] 
> > > (ata_scsi_add_hosts+0x5c/0x18c)
> > > [] (ata_scsi_add_hosts) from [] 
> > > (ata_host_register+0x150/0x2cc)
> > > [] (ata_host_register) from [] 
> > > (ata_host_activate+0xd4/0x124)
> > > [] (ata_host_activate) from [] 
> > > (ahci_host_activate+0x5c/0x194)
> > > [] (ahci_host_activate) from [] 
> > > (ahci_platform_init_host+0x1f0/0x3f0)
> > > [] (ahci_platform_init_host) from [] 
> > > (ahci_probe+0x70/0x98)
> > > [] (ahci_probe) from [] (platform_drv_probe+0x54/0xb4)
> > > 
> > > Let's fix the issue by enabling ZONE_DMA for LPAE.
> > > 
> > > Signed-off-by: Tony Lindgren 
> > > 
> > 
> > I suspect this is not the correct fix, even if it works around the problem.
> > 
> > Am I right that the AHCI device can access the first 4GB of address space
> > using 32-bit DMA, and that any RAM beyond 2GB is above that limit?
> 
> Yes the memory above 2GB is at 0x3. The same problem is there at least
> with MMC too.
> 
> > Does the ZONE_DMA have the same size? If not, you get more bounce buffers
> > than you want, which is bad for performance/
> 
> Hmm good question. I guess we should set .dma_zone_size  = SZ_2G in this
> case then as only 2GB of RAM can directly be accessed.

I think you need ".dma_zone_size  = SZ_4G", but I'm not completely sure
whether this takes PHYS_OFFSET into account or not.

> > Another problem here is that it only works with the SCSI and net subsystems
> > that have a hack in there to create manual bounce buffers, but other drivers
> > that can do DMA to high addresses will not know about this.
> 
> OK good to know.
> 
> > The right solution would be to force the use of an IOMMU, and if that not
> > works, add support for SWIOTLB on ARM.
> 
> Suman might have some accelerators in mind we could use for DMA.
> 
> For SWIOTLB, It seems we have it for arm64 but not for arm?

Correct. A number of people have run into problems with this before, but
it has never been added to the kernel. At some point, I tried to help
Peter Senna Tschudin get it implemented, but I think he gave up when it
turned out that the platform he was using to test this did not need it
after all.

The reason we have it on ARM64 is that you are completely screwed there
if you have no IOMMU but use a 32-bit DMA master, while on 32-bit platforms
most of the time you don't have memory above 4GB, and if you do then most
of the time you don't have any DMA masters other than network and scsi
(including sata) on them, or you have an IOMMU for each one.

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

Re: [PATCH] ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory

[Tony Lindgren]

* Suman Anna  [151014 13:32]:
> On 10/14/2015 03:12 PM, Arnd Bergmann wrote:
> > On Wednesday 14 October 2015 09:17:56 Tony Lindgren wrote:
> >> * Arnd Bergmann  [151014 02:20]:
> >>> On Tuesday 13 October 2015 16:13:20 Tony Lindgren wrote:
>  On boards with more than 2GB of RAM booting goes wrong with things not 
>  working
>  and we're getting lots of l3 warnings:
> 
>  WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 
>  l3_interrupt_handler+0x260/0x384()
>  4400.ocp:L3 Custom Error: MASTER MMC6 TARGET DMM1 (Idle): Data 
>  Access in User mode during Functional access
>  ...
>  [] (scsi_add_host_with_dma) from [] 
>  (ata_scsi_add_hosts+0x5c/0x18c)
>  [] (ata_scsi_add_hosts) from [] 
>  (ata_host_register+0x150/0x2cc)
>  [] (ata_host_register) from [] 
>  (ata_host_activate+0xd4/0x124)
>  [] (ata_host_activate) from [] 
>  (ahci_host_activate+0x5c/0x194)
>  [] (ahci_host_activate) from [] 
>  (ahci_platform_init_host+0x1f0/0x3f0)
>  [] (ahci_platform_init_host) from [] 
>  (ahci_probe+0x70/0x98)
>  [] (ahci_probe) from [] 
>  (platform_drv_probe+0x54/0xb4)
> 
>  Let's fix the issue by enabling ZONE_DMA for LPAE.
> 
>  Signed-off-by: Tony Lindgren 
> 
> >>>
> >>> I suspect this is not the correct fix, even if it works around the 
> >>> problem.
> >>>
> >>> Am I right that the AHCI device can access the first 4GB of address space
> >>> using 32-bit DMA, and that any RAM beyond 2GB is above that limit?
> >>
> >> Yes the memory above 2GB is at 0x3. The same problem is there at 
> >> least
> >> with MMC too.
> >>
> >>> Does the ZONE_DMA have the same size? If not, you get more bounce buffers
> >>> than you want, which is bad for performance/
> >>
> >> Hmm good question. I guess we should set .dma_zone_size  = SZ_2G in this
> >> case then as only 2GB of RAM can directly be accessed.
> > 
> > I think you need ".dma_zone_size  = SZ_4G", but I'm not completely sure
> > whether this takes PHYS_OFFSET into account or not.

OK I'll check and do some tests.

> >>> Another problem here is that it only works with the SCSI and net 
> >>> subsystems
> >>> that have a hack in there to create manual bounce buffers, but other 
> >>> drivers
> >>> that can do DMA to high addresses will not know about this.
> >>
> >> OK good to know.
> >>
> >>> The right solution would be to force the use of an IOMMU, and if that not
> >>> works, add support for SWIOTLB on ARM.
> >>
> >> Suman might have some accelerators in mind we could use for DMA.
> 
> Only MMUs that we have on OMAP5 are the ones for the processors on the
> SoC - MPU, DSP or the IPU (Dual-Cortex M4). There is one eDMA engine
> within the DSP subsystem that goes through the DSP MMU, but this is
> typically used by software running on DSP.

OK. Felipe mentioned maybe using tiler :)

> >> For SWIOTLB, It seems we have it for arm64 but not for arm?
> > 
> > Correct. A number of people have run into problems with this before, but
> > it has never been added to the kernel. At some point, I tried to help
> > Peter Senna Tschudin get it implemented, but I think he gave up when it
> > turned out that the platform he was using to test this did not need it
> > after all.
> > 
> > The reason we have it on ARM64 is that you are completely screwed there
> > if you have no IOMMU but use a 32-bit DMA master, while on 32-bit platforms
> > most of the time you don't have memory above 4GB, and if you do then most
> > of the time you don't have any DMA masters other than network and scsi
> > (including sata) on them, or you have an IOMMU for each one.

OK. Sounds like the way to go use use the ZONE_DMA for now, then use
SWIOTLB when available.

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] Add USB hooks into NanoBone DTS file

[Tony Lindgren]

* Mark Jackson  [151014 06:35]:
> Add USB hooks into NanoBone DTS file

Hmm looking at things, we really should not set status = "disabled"
for any of the internal devices. Setting "disabled" makes the kernel
completely ignore the device and we're better off from PM point of
view to probe and idle the device. The devices are there for sure, and
typically just the pins are not configured for them.

How about just remove the status = "disabled" from am33xx.dtsi
instead?

Regards,

Tony

> Signed-off-by: Mark Jackson 
> ---
>  arch/arm/boot/dts/am335x-nano.dts | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am335x-nano.dts 
> b/arch/arm/boot/dts/am335x-nano.dts
> index 5ed4ca6..b86937a 100644
> --- a/arch/arm/boot/dts/am335x-nano.dts
> +++ b/arch/arm/boot/dts/am335x-nano.dts
> @@ -375,6 +375,23 @@
>   wp-gpios = < 18 0>;
>  };
>  
> + {
> + status = "okay";
> +};
> +
> +_ctrl_mod {
> + status = "okay";
> +};
> +
> +_phy {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + dr_mode = "host";
> +};
> +
>  #include "tps65217.dtsi"
>  
>   {
> -- 
> 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: [PATCHv2] ARM: OMAP3: clock: remove un-used core dpll re-program code

[Tony Lindgren]

* Tero Kristo  [151014 04:52]:
> Remove the OMAP3 core DPLL re-program code, and the associated SRAM
> code that does the low-level programming of the DPLL divider, idling
> of the SDRAM etc.
> 
> This code was never fully implemented in the kernel; things missing
> were driver side handling of core clock changes (they need to account
> for their functional clock rate being changed on-the-fly), and the whole
> framework required for handling this. Thus, there is not much point
> to keep carrying the low-level support code either.

Thanks applying into omap-for-v4.4/cleanup.

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: OMAP2+: Fix oops with LPAE and more than 2GB of memory

[Suman Anna]

On 10/14/2015 03:12 PM, Arnd Bergmann wrote:
> On Wednesday 14 October 2015 09:17:56 Tony Lindgren wrote:
>> * Arnd Bergmann  [151014 02:20]:
>>> On Tuesday 13 October 2015 16:13:20 Tony Lindgren wrote:
 On boards with more than 2GB of RAM booting goes wrong with things not 
 working
 and we're getting lots of l3 warnings:

 WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 
 l3_interrupt_handler+0x260/0x384()
 4400.ocp:L3 Custom Error: MASTER MMC6 TARGET DMM1 (Idle): Data Access 
 in User mode during Functional access
 ...
 [] (scsi_add_host_with_dma) from [] 
 (ata_scsi_add_hosts+0x5c/0x18c)
 [] (ata_scsi_add_hosts) from [] 
 (ata_host_register+0x150/0x2cc)
 [] (ata_host_register) from [] 
 (ata_host_activate+0xd4/0x124)
 [] (ata_host_activate) from [] 
 (ahci_host_activate+0x5c/0x194)
 [] (ahci_host_activate) from [] 
 (ahci_platform_init_host+0x1f0/0x3f0)
 [] (ahci_platform_init_host) from [] 
 (ahci_probe+0x70/0x98)
 [] (ahci_probe) from [] (platform_drv_probe+0x54/0xb4)

 Let's fix the issue by enabling ZONE_DMA for LPAE.

 Signed-off-by: Tony Lindgren 

>>>
>>> I suspect this is not the correct fix, even if it works around the problem.
>>>
>>> Am I right that the AHCI device can access the first 4GB of address space
>>> using 32-bit DMA, and that any RAM beyond 2GB is above that limit?
>>
>> Yes the memory above 2GB is at 0x3. The same problem is there at 
>> least
>> with MMC too.
>>
>>> Does the ZONE_DMA have the same size? If not, you get more bounce buffers
>>> than you want, which is bad for performance/
>>
>> Hmm good question. I guess we should set .dma_zone_size  = SZ_2G in this
>> case then as only 2GB of RAM can directly be accessed.
> 
> I think you need ".dma_zone_size  = SZ_4G", but I'm not completely sure
> whether this takes PHYS_OFFSET into account or not.
> 
>>> Another problem here is that it only works with the SCSI and net subsystems
>>> that have a hack in there to create manual bounce buffers, but other drivers
>>> that can do DMA to high addresses will not know about this.
>>
>> OK good to know.
>>
>>> The right solution would be to force the use of an IOMMU, and if that not
>>> works, add support for SWIOTLB on ARM.
>>
>> Suman might have some accelerators in mind we could use for DMA.

Only MMUs that we have on OMAP5 are the ones for the processors on the
SoC - MPU, DSP or the IPU (Dual-Cortex M4). There is one eDMA engine
within the DSP subsystem that goes through the DSP MMU, but this is
typically used by software running on DSP.

regards
Suman

>>
>> For SWIOTLB, It seems we have it for arm64 but not for arm?
> 
> Correct. A number of people have run into problems with this before, but
> it has never been added to the kernel. At some point, I tried to help
> Peter Senna Tschudin get it implemented, but I think he gave up when it
> turned out that the platform he was using to test this did not need it
> after all.
> 
> The reason we have it on ARM64 is that you are completely screwed there
> if you have no IOMMU but use a 32-bit DMA master, while on 32-bit platforms
> most of the time you don't have memory above 4GB, and if you do then most
> of the time you don't have any DMA masters other than network and scsi
> (including sata) on them, or you have an IOMMU for each one.
> 
>   Arnd
> 

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

[GIT PULL 2/2] omap device tree changes for v4.4

[Tony Lindgren]

The following changes since commit 049e6dde7e57f0054fdc49102e7ef4830c698b46:

  Linux 4.3-rc4 (2015-10-04 16:57:17 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v4.4/dt-pt1

for you to fetch changes up to be146412501bc2ed49183637605da97f47125696:

  ARM: dts: omap3-igep: Use OMAP3_CORE1_IOPAD pinmux macro (2015-10-14 12:28:13 
-0700)


Device tree changes for omaps for v4.4 merge window:

- DCAN sleep pins for am437x-gp-evm

- A series of changes to add audio support for dra7

- Add support for gpio keys and LEDs on dra7

- Regulator clean-up for am335x-wega

- A series of changes to enable IOMMUs and mailboxes for dra7
  accelerators

- Add support for am335x-bonegreen

- Fix up GPIO flags where 0 was used instead of GPIO_ACTIVE_HIGH

- Fix omap3-lilly-am33x IRQ level flag

- Remove duplicate uart2 pinmux for igep and fix indentation and
  update igep to use pinctrl macros for the register offsets

- Fix MMC cd-gpios usage

Note that this branch is against v4.3-rc4 as that contains critical
MMC related fixes to boot with MMC working on most omaps.


Grygorii Strashko (3):
  ARM: dts: dra7-evm: add pcf8575 gpio expander (i2c1 addr 20)
  ARM: dts: dra7-evm: add gpio leds support
  ARM: dts: dra7-evm: add gpio key support

Javier Martinez Canillas (2):
  ARM: dts: Use defined GPIO constants in flags cell for OMAP2+ boards
  ARM: dts: omap3-lilly-a83x: Don't use IRQ level flag for a GPIO

Laurent Pinchart (3):
  ARM: dts: omap3-igep: Fix indentation
  ARM: dts: omap3-igep0020: Remove duplicate uart2 pinmux
  ARM: dts: omap3-igep: Use OMAP3_CORE1_IOPAD pinmux macro

Mugunthan V N (3):
  ARM: dts: am335x: fix cd-gpios definition as per hardware design and dt 
binding docs
  ARM: dts: am43xx: fix cd-gpios definition as per hardware design and dt 
binding docs
  ARM: dts: dra7xx: am57xx: fix cd-gpios definition as per hardware design 
and dt binding docs

Peter Ujfalusi (10):
  ARM: dts: dra7: Add McASP3 node
  ARM: dts: dra7-evm: Rename mmc2_3v3 supply to evm_3v3_sw
  ARM: dts: dra7-evm: Add fixed regulator to be used by aic3106's DVDD
  ARM: dts: dra7-evm: Enable pcf8575 (0x26 address) on i2c2 bus
  ARM: dts: dra7-evm: Audio support
  ARM: dts: dra72-evm: Add fixed regulator representing DVDD supply for 
aic3106
  ARM: dts: dra72-evm: Add gpio hog for vin6_sel_s0 to select audio
  ARM: dts: dra72-evm: Audio support
  ARM: dts: am57xx-beagle-x15: Add fixed regulator for aic3104's DVDD
  ARM: dts: am57xx-beagle-x15: Enable analog audio support

Robert Nelson (1):
  ARM: dts: Add am335x-bonegreen

Roger Quadros (1):
  ARM: dts: am437x-gp-evm: Add DCAN sleep pins

Suman Anna (9):
  ARM: dts: DRA74x: Add IPC sub-mailbox nodes for all IPUs & DSPs
  ARM: dts: DRA72x: Add IPC sub-mailbox nodes for IPU1, IPU2 & DSP1
  ARM: dts: dra7-evm: Enable the system mailboxes 5 and 6
  ARM: dts: dra72-evm: Enable the system mailboxes 5 and 6
  ARM: dts: beagle-x15: Enable the system mailboxes 5 and 6
  ARM: dts: DRA7: Add dsp1_system syscon node
  ARM: dts: DRA74x: Add dsp2_system syscon node
  ARM: dts: DRA7: Add common IOMMU nodes
  ARM: dts: DRA74x: Add IOMMU nodes for DSP2

Teresa Remmet (1):
  ARM: dts: am335x-wega: Clean up regulators

 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/am335x-bone-common.dtsi  |   3 +-
 arch/arm/boot/dts/am335x-bonegreen.dts |  53 +
 arch/arm/boot/dts/am335x-evm.dts   |   2 +-
 arch/arm/boot/dts/am335x-evmsk.dts |   2 +-
 arch/arm/boot/dts/am335x-phycore-som.dtsi  |  36 ++--
 arch/arm/boot/dts/am335x-wega.dtsi |  13 +-
 arch/arm/boot/dts/am437x-gp-evm.dts|  22 +-
 arch/arm/boot/dts/am437x-idk-evm.dts   |   2 +-
 arch/arm/boot/dts/am437x-sk-evm.dts|   2 +-
 arch/arm/boot/dts/am43x-epos-evm.dts   |   2 +-
 arch/arm/boot/dts/am57xx-beagle-x15.dts| 117 ++-
 arch/arm/boot/dts/dra7-evm.dts | 222 -
 arch/arm/boot/dts/dra7.dtsi|  60 ++
 arch/arm/boot/dts/dra72-evm.dts| 157 ++-
 arch/arm/boot/dts/dra72x.dtsi  |  21 ++
 arch/arm/boot/dts/dra74x.dtsi  |  51 +
 arch/arm/boot/dts/omap2420-n8x0-common.dtsi|   6 +-
 arch/arm/boot/dts/omap3-beagle-xm.dts  |   2 +-
 arch/arm/boot/dts/omap3-beagle.dts |   2 +-
 arch/arm/boot/dts/omap3-cm-t3x.dtsi|   2 +-
 arch/arm/boot/dts/omap3-devkit8000-lcd-common.dtsi |   2 +-
 arch/arm/boot/dts/omap3-evm-common.dtsi|   4 +-
 

[GIT PULL 1/2] omap clean-up for v4.4

[Tony Lindgren]

The following changes since commit 049e6dde7e57f0054fdc49102e7ef4830c698b46:

  Linux 4.3-rc4 (2015-10-04 16:57:17 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v4.4/cleanup-pt1

for you to fetch changes up to d42f265a5d7a352d40fa2911666cd5236bc3ccaf:

  ARM: OMAP3: clock: remove un-used core dpll re-program code (2015-10-14 
12:35:27 -0700)


Clean-up for omaps for v4.4 merge window:

- Remove legacy omap3 ISP code as the driver is DT only

- Remove VoiceBlue board support as it's been unused over
  10 years now

- Remove unused polarity control macros for TWL

- Remove two unneeded semicolons

- Remove unused core dpll code for reprogramming the rates

Note that this branch is against v4.3-rc4 as that contains critical
MMC related fixes to boot with MMC working on most omaps.


Javier Martinez Canillas (2):
  ARM: OMAP3: vc: Remove unused macros
  ARM: OMAP2+: Remove unneeded semicolons

Ladislav Michl (1):
  ARM: OMAP1: Remove board support for VoiceBlue board

Laurent Pinchart (1):
  ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation

Tero Kristo (1):
  ARM: OMAP3: clock: remove un-used core dpll re-program code

 arch/arm/mach-omap1/Kconfig|   7 -
 arch/arm/mach-omap1/Makefile   |   1 -
 arch/arm/mach-omap1/board-voiceblue.c  | 296 --
 arch/arm/mach-omap1/include/mach/board-voiceblue.h |  19 --
 arch/arm/mach-omap2/Makefile   |   3 -
 arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 122 
 arch/arm/mach-omap2/devices.c  |  53 
 arch/arm/mach-omap2/devices.h  |  19 --
 arch/arm/mach-omap2/pm44xx.c   |   2 +-
 arch/arm/mach-omap2/powerdomains3xxx_data.c|   2 +-
 arch/arm/mach-omap2/sram.c |  25 --
 arch/arm/mach-omap2/sram.h |  14 -
 arch/arm/mach-omap2/sram34xx.S | 346 -
 arch/arm/mach-omap2/vc.c   |   4 -
 14 files changed, 2 insertions(+), 911 deletions(-)
 delete mode 100644 arch/arm/mach-omap1/board-voiceblue.c
 delete mode 100644 arch/arm/mach-omap1/include/mach/board-voiceblue.h
 delete mode 100644 arch/arm/mach-omap2/clkt34xx_dpll3m2.c
 delete mode 100644 arch/arm/mach-omap2/devices.h
 delete mode 100644 arch/arm/mach-omap2/sram34xx.S
--
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/4] ARM: mvebu: remove the workaround imprecise abort fault handler

[Thomas Petazzoni]

Lucas,

On Wed, 14 Oct 2015 16:48:32 +0200, Lucas Stach wrote:
> This is not needed anymore. Handling a potentially pending imprecise external
> abort left behind by the bootloader is now done in a slightly safer way inside
> the common ARM startup code.
> 
> Signed-off-by: Lucas Stach 
> ---
>  arch/arm/mach-mvebu/board-v7.c | 35 ---
>  1 file changed, 35 deletions(-)

Reviewed-by: Thomas Petazzoni 

In fact this code is anyway no longer needed, since this workaround was
only needed for the Armada 375 Z1 stepping, which we no longer support
in mainline anyway.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] ARM: BCM5301X: remove workaround imprecise abort fault handler

[Hauke Mehrtens]

On 10/14/2015 04:48 PM, Lucas Stach wrote:
> This is not needed anymore. Handling a potentially pending imprecise external
> abort left behind by the bootloader is now done in a slightly safer way inside
> the common ARM startup code.
> 
> Signed-off-by: Lucas Stach 
Acked-by: Hauke Mehrtens 

I tested this on my board and this fixes the problem.

Hauke
--
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] ARM: catch pending imprecise abort on unmask

[Hauke Mehrtens]

On 10/14/2015 04:48 PM, Lucas Stach wrote:
> Install a non-faulting handler just before unmasking imprecise aborts
> and switch back to the regular one after unmasking is done.
> 
> This catches any pending imprecise abort that the firmware/bootloader
> may have left behind that would normally crash the kernel at that point.
> As there are apparently a lot of bootlaoders out there that do such a
> thing it makes sense to handle it in the common startup code.
> 
> Signed-off-by: Lucas Stach 
> ---
>  arch/arm/mm/fault.c | 15 +++
>  arch/arm/mm/fault.h |  2 ++
>  arch/arm/mm/mmu.c   | 19 ++-
>  3 files changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> index 0d629b8f973f..519f694ec9db 100644
> --- a/arch/arm/mm/fault.c
> +++ b/arch/arm/mm/fault.c
> @@ -538,6 +538,21 @@ hook_fault_code(int nr, int (*fn)(unsigned long, 
> unsigned int, struct pt_regs *)
>   fsr_info[nr].name = name;
>  }
>  
> +void * __init
> +swap_fault_function(int nr,
> + int (*fn)(unsigned long, unsigned int, struct pt_regs *))
> +{
> + void *old_fn;
> +
> + if (nr < 0 || nr >= ARRAY_SIZE(fsr_info))
> + BUG();
> +
> + old_fn = fsr_info[nr].fn;
> + fsr_info[nr].fn = fn;
> +
> + return old_fn;
> +}
> +
>  /*
>   * Dispatch a data abort to the relevant handler.
>   */
> diff --git a/arch/arm/mm/fault.h b/arch/arm/mm/fault.h
> index cf08bdfbe0d6..2deb7494d84f 100644
> --- a/arch/arm/mm/fault.h
> +++ b/arch/arm/mm/fault.h
> @@ -24,5 +24,7 @@ static inline int fsr_fs(unsigned int fsr)
>  
>  void do_bad_area(unsigned long addr, unsigned int fsr, struct pt_regs *regs);
>  unsigned long search_exception_table(unsigned long addr);
> +void *swap_fault_function(int nr,
> + int (*fn)(unsigned long, unsigned int, struct pt_regs *));
>  
>  #endif   /* __ARCH_ARM_FAULT_H */
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index f65a6f344b6d..78c420776f4c 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -38,6 +38,7 @@
>  #include 
>  #include 
>  
> +#include "fault.h"
>  #include "mm.h"
>  #include "tcm.h"
>  
> @@ -1259,6 +1260,20 @@ void __init arm_mm_memblock_reserve(void)
>  }
>  
>  /*
> + * Abort handler to be used only during unmasking of imprecise aborts. This
> + * makes sure that the machine will not die if the firmware/bootloader left 
> an
> + * imprecise abort pending for us to trip over.
> + */
> +static int __init early_abort_handler(unsigned long addr, unsigned int fsr,
> +   struct pt_regs *regs)
> +{
> + pr_warn("Hit pending imprecise external abort during first unmask, "
> + "this is most likely caused by a firmware/bootloader bug.\n");

Why don't you add the fsr value into the print, so it is easier to debug.

Otherwise:

Acked-by: Hauke Mehrtens 

> +
> + return 0;
> +}
> +
> +/*
>   * Set up the device mappings.  Since we clear out the page tables for all
>   * mappings above VMALLOC_START, except early fixmap, we might remove debug
>   * device mappings.  This means earlycon can be used to debug this function
> @@ -1269,7 +1284,7 @@ static void __init devicemaps_init(const struct 
> machine_desc *mdesc)
>  {
>   struct map_desc map;
>   unsigned long addr;
> - void *vectors;
> + void *vectors, *saved_fault_fn;
>  
>   /*
>* Allocate the vector page early.
> @@ -1365,7 +1380,9 @@ static void __init devicemaps_init(const struct 
> machine_desc *mdesc)
>   flush_cache_all();
>  
>   /* Enable asynchronous aborts */
> + saved_fault_fn = swap_fault_function(22, early_abort_handler);
>   local_abt_enable();
> + swap_fault_function(22, saved_fault_fn);
>  }
>  
>  static void __init kmap_init(void)
> 

--
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, sram: On HS/EMU devices, only 64K internal SRAM is available.

[Tony Lindgren]

* Tony Lindgren  [151014 10:56]:
> * Heiko Schocher  [151012 22:58]:
> > Of this, secure content (including PPA) uses initial
> > portion of the SRAM. This chunk is not (and shouldn't
> > be) accessible from the public code.
> > 
> > The minimum size of this chunk (0x350) is used in this
> > patch. Available size is rounded off to 63K.
> > 
> > Both values would require a change if size of secure
> > content grows beyond 0x350.
> 
> Makes sense to me. And something similar is needed at least for
> dm814x to get rid of the imprecise abort during boot with
> commit bbeb92095159 ("ARM: 8422/1: enable imprecise aborts during
> early kernel startup") applied.
>
> Is this needed as a fix to the -rc cycle, or can this wait for
> v4.4?

Actually I think we may have a regression somwhere. If you look
at commit 8b9a2810b02e ("ARM: OMAP4+: Move SRAM data to DT")
this should all be handled by drivers/misc/sram.c nowadays.

So for most SoCs, we should completely skip the plat-omap/sram.c
code.

Regards,

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

[PATCH 0/2] omap: hsi: Fix warnings on boards that don't use ssi ports

[Roger Quadros]

Hi,

This series fixes warnings and console noise for boards that don't use
ssi ports. Tested on beagleboard-c4.

cheers,
-roger

Roger Quadros (2):
  hsi: omap_ssi_port: Prevent warning if cawake_gpio is not defined.
  ARM: dts: omap3: keep ssi ports by default

 arch/arm/boot/dts/omap3-n900.dts| 1 +
 arch/arm/boot/dts/omap3.dtsi| 2 ++
 drivers/hsi/controllers/omap_ssi_port.c | 2 +-
 3 files changed, 4 insertions(+), 1 deletion(-)

-- 
2.1.4

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

[PATCH 1/2] hsi: omap_ssi_port: Prevent warning if cawake_gpio is not defined.

[Roger Quadros]

The error handling path is broken as cawake_gpio was defined as
unsigned integer causing the following warnings on boards that don't
use SSI port and so don't have cawake_gpio defined. e.g. beagleboard C4.

[   30.094635] WARNING: CPU: 0 PID: 322 at drivers/gpio/gpiolib.c:86 
gpio_to_desc+0xa4/0xb8()
[   30.103363] invalid GPIO -2
[   30.106292] Modules linked in: omap_ssi_port(+) cpufreq_dt cfbfillrect 
cfbimgblt leds_gpio cfbcopyarea thermal_sys led_class hwmon gpio_keys 
encoder_tfp410 connector_analog_tv connector_dvi omap_hdq snd phy_i
[   30.145477] CPU: 0 PID: 322 Comm: modprobe Not tainted 
4.3.0-rc4-00030-gca978c0-dirty #335
[   30.154174] Hardware name: Generic OMAP3-GP (Flattened Device Tree)
[   30.160827] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[   30.168975] [] (show_stack) from [] 
(dump_stack+0x80/0x9c)
[   30.176635] [] (dump_stack) from [] 
(warn_slowpath_common+0x7c/0xb8)
[   30.185180] [] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x30/0x40)
[   30.194366] [] (warn_slowpath_fmt) from [] 
(gpio_to_desc+0xa4/0xb8)
[   30.202819] [] (gpio_to_desc) from [] 
(gpio_request_one+0x14/0x11c)
[   30.211273] [] (gpio_request_one) from [] 
(devm_gpio_request_one+0x3c/0x78)
[   30.220458] [] (devm_gpio_request_one) from [] 
(ssi_port_probe+0x118/0x504 [omap_ssi_port])
[   30.231170] [] (ssi_port_probe [omap_ssi_port]) from [] 
(platform_drv_probe+0x48/0xa4)
[   30.241424] [] (platform_drv_probe) from [] 
(driver_probe_device+0x1dc/0x2a0)
[   30.250793] [] (driver_probe_device) from [] 
(__driver_attach+0x94/0x98)
[   30.259643] [] (__driver_attach) from [] 
(bus_for_each_dev+0x54/0x88)
[   30.268249] [] (bus_for_each_dev) from [] 
(bus_add_driver+0xe8/0x1f8)
[   30.276916] [] (bus_add_driver) from [] 
(driver_register+0x78/0xf4)
[   30.285369] [] (driver_register) from [] 
(__platform_driver_probe+0x34/0xd8)
[   30.294647] [] (__platform_driver_probe) from [] 
(do_one_initcall+0x80/0x1d8)
[   30.303985] [] (do_one_initcall) from [] 
(do_init_module+0x5c/0x1cc)
[   30.312561] [] (do_init_module) from [] 
(load_module+0x18c8/0x1f0c)
[   30.320983] [] (load_module) from [] 
(SyS_init_module+0xdc/0x150)
[   30.329223] [] (SyS_init_module) from [] 
(ret_fast_syscall+0x0/0x1c)

Signed-off-by: Roger Quadros 
---
 drivers/hsi/controllers/omap_ssi_port.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hsi/controllers/omap_ssi_port.c 
b/drivers/hsi/controllers/omap_ssi_port.c
index 1f8652b..02e6603 100644
--- a/drivers/hsi/controllers/omap_ssi_port.c
+++ b/drivers/hsi/controllers/omap_ssi_port.c
@@ -,7 +,7 @@ static int __init ssi_port_probe(struct platform_device 
*pd)
struct omap_ssi_port *omap_port;
struct hsi_controller *ssi = dev_get_drvdata(pd->dev.parent);
struct omap_ssi_controller *omap_ssi = hsi_controller_drvdata(ssi);
-   u32 cawake_gpio = 0;
+   int cawake_gpio = 0;
u32 port_id;
int err;
 
-- 
2.1.4

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

Re: [PATCH] ARM: dts: am437x-gp-evm: Add wakeup interrupt source for pixcir_i2c_ts

[Roger Quadros]

Vignesh,

On 14/10/15 12:12, Vignesh R wrote:
> 
> 
> On 10/14/2015 02:16 PM, Roger Quadros wrote:
> 
>>
>> On 14/10/15 08:52, Vignesh R wrote:
>>> On am437x-gp-evm, pixcir_i2c_ts can wakeup the system from lower power
>>> state via pinctrl and IO daisy chain using generic wakeirq framework.
>>> With commit 3fffd1283927 ("i2c: allow specifying separate wakeup
>>> interrupt in device tree") i2c core allows optional wakeirq to be
>>> specified via device tree. Add wakeup irq entry to enable pixcir_i2c_ts
>>> to wake the system from low power state.
>>>
>>> Signed-off-by: Vignesh R 
>>> ---
>>>  arch/arm/boot/dts/am437x-gp-evm.dts | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
>>> b/arch/arm/boot/dts/am437x-gp-evm.dts
>>> index 22038f21f228..69e93af7df0d 100644
>>> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
>>> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
>>> @@ -581,8 +581,13 @@
>>>  
>>> attb-gpio = < 22 GPIO_ACTIVE_HIGH>;
>>>  
>>> +   interrupts-extended = < 22 GPIO_ACTIVE_HIGH>,
>>> + <_pinmux 0x264>;
>>
>> How does this work?
>>
>> interrupts-extended property must have
>> 1) interrupt parent
>> 2) interrupt number
>> 3) interrupt flags
>>
>> Your change doesn't seem to comply with those requirements.
> 
> AFAIU, interrupts-extended has two parts: interrupt parent phandle and
> interrupt specifier.
> The number of cells in interrupt specifier is determined by
> interrupt-cells property of interrupt parent node.

Got it.

> In above case, gpio3 has interrupt-cells = 2 hence interrupt specifier
> has interrupt number and interrupt flag field.

But is GPIO_ACTIVE_HIGH an interrupt flag?

> But in case am43xx_pinmux node, interrupt-cells is 1 hence has no
> interrupt flag field.
> 
Understood, thanks. Might be worth adding a comment as to what 0x264 means 
though.

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 v4 00/25] dmaengine/ARM: Merge the edma drivers into one

[Peter Ujfalusi]

On 10/14/2015 01:27 PM, Vinod Koul wrote:
> On Thu, Sep 24, 2015 at 01:01:47PM +0300, Peter Ujfalusi wrote:
>> Hi,
>>
>> Cover letter:
>>
>> with this series the edma two driver setup will be changed to have only one
>> driver to support eDMA3. The legacy edma interface will be removed and eDMA 
>> can
>> only be used via dmaengine API from this point on.
>> In order to do the merge the following improvements has been done:
>> - One driver instance per eDMA:
>>  - Any number of eDMA instances are supported (both legacy and DT boot)
>> - Not relying on global variables, arrays, etc
>> - Code simplification and optimizations in several places
> 
> One question though, after this move and merge are we still left with edma
> in arm/ ?

The code from arch/arm/ is gone with this series.

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

Re: [PATCH v4 20/25] dmaengine: edma: Simplify the interrupt handling

[Peter Ujfalusi]

On 10/14/2015 01:20 PM, Vinod Koul wrote:
> On Thu, Sep 24, 2015 at 01:02:07PM +0300, Peter Ujfalusi wrote:
> 
>> +if (edesc->cyclic) {
>> +vchan_cyclic_callback(>vdesc);
>> +spin_unlock(>vchan.lock);
>> +return;
>> +} else if (edesc->processed == edesc->pset_nr) {
>> +dev_dbg(dev, "Transfer completed on channel %d\n",
>> +echan->ch_num);
> 
> perhaps not a great choice for a print, we would ideally want to complete
> the cookie and then print

OK, I have moved the print.

> 
>> +sh_ipr = edma_shadow0_read_array(ecc, SH_IPR, 0);
>> +if (!sh_ipr) {
>> +sh_ipr = edma_shadow0_read_array(ecc, SH_IPR, 1);
>> +if (!sh_ipr)
>> +return IRQ_NONE;
>> +sh_ier = edma_shadow0_read_array(ecc, SH_IER, 1);
>> +bank = 1;
>> +} else {
>> +sh_ier = edma_shadow0_read_array(ecc, SH_IER, 0);
>> +bank = 0;
>> +}
>> +
>> +do {
>> +u32 slot;
>> +u32 channel;
>> +
>> +dev_dbg(ecc->dev, "IPR%d %08x\n", bank, sh_ipr);
> 
> Too much debug prints...

OK, removed this one and changed the dev_dbg for both completion and error
interrupt handler at the start of each function to dev_vdbg() to generate less
noise.

> 
>> +edma_read_slot(ecc, echan->slot[0], );
>> +/*
>> + * Issue later based on missed flag which will be sure
>> + * to happen as:
>> + * (1) we finished transmitting an intermediate slot and
>> + * edma_execute is coming up.
>> + * (2) or we finished current transfer and issue will
>> + * call edma_execute.
>> + *
>> + * Important note: issuing can be dangerous here and
>> + * lead to some nasty recursion when we are in a NULL
>> + * slot. So we avoid doing so and set the missed flag.
>> + */
>> +if (p.a_b_cnt == 0 && p.ccnt == 0) {
>> +dev_dbg(dev, "Error on null slot, setting miss\n");
> 
> Shouldn't this be err?

Probably yes. I have not seen this one ever happening, but it indicates that
something went wrong for sure.

> 
>> +} else if (edma_read(ecc, EDMA_QEMR)) {
>> +dev_dbg(ecc->dev, "QEMR %02x\n",
>> +edma_read(ecc, EDMA_QEMR));
>> +for (i = 0; i < 8; i++) {
>> +if (edma_read(ecc, EDMA_QEMR) & BIT(i)) {
>> +/* Clear the corresponding IPR bits */
>> +edma_write(ecc, EDMA_QEMCR, BIT(i));
>> +edma_shadow0_write(ecc, SH_QSECR,
>> +   BIT(i));
>> +
>> +/* NOTE:  not reported!! */
> 
> what does this mean?

For QEMR and CCERR registers the Linux driver only acks the event, but do not
do anything.
In Linux we are not using the qDMA of the eDMA3 and there is not much we can
do when the CCERR happens.
Hrm, probably moving the CCERR print to dev_err() might be useful, but again I
have not seen this happen. But if it does, we need to come up with something
to avoid it. Basically repartition the use of Transfer Controllers, but this
can not be done with this stack. An upcoming series will give us ways to fine
tune the use of TCs.

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

Re: [PATCH 2/2] ARM: dts: omap3: keep ssi ports by default

[Sebastian Reichel]

Hi,

On Wed, Oct 14, 2015 at 01:44:16PM +0300, Roger Quadros wrote:
> Let's keep the SSI ports disabled in the omap3.dtsi to avoid
> getting the following noise on the console for boards that don't
> use the SSI ports.
> 
> "omap_ssi_port 4805a000.ssi-port: DT data is missing cawake gpio (err=-2)"
> 
> As omap3-n900 uses one SSI port, mark it enabled there.
> 
> Signed-off-by: Roger Quadros 

Acked-By: Sebastian Reichel 

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH 1/2] hsi: omap_ssi_port: Prevent warning if cawake_gpio is not defined.

[Sebastian Reichel]

Hi,

On Wed, Oct 14, 2015 at 01:44:15PM +0300, Roger Quadros wrote:
> The error handling path is broken as cawake_gpio was defined as
> unsigned integer causing the following warnings on boards that don't
> use SSI port and so don't have cawake_gpio defined. e.g. beagleboard C4.
>
> [...]

Thanks, I queued this one together with a

Fixes: b209e047bc743 ("HSI: Introduce OMAP SSI driver")

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH] ARM: dts: am437x-gp-evm: Add wakeup interrupt source for pixcir_i2c_ts

[Vignesh R]

On 10/14/2015 04:34 PM, Roger Quadros wrote:
> Vignesh,
> 
> On 14/10/15 12:12, Vignesh R wrote:
>>
>>
>> On 10/14/2015 02:16 PM, Roger Quadros wrote:
>>
>>>
>>> On 14/10/15 08:52, Vignesh R wrote:
 On am437x-gp-evm, pixcir_i2c_ts can wakeup the system from lower power
 state via pinctrl and IO daisy chain using generic wakeirq framework.
 With commit 3fffd1283927 ("i2c: allow specifying separate wakeup
 interrupt in device tree") i2c core allows optional wakeirq to be
 specified via device tree. Add wakeup irq entry to enable pixcir_i2c_ts
 to wake the system from low power state.

 Signed-off-by: Vignesh R 
 ---
  arch/arm/boot/dts/am437x-gp-evm.dts | 5 +
  1 file changed, 5 insertions(+)

 diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
 b/arch/arm/boot/dts/am437x-gp-evm.dts
 index 22038f21f228..69e93af7df0d 100644
 --- a/arch/arm/boot/dts/am437x-gp-evm.dts
 +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
 @@ -581,8 +581,13 @@
  
attb-gpio = < 22 GPIO_ACTIVE_HIGH>;
  
 +  interrupts-extended = < 22 GPIO_ACTIVE_HIGH>,
 +<_pinmux 0x264>;
>>>
>>> How does this work?
>>>
>>> interrupts-extended property must have
>>> 1) interrupt parent
>>> 2) interrupt number
>>> 3) interrupt flags
>>>
>>> Your change doesn't seem to comply with those requirements.
>>
>> AFAIU, interrupts-extended has two parts: interrupt parent phandle and
>> interrupt specifier.
>> The number of cells in interrupt specifier is determined by
>> interrupt-cells property of interrupt parent node.
> 
> Got it.
> 
>> In above case, gpio3 has interrupt-cells = 2 hence interrupt specifier
>> has interrupt number and interrupt flag field.
> 
> But is GPIO_ACTIVE_HIGH an interrupt flag?

Oops.. I will change it to IRQ_TYPE_NONE as represented in interrupts
property.

> 
>> But in case am43xx_pinmux node, interrupt-cells is 1 hence has no
>> interrupt flag field.
>>
> Understood, thanks. Might be worth adding a comment as to what 0x264 means 
> though.
> 

Will add a one line comment indicating its the offset of gpio3_22
padconf register from am43xx_pinmux base.

> cheers,
> -roger
> 

-- 
Regards
Vignesh
--
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 20/25] dmaengine: edma: Simplify the interrupt handling

[Vinod Koul]

On Thu, Sep 24, 2015 at 01:02:07PM +0300, Peter Ujfalusi wrote:

> + if (edesc->cyclic) {
> + vchan_cyclic_callback(>vdesc);
> + spin_unlock(>vchan.lock);
> + return;
> + } else if (edesc->processed == edesc->pset_nr) {
> + dev_dbg(dev, "Transfer completed on channel %d\n",
> + echan->ch_num);

perhaps not a great choice for a print, we would ideally want to complete
the cookie and then print

> + sh_ipr = edma_shadow0_read_array(ecc, SH_IPR, 0);
> + if (!sh_ipr) {
> + sh_ipr = edma_shadow0_read_array(ecc, SH_IPR, 1);
> + if (!sh_ipr)
> + return IRQ_NONE;
> + sh_ier = edma_shadow0_read_array(ecc, SH_IER, 1);
> + bank = 1;
> + } else {
> + sh_ier = edma_shadow0_read_array(ecc, SH_IER, 0);
> + bank = 0;
> + }
> +
> + do {
> + u32 slot;
> + u32 channel;
> +
> + dev_dbg(ecc->dev, "IPR%d %08x\n", bank, sh_ipr);

Too much debug prints...

> + edma_read_slot(ecc, echan->slot[0], );
> + /*
> +  * Issue later based on missed flag which will be sure
> +  * to happen as:
> +  * (1) we finished transmitting an intermediate slot and
> +  * edma_execute is coming up.
> +  * (2) or we finished current transfer and issue will
> +  * call edma_execute.
> +  *
> +  * Important note: issuing can be dangerous here and
> +  * lead to some nasty recursion when we are in a NULL
> +  * slot. So we avoid doing so and set the missed flag.
> +  */
> + if (p.a_b_cnt == 0 && p.ccnt == 0) {
> + dev_dbg(dev, "Error on null slot, setting miss\n");

Shouldn't this be err ?

> + } else if (edma_read(ecc, EDMA_QEMR)) {
> + dev_dbg(ecc->dev, "QEMR %02x\n",
> + edma_read(ecc, EDMA_QEMR));
> + for (i = 0; i < 8; i++) {
> + if (edma_read(ecc, EDMA_QEMR) & BIT(i)) {
> + /* Clear the corresponding IPR bits */
> + edma_write(ecc, EDMA_QEMCR, BIT(i));
> + edma_shadow0_write(ecc, SH_QSECR,
> +BIT(i));
> +
> + /* NOTE:  not reported!! */

what does this mean?

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

Re: [PATCH 2/2] ARM: dts: omap3: keep ssi ports by default

[Pali Rohár]

On Wednesday 14 October 2015 13:44:16 Roger Quadros wrote:
> Let's keep the SSI ports disabled in the omap3.dtsi to avoid
> getting the following noise on the console for boards that don't
> use the SSI ports.
> 
> "omap_ssi_port 4805a000.ssi-port: DT data is missing cawake gpio (err=-2)"
> 
> As omap3-n900 uses one SSI port, mark it enabled there.
> 

Sebastian, why is second SSI port disabled on N900? It is not used or
in DTS file are missing some definitions?

-- 
Pali Rohár
pali.ro...@gmail.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 2/2] ARM: dts: omap3: keep ssi ports by default

[Sebastian Reichel]

Hi Pali,

On Wed, Oct 14, 2015 at 12:53:04PM +0200, Pali Rohár wrote:
> On Wednesday 14 October 2015 13:44:16 Roger Quadros wrote:
> > Let's keep the SSI ports disabled in the omap3.dtsi to avoid
> > getting the following noise on the console for boards that don't
> > use the SSI ports.
> > 
> > "omap_ssi_port 4805a000.ssi-port: DT data is missing cawake gpio (err=-2)"
> > 
> > As omap3-n900 uses one SSI port, mark it enabled there.
> > 
> 
> Sebastian, why is second SSI port disabled on N900? It is not used or
> in DTS file are missing some definitions?

Since the second SSI port is not used on the Nokia N900. It's pins
are used for other things, e.g. as GPIO. It's easily verifiable
by checking the mux data:

$ grep -C1 "ssi2_" arch/arm/mach-omap2/mux34xx.c
_OMAP3_MUXENTRY(CAM_D10, 109,
"cam_d10", "ssi2_wake", NULL, NULL,
"gpio_109", "hw_dbg8", NULL, "safe_mode"),
_OMAP3_MUXENTRY(CAM_D2, 101,
"cam_d2", "ssi2_rdy_tx", NULL, NULL,
"gpio_101", "hw_dbg4", NULL, "safe_mode"),
_OMAP3_MUXENTRY(CAM_D3, 102,
"cam_d3", "ssi2_dat_rx", NULL, NULL,
"gpio_102", "hw_dbg5", NULL, "safe_mode"),
_OMAP3_MUXENTRY(CAM_D4, 103,
"cam_d4", "ssi2_flag_rx", NULL, NULL,
"gpio_103", "hw_dbg6", NULL, "safe_mode"),
_OMAP3_MUXENTRY(CAM_D5, 104,
"cam_d5", "ssi2_rdy_rx", NULL, NULL,
"gpio_104", "hw_dbg7", NULL, "safe_mode"),
_OMAP3_MUXENTRY(CAM_HS, 94,
"cam_hs", "ssi2_dat_tx", NULL, NULL,
"gpio_94", "hw_dbg0", NULL, "safe_mode"),
_OMAP3_MUXENTRY(CAM_VS, 95,
"cam_vs", "ssi2_flag_tx", NULL, NULL,
"gpio_95", "hw_dbg1", NULL, "safe_mode"),

At least gpio 104 is already used for resetting the tsc2005.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH 2/2] ARM: dts: omap3: keep ssi ports by default

[Roger Quadros]

On 14/10/15 14:19, Sebastian Reichel wrote:
> Hi,
> 
> On Wed, Oct 14, 2015 at 01:44:16PM +0300, Roger Quadros wrote:
>> Let's keep the SSI ports disabled in the omap3.dtsi to avoid
>> getting the following noise on the console for boards that don't
>> use the SSI ports.
>>
>> "omap_ssi_port 4805a000.ssi-port: DT data is missing cawake gpio (err=-2)"
>>
>> As omap3-n900 uses one SSI port, mark it enabled there.
>>
>> Signed-off-by: Roger Quadros 
> 
> Acked-By: Sebastian Reichel 

Would it be preferable to disable the ssi-controller node as well in the
omap3.dtsi file?

cheers,
-roger



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/2] ARM: dts: omap3: keep ssi ports by default

[Sebastian Reichel]

Hi,

On Wed, Oct 14, 2015 at 02:27:27PM +0300, Roger Quadros wrote:
> On 14/10/15 14:19, Sebastian Reichel wrote:
> > On Wed, Oct 14, 2015 at 01:44:16PM +0300, Roger Quadros wrote:
> >> Let's keep the SSI ports disabled in the omap3.dtsi to avoid
> >> getting the following noise on the console for boards that don't
> >> use the SSI ports.
> >>
> >> "omap_ssi_port 4805a000.ssi-port: DT data is missing cawake gpio (err=-2)"
> >>
> >> As omap3-n900 uses one SSI port, mark it enabled there.
>
> Would it be preferable to disable the ssi-controller node as well in the
> omap3.dtsi file?

If I remember it correctly, existing, but unused IP-Cores
should not be disabled in DT, so that hwmod picks them up
for power management.

Note, that it actually is disabled in omap3.dtsi and then enabled in
omap34xx/omap36xx dts files (the other variants do not have an ssi
module).

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH v4 20/25] dmaengine: edma: Simplify the interrupt handling

[Peter Ujfalusi]

On 10/14/2015 02:12 PM, Peter Ujfalusi wrote:
>>> +   } else if (edma_read(ecc, EDMA_QEMR)) {
>>> +   dev_dbg(ecc->dev, "QEMR %02x\n",
>>> +   edma_read(ecc, EDMA_QEMR));
>>> +   for (i = 0; i < 8; i++) {
>>> +   if (edma_read(ecc, EDMA_QEMR) & BIT(i)) {
>>> +   /* Clear the corresponding IPR bits */
>>> +   edma_write(ecc, EDMA_QEMCR, BIT(i));
>>> +   edma_shadow0_write(ecc, SH_QSECR,
>>> +  BIT(i));
>>> +
>>> +   /* NOTE:  not reported!! */
>>
>> what does this mean?
> 
> For QEMR and CCERR registers the Linux driver only acks the event, but do not
> do anything.
> In Linux we are not using the qDMA of the eDMA3 and there is not much we can
> do when the CCERR happens.
> Hrm, probably moving the CCERR print to dev_err() might be useful, but again I
> have not seen this happen. But if it does, we need to come up with something
> to avoid it. Basically repartition the use of Transfer Controllers, but this
> can not be done with this stack. An upcoming series will give us ways to fine
> tune the use of TCs.

In the interrupt handler simplification patch I move the CCERR to dev_warn()
so I leave it like this for this patch - as the function has been just moved
down in the code to be able to call the actual handler of the events.

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

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

[Roger Quadros]

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 

Acked-by: Roger Quadros 

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

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, omap2, sram: On HS/EMU devices, only 64K internal SRAM is available.

[Tony Lindgren]

* Tony Lindgren  [151014 15:27]:
> * Tony Lindgren  [151014 10:56]:
> > * Heiko Schocher  [151012 22:58]:
> > > Of this, secure content (including PPA) uses initial
> > > portion of the SRAM. This chunk is not (and shouldn't
> > > be) accessible from the public code.
> > > 
> > > The minimum size of this chunk (0x350) is used in this
> > > patch. Available size is rounded off to 63K.
> > > 
> > > Both values would require a change if size of secure
> > > content grows beyond 0x350.
> > 
> > Makes sense to me. And something similar is needed at least for
> > dm814x to get rid of the imprecise abort during boot with
> > commit bbeb92095159 ("ARM: 8422/1: enable imprecise aborts during
> > early kernel startup") applied.
> >
> > Is this needed as a fix to the -rc cycle, or can this wait for
> > v4.4?
> 
> Actually I think we may have a regression somwhere. If you look
> at commit 8b9a2810b02e ("ARM: OMAP4+: Move SRAM data to DT")
> this should all be handled by drivers/misc/sram.c nowadays.
> 
> So for most SoCs, we should completely skip the plat-omap/sram.c
> code.

I wonder if the following is enough to fix the issue for you?

This fixes the dm814x imprecise external abort issue on dm814x.

Regards,

Tony

8< -
From: Tony Lindgren 
Date: Wed, 14 Oct 2015 16:09:29 -0700
Subject: [PATCH] ARM: OMAP2+: Fix imprecise external abort caused by bogus
 SRAM init

Some omaps are producing imprecise external aborts because we are
wrongly trying to init SRAM for device tree based booting. Only
omap3 is still using the legacy SRAM code, so we need to make it
omap3 specific. Otherwise we can get errors like this on at least
dm814x:

Unhandled fault: imprecise external abort (0xc06) at 0xc08b156c
pgd = c0004000
[c08b156c] *pgd=8080040e(bad)
Internal error: : c06 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW   
4.3.0-rc5-1-g3b6348b #1672
Hardware name: Generic ti814x (Flattened Device Tree)
task: ee08ed40 ti: ee09 task.ti: ee09
PC is at omap_rev+0x0/0x10
LR is at omap_sram_init+0xf8/0x3e0
pc : []lr : []psr: 6013
sp : ee091eb0  ip : f004a800  fp : 0099
r10: c08f1858  r9 :   r8 : c08a57c4
r7 : c09d  r6 : ee0e8980  r5 :   r4 : c09d08dc
r3 :   r2 :   r1 :   r0 : f004a000
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 80004019  DAC: 0051
Process swapper/0 (pid: 1, stack limit = 0xee090218)
Stack: (0xee091eb0 to 0xee092000)
1ea0: c08efa48   ee0e8980
1ec0: c09d c08aca0c c08efa48 c08faf44 c0904844 c08b581c c08efa48 c091a3b0
1ee0: c091a3b0 c08b5478 c08efa48 c08a57e0  c00098a4 ee08ed40 c0951e2c
1f00: ee08f280  ee08ed00 0004 0006  ef7fcb3d c066c6b8
1f20: 0099 c005eba0 0001  c086e2b4 ef7fcb51 0003 0003
1f40: c090ab00 c090ac0c c090ac14 0003 c09d c09d c08f1840 
1f60: c08f1858 c08a2ec4 0003 0003  c08a2594  
1f80: c063a54c  c063a54c     
1fa0:  c063a554  c000f890    
1fc0:        
1fe0:     0013   
[] (omap_rev) from [] (omap_sram_init+0xf8/0x3e0)
[] (omap_sram_init) from [] (omap_sdrc_init+0x10/0xb0)
[] (omap_sdrc_init) from [] (pdata_quirks_init+0x18/0x44)
[] (pdata_quirks_init) from [] (omap_generic_init+0x10/0x1c)
[] (omap_generic_init) from [] (customize_machine+0x1c/0x40)
[] (customize_machine) from [] (do_one_initcall+0x80/0x1dc)
[] (do_one_initcall) from [] 
(kernel_init_freeable+0x218/0x2e8)
[] (kernel_init_freeable) from [] (kernel_init+0x8/0xec)
[] (kernel_init) from [] (ret_from_fork+0x14/0x24)
Code: e3a03000 e5843064 e8bd8010 c0959e3c (e59f3004)

Let's fix the issue by making sure omap_sdrc_init only gets called for
omap3. To do that, we need to have compatible "ti,omap3" in the dts
files. And let's also use "ti,omap3630" instead of "ti,omap36xx" like
we're supposed to.

Signed-off-by: Tony Lindgren 

--- a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
+++ b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
@@ -12,7 +12,7 @@
 
 / {
model = "LogicPD Zoom DM3730 Torpedo Development Kit";
-   compatible = "logicpd,dm3730-torpedo-devkit", "ti,omap36xx";
+   compatible = "logicpd,dm3730-torpedo-devkit", "ti,omap3630", "ti,omap3";
 
gpio_keys {
compatible = "gpio-keys";
--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -13,7 +13,7 @@
 
 / {
model = "TI OMAP37XX EVM (TMDSEVM3730)";
-   compatible = "ti,omap3-evm-37xx", "ti,omap36xx";
+   compatible = "ti,omap3-evm-37xx", "ti,omap3630", "ti,omap3";
 

[PATCH v5 20/24] dmaengine: edma: Move the pending error check into helper function

[Peter Ujfalusi]

In the ccerr interrupt handler the code checks for pending errors in the
error status registers in two different places.
Move the check out to a helper function.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index daa94a4bbe11..84b98a01993a 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1626,6 +1626,16 @@ static void edma_error_handler(struct edma_chan *echan)
spin_unlock(>vchan.lock);
 }
 
+static inline bool edma_error_pending(struct edma_cc *ecc)
+{
+   if (edma_read_array(ecc, EDMA_EMR, 0) ||
+   edma_read_array(ecc, EDMA_EMR, 1) ||
+   edma_read(ecc, EDMA_QEMR) || edma_read(ecc, EDMA_CCERR))
+   return true;
+
+   return false;
+}
+
 /* eDMA error interrupt handler */
 static irqreturn_t dma_ccerr_handler(int irq, void *data)
 {
@@ -1640,10 +1650,7 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
 
dev_vdbg(ecc->dev, "dma_ccerr_handler\n");
 
-   if ((edma_read_array(ecc, EDMA_EMR, 0) == 0) &&
-   (edma_read_array(ecc, EDMA_EMR, 1) == 0) &&
-   (edma_read(ecc, EDMA_QEMR) == 0) &&
-   (edma_read(ecc, EDMA_CCERR) == 0))
+   if (!edma_error_pending(ecc))
return IRQ_NONE;
 
while (1) {
@@ -1698,10 +1705,7 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
}
}
}
-   if ((edma_read_array(ecc, EDMA_EMR, 0) == 0) &&
-   (edma_read_array(ecc, EDMA_EMR, 1) == 0) &&
-   (edma_read(ecc, EDMA_QEMR) == 0) &&
-   (edma_read(ecc, EDMA_CCERR) == 0))
+   if (!edma_error_pending(ecc))
break;
cnt++;
if (cnt > 10)
-- 
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 v5 00/24] dmaengine/ARM: Merge the edma drivers into one

[Peter Ujfalusi]

Hi,

Changes since v4:
- checkpatch errors/warnings/checks has been fixed in spot and not in a followup
  patch.
- Sekhar's Acked-by added to patches touching arch/arm/mach-davinci/
- Other comments for v4 has been addressed

Changes since v3:
- Separated the two (patch 10/11 in v2 patch 10 in v3) patch which got squashed
  by accident for v3
- Added Tony's Acked-by to patch 11 (for mach-oamp2 part)

Changes since v2:
- devm_kasprintf format string fixed
- Additional patch to enable dynamic paRAM slot usage when the channel mapping
  is supported by the eDMA module.
  On am335x we have 256 paRAM slots and 64 DMA channels, this means that we had
  64 slots 'locked away' all the time. The dynamic paRAM slot logic will allow
  us to use all 256 slots freely for any purpose.

Changes since v1:
- Convert edma platform device registration to use platform_device_register_full
- Moved the PM callback also to the dmaengine driver - missed in v1
- Commit message added to:
  ARM/dmaengine: edma: Remove limitation on the number of eDMA controllers
- New patch which reads the flag for the channel mapping support in one place

Cover letter:

with this series the edma two driver setup will be changed to have only one
driver to support eDMA3. The legacy edma interface will be removed and eDMA can
only be used via dmaengine API from this point on.
In order to do the merge the following improvements has been done:
- One driver instance per eDMA:
 - Any number of eDMA instances are supported (both legacy and DT boot)
- Not relying on global variables, arrays, etc
- Code simplification and optimizations in several places

This change will also help us to do bigger changes in the eDMA driver since,
since now we have only one driver to work with.

The series has been tested on:
da850-evm (OMAP-L138)
- with legacy and DT boot (both eDMA0 and eDMA1 is enabled)
- In code swapping the eDMA instances in legacy mode to make sure the second
  instance is handled correctly.

am335x-evmsk
- DT boot

I think this series could go via the dmaengine tree. Changes are trivial under
arch/arm/

Regards,
Peter
---
Peter Ujfalusi (24):
  ARM: common: edma: Fix channel parameter for irq callbacks
  ARM: common: edma: Remove unused functions
  dmaengine: edma: Simplify and optimize the edma_execute path
  ARM: davinci/common: Convert edma driver to handle one eDMA instance
per driver
  ARM/dmaengine: edma: Move of_dma_controller_register to the dmaengine
driver
  ARM: common: edma: Internal API to use pointer to 'struct edma'
  ARM/dmaengine: edma: Public API to use private struct pointer
  ARM/dmaengine: edma: Remove limitation on the number of eDMA
controllers
  ARM: davinci: Use platform_device_register_full() to create pdev for
eDMA
  ARM: davinci: Add dma_mask to eDMA devices
  ARM/dmaengine: edma: Merge the two drivers under drivers/dma/
  dmaengine: edma: Allocate memory dynamically for bitmaps and
structures
  dmaengine: edma: Use devm_kcalloc when possible
  dmaengine: edma: Cleanup regarding the use of dev around the code
  dmaengine: edma: Use dev_dbg instead pr_debug
  dmaengine: edma: Use the edma_write_slot instead open coded
memcpy_toio
  dmaengine: edma: Print warning when linking slots from different eDMA
  dmaengine: edma: Consolidate the comments for functions
  dmaengine: edma: Simplify the interrupt handling
  dmaengine: edma: Move the pending error check into helper function
  dmaengine: edma: Simplify and optimize ccerr interrupt handler
  dmaengine: edma: Read channel mapping support only once from HW
  dmaengine: edma: Rename bitfields for slot and channel usage tracking
  dmaengine: edma: Dynamic paRAM slot handling if HW supports it

 arch/arm/Kconfig  |1 -
 arch/arm/common/Kconfig   |3 -
 arch/arm/common/Makefile  |1 -
 arch/arm/common/edma.c| 1876 -
 arch/arm/mach-davinci/devices-da8xx.c |  122 +--
 arch/arm/mach-davinci/dm355.c |   40 +-
 arch/arm/mach-davinci/dm365.c |   25 +-
 arch/arm/mach-davinci/dm644x.c|   40 +-
 arch/arm/mach-davinci/dm646x.c|   44 +-
 arch/arm/mach-omap2/Kconfig   |1 -
 drivers/dma/Kconfig   |1 -
 drivers/dma/edma.c| 1631 
 include/linux/platform_data/edma.h|  101 --
 13 files changed, 1566 insertions(+), 2320 deletions(-)
 delete mode 100644 arch/arm/common/edma.c

-- 
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 v5 12/24] dmaengine: edma: Allocate memory dynamically for bitmaps and structures

[Peter Ujfalusi]

Instead of using defines to specify the size of different arrays and
bitmaps, allocate the memory for them based on the information we get from
the HW itself.
Since these defines are set based on the worst case, there are devices
where they are not valid.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 62 ++
 1 file changed, 34 insertions(+), 28 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index aeb67e0cc523..d5a76c67f83f 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -113,23 +113,6 @@
 #define CHMAP_EXISTBIT(24)
 
 /*
- * This will go away when the private EDMA API is folded
- * into this driver and the platform device(s) are
- * instantiated in the arch code. We can only get away
- * with this simplification because DA8XX may not be built
- * in the same kernel image with other DaVinci parts. This
- * avoids having to sprinkle dmaengine driver platform devices
- * and data throughout all the existing board files.
- */
-#ifdef CONFIG_ARCH_DAVINCI_DA8XX
-#define EDMA_CTLRS 2
-#define EDMA_CHANS 32
-#else
-#define EDMA_CTLRS 1
-#define EDMA_CHANS 64
-#endif /* CONFIG_ARCH_DAVINCI_DA8XX */
-
-/*
  * Max of 20 segments per channel to conserve PaRAM slots
  * Also note that MAX_NR_SG should be atleast the no.of periods
  * that are required for ASoC, otherwise DMA prep calls will
@@ -140,16 +123,12 @@
 #define EDMA_MAX_SLOTS MAX_NR_SG
 #define EDMA_DESCRIPTORS   16
 
-#define EDMA_MAX_PARAMENTRY 512
-
 #define EDMA_CHANNEL_ANY   -1  /* for edma_alloc_channel() */
 #define EDMA_SLOT_ANY  -1  /* for edma_alloc_slot() */
 #define EDMA_CONT_PARAMS_ANY1001
 #define EDMA_CONT_PARAMS_FIXED_EXACT1002
 #define EDMA_CONT_PARAMS_FIXED_NOT_EXACT 1003
 
-#define EDMA_MAX_CC   2
-
 /* PaRAM slots are laid out like this */
 struct edmacc_param {
u32 opt;
@@ -256,22 +235,22 @@ struct edma_cc {
/* The edma_inuse bit for each PaRAM slot is clear unless the
 * channel is in use ... by ARM or DSP, for QDMA, or whatever.
 */
-   DECLARE_BITMAP(edma_inuse, EDMA_MAX_PARAMENTRY);
+   unsigned long *edma_inuse;
 
/* The edma_unused bit for each channel is clear unless
 * it is not being used on this platform. It uses a bit
 * of SOC-specific initialization code.
 */
-   DECLARE_BITMAP(edma_unused, EDMA_CHANS);
+   unsigned long *edma_unused;
 
struct dma_interrupt_data {
void (*callback)(unsigned channel, unsigned short ch_status,
 void *data);
void *data;
-   } intr_data[EDMA_CHANS];
+   } *intr_data;
 
struct dma_device   dma_slave;
-   struct edma_chanslave_chans[EDMA_CHANS];
+   struct edma_chan*slave_chans;
int dummy_slot;
 };
 
@@ -457,6 +436,8 @@ static int prepare_unused_channel_list(struct device *dev, 
void *data)
 {
struct platform_device *pdev = to_platform_device(dev);
struct edma_cc *ecc = data;
+   int dma_req_min = EDMA_CTLR_CHAN(ecc->id, 0);
+   int dma_req_max = dma_req_min + ecc->num_channels;
int i, count;
struct of_phandle_args  dma_spec;
 
@@ -491,11 +472,15 @@ static int prepare_unused_channel_list(struct device 
*dev, void *data)
/* For non-OF case */
for (i = 0; i < pdev->num_resources; i++) {
struct resource *res = >resource[i];
+   int dma_req;
+
+   if (!(res->flags & IORESOURCE_DMA))
+   continue;
 
-   if ((res->flags & IORESOURCE_DMA) && (int)res->start >= 0) {
+   dma_req = (int)res->start;
+   if (dma_req >= dma_req_min && dma_req < dma_req_max)
clear_bit(EDMA_CHAN_SLOT(pdev->resource[i].start),
  ecc->edma_unused);
-   }
}
 
return 0;
@@ -1978,7 +1963,7 @@ static void __init edma_chan_init(struct edma_cc *ecc, 
struct dma_device *dma,
 {
int i, j;
 
-   for (i = 0; i < EDMA_CHANS; i++) {
+   for (i = 0; i < ecc->num_channels; i++) {
struct edma_chan *echan = [i];
echan->ch_num = EDMA_CTLR_CHAN(ecc->id, i);
echan->ecc = ecc;
@@ -2247,6 +2232,27 @@ static int edma_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   /* Allocate memory based on the information we got from the IP */
+   ecc->slave_chans = devm_kcalloc(dev, ecc->num_channels,
+   sizeof(*ecc->slave_chans), GFP_KERNEL);
+   if (!ecc->slave_chans)
+   return -ENOMEM;
+
+   ecc->intr_data = devm_kcalloc(dev, ecc->num_channels,
+ 

[PATCH v5 11/24] ARM/dmaengine: edma: Merge the two drivers under drivers/dma/

[Peter Ujfalusi]

Move the code out from arch/arm/common and merge it inside of the dmaengine
driver.
This change is done with as minimal (if eny) functional change to the code
as possible to avoid introducing regression.

Signed-off-by: Peter Ujfalusi 
Acked-by: Tony Lindgren 
---
 arch/arm/Kconfig   |1 -
 arch/arm/common/Kconfig|3 -
 arch/arm/common/Makefile   |1 -
 arch/arm/common/edma.c | 1431 --
 arch/arm/mach-omap2/Kconfig|1 -
 drivers/dma/Kconfig|1 -
 drivers/dma/edma.c | 1506 ++--
 include/linux/platform_data/edma.h |   74 --
 8 files changed, 1431 insertions(+), 1587 deletions(-)
 delete mode 100644 arch/arm/common/edma.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 39d7d4bd4d5a..0365cbbc9179 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -715,7 +715,6 @@ config ARCH_DAVINCI
select GENERIC_CLOCKEVENTS
select GENERIC_IRQ_CHIP
select HAVE_IDE
-   select TI_PRIV_EDMA
select USE_OF
select ZONE_DMA
help
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index c3a4e9ceba34..9353184d730d 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -17,6 +17,3 @@ config SHARP_PARAM
 
 config SHARP_SCOOP
bool
-
-config TI_PRIV_EDMA
-   bool
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index 6ee5959a813b..27f23b15b1ea 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -15,6 +15,5 @@ obj-$(CONFIG_MCPM)+= mcpm_head.o mcpm_entry.o 
mcpm_platsmp.o vlock.o
 CFLAGS_REMOVE_mcpm_entry.o = -pg
 AFLAGS_mcpm_head.o := -march=armv7-a
 AFLAGS_vlock.o := -march=armv7-a
-obj-$(CONFIG_TI_PRIV_EDMA) += edma.o
 obj-$(CONFIG_BL_SWITCHER)  += bL_switcher.o
 obj-$(CONFIG_BL_SWITCHER_DUMMY_IF) += bL_switcher_dummy_if.o
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
deleted file mode 100644
index 5b747f1bc8b5..
--- a/arch/arm/common/edma.c
+++ /dev/null
@@ -1,1431 +0,0 @@
-/*
- * EDMA3 support for DaVinci
- *
- * Copyright (C) 2006-2009 Texas Instruments.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-/* Offsets matching "struct edmacc_param" */
-#define PARM_OPT   0x00
-#define PARM_SRC   0x04
-#define PARM_A_B_CNT   0x08
-#define PARM_DST   0x0c
-#define PARM_SRC_DST_BIDX  0x10
-#define PARM_LINK_BCNTRLD  0x14
-#define PARM_SRC_DST_CIDX  0x18
-#define PARM_CCNT  0x1c
-
-#define PARM_SIZE  0x20
-
-/* Offsets for EDMA CC global channel registers and their shadows */
-#define SH_ER  0x00/* 64 bits */
-#define SH_ECR 0x08/* 64 bits */
-#define SH_ESR 0x10/* 64 bits */
-#define SH_CER 0x18/* 64 bits */
-#define SH_EER 0x20/* 64 bits */
-#define SH_EECR0x28/* 64 bits */
-#define SH_EESR0x30/* 64 bits */
-#define SH_SER 0x38/* 64 bits */
-#define SH_SECR0x40/* 64 bits */
-#define SH_IER 0x50/* 64 bits */
-#define SH_IECR0x58/* 64 bits */
-#define SH_IESR0x60/* 64 bits */
-#define SH_IPR 0x68/* 64 bits */
-#define SH_ICR 0x70/* 64 bits */
-#define SH_IEVAL   0x78
-#define SH_QER 0x80
-#define SH_QEER0x84
-#define SH_QEECR   0x88
-#define SH_QEESR   0x8c
-#define SH_QSER0x90
-#define SH_QSECR   0x94
-#define SH_SIZE0x200
-
-/* Offsets for EDMA CC global registers */
-#define EDMA_REV   0x
-#define EDMA_CCCFG 0x0004
-#define EDMA_QCHMAP0x0200  /* 8 registers */
-#define EDMA_DMAQNUM   0x0240  /* 8 registers (4 on OMAP-L1xx) */
-#define EDMA_QDMAQNUM  0x0260
-#define EDMA_QUETCMAP  0x0280
-#define EDMA_QUEPRI0x0284
-#define EDMA_EMR   0x0300  /* 64 bits */
-#define EDMA_EMCR  0x0308  /* 64 bits */
-#define EDMA_QEMR  

[PATCH v5 17/24] dmaengine: edma: Print warning when linking slots from different eDMA

[Peter Ujfalusi]

Warning message in case of linking between paRAM slots in different eDMA
controllers.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index f6653da0ee16..d33ae0b43925 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -619,6 +619,9 @@ static void edma_free_slot(struct edma_cc *ecc, unsigned 
slot)
  */
 static void edma_link(struct edma_cc *ecc, unsigned from, unsigned to)
 {
+   if (unlikely(EDMA_CTLR(from) != EDMA_CTLR(to)))
+   dev_warn(ecc->dev, "Ignoring eDMA instance for linking\n");
+
from = EDMA_CHAN_SLOT(from);
to = EDMA_CHAN_SLOT(to);
if (from >= ecc->num_slots || to >= ecc->num_slots)
-- 
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 v5 19/24] dmaengine: edma: Simplify the interrupt handling

[Peter Ujfalusi]

With the merger of the arch/arm/common/edma.c code into the dmaengine
driver, there is no longer need to have per channel callback/data storage
for interrupt events.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 450 -
 1 file changed, 205 insertions(+), 245 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 6bcbdceb3dc2..daa94a4bbe11 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -154,12 +154,6 @@ struct edmacc_param {
 #define TCCHEN BIT(22)
 #define ITCCHENBIT(23)
 
-/*ch_status parameter of callback function possible values*/
-#define EDMA_DMA_COMPLETE 1
-#define EDMA_DMA_CC_ERROR 2
-#define EDMA_DMA_TC1_ERROR 3
-#define EDMA_DMA_TC2_ERROR 4
-
 struct edma_pset {
u32 len;
dma_addr_t  addr;
@@ -243,12 +237,6 @@ struct edma_cc {
 */
unsigned long *edma_unused;
 
-   struct dma_interrupt_data {
-   void (*callback)(unsigned channel, unsigned short ch_status,
-void *data);
-   void *data;
-   } *intr_data;
-
struct dma_device   dma_slave;
struct edma_chan*slave_chans;
int dummy_slot;
@@ -486,24 +474,18 @@ static int prepare_unused_channel_list(struct device 
*dev, void *data)
return 0;
 }
 
-static void edma_setup_interrupt(struct edma_cc *ecc, unsigned lch,
-   void (*callback)(unsigned channel, u16 ch_status, void *data),
-   void *data)
+static void edma_setup_interrupt(struct edma_cc *ecc, unsigned lch, bool 
enable)
 {
lch = EDMA_CHAN_SLOT(lch);
 
-   if (!callback)
-   edma_shadow0_write_array(ecc, SH_IECR, lch >> 5,
-BIT(lch & 0x1f));
-
-   ecc->intr_data[lch].callback = callback;
-   ecc->intr_data[lch].data = data;
-
-   if (callback) {
+   if (enable) {
edma_shadow0_write_array(ecc, SH_ICR, lch >> 5,
 BIT(lch & 0x1f));
edma_shadow0_write_array(ecc, SH_IESR, lch >> 5,
 BIT(lch & 0x1f));
+   } else {
+   edma_shadow0_write_array(ecc, SH_IECR, lch >> 5,
+BIT(lch & 0x1f));
}
 }
 
@@ -795,8 +777,6 @@ static void edma_clean_channel(struct edma_cc *ecc, 
unsigned channel)
  * edma_alloc_channel - allocate DMA channel and paired parameter RAM
  * @ecc: pointer to edma_cc struct
  * @channel: specific channel to allocate; negative for "any unmapped channel"
- * @callback: optional; to be issued on DMA completion or errors
- * @data: passed to callback
  * @eventq_no: an EVENTQ_* constant, used to choose which Transfer
  * Controller (TC) executes requests using this channel.  Use
  * EVENTQ_DEFAULT unless you really need a high priority queue.
@@ -823,9 +803,7 @@ static void edma_clean_channel(struct edma_cc *ecc, 
unsigned channel)
  * Returns the number of the channel, else negative errno.
  */
 static int edma_alloc_channel(struct edma_cc *ecc, int channel,
-   void (*callback)(unsigned channel, u16 ch_status, void *data),
-   void *data,
-   enum dma_event_q eventq_no)
+ enum dma_event_q eventq_no)
 {
unsigned done = 0;
int ret = 0;
@@ -881,9 +859,7 @@ static int edma_alloc_channel(struct edma_cc *ecc, int 
channel,
edma_stop(ecc, EDMA_CTLR_CHAN(ecc->id, channel));
edma_write_slot(ecc, channel, _paramset);
 
-   if (callback)
-   edma_setup_interrupt(ecc, EDMA_CTLR_CHAN(ecc->id, channel),
-callback, data);
+   edma_setup_interrupt(ecc, EDMA_CTLR_CHAN(ecc->id, channel), true);
 
edma_map_dmach_to_queue(ecc, channel, eventq_no);
 
@@ -914,7 +890,7 @@ static void edma_free_channel(struct edma_cc *ecc, unsigned 
channel)
if (channel >= ecc->num_channels)
return;
 
-   edma_setup_interrupt(ecc, channel, NULL, NULL);
+   edma_setup_interrupt(ecc, channel, false);
/* REVISIT should probably take out of shadow region 0 */
 
edma_write_slot(ecc, channel, _paramset);
@@ -944,148 +920,6 @@ static void edma_assign_channel_eventq(struct edma_cc 
*ecc, unsigned channel,
edma_map_dmach_to_queue(ecc, channel, eventq_no);
 }
 
-/* eDMA interrupt handler */
-static irqreturn_t dma_irq_handler(int irq, void *data)
-{
-   struct edma_cc *ecc = data;
-   int ctlr;
-   u32 sh_ier;
-   u32 sh_ipr;
-   u32 bank;
-
-   ctlr = ecc->id;
-   if (ctlr < 0)
-   return IRQ_NONE;
-
-   dev_dbg(ecc->dev, "dma_irq_handler\n");
-
-   sh_ipr = edma_shadow0_read_array(ecc, SH_IPR, 0);
-   if (!sh_ipr) {
-   sh_ipr = 

[PATCH v5 22/24] dmaengine: edma: Read channel mapping support only once from HW

[Peter Ujfalusi]

Instead of directly reading it from CCCFG register take the information out
once when we set up the configuration from the HW.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index d105d1ae0f13..4b2ccc9de0ad 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -223,6 +223,7 @@ struct edma_cc {
unsignednum_region;
unsignednum_slots;
unsignednum_tc;
+   boolchmap_exist;
enum dma_event_qdefault_queue;
 
boolunused_chan_list_done;
@@ -1930,11 +1931,14 @@ static int edma_setup_from_hw(struct device *dev, 
struct edma_soc_info *pdata,
value = GET_NUM_EVQUE(cccfg);
ecc->num_tc = value + 1;
 
+   ecc->chmap_exist = (cccfg & CHMAP_EXIST) ? true : false;
+
dev_dbg(dev, "eDMA3 CC HW configuration (cccfg: 0x%08x):\n", cccfg);
dev_dbg(dev, "num_region: %u\n", ecc->num_region);
dev_dbg(dev, "num_channels: %u\n", ecc->num_channels);
dev_dbg(dev, "num_slots: %u\n", ecc->num_slots);
dev_dbg(dev, "num_tc: %u\n", ecc->num_tc);
+   dev_dbg(dev, "chmap_exist: %s\n", ecc->chmap_exist ? "yes" : "no");
 
/* Nothing need to be done if queue priority is provided */
if (pdata->queue_priority_mapping)
@@ -2223,7 +2227,7 @@ static int edma_probe(struct platform_device *pdev)
  queue_priority_mapping[i][1]);
 
/* Map the channel to param entry if channel mapping logic exist */
-   if (edma_read(ecc, EDMA_CCCFG) & CHMAP_EXIST)
+   if (ecc->chmap_exist)
edma_direct_dmach_to_param_mapping(ecc);
 
for (i = 0; i < ecc->num_region; i++) {
@@ -2293,7 +2297,7 @@ static int edma_pm_resume(struct device *dev)
  queue_priority_mapping[i][1]);
 
/* Map the channel to param entry if channel mapping logic */
-   if (edma_read(ecc, EDMA_CCCFG) & CHMAP_EXIST)
+   if (ecc->chmap_exist)
edma_direct_dmach_to_param_mapping(ecc);
 
for (i = 0; i < ecc->num_channels; i++) {
-- 
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 2/2] ARM: dts: omap3: keep ssi ports by default

[Roger Quadros]

On 14/10/15 14:37, Sebastian Reichel wrote:
> Hi,
> 
> On Wed, Oct 14, 2015 at 02:27:27PM +0300, Roger Quadros wrote:
>> On 14/10/15 14:19, Sebastian Reichel wrote:
>>> On Wed, Oct 14, 2015 at 01:44:16PM +0300, Roger Quadros wrote:
 Let's keep the SSI ports disabled in the omap3.dtsi to avoid
 getting the following noise on the console for boards that don't
 use the SSI ports.

 "omap_ssi_port 4805a000.ssi-port: DT data is missing cawake gpio (err=-2)"

 As omap3-n900 uses one SSI port, mark it enabled there.
>>
>> Would it be preferable to disable the ssi-controller node as well in the
>> omap3.dtsi file?
> 
> If I remember it correctly, existing, but unused IP-Cores
> should not be disabled in DT, so that hwmod picks them up
> for power management.

OK.
> 
> Note, that it actually is disabled in omap3.dtsi and then enabled in
> omap34xx/omap36xx dts files (the other variants do not have an ssi
> module).

Thanks for the info :)

cheers,
-roger



signature.asc
Description: OpenPGP digital signature

Re: [REPOST PATCH 0/2] DRA7 DSP MMU config support

[Joerg Roedel]

On Fri, Oct 02, 2015 at 06:02:42PM -0500, Suman Anna wrote:
> Suman Anna (2):
>   Documentation: dt: Update OMAP iommu bindings for DRA7 DSPs
>   iommu/omap: Add support for configuring dsp iommus on DRA7xx
> 
>  .../devicetree/bindings/iommu/ti,omap-iommu.txt| 27 ++
>  drivers/iommu/omap-iommu.c | 58 
> ++
>  drivers/iommu/omap-iommu.h |  9 
>  3 files changed, 94 insertions(+)

Applied, thanks.

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

[Roger Quadros]

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

>   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

[PATCH v5 21/24] dmaengine: edma: Simplify and optimize ccerr interrupt handler

[Peter Ujfalusi]

No need to run through the bits in QEMR and CCERR events since they will
not trigger any action, so just clearing the errors there is fine.
In case of the missed event the loop can be optimized so we spend less time
to handle the event.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 82 +++---
 1 file changed, 35 insertions(+), 47 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 84b98a01993a..d105d1ae0f13 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1640,9 +1640,10 @@ static inline bool edma_error_pending(struct edma_cc 
*ecc)
 static irqreturn_t dma_ccerr_handler(int irq, void *data)
 {
struct edma_cc *ecc = data;
-   int i;
+   int i, j;
int ctlr;
unsigned int cnt = 0;
+   unsigned int val;
 
ctlr = ecc->id;
if (ctlr < 0)
@@ -1654,57 +1655,44 @@ static irqreturn_t dma_ccerr_handler(int irq, void 
*data)
return IRQ_NONE;
 
while (1) {
-   int j = -1;
-
-   if (edma_read_array(ecc, EDMA_EMR, 0))
-   j = 0;
-   else if (edma_read_array(ecc, EDMA_EMR, 1))
-   j = 1;
-   if (j >= 0) {
-   dev_dbg(ecc->dev, "EMR%d %08x\n", j,
-   edma_read_array(ecc, EDMA_EMR, j));
-   for (i = 0; i < 32; i++) {
+   /* Event missed register(s) */
+   for (j = 0; j < 2; j++) {
+   unsigned long emr;
+
+   val = edma_read_array(ecc, EDMA_EMR, j);
+   if (!val)
+   continue;
+
+   dev_dbg(ecc->dev, "EMR%d 0x%08x\n", j, val);
+   emr = val;
+   for (i = find_next_bit(, 32, 0); i < 32;
+i = find_next_bit(, 32, i + 1)) {
int k = (j << 5) + i;
 
-   if (edma_read_array(ecc, EDMA_EMR, j) &
-   BIT(i)) {
-   /* Clear the corresponding EMR bits */
-   edma_write_array(ecc, EDMA_EMCR, j,
+   /* Clear the corresponding EMR bits */
+   edma_write_array(ecc, EDMA_EMCR, j, BIT(i));
+   /* Clear any SER */
+   edma_shadow0_write_array(ecc, SH_SECR, j,
 BIT(i));
-   /* Clear any SER */
-   edma_shadow0_write_array(ecc, SH_SECR,
-j, BIT(i));
-   
edma_error_handler(>slave_chans[k]);
-   }
-   }
-   } else if (edma_read(ecc, EDMA_QEMR)) {
-   dev_dbg(ecc->dev, "QEMR %02x\n",
-   edma_read(ecc, EDMA_QEMR));
-   for (i = 0; i < 8; i++) {
-   if (edma_read(ecc, EDMA_QEMR) & BIT(i)) {
-   /* Clear the corresponding IPR bits */
-   edma_write(ecc, EDMA_QEMCR, BIT(i));
-   edma_shadow0_write(ecc, SH_QSECR,
-  BIT(i));
-
-   /* NOTE:  not reported!! */
-   }
-   }
-   } else if (edma_read(ecc, EDMA_CCERR)) {
-   dev_dbg(ecc->dev, "CCERR %08x\n",
-   edma_read(ecc, EDMA_CCERR));
-   /* FIXME:  CCERR.BIT(16) ignored!  much better
-* to just write CCERRCLR with CCERR value...
-*/
-   for (i = 0; i < 8; i++) {
-   if (edma_read(ecc, EDMA_CCERR) & BIT(i)) {
-   /* Clear the corresponding IPR bits */
-   edma_write(ecc, EDMA_CCERRCLR, BIT(i));
-
-   /* NOTE:  not reported!! */
-   }
+   edma_error_handler(>slave_chans[k]);
}
}
+
+   val = edma_read(ecc, EDMA_QEMR);
+   if (val) {
+   dev_dbg(ecc->dev, "QEMR 0x%02x\n", val);
+   /* Not reported, just clear the interrupt reason. */
+   edma_write(ecc, EDMA_QEMCR, val);
+   edma_shadow0_write(ecc, SH_QSECR, val);
+   }
+
+   val = edma_read(ecc, EDMA_CCERR);
+ 

[PATCH v5 10/24] ARM: davinci: Add dma_mask to eDMA devices

[Peter Ujfalusi]

The upcoming change to merge the arch/arm/common/edma.c into
drivers/dma/edma.c will need this change when booting daVinci devices in
no DT mode.

Signed-off-by: Peter Ujfalusi 
Acked-by: Sekhar Nori 
---
 arch/arm/mach-davinci/devices-da8xx.c | 2 ++
 arch/arm/mach-davinci/dm355.c | 1 +
 arch/arm/mach-davinci/dm644x.c| 1 +
 arch/arm/mach-davinci/dm646x.c| 1 +
 4 files changed, 5 insertions(+)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c 
b/arch/arm/mach-davinci/devices-da8xx.c
index 9f7d266faa0c..28c90bc372bd 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -216,6 +216,7 @@ static struct resource da850_edma1_resources[] = {
 static const struct platform_device_info da8xx_edma0_device __initconst = {
.name   = "edma",
.id = 0,
+   .dma_mask   = DMA_BIT_MASK(32),
.res= da8xx_edma0_resources,
.num_res= ARRAY_SIZE(da8xx_edma0_resources),
.data   = _edma0_pdata,
@@ -225,6 +226,7 @@ static const struct platform_device_info da8xx_edma0_device 
__initconst = {
 static const struct platform_device_info da850_edma1_device __initconst = {
.name   = "edma",
.id = 1,
+   .dma_mask   = DMA_BIT_MASK(32),
.res= da850_edma1_resources,
.num_res= ARRAY_SIZE(da850_edma1_resources),
.data   = _edma1_pdata,
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 5f10c6695e31..609950b8c191 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -616,6 +616,7 @@ static struct resource edma_resources[] = {
 static const struct platform_device_info dm355_edma_device __initconst = {
.name   = "edma",
.id = 0,
+   .dma_mask   = DMA_BIT_MASK(32),
.res= edma_resources,
.num_res= ARRAY_SIZE(edma_resources),
.data   = _edma_pdata,
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index aa3453b40d5f..d38f5049d56e 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -545,6 +545,7 @@ static struct resource edma_resources[] = {
 static const struct platform_device_info dm644x_edma_device __initconst = {
.name   = "edma",
.id = 0,
+   .dma_mask   = DMA_BIT_MASK(32),
.res= edma_resources,
.num_res= ARRAY_SIZE(edma_resources),
.data   = _edma_pdata,
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 79c1d8917dd3..70eb42725eec 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -592,6 +592,7 @@ static struct resource edma_resources[] = {
 static const struct platform_device_info dm646x_edma_device __initconst = {
.name   = "edma",
.id = 0,
+   .dma_mask   = DMA_BIT_MASK(32),
.res= edma_resources,
.num_res= ARRAY_SIZE(edma_resources),
.data   = _edma_pdata,
-- 
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 v5 09/24] ARM: davinci: Use platform_device_register_full() to create pdev for eDMA

[Peter Ujfalusi]

Convert the eDMA platform device creation to use
struct platform_device_info XX __initconst and
platform_device_register_full()
This will allow us to cleanly specify the dma_mask for the devices in an
upcoming patch.

Signed-off-by: Peter Ujfalusi 
Acked-by: Sekhar Nori 
---
 arch/arm/mach-davinci/devices-da8xx.c | 38 ++-
 arch/arm/mach-davinci/dm355.c | 20 +++---
 arch/arm/mach-davinci/dm644x.c| 20 +++---
 arch/arm/mach-davinci/dm646x.c| 18 ++---
 4 files changed, 57 insertions(+), 39 deletions(-)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c 
b/arch/arm/mach-davinci/devices-da8xx.c
index 9ae049ae816a..9f7d266faa0c 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -213,48 +213,50 @@ static struct resource da850_edma1_resources[] = {
},
 };
 
-static struct platform_device da8xx_edma0_device = {
+static const struct platform_device_info da8xx_edma0_device __initconst = {
.name   = "edma",
.id = 0,
-   .dev = {
-   .platform_data = _edma0_pdata,
-   },
-   .num_resources  = ARRAY_SIZE(da8xx_edma0_resources),
-   .resource   = da8xx_edma0_resources,
+   .res= da8xx_edma0_resources,
+   .num_res= ARRAY_SIZE(da8xx_edma0_resources),
+   .data   = _edma0_pdata,
+   .size_data  = sizeof(da8xx_edma0_pdata),
 };
 
-static struct platform_device da850_edma1_device = {
+static const struct platform_device_info da850_edma1_device __initconst = {
.name   = "edma",
.id = 1,
-   .dev = {
-   .platform_data = _edma1_pdata,
-   },
-   .num_resources  = ARRAY_SIZE(da850_edma1_resources),
-   .resource   = da850_edma1_resources,
+   .res= da850_edma1_resources,
+   .num_res= ARRAY_SIZE(da850_edma1_resources),
+   .data   = _edma1_pdata,
+   .size_data  = sizeof(da850_edma1_pdata),
 };
 
 int __init da830_register_edma(struct edma_rsv_info *rsv)
 {
+   struct platform_device *edma_pdev;
+
da8xx_edma0_pdata.rsv = rsv;
 
-   return platform_device_register(_edma0_device);
+   edma_pdev = platform_device_register_full(_edma0_device);
+   return IS_ERR(edma_pdev) ? PTR_ERR(edma_pdev) : 0;
 }
 
 int __init da850_register_edma(struct edma_rsv_info *rsv[2])
 {
-   int ret;
+   struct platform_device *edma_pdev;
 
if (rsv) {
da8xx_edma0_pdata.rsv = rsv[0];
da850_edma1_pdata.rsv = rsv[1];
}
 
-   ret = platform_device_register(_edma0_device);
-   if (ret) {
+   edma_pdev = platform_device_register_full(_edma0_device);
+   if (IS_ERR(edma_pdev)) {
pr_warn("%s: Failed to register eDMA0\n", __func__);
-   return ret;
+   return PTR_ERR(edma_pdev);
}
-   return platform_device_register(_edma1_device);
+   edma_pdev = platform_device_register_full(_edma1_device);
+   return IS_ERR(edma_pdev) ? PTR_ERR(edma_pdev) : 0;
 }
 
 static struct resource da8xx_i2c_resources0[] = {
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index a50bb9c66952..5f10c6695e31 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -613,12 +613,13 @@ static struct resource edma_resources[] = {
/* not using (or muxing) TC*_ERR */
 };
 
-static struct platform_device dm355_edma_device = {
-   .name   = "edma",
-   .id = 0,
-   .dev.platform_data  = _edma_pdata,
-   .num_resources  = ARRAY_SIZE(edma_resources),
-   .resource   = edma_resources,
+static const struct platform_device_info dm355_edma_device __initconst = {
+   .name   = "edma",
+   .id = 0,
+   .res= edma_resources,
+   .num_res= ARRAY_SIZE(edma_resources),
+   .data   = _edma_pdata,
+   .size_data  = sizeof(dm355_edma_pdata),
 };
 
 static struct resource dm355_asp1_resources[] = {
@@ -1057,13 +1058,18 @@ int __init dm355_init_video(struct vpfe_config 
*vpfe_cfg,
 
 static int __init dm355_init_devices(void)
 {
+   struct platform_device *edma_pdev;
int ret = 0;
 
if (!cpu_is_davinci_dm355())
return 0;
 
davinci_cfg_reg(DM355_INT_EDMA_CC);
-   platform_device_register(_edma_device);
+   edma_pdev = platform_device_register_full(_edma_device);
+   if (IS_ERR(edma_pdev)) {
+   pr_warn("%s: Failed to register eDMA\n", __func__);
+   return PTR_ERR(edma_pdev);
+   }
 
ret = davinci_init_wdt();
if (ret)
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index d759ca8e58e8..aa3453b40d5f 100644
--- 

[PATCH v5 03/24] dmaengine: edma: Simplify and optimize the edma_execute path

[Peter Ujfalusi]

The code path in edma_execute() and edma_callback() can be simplified
and make it more optimal.
There is not need to call in to edma_execute() when the transfer
has been finished for example.
Also the handling of missed/first or next batch of paRAMs can
be done in a more optimal way.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 76 +-
 1 file changed, 29 insertions(+), 47 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 558b0b4e7536..19fa49d6f555 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -154,15 +154,11 @@ static void edma_execute(struct edma_chan *echan)
struct device *dev = echan->vchan.chan.device->dev;
int i, j, left, nslots;
 
-   /* If either we processed all psets or we're still not started */
-   if (!echan->edesc ||
-   echan->edesc->pset_nr == echan->edesc->processed) {
-   /* Get next vdesc */
+   if (!echan->edesc) {
+   /* Setup is needed for the first transfer */
vdesc = vchan_next_desc(>vchan);
-   if (!vdesc) {
-   echan->edesc = NULL;
+   if (!vdesc)
return;
-   }
list_del(>node);
echan->edesc = to_edma_desc(>tx);
}
@@ -220,28 +216,26 @@ static void edma_execute(struct edma_chan *echan)
  echan->ecc->dummy_slot);
}
 
-   if (edesc->processed <= MAX_NR_SG) {
-   dev_dbg(dev, "first transfer starting on channel %d\n",
-   echan->ch_num);
-   edma_start(echan->ch_num);
-   } else {
-   dev_dbg(dev, "chan: %d: completed %d elements, resuming\n",
-   echan->ch_num, edesc->processed);
-   edma_resume(echan->ch_num);
-   }
-
-   /*
-* This happens due to setup times between intermediate transfers
-* in long SG lists which have to be broken up into transfers of
-* MAX_NR_SG
-*/
if (echan->missed) {
+   /*
+* This happens due to setup times between intermediate
+* transfers in long SG lists which have to be broken up into
+* transfers of MAX_NR_SG
+*/
dev_dbg(dev, "missed event on channel %d\n", echan->ch_num);
edma_clean_channel(echan->ch_num);
edma_stop(echan->ch_num);
edma_start(echan->ch_num);
edma_trigger_channel(echan->ch_num);
echan->missed = 0;
+   } else if (edesc->processed <= MAX_NR_SG) {
+   dev_dbg(dev, "first transfer starting on channel %d\n",
+   echan->ch_num);
+   edma_start(echan->ch_num);
+   } else {
+   dev_dbg(dev, "chan: %d: completed %d elements, resuming\n",
+   echan->ch_num, edesc->processed);
+   edma_resume(echan->ch_num);
}
 }
 
@@ -259,20 +253,17 @@ static int edma_terminate_all(struct dma_chan *chan)
 * echan->edesc is NULL and exit.)
 */
if (echan->edesc) {
-   int cyclic = echan->edesc->cyclic;
-
+   edma_stop(echan->ch_num);
+   /* Move the cyclic channel back to default queue */
+   if (echan->edesc->cyclic)
+   edma_assign_channel_eventq(echan->ch_num,
+  EVENTQ_DEFAULT);
/*
 * free the running request descriptor
 * since it is not in any of the vdesc lists
 */
edma_desc_free(>edesc->vdesc);
-
echan->edesc = NULL;
-   edma_stop(echan->ch_num);
-   /* Move the cyclic channel back to default queue */
-   if (cyclic)
-   edma_assign_channel_eventq(echan->ch_num,
-  EVENTQ_DEFAULT);
}
 
vchan_get_all_descriptors(>vchan, );
@@ -725,41 +716,33 @@ static void edma_callback(unsigned ch_num, u16 ch_status, 
void *data)
 
edesc = echan->edesc;
 
-   /* Pause the channel for non-cyclic */
-   if (!edesc || !edesc->cyclic)
-   edma_pause(echan->ch_num);
-
+   spin_lock(>vchan.lock);
switch (ch_status) {
case EDMA_DMA_COMPLETE:
-   spin_lock(>vchan.lock);
-
if (edesc) {
if (edesc->cyclic) {
vchan_cyclic_callback(>vdesc);
+   goto out;
} else if (edesc->processed == edesc->pset_nr) {
dev_dbg(dev, "Transfer complete, stopping 
channel %d\n", ch_num);
edesc->residue = 0;

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

[Roger Quadros]

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 
> ---
>  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-names DMA 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"

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?

>   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 v5 08/24] ARM/dmaengine: edma: Remove limitation on the number of eDMA controllers

[Peter Ujfalusi]

Since the driver stack no longer depends on lookup with id number in a
global array of pointers, the limitation for the number of eDMAs are no
longer needed. We can handle as many eDMAs in legacy and DT boot as we have
memory for them to allocate the needed structures.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/common/edma.c | 22 +-
 drivers/dma/edma.c | 17 -
 2 files changed, 13 insertions(+), 26 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 03692520812a..5b747f1bc8b5 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1227,24 +1227,7 @@ static int edma_probe(struct platform_device *pdev)
.parent = >dev,
};
 
-   /* When booting with DT the pdev->id is -1 */
-   if (dev_id < 0)
-   dev_id = arch_num_cc;
-
-   if (dev_id >= EDMA_MAX_CC) {
-   dev_err(dev,
-   "eDMA3 with device id 0 and 1 is supported (id: %d)\n",
-   dev_id);
-   return -EINVAL;
-   }
-
if (node) {
-   /* Check if this is a second instance registered */
-   if (arch_num_cc) {
-   dev_err(dev, "only one EDMA instance is supported via 
DT\n");
-   return -ENODEV;
-   }
-
info = edma_setup_info_from_dt(dev, node);
if (IS_ERR(info)) {
dev_err(dev, "failed to get DT data\n");
@@ -1278,6 +1261,11 @@ static int edma_probe(struct platform_device *pdev)
 
cc->dev = dev;
cc->id = dev_id;
+   /* When booting with DT the pdev->id is -1 */
+   if (dev_id < 0) {
+   cc->id = 0;
+   dev_id = arch_num_cc;
+   }
dev_set_drvdata(dev, cc);
 
cc->base = devm_ioremap_resource(dev, mem);
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 53d48b2a700d..fc91ab9dd1bb 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -991,14 +991,12 @@ static void edma_dma_init(struct edma_cc *ecc, struct 
dma_device *dma,
INIT_LIST_HEAD(>channels);
 }
 
-static struct of_dma_filter_info edma_filter_info = {
-   .filter_fn = edma_filter_fn,
-};
-
 static int edma_probe(struct platform_device *pdev)
 {
struct edma_cc *ecc;
struct device_node *parent_node = pdev->dev.parent->of_node;
+   struct platform_device *parent_pdev =
+   to_platform_device(pdev->dev.parent);
int ret;
 
ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
@@ -1015,7 +1013,10 @@ static int edma_probe(struct platform_device *pdev)
if (!ecc->cc)
return -ENODEV;
 
-   ecc->ctlr = pdev->id;
+   ecc->ctlr = parent_pdev->id;
+   if (ecc->ctlr < 0)
+   ecc->ctlr = 0;
+
ecc->dummy_slot = edma_alloc_slot(ecc->cc, EDMA_SLOT_ANY);
if (ecc->dummy_slot < 0) {
dev_err(>dev, "Can't allocate PaRAM dummy slot\n");
@@ -1038,10 +1039,8 @@ static int edma_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ecc);
 
if (parent_node) {
-   dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap);
-   dma_cap_set(DMA_CYCLIC, edma_filter_info.dma_cap);
-   of_dma_controller_register(parent_node, of_dma_simple_xlate,
-  _filter_info);
+   of_dma_controller_register(parent_node, of_dma_xlate_by_chan_id,
+  >dma_slave);
}
 
dev_info(>dev, "TI EDMA DMA engine driver\n");
-- 
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 v5 04/24] ARM: davinci/common: Convert edma driver to handle one eDMA instance per driver

[Peter Ujfalusi]

Currently we have one device created to handle all (maximum 2) eDMAs in the
system.
With this change all eDMA instance will have it's own device/driver.
This change is needed for further cleanups in the eDMA driver stack since
the one device/driver to handle all eDMAs in the system was not flexible
enough and prevents the upcoming work.

Signed-off-by: Peter Ujfalusi 
Acked-by: Sekhar Nori 
---
 arch/arm/common/edma.c| 356 +++---
 arch/arm/mach-davinci/devices-da8xx.c | 110 ---
 arch/arm/mach-davinci/dm355.c |  21 +-
 arch/arm/mach-davinci/dm365.c |  25 +--
 arch/arm/mach-davinci/dm644x.c|  21 +-
 arch/arm/mach-davinci/dm646x.c|  27 ++-
 6 files changed, 234 insertions(+), 326 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index e9c4cb16a47e..7c2fe527e53b 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -235,6 +235,7 @@ static inline void clear_bits(int offset, int len, unsigned 
long *p)
 
 /* actual number of DMA channels and slots on this silicon */
 struct edma {
+   struct device   *dev;
/* how many dma resources of each type */
unsignednum_channels;
unsignednum_region;
@@ -246,6 +247,7 @@ struct edma {
const s8*noevent;
 
struct edma_soc_info *info;
+   int id;
 
/* The edma_inuse bit for each PaRAM slot is clear unless the
 * channel is in use ... by ARM or DSP, for QDMA, or whatever.
@@ -258,9 +260,6 @@ struct edma {
 */
DECLARE_BITMAP(edma_unused, EDMA_MAX_DMACH);
 
-   unsignedirq_res_start;
-   unsignedirq_res_end;
-
struct dma_interrupt_data {
void (*callback)(unsigned channel, unsigned short ch_status,
void *data);
@@ -349,17 +348,6 @@ setup_dma_interrupt(unsigned lch,
}
 }
 
-static int irq2ctlr(int irq)
-{
-   if (irq >= edma_cc[0]->irq_res_start && irq <= edma_cc[0]->irq_res_end)
-   return 0;
-   else if (irq >= edma_cc[1]->irq_res_start &&
-   irq <= edma_cc[1]->irq_res_end)
-   return 1;
-
-   return -1;
-}
-
 /**
  *
  * DMA interrupt handler
@@ -367,16 +355,17 @@ static int irq2ctlr(int irq)
  */
 static irqreturn_t dma_irq_handler(int irq, void *data)
 {
+   struct edma *cc = data;
int ctlr;
u32 sh_ier;
u32 sh_ipr;
u32 bank;
 
-   ctlr = irq2ctlr(irq);
+   ctlr = cc->id;
if (ctlr < 0)
return IRQ_NONE;
 
-   dev_dbg(data, "dma_irq_handler\n");
+   dev_dbg(cc->dev, "dma_irq_handler\n");
 
sh_ipr = edma_shadow0_read_array(ctlr, SH_IPR, 0);
if (!sh_ipr) {
@@ -394,7 +383,7 @@ static irqreturn_t dma_irq_handler(int irq, void *data)
u32 slot;
u32 channel;
 
-   dev_dbg(data, "IPR%d %08x\n", bank, sh_ipr);
+   dev_dbg(cc->dev, "IPR%d %08x\n", bank, sh_ipr);
 
slot = __ffs(sh_ipr);
sh_ipr &= ~(BIT(slot));
@@ -404,11 +393,11 @@ static irqreturn_t dma_irq_handler(int irq, void *data)
/* Clear the corresponding IPR bits */
edma_shadow0_write_array(ctlr, SH_ICR, bank,
BIT(slot));
-   if (edma_cc[ctlr]->intr_data[channel].callback)
-   edma_cc[ctlr]->intr_data[channel].callback(
+   if (cc->intr_data[channel].callback)
+   cc->intr_data[channel].callback(
EDMA_CTLR_CHAN(ctlr, channel),
EDMA_DMA_COMPLETE,
-   edma_cc[ctlr]->intr_data[channel].data);
+   cc->intr_data[channel].data);
}
} while (sh_ipr);
 
@@ -423,15 +412,16 @@ static irqreturn_t dma_irq_handler(int irq, void *data)
  */
 static irqreturn_t dma_ccerr_handler(int irq, void *data)
 {
+   struct edma *cc = data;
int i;
int ctlr;
unsigned int cnt = 0;
 
-   ctlr = irq2ctlr(irq);
+   ctlr = cc->id;
if (ctlr < 0)
return IRQ_NONE;
 
-   dev_dbg(data, "dma_ccerr_handler\n");
+   dev_dbg(cc->dev, "dma_ccerr_handler\n");
 
if ((edma_read_array(ctlr, EDMA_EMR, 0) == 0) &&
(edma_read_array(ctlr, EDMA_EMR, 1) == 0) &&
@@ -446,8 +436,8 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
else if (edma_read_array(ctlr, EDMA_EMR, 1))
j = 1;
 

[PATCH v5 05/24] ARM/dmaengine: edma: Move of_dma_controller_register to the dmaengine driver

[Peter Ujfalusi]

If the of_dma_controller is registered in the non dmaengine driver we could
have race condition:
the of_dma_controller has been registered, but the dmaengine driver is not
yet probed. Drivers requesting DMA channels during this window will fail
since we do not yet have dmaengine drivers registered.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/common/edma.c | 10 --
 drivers/dma/edma.c | 16 
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 7c2fe527e53b..d82fceda13a3 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -29,7 +29,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -1191,10 +1190,6 @@ static int edma_of_parse_dt(struct device *dev,
return ret;
 }
 
-static struct of_dma_filter_info edma_filter_info = {
-   .filter_fn = edma_filter_fn,
-};
-
 static struct edma_soc_info *edma_setup_info_from_dt(struct device *dev,
  struct device_node *node)
 {
@@ -1209,11 +1204,6 @@ static struct edma_soc_info 
*edma_setup_info_from_dt(struct device *dev,
if (ret)
return ERR_PTR(ret);
 
-   dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap);
-   dma_cap_set(DMA_CYCLIC, edma_filter_info.dma_cap);
-   of_dma_controller_register(dev->of_node, of_dma_simple_xlate,
-  _filter_info);
-
return info;
 }
 #else
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 19fa49d6f555..fcb4680efed7 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -987,9 +988,14 @@ static void edma_dma_init(struct edma_cc *ecc, struct 
dma_device *dma,
INIT_LIST_HEAD(>channels);
 }
 
+static struct of_dma_filter_info edma_filter_info = {
+   .filter_fn = edma_filter_fn,
+};
+
 static int edma_probe(struct platform_device *pdev)
 {
struct edma_cc *ecc;
+   struct device_node *parent_node = pdev->dev.parent->of_node;
int ret;
 
ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
@@ -1024,6 +1030,13 @@ static int edma_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, ecc);
 
+   if (parent_node) {
+   dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap);
+   dma_cap_set(DMA_CYCLIC, edma_filter_info.dma_cap);
+   of_dma_controller_register(parent_node, of_dma_simple_xlate,
+  _filter_info);
+   }
+
dev_info(>dev, "TI EDMA DMA engine driver\n");
 
return 0;
@@ -1037,7 +1050,10 @@ static int edma_remove(struct platform_device *pdev)
 {
struct device *dev = >dev;
struct edma_cc *ecc = dev_get_drvdata(dev);
+   struct device_node *parent_node = pdev->dev.parent->of_node;
 
+   if (parent_node)
+   of_dma_controller_free(parent_node);
dma_async_device_unregister(>dma_slave);
edma_free_slot(ecc->dummy_slot);
 
-- 
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 v5 02/24] ARM: common: edma: Remove unused functions

[Peter Ujfalusi]

We no longer have users for these functions so they can be removed.
Remove also unused enums from the header file.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/common/edma.c | 376 -
 include/linux/platform_data/edma.h |  33 
 2 files changed, 409 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 56fc339571f9..e9c4cb16a47e 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -510,62 +510,6 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
return IRQ_HANDLED;
 }
 
-static int reserve_contiguous_slots(int ctlr, unsigned int id,
-unsigned int num_slots,
-unsigned int start_slot)
-{
-   int i, j;
-   unsigned int count = num_slots;
-   int stop_slot = start_slot;
-   DECLARE_BITMAP(tmp_inuse, EDMA_MAX_PARAMENTRY);
-
-   for (i = start_slot; i < edma_cc[ctlr]->num_slots; ++i) {
-   j = EDMA_CHAN_SLOT(i);
-   if (!test_and_set_bit(j, edma_cc[ctlr]->edma_inuse)) {
-   /* Record our current beginning slot */
-   if (count == num_slots)
-   stop_slot = i;
-
-   count--;
-   set_bit(j, tmp_inuse);
-
-   if (count == 0)
-   break;
-   } else {
-   clear_bit(j, tmp_inuse);
-
-   if (id == EDMA_CONT_PARAMS_FIXED_EXACT) {
-   stop_slot = i;
-   break;
-   } else {
-   count = num_slots;
-   }
-   }
-   }
-
-   /*
-* We have to clear any bits that we set
-* if we run out parameter RAM slots, i.e we do find a set
-* of contiguous parameter RAM slots but do not find the exact number
-* requested as we may reach the total number of parameter RAM slots
-*/
-   if (i == edma_cc[ctlr]->num_slots)
-   stop_slot = i;
-
-   j = start_slot;
-   for_each_set_bit_from(j, tmp_inuse, stop_slot)
-   clear_bit(j, edma_cc[ctlr]->edma_inuse);
-
-   if (count)
-   return -EBUSY;
-
-   for (j = i - num_slots + 1; j <= i; ++j)
-   memcpy_toio(edmacc_regs_base[ctlr] + PARM_OFFSET(j),
-   _paramset, PARM_SIZE);
-
-   return EDMA_CTLR_CHAN(ctlr, i - num_slots + 1);
-}
-
 static int prepare_unused_channel_list(struct device *dev, void *data)
 {
struct platform_device *pdev = to_platform_device(dev);
@@ -818,186 +762,11 @@ void edma_free_slot(unsigned slot)
 }
 EXPORT_SYMBOL(edma_free_slot);
 
-
-/**
- * edma_alloc_cont_slots- alloc contiguous parameter RAM slots
- * The API will return the starting point of a set of
- * contiguous parameter RAM slots that have been requested
- *
- * @id: can only be EDMA_CONT_PARAMS_ANY or EDMA_CONT_PARAMS_FIXED_EXACT
- * or EDMA_CONT_PARAMS_FIXED_NOT_EXACT
- * @count: number of contiguous Paramter RAM slots
- * @slot  - the start value of Parameter RAM slot that should be passed if id
- * is EDMA_CONT_PARAMS_FIXED_EXACT or EDMA_CONT_PARAMS_FIXED_NOT_EXACT
- *
- * If id is EDMA_CONT_PARAMS_ANY then the API starts looking for a set of
- * contiguous Parameter RAM slots from parameter RAM 64 in the case of
- * DaVinci SOCs and 32 in the case of DA8xx SOCs.
- *
- * If id is EDMA_CONT_PARAMS_FIXED_EXACT then the API starts looking for a
- * set of contiguous parameter RAM slots from the "slot" that is passed as an
- * argument to the API.
- *
- * If id is EDMA_CONT_PARAMS_FIXED_NOT_EXACT then the API initially tries
- * starts looking for a set of contiguous parameter RAMs from the "slot"
- * that is passed as an argument to the API. On failure the API will try to
- * find a set of contiguous Parameter RAM slots from the remaining Parameter
- * RAM slots
- */
-int edma_alloc_cont_slots(unsigned ctlr, unsigned int id, int slot, int count)
-{
-   /*
-* The start slot requested should be greater than
-* the number of channels and lesser than the total number
-* of slots
-*/
-   if ((id != EDMA_CONT_PARAMS_ANY) &&
-   (slot < edma_cc[ctlr]->num_channels ||
-   slot >= edma_cc[ctlr]->num_slots))
-   return -EINVAL;
-
-   /*
-* The number of parameter RAM slots requested cannot be less than 1
-* and cannot be more than the number of slots minus the number of
-* channels
-*/
-   if (count < 1 || count >
-   (edma_cc[ctlr]->num_slots - edma_cc[ctlr]->num_channels))
-   return -EINVAL;
-
-   switch (id) {
-   case EDMA_CONT_PARAMS_ANY:
-   return reserve_contiguous_slots(ctlr, id, count,
-  

[PATCH v5 16/24] dmaengine: edma: Use the edma_write_slot instead open coded memcpy_toio

[Peter Ujfalusi]

edma_write_slot() is for writing an entire paRAM slot.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 08f9bd0aa0b3..f6653da0ee16 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -968,8 +968,7 @@ static void edma_free_channel(struct edma_cc *ecc, unsigned 
channel)
edma_setup_interrupt(ecc, channel, NULL, NULL);
/* REVISIT should probably take out of shadow region 0 */
 
-   memcpy_toio(ecc->base + PARM_OFFSET(channel), _paramset,
-   PARM_SIZE);
+   edma_write_slot(ecc, channel, _paramset);
clear_bit(channel, ecc->edma_inuse);
 }
 
-- 
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 v5 24/24] dmaengine: edma: Dynamic paRAM slot handling if HW supports it

[Peter Ujfalusi]

If the eDMA3 has support for channel paRAM slot mapping we can utilize it
to allocate slots on demand and save precious slots for real transfers.
On am335x the eDMA has 64 channels which means we can unlock 64 paRAM
slots out from the available 256.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 101 +++--
 1 file changed, 52 insertions(+), 49 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 8d9169b7f208..7eefbf1e1c94 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -413,12 +413,13 @@ static void edma_assign_priority_to_queue(struct edma_cc 
*ecc, int queue_no,
edma_modify(ecc, EDMA_QUEPRI, ~(0x7 << bit), ((priority & 0x7) << bit));
 }
 
-static void edma_direct_dmach_to_param_mapping(struct edma_cc *ecc)
+static void edma_set_chmap(struct edma_cc *ecc, int channel, int slot)
 {
-   int i;
-
-   for (i = 0; i < ecc->num_channels; i++)
-   edma_write_array(ecc, EDMA_DCHMAP, i, (i << 5));
+   if (ecc->chmap_exist) {
+   channel = EDMA_CHAN_SLOT(channel);
+   slot = EDMA_CHAN_SLOT(slot);
+   edma_write_array(ecc, EDMA_DCHMAP, channel, (slot << 5));
+   }
 }
 
 static int prepare_unused_channel_list(struct device *dev, void *data)
@@ -528,10 +529,18 @@ static void edma_read_slot(struct edma_cc *ecc, unsigned 
slot,
  */
 static int edma_alloc_slot(struct edma_cc *ecc, int slot)
 {
-   if (slot > 0)
+   if (slot > 0) {
slot = EDMA_CHAN_SLOT(slot);
+   /* Requesting entry paRAM slot for a HW triggered channel. */
+   if (ecc->chmap_exist && slot < ecc->num_channels)
+   slot = EDMA_SLOT_ANY;
+   }
+
if (slot < 0) {
-   slot = ecc->num_channels;
+   if (ecc->chmap_exist)
+   slot = 0;
+   else
+   slot = ecc->num_channels;
for (;;) {
slot = find_next_zero_bit(ecc->slot_inuse,
  ecc->num_slots,
@@ -541,7 +550,7 @@ static int edma_alloc_slot(struct edma_cc *ecc, int slot)
if (!test_and_set_bit(slot, ecc->slot_inuse))
break;
}
-   } else if (slot < ecc->num_channels || slot >= ecc->num_slots) {
+   } else if (slot >= ecc->num_slots) {
return -EINVAL;
} else if (test_and_set_bit(slot, ecc->slot_inuse)) {
return -EBUSY;
@@ -555,7 +564,7 @@ static int edma_alloc_slot(struct edma_cc *ecc, int slot)
 static void edma_free_slot(struct edma_cc *ecc, unsigned slot)
 {
slot = EDMA_CHAN_SLOT(slot);
-   if (slot < ecc->num_channels || slot >= ecc->num_slots)
+   if (slot >= ecc->num_slots)
return;
 
edma_write_slot(ecc, slot, _paramset);
@@ -806,7 +815,6 @@ static void edma_clean_channel(struct edma_cc *ecc, 
unsigned channel)
 static int edma_alloc_channel(struct edma_cc *ecc, int channel,
  enum dma_event_q eventq_no)
 {
-   unsigned done = 0;
int ret = 0;
 
if (!ecc->unused_chan_list_done) {
@@ -833,24 +841,12 @@ static int edma_alloc_channel(struct edma_cc *ecc, int 
channel,
}
 
if (channel < 0) {
-   channel = 0;
-   for (;;) {
-   channel = find_next_bit(ecc->channel_unused,
-   ecc->num_channels, channel);
-   if (channel == ecc->num_channels)
-   break;
-   if (!test_and_set_bit(channel, ecc->slot_inuse)) {
-   done = 1;
-   break;
-   }
-   channel++;
-   }
-   if (!done)
-   return -ENOMEM;
+   channel = find_next_bit(ecc->channel_unused, ecc->num_channels,
+   0);
+   if (channel == ecc->num_channels)
+   return -EBUSY;
} else if (channel >= ecc->num_channels) {
return -EINVAL;
-   } else if (test_and_set_bit(channel, ecc->slot_inuse)) {
-   return -EBUSY;
}
 
/* ensure access through shadow region 0 */
@@ -858,7 +854,6 @@ static int edma_alloc_channel(struct edma_cc *ecc, int 
channel,
 
/* ensure no events are pending */
edma_stop(ecc, EDMA_CTLR_CHAN(ecc->id, channel));
-   edma_write_slot(ecc, channel, _paramset);
 
edma_setup_interrupt(ecc, EDMA_CTLR_CHAN(ecc->id, channel), true);
 
@@ -891,11 +886,8 @@ static void edma_free_channel(struct edma_cc *ecc, 
unsigned channel)
if (channel >= ecc->num_channels)
return;
 
-   edma_setup_interrupt(ecc, channel, false);
/* REVISIT should 

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

[Roger Quadros]

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

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 v5 23/24] dmaengine: edma: Rename bitfields for slot and channel usage tracking

[Peter Ujfalusi]

The names chosen for the bitfields were quite confusing and given no real
information on what they are used for...

edma_inuse -> slot_inuse: tracks the slot usage/availability
edma_unused -> channel_unused: tracks the channel usage/availability

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 51 ++-
 1 file changed, 26 insertions(+), 25 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 4b2ccc9de0ad..8d9169b7f208 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -227,16 +227,16 @@ struct edma_cc {
enum dma_event_qdefault_queue;
 
boolunused_chan_list_done;
-   /* The edma_inuse bit for each PaRAM slot is clear unless the
+   /* The slot_inuse bit for each PaRAM slot is clear unless the
 * channel is in use ... by ARM or DSP, for QDMA, or whatever.
 */
-   unsigned long *edma_inuse;
+   unsigned long *slot_inuse;
 
-   /* The edma_unused bit for each channel is clear unless
+   /* The channel_unused bit for each channel is clear unless
 * it is not being used on this platform. It uses a bit
 * of SOC-specific initialization code.
 */
-   unsigned long *edma_unused;
+   unsigned long *channel_unused;
 
struct dma_device   dma_slave;
struct edma_chan*slave_chans;
@@ -452,7 +452,7 @@ static int prepare_unused_channel_list(struct device *dev, 
void *data)
continue;
 
clear_bit(EDMA_CHAN_SLOT(dma_spec.args[0]),
- ecc->edma_unused);
+ ecc->channel_unused);
of_node_put(dma_spec.np);
}
return 0;
@@ -469,7 +469,7 @@ static int prepare_unused_channel_list(struct device *dev, 
void *data)
dma_req = (int)res->start;
if (dma_req >= dma_req_min && dma_req < dma_req_max)
clear_bit(EDMA_CHAN_SLOT(pdev->resource[i].start),
- ecc->edma_unused);
+ ecc->channel_unused);
}
 
return 0;
@@ -533,17 +533,17 @@ static int edma_alloc_slot(struct edma_cc *ecc, int slot)
if (slot < 0) {
slot = ecc->num_channels;
for (;;) {
-   slot = find_next_zero_bit(ecc->edma_inuse,
+   slot = find_next_zero_bit(ecc->slot_inuse,
  ecc->num_slots,
  slot);
if (slot == ecc->num_slots)
return -ENOMEM;
-   if (!test_and_set_bit(slot, ecc->edma_inuse))
+   if (!test_and_set_bit(slot, ecc->slot_inuse))
break;
}
} else if (slot < ecc->num_channels || slot >= ecc->num_slots) {
return -EINVAL;
-   } else if (test_and_set_bit(slot, ecc->edma_inuse)) {
+   } else if (test_and_set_bit(slot, ecc->slot_inuse)) {
return -EBUSY;
}
 
@@ -559,7 +559,7 @@ static void edma_free_slot(struct edma_cc *ecc, unsigned 
slot)
return;
 
edma_write_slot(ecc, slot, _paramset);
-   clear_bit(slot, ecc->edma_inuse);
+   clear_bit(slot, ecc->slot_inuse);
 }
 
 /**
@@ -631,7 +631,7 @@ static int edma_start(struct edma_cc *ecc, unsigned channel)
unsigned int mask = BIT(channel & 0x1f);
 
/* EDMA channels without event association */
-   if (test_bit(channel, ecc->edma_unused)) {
+   if (test_bit(channel, ecc->channel_unused)) {
dev_dbg(ecc->dev, "ESR%d %08x\n", j,
edma_shadow0_read_array(ecc, SH_ESR, j));
edma_shadow0_write_array(ecc, SH_ESR, j, mask);
@@ -835,11 +835,11 @@ static int edma_alloc_channel(struct edma_cc *ecc, int 
channel,
if (channel < 0) {
channel = 0;
for (;;) {
-   channel = find_next_bit(ecc->edma_unused,
+   channel = find_next_bit(ecc->channel_unused,
ecc->num_channels, channel);
if (channel == ecc->num_channels)
break;
-   if (!test_and_set_bit(channel, ecc->edma_inuse)) {
+   if (!test_and_set_bit(channel, ecc->slot_inuse)) {
done = 1;
break;
}
@@ -849,7 +849,7 @@ static int edma_alloc_channel(struct edma_cc *ecc, int 
channel,
return -ENOMEM;
} else if (channel >= ecc->num_channels) {
  

[PATCHv2] ARM: OMAP3: clock: remove un-used core dpll re-program code

[Tero Kristo]

Remove the OMAP3 core DPLL re-program code, and the associated SRAM
code that does the low-level programming of the DPLL divider, idling
of the SDRAM etc.

This code was never fully implemented in the kernel; things missing
were driver side handling of core clock changes (they need to account
for their functional clock rate being changed on-the-fly), and the whole
framework required for handling this. Thus, there is not much point
to keep carrying the low-level support code either.

Signed-off-by: Tero Kristo 
Cc: Tony Lindgren 
Cc: Paul Walmsley 
---
Changes since v1:
 - rebased on top of 4.3-rc4
 - removed AFLAGS for sram34xx.S file which has been removed

 arch/arm/mach-omap2/Makefile   |3 -
 arch/arm/mach-omap2/clkt34xx_dpll3m2.c |  122 ---
 arch/arm/mach-omap2/sram.c |   25 ---
 arch/arm/mach-omap2/sram.h |   14 --
 arch/arm/mach-omap2/sram34xx.S |  346 
 5 files changed, 510 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/clkt34xx_dpll3m2.c
 delete mode 100644 arch/arm/mach-omap2/sram34xx.S

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 9358696..ceefcee 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -48,11 +48,9 @@ AFLAGS_sleep44xx.o   
:=-Wa,-march=armv7-a$(plus_sec)
 # Functions loaded to SRAM
 obj-$(CONFIG_SOC_OMAP2420) += sram242x.o
 obj-$(CONFIG_SOC_OMAP2430) += sram243x.o
-obj-$(CONFIG_ARCH_OMAP3)   += sram34xx.o
 
 AFLAGS_sram242x.o  :=-Wa,-march=armv6
 AFLAGS_sram243x.o  :=-Wa,-march=armv6
-AFLAGS_sram34xx.o  :=-Wa,-march=armv7-a
 
 # Restart code (OMAP4/5 currently in omap4-common.c)
 obj-$(CONFIG_SOC_OMAP2420) += omap2-restart.o
@@ -186,7 +184,6 @@ obj-$(CONFIG_ARCH_OMAP2)+= clkt2xxx_dpllcore.o
 obj-$(CONFIG_ARCH_OMAP2)   += clkt2xxx_virt_prcm_set.o
 obj-$(CONFIG_ARCH_OMAP2)   += clkt2xxx_dpll.o
 obj-$(CONFIG_ARCH_OMAP3)   += $(clock-common)
-obj-$(CONFIG_ARCH_OMAP3)   += clkt34xx_dpll3m2.o
 obj-$(CONFIG_ARCH_OMAP4)   += $(clock-common)
 obj-$(CONFIG_SOC_AM33XX)   += $(clock-common)
 obj-$(CONFIG_SOC_OMAP5)+= $(clock-common)
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c 
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
deleted file mode 100644
index 3f65213..000
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ /dev/null
@@ -1,122 +0,0 @@
-/*
- * OMAP34xx M2 divider clock code
- *
- * Copyright (C) 2007-2008 Texas Instruments, Inc.
- * Copyright (C) 2007-2010 Nokia Corporation
- *
- * Paul Walmsley
- * Jouni Högander
- *
- * Parts of this code are based on code written by
- * Richard Woodruff, Tony Lindgren, Tuukka Tikkanen, Karthik Dasu
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#undef DEBUG
-
-#include 
-#include 
-#include 
-#include 
-
-#include "clock.h"
-#include "clock3xxx.h"
-#include "sdrc.h"
-#include "sram.h"
-
-#define CYCLES_PER_MHZ 100
-
-struct clk *sdrc_ick_p, *arm_fck_p;
-
-/*
- * CORE DPLL (DPLL3) M2 divider rate programming functions
- *
- * These call into SRAM code to do the actual CM writes, since the SDRAM
- * is clocked from DPLL3.
- */
-
-/**
- * omap3_core_dpll_m2_set_rate - set CORE DPLL M2 divider
- * @clk: struct clk * of DPLL to set
- * @rate: rounded target rate
- *
- * Program the DPLL M2 divider with the rounded target rate.  Returns
- * -EINVAL upon error, or 0 upon success.
- */
-int omap3_core_dpll_m2_set_rate(struct clk_hw *hw, unsigned long rate,
-   unsigned long parent_rate)
-{
-   struct clk_hw_omap *clk = to_clk_hw_omap(hw);
-   u32 new_div = 0;
-   u32 unlock_dll = 0;
-   u32 c;
-   unsigned long validrate, sdrcrate, _mpurate;
-   struct omap_sdrc_params *sdrc_cs0;
-   struct omap_sdrc_params *sdrc_cs1;
-   int ret;
-   unsigned long clkrate;
-
-   if (!clk || !rate)
-   return -EINVAL;
-
-   new_div = DIV_ROUND_UP(parent_rate, rate);
-   validrate = parent_rate / new_div;
-
-   if (validrate != rate)
-   return -EINVAL;
-
-   sdrcrate = clk_get_rate(sdrc_ick_p);
-   clkrate = clk_hw_get_rate(hw);
-   if (rate > clkrate)
-   sdrcrate <<= ((rate / clkrate) >> 1);
-   else
-   sdrcrate >>= ((clkrate / rate) >> 1);
-
-   ret = omap2_sdrc_get_params(sdrcrate, _cs0, _cs1);
-   if (ret)
-   return -EINVAL;
-
-   if (sdrcrate < MIN_SDRC_DLL_LOCK_FREQ) {
-   pr_debug("clock: will unlock SDRC DLL\n");
-   unlock_dll = 1;
-   }
-
-   /*
-* 

[PATCH v5 06/24] ARM: common: edma: Internal API to use pointer to 'struct edma'

[Peter Ujfalusi]

Merge the iomem into the 'struct edma' and change the internal (static)
functions to use pointer to the edma_cc instead of the ctlr number.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/common/edma.c | 400 -
 1 file changed, 197 insertions(+), 203 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index d82fceda13a3..0b4c0ee59ed9 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -114,108 +114,141 @@
 #define EDMA_MAX_PARAMENTRY 512
 
 /*/
+struct edma {
+   struct device   *dev;
+   void __iomem *base;
+
+   /* how many dma resources of each type */
+   unsignednum_channels;
+   unsignednum_region;
+   unsignednum_slots;
+   unsignednum_tc;
+   enum dma_event_qdefault_queue;
 
-static void __iomem *edmacc_regs_base[EDMA_MAX_CC];
+   /* list of channels with no even trigger; terminated by "-1" */
+   const s8*noevent;
+
+   struct edma_soc_info *info;
+   int id;
+
+   /* The edma_inuse bit for each PaRAM slot is clear unless the
+* channel is in use ... by ARM or DSP, for QDMA, or whatever.
+*/
+   DECLARE_BITMAP(edma_inuse, EDMA_MAX_PARAMENTRY);
 
-static inline unsigned int edma_read(unsigned ctlr, int offset)
+   /* The edma_unused bit for each channel is clear unless
+* it is not being used on this platform. It uses a bit
+* of SOC-specific initialization code.
+*/
+   DECLARE_BITMAP(edma_unused, EDMA_MAX_DMACH);
+
+   struct dma_interrupt_data {
+   void (*callback)(unsigned channel, unsigned short ch_status,
+   void *data);
+   void *data;
+   } intr_data[EDMA_MAX_DMACH];
+};
+/*/
+
+static inline unsigned int edma_read(struct edma *cc, int offset)
 {
-   return (unsigned int)__raw_readl(edmacc_regs_base[ctlr] + offset);
+   return (unsigned int)__raw_readl(cc->base + offset);
 }
 
-static inline void edma_write(unsigned ctlr, int offset, int val)
+static inline void edma_write(struct edma *cc, int offset, int val)
 {
-   __raw_writel(val, edmacc_regs_base[ctlr] + offset);
+   __raw_writel(val, cc->base + offset);
 }
-static inline void edma_modify(unsigned ctlr, int offset, unsigned and,
-   unsigned or)
+static inline void edma_modify(struct edma *cc, int offset, unsigned and,
+  unsigned or)
 {
-   unsigned val = edma_read(ctlr, offset);
+   unsigned val = edma_read(cc, offset);
val &= and;
val |= or;
-   edma_write(ctlr, offset, val);
+   edma_write(cc, offset, val);
 }
-static inline void edma_and(unsigned ctlr, int offset, unsigned and)
+static inline void edma_and(struct edma *cc, int offset, unsigned and)
 {
-   unsigned val = edma_read(ctlr, offset);
+   unsigned val = edma_read(cc, offset);
val &= and;
-   edma_write(ctlr, offset, val);
+   edma_write(cc, offset, val);
 }
-static inline void edma_or(unsigned ctlr, int offset, unsigned or)
+static inline void edma_or(struct edma *cc, int offset, unsigned or)
 {
-   unsigned val = edma_read(ctlr, offset);
+   unsigned val = edma_read(cc, offset);
val |= or;
-   edma_write(ctlr, offset, val);
+   edma_write(cc, offset, val);
 }
-static inline unsigned int edma_read_array(unsigned ctlr, int offset, int i)
+static inline unsigned int edma_read_array(struct edma *cc, int offset, int i)
 {
-   return edma_read(ctlr, offset + (i << 2));
+   return edma_read(cc, offset + (i << 2));
 }
-static inline void edma_write_array(unsigned ctlr, int offset, int i,
+static inline void edma_write_array(struct edma *cc, int offset, int i,
unsigned val)
 {
-   edma_write(ctlr, offset + (i << 2), val);
+   edma_write(cc, offset + (i << 2), val);
 }
-static inline void edma_modify_array(unsigned ctlr, int offset, int i,
+static inline void edma_modify_array(struct edma *cc, int offset, int i,
unsigned and, unsigned or)
 {
-   edma_modify(ctlr, offset + (i << 2), and, or);
+   edma_modify(cc, offset + (i << 2), and, or);
 }
-static inline void edma_or_array(unsigned ctlr, int offset, int i, unsigned or)
+static inline void edma_or_array(struct edma *cc, int offset, int i, unsigned 
or)
 {
-   edma_or(ctlr, offset + (i << 2), or);
+   edma_or(cc, offset + (i << 2), or);
 }
-static inline void edma_or_array2(unsigned ctlr, int offset, int i, int j,
+static inline void edma_or_array2(struct edma *cc, int offset, int i, int j,
unsigned or)
 {
-   edma_or(ctlr, offset + ((i*2 + j) << 2), or);
+   edma_or(cc, offset + ((i*2 + j) << 2), or);
 }
-static inline void 

Re: [PATCH] ARM: OMAP3: clock: remove un-used core dpll re-program code

[Tero Kristo]

On 10/12/2015 08:01 PM, Tony Lindgren wrote:

* Tony Lindgren  [150812 03:59]:

* Tony Lindgren  [150812 00:29]:

* Tero Kristo  [150716 01:10]:

Remove the OMAP3 core DPLL re-program code, and the associated SRAM
code that does the low-level programming of the DPLL divider, idling
of the SDRAM etc.

This code was never fully implemented in the kernel; things missing
were driver side handling of core clock changes (they need to account
for their functional clock rate being changed on-the-fly), and the whole
framework required for handling this. Thus, there is not much point
to keep carrying the low-level support code either.


OK I'm applying this into omap-for-v4.3/soc. If we ever need the code
it will be in the git history.


Actually I'll wait on this one and apply it later on as it currently
adds merge conflicts into Linux next.


Looks like this needs to be updated to apply on v4.3-rc4, can you
please repost?


Ok, just posted it.

-Tero



Using v4.3-rc4 as the base for v4.4 because it contains most of the
mmc fixes.

Regards,

Tony



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

[PATCH v5 18/24] dmaengine: edma: Consolidate the comments for functions

[Peter Ujfalusi]

Remove or rewrite the comments for the internal functions.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 86 +++---
 1 file changed, 11 insertions(+), 75 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index d33ae0b43925..6bcbdceb3dc2 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -508,19 +508,7 @@ static void edma_setup_interrupt(struct edma_cc *ecc, 
unsigned lch,
 }
 
 /*
- * paRAM management functions
- */
-
-/**
- * edma_write_slot - write parameter RAM data for slot
- * @ecc: pointer to edma_cc struct
- * @slot: number of parameter RAM slot being modified
- * @param: data to be written into parameter RAM slot
- *
- * Use this to assign all parameters of a transfer at once.  This
- * allows more efficient setup of transfers than issuing multiple
- * calls to set up those parameters in small pieces, and provides
- * complete control over all transfer options.
+ * paRAM slot management functions
  */
 static void edma_write_slot(struct edma_cc *ecc, unsigned slot,
const struct edmacc_param *param)
@@ -531,15 +519,6 @@ static void edma_write_slot(struct edma_cc *ecc, unsigned 
slot,
memcpy_toio(ecc->base + PARM_OFFSET(slot), param, PARM_SIZE);
 }
 
-/**
- * edma_read_slot - read parameter RAM data from slot
- * @ecc: pointer to edma_cc struct
- * @slot: number of parameter RAM slot being copied
- * @param: where to store copy of parameter RAM data
- *
- * Use this to read data from a parameter RAM slot, perhaps to
- * save them as a template for later reuse.
- */
 static void edma_read_slot(struct edma_cc *ecc, unsigned slot,
   struct edmacc_param *param)
 {
@@ -590,15 +569,6 @@ static int edma_alloc_slot(struct edma_cc *ecc, int slot)
return EDMA_CTLR_CHAN(ecc->id, slot);
 }
 
-/**
- * edma_free_slot - deallocate DMA parameter RAM
- * @ecc: pointer to edma_cc struct
- * @slot: parameter RAM slot returned from edma_alloc_slot()
- *
- * This deallocates the parameter RAM slot allocated by edma_alloc_slot().
- * Callers are responsible for ensuring the slot is inactive, and will
- * not be activated.
- */
 static void edma_free_slot(struct edma_cc *ecc, unsigned slot)
 {
slot = EDMA_CHAN_SLOT(slot);
@@ -707,10 +677,9 @@ static int edma_start(struct edma_cc *ecc, unsigned 
channel)
  * @ecc: pointer to edma_cc struct
  * @channel: channel being deactivated
  *
- * When @lch is a channel, any active transfer is paused and
- * all pending hardware events are cleared.  The current transfer
- * may not be resumed, and the channel's Parameter RAM should be
- * reinitialized before being reused.
+ * Any active transfer is paused and all pending hardware events are cleared.
+ * The current transfer may not be resumed, and the channel's Parameter RAM
+ * should be reinitialized before being reused.
  */
 static void edma_stop(struct edma_cc *ecc, unsigned channel)
 {
@@ -742,13 +711,9 @@ static void edma_stop(struct edma_cc *ecc, unsigned 
channel)
}
 }
 
-/**
- * edma_pause - pause dma on a channel
- * @ecc: pointer to edma_cc struct
- * @channel: on which edma_start() has been called
- *
- * This temporarily disables EDMA hardware events on the specified channel,
- * preventing them from triggering new transfers on its behalf
+/*
+ * Temporarily disable EDMA hardware events on the specified channel,
+ * preventing them from triggering new transfers
  */
 static void edma_pause(struct edma_cc *ecc, unsigned channel)
 {
@@ -766,13 +731,7 @@ static void edma_pause(struct edma_cc *ecc, unsigned 
channel)
}
 }
 
-/**
- * edma_resume - resumes dma on a paused channel
- * @ecc: pointer to edma_cc struct
- * @channel: on which edma_pause() has been called
- *
- * This re-enables EDMA hardware events on the specified channel.
- */
+/* Re-enable EDMA hardware events on the specified channel.  */
 static void edma_resume(struct edma_cc *ecc, unsigned channel)
 {
if (ecc->id != EDMA_CTLR(channel)) {
@@ -808,19 +767,6 @@ static int edma_trigger_channel(struct edma_cc *ecc, 
unsigned channel)
return 0;
 }
 
-/**
- *
- * It cleans ParamEntry qand bring back EDMA to initial state if media has
- * been removed before EDMA has finished.It is usedful for removable media.
- * Arguments:
- *  ch_no - channel no
- *
- * Return: zero on success, or corresponding error no on failure
- *
- * FIXME this should not be needed ... edma_stop() should suffice.
- *
- */
-
 static void edma_clean_channel(struct edma_cc *ecc, unsigned channel)
 {
if (ecc->id != EDMA_CTLR(channel)) {
@@ -975,14 +921,7 @@ static void edma_free_channel(struct edma_cc *ecc, 
unsigned channel)
clear_bit(channel, ecc->edma_inuse);
 }
 
-/*
- * edma_assign_channel_eventq - move 

[PATCH v5 15/24] dmaengine: edma: Use dev_dbg instead pr_debug

[Peter Ujfalusi]

We have access to dev, so it is better to use the dev_dbg for debug prints.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index a9fe5c92451d..08f9bd0aa0b3 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -676,23 +676,23 @@ static int edma_start(struct edma_cc *ecc, unsigned 
channel)
 
/* EDMA channels without event association */
if (test_bit(channel, ecc->edma_unused)) {
-   pr_debug("EDMA: ESR%d %08x\n", j,
-edma_shadow0_read_array(ecc, SH_ESR, j));
+   dev_dbg(ecc->dev, "ESR%d %08x\n", j,
+   edma_shadow0_read_array(ecc, SH_ESR, j));
edma_shadow0_write_array(ecc, SH_ESR, j, mask);
return 0;
}
 
/* EDMA channel with event association */
-   pr_debug("EDMA: ER%d %08x\n", j,
-edma_shadow0_read_array(ecc, SH_ER, j));
+   dev_dbg(ecc->dev, "ER%d %08x\n", j,
+   edma_shadow0_read_array(ecc, SH_ER, j));
/* Clear any pending event or error */
edma_write_array(ecc, EDMA_ECR, j, mask);
edma_write_array(ecc, EDMA_EMCR, j, mask);
/* Clear any SER */
edma_shadow0_write_array(ecc, SH_SECR, j, mask);
edma_shadow0_write_array(ecc, SH_EESR, j, mask);
-   pr_debug("EDMA: EER%d %08x\n", j,
-edma_shadow0_read_array(ecc, SH_EER, j));
+   dev_dbg(ecc->dev, "EER%d %08x\n", j,
+   edma_shadow0_read_array(ecc, SH_EER, j));
return 0;
}
 
@@ -730,8 +730,8 @@ static void edma_stop(struct edma_cc *ecc, unsigned channel)
/* clear possibly pending completion interrupt */
edma_shadow0_write_array(ecc, SH_ICR, j, mask);
 
-   pr_debug("EDMA: EER%d %08x\n", j,
-edma_shadow0_read_array(ecc, SH_EER, j));
+   dev_dbg(ecc->dev, "EER%d %08x\n", j,
+   edma_shadow0_read_array(ecc, SH_EER, j));
 
/* REVISIT:  consider guarding against inappropriate event
 * chaining by overwriting with dummy_paramset.
@@ -800,8 +800,8 @@ static int edma_trigger_channel(struct edma_cc *ecc, 
unsigned channel)
 
edma_shadow0_write_array(ecc, SH_ESR, (channel >> 5), mask);
 
-   pr_debug("EDMA: ESR%d %08x\n", (channel >> 5),
-edma_shadow0_read_array(ecc, SH_ESR, (channel >> 5)));
+   dev_dbg(ecc->dev, "ESR%d %08x\n", (channel >> 5),
+   edma_shadow0_read_array(ecc, SH_ESR, (channel >> 5)));
return 0;
 }
 
@@ -831,8 +831,8 @@ static void edma_clean_channel(struct edma_cc *ecc, 
unsigned channel)
int j = (channel >> 5);
unsigned int mask = BIT(channel & 0x1f);
 
-   pr_debug("EDMA: EMR%d %08x\n", j,
-edma_read_array(ecc, EDMA_EMR, j));
+   dev_dbg(ecc->dev, "EMR%d %08x\n", j,
+   edma_read_array(ecc, EDMA_EMR, j));
edma_shadow0_write_array(ecc, SH_ECR, j, mask);
/* Clear the corresponding EMR bits */
edma_write_array(ecc, EDMA_EMCR, j, mask);
-- 
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 v5 07/24] ARM/dmaengine: edma: Public API to use private struct pointer

[Peter Ujfalusi]

Instead of relying on indexes pointing to edma private date in the global
pointer array, pass the private data pointer via the public API.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/common/edma.c | 305 ++---
 drivers/dma/edma.c |  79 +-
 include/linux/platform_data/edma.h |  38 +++--
 3 files changed, 214 insertions(+), 208 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 0b4c0ee59ed9..03692520812a 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -130,7 +130,7 @@ struct edma {
 
struct edma_soc_info *info;
int id;
-
+   boolunused_chan_list_done;
/* The edma_inuse bit for each PaRAM slot is clear unless the
 * channel is in use ... by ARM or DSP, for QDMA, or whatever.
 */
@@ -264,7 +264,6 @@ static inline void clear_bits(int offset, int len, unsigned 
long *p)
 }
 
 /*/
-static struct edma *edma_cc[EDMA_MAX_CC];
 static int arch_num_cc;
 
 /* dummy param set used to (re)initialize parameter RAM slots */
@@ -490,14 +489,18 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
 static int prepare_unused_channel_list(struct device *dev, void *data)
 {
struct platform_device *pdev = to_platform_device(dev);
-   int i, count, ctlr;
+   struct edma *cc = data;
+   int i, count;
struct of_phandle_args  dma_spec;
 
if (dev->of_node) {
+   struct platform_device *dma_pdev;
+
count = of_property_count_strings(dev->of_node, "dma-names");
if (count < 0)
return 0;
for (i = 0; i < count; i++) {
+
if (of_parse_phandle_with_args(dev->of_node, "dmas",
   "#dma-cells", i,
   _spec))
@@ -508,8 +511,12 @@ static int prepare_unused_channel_list(struct device *dev, 
void *data)
continue;
}
 
+   dma_pdev = of_find_device_by_node(dma_spec.np);
+   if (_pdev->dev != cc->dev)
+   continue;
+
clear_bit(EDMA_CHAN_SLOT(dma_spec.args[0]),
- edma_cc[0]->edma_unused);
+ cc->edma_unused);
of_node_put(dma_spec.np);
}
return 0;
@@ -517,11 +524,11 @@ static int prepare_unused_channel_list(struct device 
*dev, void *data)
 
/* For non-OF case */
for (i = 0; i < pdev->num_resources; i++) {
-   if ((pdev->resource[i].flags & IORESOURCE_DMA) &&
-   (int)pdev->resource[i].start >= 0) {
-   ctlr = EDMA_CTLR(pdev->resource[i].start);
+   struct resource *res = >resource[i];
+
+   if ((res->flags & IORESOURCE_DMA) && (int)res->start >= 0) {
clear_bit(EDMA_CHAN_SLOT(pdev->resource[i].start),
- edma_cc[ctlr]->edma_unused);
+ cc->edma_unused);
}
}
 
@@ -530,8 +537,6 @@ static int prepare_unused_channel_list(struct device *dev, 
void *data)
 
 /*---*/
 
-static bool unused_chan_list_done;
-
 /* Resource alloc/free:  dma channels, parameter RAM slots */
 
 /**
@@ -564,77 +569,73 @@ static bool unused_chan_list_done;
  *
  * Returns the number of the channel, else negative errno.
  */
-int edma_alloc_channel(int channel,
+int edma_alloc_channel(struct edma *cc, int channel,
void (*callback)(unsigned channel, u16 ch_status, void *data),
void *data,
enum dma_event_q eventq_no)
 {
-   unsigned i, done = 0, ctlr = 0;
+   unsigned done = 0;
int ret = 0;
 
-   if (!unused_chan_list_done) {
+   if (!cc->unused_chan_list_done) {
/*
 * Scan all the platform devices to find out the EDMA channels
 * used and clear them in the unused list, making the rest
 * available for ARM usage.
 */
-   ret = bus_for_each_dev(_bus_type, NULL, NULL,
-   prepare_unused_channel_list);
+   ret = bus_for_each_dev(_bus_type, NULL, cc,
+  prepare_unused_channel_list);
if (ret < 0)
return ret;
 
-   unused_chan_list_done = true;
+   cc->unused_chan_list_done = true;
}
 
if (channel >= 0) {
-   ctlr = EDMA_CTLR(channel);
+   if (cc->id != EDMA_CTLR(channel)) {
+ 

[PATCH v5 14/24] dmaengine: edma: Cleanup regarding the use of dev around the code

[Peter Ujfalusi]

Be consistent and do not mix the use of dev, >dev, etc in the
functions.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 61 +++---
 1 file changed, 30 insertions(+), 31 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 95c10373168d..a9fe5c92451d 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1198,27 +1198,27 @@ static void edma_execute(struct edma_chan *echan)
j = i + edesc->processed;
edma_write_slot(ecc, echan->slot[i], >pset[j].param);
edesc->sg_len += edesc->pset[j].len;
-   dev_vdbg(echan->vchan.chan.device->dev,
-   "\n pset[%d]:\n"
-   "  chnum\t%d\n"
-   "  slot\t%d\n"
-   "  opt\t%08x\n"
-   "  src\t%08x\n"
-   "  dst\t%08x\n"
-   "  abcnt\t%08x\n"
-   "  ccnt\t%08x\n"
-   "  bidx\t%08x\n"
-   "  cidx\t%08x\n"
-   "  lkrld\t%08x\n",
-   j, echan->ch_num, echan->slot[i],
-   edesc->pset[j].param.opt,
-   edesc->pset[j].param.src,
-   edesc->pset[j].param.dst,
-   edesc->pset[j].param.a_b_cnt,
-   edesc->pset[j].param.ccnt,
-   edesc->pset[j].param.src_dst_bidx,
-   edesc->pset[j].param.src_dst_cidx,
-   edesc->pset[j].param.link_bcntrld);
+   dev_vdbg(dev,
+"\n pset[%d]:\n"
+"  chnum\t%d\n"
+"  slot\t%d\n"
+"  opt\t%08x\n"
+"  src\t%08x\n"
+"  dst\t%08x\n"
+"  abcnt\t%08x\n"
+"  ccnt\t%08x\n"
+"  bidx\t%08x\n"
+"  cidx\t%08x\n"
+"  lkrld\t%08x\n",
+j, echan->ch_num, echan->slot[i],
+edesc->pset[j].param.opt,
+edesc->pset[j].param.src,
+edesc->pset[j].param.dst,
+edesc->pset[j].param.a_b_cnt,
+edesc->pset[j].param.ccnt,
+edesc->pset[j].param.src_dst_bidx,
+edesc->pset[j].param.src_dst_cidx,
+edesc->pset[j].param.link_bcntrld);
/* Link to the previous slot if not the last set */
if (i != (nslots - 1))
edma_link(ecc, echan->slot[i], echan->slot[i + 1]);
@@ -1849,7 +1849,6 @@ err_no_chan:
 static void edma_free_chan_resources(struct dma_chan *chan)
 {
struct edma_chan *echan = to_edma_chan(chan);
-   struct device *dev = chan->device->dev;
int i;
 
/* Terminate transfers */
@@ -1871,7 +1870,7 @@ static void edma_free_chan_resources(struct dma_chan 
*chan)
echan->alloced = false;
}
 
-   dev_dbg(dev, "freeing channel for %u\n", echan->ch_num);
+   dev_dbg(chan->device->dev, "freeing channel for %u\n", echan->ch_num);
 }
 
 /* Send pending descriptor to hardware */
@@ -2196,13 +2195,13 @@ static int edma_probe(struct platform_device *pdev)
return ret;
}
 
-   ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
+   ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
if (ret)
return ret;
 
-   ecc = devm_kzalloc(>dev, sizeof(*ecc), GFP_KERNEL);
+   ecc = devm_kzalloc(dev, sizeof(*ecc), GFP_KERNEL);
if (!ecc) {
-   dev_err(>dev, "Can't allocate controller\n");
+   dev_err(dev, "Can't allocate controller\n");
return -ENOMEM;
}
 
@@ -2345,7 +2344,7 @@ static int edma_probe(struct platform_device *pdev)
 
ecc->dummy_slot = edma_alloc_slot(ecc, EDMA_SLOT_ANY);
if (ecc->dummy_slot < 0) {
-   dev_err(>dev, "Can't allocate PaRAM dummy slot\n");
+   dev_err(dev, "Can't allocate PaRAM dummy slot\n");
return ecc->dummy_slot;
}
 
@@ -2354,7 +2353,7 @@ static int edma_probe(struct platform_device *pdev)
dma_cap_set(DMA_CYCLIC, ecc->dma_slave.cap_mask);
dma_cap_set(DMA_MEMCPY, ecc->dma_slave.cap_mask);
 
-   edma_dma_init(ecc, >dma_slave, >dev);
+   edma_dma_init(ecc, >dma_slave, dev);
 
edma_chan_init(ecc, >dma_slave, ecc->slave_chans);
 
@@ -2366,7 +2365,7 @@ static int edma_probe(struct platform_device *pdev)
of_dma_controller_register(node, of_dma_xlate_by_chan_id,
   >dma_slave);
 
-   dev_info(>dev, "TI EDMA DMA engine driver\n");
+   dev_info(dev, "TI EDMA DMA 

[PATCH v5 13/24] dmaengine: edma: Use devm_kcalloc when possible

[Peter Ujfalusi]

When allocating a memory for number of items it is better (looks better)
to use devm_kcalloc.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index d5a76c67f83f..95c10373168d 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -2055,7 +2055,7 @@ static int edma_setup_from_hw(struct device *dev, struct 
edma_soc_info *pdata,
 * priority. So Q0 is the highest priority queue and the last queue has
 * the lowest priority.
 */
-   queue_priority_map = devm_kzalloc(dev, (ecc->num_tc + 1) * sizeof(s8),
+   queue_priority_map = devm_kcalloc(dev, ecc->num_tc + 1, sizeof(s8),
  GFP_KERNEL);
if (!queue_priority_map)
return -ENOMEM;
@@ -2086,7 +2086,7 @@ static int edma_xbar_event_map(struct device *dev, struct 
edma_soc_info *pdata,
u32 shift, offset, mux;
int ret, i;
 
-   xbar_chans = devm_kzalloc(dev, (nelm + 2) * sizeof(s16), GFP_KERNEL);
+   xbar_chans = devm_kcalloc(dev, nelm + 2, sizeof(s16), GFP_KERNEL);
if (!xbar_chans)
return -ENOMEM;
 
-- 
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