Re: [PATCH v4 3/5] mtd: devices: m25p80: add support for mmap read request

[Cyrille Pitchen]

Hi Vignesh,

Le 30/11/2015 06:15, Vignesh R a écrit :
> Certain spi controllers may provide accelerated interface to read from
> m25p80 type flash devices. This interface provides better read
> performance than regular SPI interface.
> Call spi_flash_read(), if supported, to make use of such interface.
> 
> Signed-off-by: Vignesh R 
> ---
> 
> v4: 
>  * Use spi_flash_read_message struct to pass args.
>  * support passing of opcode/addr/data nbits.
> 
>  drivers/mtd/devices/m25p80.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index fe9ceb7b5405..00094a668c62 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -131,6 +131,26 @@ static int m25p80_read(struct spi_nor *nor, loff_t from, 
> size_t len,
>   /* convert the dummy cycles to the number of bytes */
>   dummy /= 8;
>  
> + if (spi_flash_read_supported(spi)) {
> + struct spi_flash_read_message msg;
> + int ret;
> +
> + msg.buf = buf;
> + msg.from = from;
> + msg.len = len;
> + msg.read_opcode = nor->read_opcode;
> + msg.addr_width = nor->addr_width;
> + msg.dummy_bytes = dummy;
> + /* TODO: Support other combinations */
> + msg.opcode_nbits = SPI_NBITS_SINGLE;
> + msg.addr_nbits = SPI_NBITS_SINGLE;
> + msg.data_nbits = m25p80_rx_nbits(nor);

I wanted to let you know that the support of other SPI protocols has already
been implemented by this series:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/371170.html

patches 2 & 3 handle the probing of the (Q)SPI memory in spi_nor_scan() and
select the right protocols for register read/write, memory read, memory write,
and memory erase operations. The choice is done according to both the memory
and SPI controller capabilities.

patch 4 updates the m25p80 driver to take advantage of the bandwidth increase
allowed by QSPI protocols. For instance, the Atmel QSPI controller, like TI
one, maps the SPI NOR memory to the system bus. Yesterday I ran mtd_speedtest
to compare Fast Read 1-1-1 (0x0b) and Fast Read 1-1-4 (0x6b). The SPI clock
frequency was limited to 83MHz. The QSPI memory is a Micron n25q128a13.

I only had to change the mode argument of spi_nor_scan() from SPI_NOR_QUAD to
SPI_NOR_FAST in the atmel_quadspi driver (based on fsl-quadspi driver from
Freescale since Atmel's driver also uses the system bus mapping for memory
write operations) to force the spi-nor framework to choose the SPI 1-1-1
protocol instead of the SPI-1-1-4.

1 - Fast Read 1-1-1

mtd_speedtest: testing eraseblock write speed
mtd_speedtest: eraseblock read speed is 9319 KiB/s
[...]
mtd_speedtest: testing page read speed
mtd_speedtest: page read speed is 6649 KiB/s
[...]
mtd_speedtest: testing 2 page read speed
mtd_speedtest: 2 page read speed is 7757 KiB/s

2 - Fast Read 1-1-4

mtd_speedtest: testing eraseblock read speed
mtd_speedtest: eraseblock read speed is 30117 KiB/s
[...]
mtd_speedtest: testing page read speed
mtd_speedtest: page read speed is 13096 KiB/s
[...]
mtd_speedtest: testing 2 page read speed
mtd_speedtest: 2 page read speed is 18224 KiB/s

So the performance improvements are:
eraseblock read speed (65536 bytes) : +223%
page read speed (512 bytes) :  +97%
2 page read speed (1024 bytes)  : +135%


That's why I believe that you could take advantage of these performance
improvements in the TI (Q)SPI controller driver.


Also please note that you may have to add in the struct spi_flash_read_message
two other fields for the number of option/mode cycles and their value.
Option/mode cycles are sent between the address and dummy cycles. They are
used by some memory manufacturers such as Spansion, Micron and Macronix to
enter/leave their continuous read mode.
So if uninitialized dummy cycles are interpreted by the QSPI memory as
option/mode cycles, depending on the actual value, the memory may enter by
mistake in continuous mode. Once in continuous mode, the command op code byte
must not be sent and is not expected by the memory: the memory implicitly uses
the read op code sent in the SPI message which triggered the memory to enter
continuous read mode. Next SPI messages start from the address cycles until
the right option/mode cycles are sent to leave the continuous read mode.

Currently the mtd layer doesn't use this feature but it should be aware of it.
That's why I believe we'll have to address this point in spi_nor_scan() and the
"regular" m25p80() sooner or later.

> +
> + ret = spi_flash_read(spi, );
> + *retlen = msg.retlen;
> + return ret;
> + }
> +
>   spi_message_init();
>   memset(t, 0, (sizeof t));
>  
> 

Best regards,

Cyrille
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to 

Re: [PATCH v4 4/5] ARM: dts: DRA7: add entry for qspi mmap region

[Vignesh R]

On 12/01/2015 10:09 PM, Tony Lindgren wrote:
> * Vignesh R  [151130 20:46]:
>> On 12/01/2015 04:04 AM, Tony Lindgren wrote:
>>>
>>> Actually none of the IO areas above are within the same interconnect target:
>>>
>>> 0x4b30  QSPI0 address space in L3 main interconnect
>>> 0x5c00  QSPI1 address space in L3 main interconnect
>>
>>
>> First address range (configuration port: 0x4b30) corresponds to QSPI
>> registers space. These registers alone are sufficient for generic SPI
>> communication (serial flash as well as non-flash SPI devices).
> 
> OK
> 
>> In order to speed up SPI flash reads SFI_MM_IF(SPI memory mapped
>> interface) is provided by QSPI IP. This _cannot_ be used with non-flash
>> devices.
> 
> OK
> 
>> The second address range (0x5c00) corresponds to memory-mapped
>> region of SFI_MM_IF, through which SPI flash memories can be read as if
>> though they were RAM addresses (i.e using readl/memcpy). The SFI_MM_IF
>> block that takes care of communicating over SPI bus and getting the data
>> from flash device.
> 
> OK
> 
>> But SFI_MM_IF block needs to know some flash specific information(such
>> as read opcode, address bytes, dummy bytes, mode). This information must
>> first be populated in QSPI_SPI_SETUP*_REG(0x4B300054-60) before
>> accessing SFI_MM_IF address range via readl.
>> Both addresses space belong to same instance of the driver, one
>> corresponds to register space and other is memory-mapped region.
>> Therefore both regions are claimed by the same driver.
> 
> OK
> 
>>> 0x4a002558  CTRL_CORE_CONTROL_IO_2 in System Control Module (SCM) in L4_CFG
>>>
>>> The first two address spaces should be two separate instances of this 
>>> driver.
>>
>> Not actually two instances.
> 
> OK. They are both on L3 main so that won't cause any issues for separate
> interconnect driver instances. As they are still separate targets flushing
> a posted write to one area will not flush anything to the other.
> 

I didn't quite understand what you meant by interconnect driver instance.
qspi_base and qspi_mmap region are tightly bound to each other and both
needs to be accessed by ti-qspi driver (though different targets).
Besides qspi_mmap region is only used to read data, there will not be
any write accesses to this target. Are you saying this binding is not
viable?

>>> The CTRL_CORE_CONTROL_IO_2 needs seems like a shared clock register that
>>> needs to be accessed using the clock framework most likely.
>>>
>>
>> Not shared clock.
>> The CTRL_CORE_CONTROL_IO_2[10:8] QSPI_MEMMAPPED_CS bit fields provides a
>> functionality for remapping the previously described address space which
>> starts at 0x5C00 L3_MAIN address to one of the four supported chip
>> selects.
>> How about using syscon to access CTRL_CORE_CONTROL_IO_2?
> 
> A separate driver implementing some Linux generic framework would be idael :)
> 
> But if that does not fit, yeah then syscon makes sense as that IO range
> will be on separate interconnect driver (and clock and possibly power domain)
> instances eventually.
> 

I will go ahead with syscon for accessing CTRL_CORE_CONTROL_IO_2 register.

-- 
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 3/5] mtd: devices: m25p80: add support for mmap read request

[Vignesh R]

Hi,

On 12/03/2015 03:12 PM, Cyrille Pitchen wrote:
> Hi Vignesh,
> 
> Le 30/11/2015 06:15, Vignesh R a écrit :
>> Certain spi controllers may provide accelerated interface to read from
>> m25p80 type flash devices. This interface provides better read
>> performance than regular SPI interface.
>> Call spi_flash_read(), if supported, to make use of such interface.
>>
>> Signed-off-by: Vignesh R 
>> ---
>>
>> v4: 
>>  * Use spi_flash_read_message struct to pass args.
>>  * support passing of opcode/addr/data nbits.
>>
>>  drivers/mtd/devices/m25p80.c | 20 
>>  1 file changed, 20 insertions(+)
>>
>> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
>> index fe9ceb7b5405..00094a668c62 100644
>> --- a/drivers/mtd/devices/m25p80.c
>> +++ b/drivers/mtd/devices/m25p80.c
>> @@ -131,6 +131,26 @@ static int m25p80_read(struct spi_nor *nor, loff_t 
>> from, size_t len,
>>  /* convert the dummy cycles to the number of bytes */
>>  dummy /= 8;
>>  
>> +if (spi_flash_read_supported(spi)) {
>> +struct spi_flash_read_message msg;
>> +int ret;
>> +
>> +msg.buf = buf;
>> +msg.from = from;
>> +msg.len = len;
>> +msg.read_opcode = nor->read_opcode;
>> +msg.addr_width = nor->addr_width;
>> +msg.dummy_bytes = dummy;
>> +/* TODO: Support other combinations */
>> +msg.opcode_nbits = SPI_NBITS_SINGLE;
>> +msg.addr_nbits = SPI_NBITS_SINGLE;
>> +msg.data_nbits = m25p80_rx_nbits(nor);
> 
> I wanted to let you know that the support of other SPI protocols has already
> been implemented by this series:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/371170.html
> 
> patches 2 & 3 handle the probing of the (Q)SPI memory in spi_nor_scan() and
> select the right protocols for register read/write, memory read, memory write,
> and memory erase operations. The choice is done according to both the memory
> and SPI controller capabilities.
> 
> patch 4 updates the m25p80 driver to take advantage of the bandwidth increase
> allowed by QSPI protocols. For instance, the Atmel QSPI controller, like TI
> one, maps the SPI NOR memory to the system bus. Yesterday I ran mtd_speedtest
> to compare Fast Read 1-1-1 (0x0b) and Fast Read 1-1-4 (0x6b). The SPI clock
> frequency was limited to 83MHz. The QSPI memory is a Micron n25q128a13.
> 
> I only had to change the mode argument of spi_nor_scan() from SPI_NOR_QUAD to
> SPI_NOR_FAST in the atmel_quadspi driver (based on fsl-quadspi driver from
> Freescale since Atmel's driver also uses the system bus mapping for memory
> write operations) to force the spi-nor framework to choose the SPI 1-1-1
> protocol instead of the SPI-1-1-4.
> 
> 1 - Fast Read 1-1-1
> 
> mtd_speedtest: testing eraseblock write speed
> mtd_speedtest: eraseblock read speed is 9319 KiB/s
> [...]
> mtd_speedtest: testing page read speed
> mtd_speedtest: page read speed is 6649 KiB/s
> [...]
> mtd_speedtest: testing 2 page read speed
> mtd_speedtest: 2 page read speed is 7757 KiB/s
> 
> 2 - Fast Read 1-1-4
> 
> mtd_speedtest: testing eraseblock read speed
> mtd_speedtest: eraseblock read speed is 30117 KiB/s
> [...]
> mtd_speedtest: testing page read speed
> mtd_speedtest: page read speed is 13096 KiB/s
> [...]
> mtd_speedtest: testing 2 page read speed
> mtd_speedtest: 2 page read speed is 18224 KiB/s
> 
> So the performance improvements are:
> eraseblock read speed (65536 bytes) : +223%
> page read speed (512 bytes) :  +97%
> 2 page read speed (1024 bytes)  : +135%
> 
> 
> That's why I believe that you could take advantage of these performance
> improvements in the TI (Q)SPI controller driver.
> 

Well, I based my patches on linux-next as per Brian's suggestion. If
patches to support other flash protocol modes are accepted, I would be
happy to rebase and make use of other modes. It would just be the matter
of populating msg.{opcode/addr}_n_bits correctly.


> 
> Also please note that you may have to add in the struct spi_flash_read_message
> two other fields for the number of option/mode cycles and their value.
> Option/mode cycles are sent between the address and dummy cycles. They are
> used by some memory manufacturers such as Spansion, Micron and Macronix to
> enter/leave their continuous read mode.
> So if uninitialized dummy cycles are interpreted by the QSPI memory as
> option/mode cycles, depending on the actual value, the memory may enter by
> mistake in continuous mode. Once in continuous mode, the command op code byte
> must not be sent and is not expected by the memory: the memory implicitly uses
> the read op code sent in the SPI message which triggered the memory to enter
> continuous read mode. Next SPI messages start from the address cycles until
> the right option/mode cycles are sent to leave the continuous read mode.
> 
> Currently the mtd layer doesn't use this feature but 

Re: [PATCH] irqchip: omap-intc: fix spurious irq handling

[Sekhar Nori]

Hi Tony,

On Tuesday 20 October 2015 08:22 PM, Tony Lindgren wrote:
> * John Ogness  [151020 00:33]:
>> On 2015-10-20, Sekhar Nori  wrote:
 Do you know what really is causing the spurious interrupts in your
 case?
>>>
>>> No, not yet.
>>
>> According to the TRM this is normal behavior if conditions that might
>> affect priority are changed during priority sorting.
>>
>> 6.2.5 ARM A8 INTC Spurious Interrupt Handling
>>
>> The spurious flag indicates whether the result of the sorting (a
>> window of 10 INTC functional clock cycles after the interrupt
>> assertion) is invalid. The sorting is invalid if:
>>
>> - The interrupt that triggered the sorting is no longer active
>>   during the sorting.
>>
>> - A change in the mask has affected the result during the sorting
>>   time.
>>
 In all the cases I've seen, the spurious interrupts were caused by a
 missing flush of posted write acking the IRQ at the device driver.
 for the _previously triggered_ INTC interrupt.

 If you have a reproducable case, I suggest you test that by printing
 out the previous interrupt to check if that makes sense. And then see
 if adding the missing read back to that interrupt handler fixes the
 issue.
>>>
>>> Okay, thats good to know. Thanks for the hints and history of your debug
>>> on OMAP3. The issue is not easily reproducible in my case. But if I try
>>> hard enough, I can get hit it though. So I can surely try your hints.
>>
>> I can reproduce the situation very easily. After running a test for a
>> few minutes and printing out the previous interrupt, I have the
>> following list. These are the irq numbers seen by the handler before the
>> spurious interrupt triggered.
>>
>> INT12 - EDMACOMPINT - TPCC (EDMA)
>> INT41 - 3PGSWRXINT0 - CPSW (Ethernet)
>> INT42 - 3PGSWTXINT0 - CPSW (Ethernet)
>> INT68 - TINT2   - DMTIMER2
>> INT72 - UART0INT- UART0
>>
>> From this I do not think we can put the blame on any single driver. I
>> trigger this situation very easily by putting a load of 7,000+
>> interrupts per second on the system. This means we have 70,000 INTC
>> clock cycles per second where a change in the interrupt priority
>> conditions would cause the priority sorting to become invalid and thus
>> cause the spurious interrupt.
>>
>> I'm not sure if we can/should do anything more than Sekhar's patch of
>> acknowledging the spurious interrupt so the priority sorting algorithm
>> can run again.
> 
> OK thanks for testing. My guess from the above list would be EDMA
> or CPSW missing a flush of posted write. Maybe try adding a readback
> of the related device revision register after acking the interrupt into
> TPCC interrupt handler and CPSW interrupt handler(s)?

I could get back to debugging this only now. I have converted
__raw_writel to writel() and also added readback from the same register
in both EDMA and CPSW drivers. But I am still able to reproduce the
spurious irq reports.

> The timer2 and uart0 seem to be false positives here naturally.

I also added readback in 8250 driver. I haven't touched the timer
driver, but I guess if that driver had an issue, it should have come out
much earlier.

I also saw that sometimes previous irq was the TI LCDC interrupt. Added
readback there too. Did not help.

> I would not yet rule out the "previous interrupt" theory until you have
> tried that. We really want to know the root cause of the issue, just
> printing out spurious interrupt does not fix the problem :)

While we cannot rule out a software issue completely, the description in
TRM around spurious interrupts suggests it can happen even with no role
of software.

May I suggest we go ahead and add this patch to the kernel after
addressing Thomas's comment? At least it will prevent kernel from
locking up with flood of prints when a spurious irq happens and allows
easier debug by others too.

Thanks,
Sekhar

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

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

[Roger Quadros]

On 03/12/15 11:52, Brian Norris wrote:
> Hi,
> 
> On Thu, Dec 03, 2015 at 11:38:14AM +0530, Roger Quadros wrote:
>> On 03/12/15 10:39, Brian Norris wrote:
>>> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
 We do a couple of things in this series which result in
 cleaner device tree implementation, faster perfomance and
 multi-platform support. As an added bonus we get new GPI/Interrupt pins
 for use in the system.

 - Establish a custom interface between NAND and GPMC driver. This is
 needed because all of the NAND registers sit in the GPMC register space.
 Some bits like NAND IRQ are even shared with GPMC.

 - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
 with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
 This causes performance increase when using prefetch-irq mode.
 30% increase in read, 17% increase in write in prefetch-irq mode.

 - Clean up device tree support so that omap-gpmc IP and the omap2 NAND
 driver can be used on non-OMAP platforms. e.g. Keystone.

 - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
 2 to 4 of these and most of them would be unused otherwise. It also
 allows a cleaner implementation of NAND Ready pin status for the NAND 
 driver.

 - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.

 This series is available at
 g...@github.com:rogerq/linux.git
 in branch
 for-v4.4/gpmc-v3

 cheers,
 -roger

 Changelog:
 v3:
 -Fixed and tested NAND using legacy boot on omap3-beagle.
 -Support rising and falling edge interrupts on WAITpins.
 -Update DT node of all gpmc users.
>>>
>>> The MTD stuff looks mostly good to me know. I've made all my comments
>>> for now, but I'm not sure how you're going to end up rebasing/splitting
>>> and what you're going to do with the irqchip removal, so I'll refrain
>>> from ack's for now. Hopefully I can either ack or merge v4.
>>
>> I'll retain the irqchip model for now and send a v4 with all comments
>> addressed and better subsystem wise patch split.
>>
>>>
>>> I brought it up on one other patch, but it's not really clear to me what
>>> the split is on board file vs. device tree handling, since you seem to
>>> have a combination of both (i.e., platform data that passes along device
>>> nodes). What's the plan on that?
>>
>> Platform data no longer passes device nodes. We're either true device tree
>> or plain legacy. The deprecated fields are no longer used once the series is
>> applied.
> 
> Well, they're still sorta used (you assign info->of_node =
> pdata->of_node, for instance). As dicussed in the other thread, I think
> we can avoid the deprecation part and just kill the fields though, and
> that would make things clearer.
> 
>>> And of course, there's the question of how exactly to merge this, given
>>> the:
>>> (1) conflicts already existing in the MTD dev tree
>>
>> I'll rebase the series on top of MTD dev tree.
> 
> OK. FWIW, we so far only need to base them on commit a61ae81a1907 ("mtd:
> nand: drop unnecessary partition parser data"). Maybe when queueing up a
> branch, that'd be the best starting point for Tony, so he doesn't need
> to have all of MTD's stuff in his tree too? I can set up a signed tag or
> something, if that would be helpful.
> 
> But for sending patches, the latest l2-mtd.git is fine too.
> 
>>> (2) this touches several trees, often in the same patch and
>>
>> I'll try my best to split the patches but not sure if this could be 100%
>> clean split without functional breakage.
>>
>>> (3) even if the patches were split out a little better into MTD and
>>> non-MTD stuff, I think there would still be dependencies such that
>>> we'd need at least 1 (probably 2) cross merges to get it all
>>> straight
>>
>> That is correct.
>> Is it OK if functionality breaks if for example only MTD changes are 
>> considered?
> 
> I think I may have misunderstood the branch proposal. If Tony queues up:
> 
>   l2-mtd.git (or just up to commit a61ae81a1907)
>   +
>   your patches
> 
> and I pull that back into l2-mtd.git as well, then we don't need to
> worry about patches that touch multiple "trees". Just do whatever makes
> things clearest, including disregarding some of my comments along the
> line of (3).

Tony,

Are you fine with this?

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/13] USB: OTG/DRD Core functionality

[Peter Chen]

On Mon, Aug 24, 2015 at 04:21:11PM +0300, Roger Quadros wrote:
> Hi,
> 
> This series centralizes OTG/Dual-role functionality in the kernel.
> As of now I've got Dual-role functionality working pretty reliably on
> dra7-evm and am437x-gp-evm.
> 
> DWC3 controller and platform related patches will be sent separately.
> 
> Series is based on Greg's usb-next tree.

Hi Roger,

Will you go on for this patch set?

Peter
> 
> Changelog:
> -
> v4:
> - Added DT support for tying otg-controller to host and gadget
>  controllers. For DT we no longer have the constraint that
>  OTG controller needs to be parent of host and gadget. They can be
>  tied together using the "otg-controller" property.
> - Relax the requirement for DT case that otg controller must register before
>  host/gadget. We maintain a wait list of host/gadget devices
>  waiting on the otg controller.
> - Use a single struct usb_otg for otg data.
> - Don't override host/gadget start/stop APIs. Let the controller
>  drivers do what they want as they know best. Helper API is provided
>  for controller start/stop that controller driver can use.
> - Introduce struct usb_otg_config to pass the otg capabilities,
>  otg ops and otg timer timeouts during otg controller registration.
> - rebased on Greg's usb.git/usb-next
> 
> v3:
> - all otg related definations now in otg.h
> - single kernel config USB_OTG to enable OTG core and FSM.
> - resolved symbol dependency issues.
> - use dev_vdbg instead of VDBG() in usb-otg-fsm.c
> - rebased on v4.2-rc1
> 
> v2:
> - Use add/remove_hcd() instead of start/stop_hcd() to enable/disable
>  the host controller
> - added dual-role-device (DRD) state machine which is a much simpler
>  mode of operation when compared to OTG. Here we don't support fancy
>  OTG features like HNP, SRP, on the fly role-swap. The mode of operation
>  is determined based on ID pin (cable type) and the role doesn't change
>  till the cable type changes.
> 
> Why?:
> 
> 
> Most of the OTG drivers have been dealing with the OTG state machine
> themselves and there is a scope for code re-use. This has been
> partly addressed by the usb/common/usb-otg-fsm.c but it still
> leaves the instantiation of the state machine and OTG timers
> to the controller drivers. We re-use usb-otg-fsm.c but
> go one step further by instantiating the state machine and timers
> thus making it easier for drivers to implement OTG functionality.
> 
> Newer OTG cores support standard host interface (e.g. xHCI) so
> host and gadget functionality are no longer closely knit like older
> cores. There needs to be a way to co-ordinate the operation of the
> host and gadget in OTG mode. i.e. to stop and start them from a
> central location. This central location should be the USB OTG core.
> 
> Host and gadget controllers might be sharing resources and can't
> be always running. One has to be stopped for the other to run.
> This can't be done as of now and can be done from the OTG core.
> 
> What?:
> -
> 
> The OTG core instantiates the OTG/DRD Finite State Machine
> per OTG controller and manages starting/stopping the
> host and gadget controllers based on the bus state.
> 
> It provides APIs for the following
> 
> - Registering an OTG capable controller
> struct otg_fsm *usb_otg_register(struct device *dev,
>  struct usb_otg_config *config);
> 
> int usb_otg_unregister(struct device *dev);
> 
> - Registering Host controllers to OTG core (used by hcd-core)
> int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>  unsigned long irqflags, struct otg_hcd_ops *ops);
> int usb_otg_unregister_hcd(struct usb_hcd *hcd);
> 
> 
> - Registering Gadget controllers to OTG core (used by udc-core)
> int usb_otg_register_gadget(struct usb_gadget *gadget,
> struct otg_gadget_ops *ops);
> int usb_otg_unregister_gadget(struct usb_gadget *gadget);
> 
> 
> - Providing inputs to and kicking the OTG state machine
> void usb_otg_sync_inputs(struct otg_fsm *fsm);
> int usb_otg_kick_fsm(struct device *hcd_gcd_device);
> 
> - Getting controller device structure from OTG state machine instance
> struct device *usb_otg_fsm_to_dev(struct otg_fsm *fsm);
> 
> 'struct otg_fsm' is the interface to the OTG state machine.
> It contains inputs to the fsm, status of the fsm and operations
> for the OTG controller driver.
> 
> - Helper APIs for starting/stopping host/gadget controllers
> int usb_otg_start_host(struct otg_fsm *fsm, int on);
> int usb_otg_start_gadget(struct otg_fsm *fsm, int on);
> 
> Usage model:
> ---
> 
> - The OTG core needs to know what host and gadget controllers are
> linked to the OTG controller. For DT boots we can provide that
> information by adding "otg-controller" property to the host and
> gadget controller nodes that points to the right otg controller.
> For legacy boot we assume that OTG controller is the parent
> of the host and gadget controllers. For DT if 

Re: [PATCH 5/7] ARM: w90x900: make headers more local

[Wan ZongShun]

2015-12-01 7:00 GMT+08:00 Arnd Bergmann :
> Some header files are never included outside of a mach-w90x900
> directory and do not need to be made visible in include/mach,
> so let's just move them all down one level.
>
> Signed-off-by: Arnd Bergmann 

Acked-by: Wan Zongshun 

Thanks!

> ---
>  arch/arm/mach-w90x900/cpu.c   | 4 ++--
>  arch/arm/mach-w90x900/{include/mach => }/regs-ebi.h   | 0
>  arch/arm/mach-w90x900/{include/mach => }/regs-gcr.h   | 0
>  arch/arm/mach-w90x900/{include/mach => }/regs-timer.h | 0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib

[Boris Brezillon]

Hi Brian,

On Wed, 2 Dec 2015 20:45:44 -0800
Brian Norris  wrote:

> (to be clear, this branch of discussion isn't directly regarding the TI
> changes; we can handle any generic handling afterward, as long as we get
> the DT binding right now)
> 
> On Tue, Oct 27, 2015 at 09:28:32AM +0100, Boris Brezillon wrote:
> > On Mon, 26 Oct 2015 13:49:00 -0700
> > Brian Norris  wrote:
> > > On Fri, Sep 18, 2015 at 05:53:40PM +0300, Roger Quadros wrote:
> > > > @@ -1782,7 +1780,9 @@ static int omap_nand_probe(struct platform_device 
> > > > *pdev)
> > > > info->reg = pdata->reg;
> > > > info->of_node = pdata->of_node;
> > > > info->ecc_opt = pdata->ecc_opt;
> > > > -   info->dev_ready = pdata->dev_ready;
> > > > +   if (pdata->dev_ready)
> > > > +   dev_info(>dev, "pdata->dev_ready is 
> > > > deprecated\n");
> > > > +
> > > > info->xfer_type = pdata->xfer_type;
> > > > info->devsize = pdata->devsize;
> > > > info->elm_of_node = pdata->elm_of_node;
> > > > @@ -1815,6 +1815,13 @@ static int omap_nand_probe(struct 
> > > > platform_device *pdev)
> > > > nand_chip->IO_ADDR_W = nand_chip->IO_ADDR_R;
> > > > nand_chip->cmd_ctrl  = omap_hwcontrol;
> > > >  
> > > > +   info->ready_gpiod = devm_gpiod_get_optional(>dev, "ready",
> > > > +   GPIOD_IN);
> > > 
> > > Others have been looking at using GPIOs for the ready/busy pin too. At a
> > > minimum, we need an updated DT binding doc for this, since I see you're
> > > adding this via device tree in a later patch (I don't see any DT binding
> > > patch for this; but I could just be overlooking it). It'd also be great
> > > if this support was moved to nand_dt_init() so other platforms can
> > > benefit, but I won't require that.
> > 
> > Actually I started to work on a generic solution parsing the DT and
> > creating CS, WP and RB gpios when they are provided, but I think it's a
> > bit more complicated than just moving the rb-gpios parsing into
> > nand_dt_init().
> > First you'll need something to store your gpio_desc pointers, which
> > means you'll have to allocate a table of gpio_desc pointers (or a table
> > of struct embedding a gpio_desc pointer).
> 
> I'm not sure what you mean by table. It seems like we would just have a
> few gpio_desc pointers in struct nand_chip, no?

Nope, because a single nand_chip can use several CS and R/B lines,
hence the gpio_desc array.

> 
> > The other blocking point is that when nand_scan_ident() is called, the
> > caller is supposed to have filled the ->dev_ready() or ->waitfunc()
> > fields, and to choose how to implement it he may need to know
> > which kind of RB handler should be used (this is the case in the sunxi
> > driver, where the user can either use a GPIO or native R/B pin directly
> > connected to the controller).
> 
> Right, I was thinking about this one.
> 
> > All this makes me think that maybe nand_dt_init() should be called
> > separately or in a different helper (nand_init() ?) taking care of the
> > basic nand_chip initializations/allocations without interacting with
> > the NAND itself.
> 
> Yeah, I feel like there have been other good reasons for something like
> this before, and we just have worked around them so far. Maybe something
> more like the alloc/add split in many other subsystems? e.g.,
> platform_device_{alloc,add}, spi_{alloc,add}_device. Now we might want
> nand_alloc()?
> 
> On a slight tangent, it seems silly that nand_scan_tail() doesn't
> register the MTD, but nand_release() unregisters it. That shouldn't be.

Yep, that's one of the things we should address too.

> 
> > Another solution would be to add an ->init() function to nand_chip
> > and call it after the generic initialization has been done (but before
> > NAND chip detection). This way the NAND controller driver could adapt
> > some fields and parse controller specific properties.
> 
> That could work too, I guess.

Hm, all these suggestions have been made before I started my
nand_controller/nand_chip separation work, and I think we can get
something way simpler if we switch to a model where the core
implements most of the initialization steps (including parsing of
generic DT properties) and ask the controller to do its specific
initialization (as is done in the SPI subsystem for example).

If you want to have an idea of where I'm heading to, you can have a
look at the last commits in this branch [1]. The generic DT parsing is
not yet automated but it could easily be places here [2], so that when
controller->ops->add() is called everything is in place and the driver
can overload the default behavior with its own implementation.

Any objection to this approach?

Best Regards,

Boris

[1]https://github.com/bbrezillon/linux-sunxi/commits/nand/layering-rework

Re: [PATCH v4 00/13] USB: OTG/DRD Core functionality

[Roger Quadros]

Peter,

On 03/12/15 13:49, Peter Chen wrote:
> On Mon, Aug 24, 2015 at 04:21:11PM +0300, Roger Quadros wrote:
>> Hi,
>>
>> This series centralizes OTG/Dual-role functionality in the kernel.
>> As of now I've got Dual-role functionality working pretty reliably on
>> dra7-evm and am437x-gp-evm.
>>
>> DWC3 controller and platform related patches will be sent separately.
>>
>> Series is based on Greg's usb-next tree.
> 
> Hi Roger,
> 
> Will you go on for this patch set?

Yes, but I can only work on this from Feb onwards.

cheers,
-roger
> 
> Peter
>>
>> Changelog:
>> -
>> v4:
>> - Added DT support for tying otg-controller to host and gadget
>>  controllers. For DT we no longer have the constraint that
>>  OTG controller needs to be parent of host and gadget. They can be
>>  tied together using the "otg-controller" property.
>> - Relax the requirement for DT case that otg controller must register before
>>  host/gadget. We maintain a wait list of host/gadget devices
>>  waiting on the otg controller.
>> - Use a single struct usb_otg for otg data.
>> - Don't override host/gadget start/stop APIs. Let the controller
>>  drivers do what they want as they know best. Helper API is provided
>>  for controller start/stop that controller driver can use.
>> - Introduce struct usb_otg_config to pass the otg capabilities,
>>  otg ops and otg timer timeouts during otg controller registration.
>> - rebased on Greg's usb.git/usb-next
>>
>> v3:
>> - all otg related definations now in otg.h
>> - single kernel config USB_OTG to enable OTG core and FSM.
>> - resolved symbol dependency issues.
>> - use dev_vdbg instead of VDBG() in usb-otg-fsm.c
>> - rebased on v4.2-rc1
>>
>> v2:
>> - Use add/remove_hcd() instead of start/stop_hcd() to enable/disable
>>  the host controller
>> - added dual-role-device (DRD) state machine which is a much simpler
>>  mode of operation when compared to OTG. Here we don't support fancy
>>  OTG features like HNP, SRP, on the fly role-swap. The mode of operation
>>  is determined based on ID pin (cable type) and the role doesn't change
>>  till the cable type changes.
>>
>> Why?:
>> 
>>
>> Most of the OTG drivers have been dealing with the OTG state machine
>> themselves and there is a scope for code re-use. This has been
>> partly addressed by the usb/common/usb-otg-fsm.c but it still
>> leaves the instantiation of the state machine and OTG timers
>> to the controller drivers. We re-use usb-otg-fsm.c but
>> go one step further by instantiating the state machine and timers
>> thus making it easier for drivers to implement OTG functionality.
>>
>> Newer OTG cores support standard host interface (e.g. xHCI) so
>> host and gadget functionality are no longer closely knit like older
>> cores. There needs to be a way to co-ordinate the operation of the
>> host and gadget in OTG mode. i.e. to stop and start them from a
>> central location. This central location should be the USB OTG core.
>>
>> Host and gadget controllers might be sharing resources and can't
>> be always running. One has to be stopped for the other to run.
>> This can't be done as of now and can be done from the OTG core.
>>
>> What?:
>> -
>>
>> The OTG core instantiates the OTG/DRD Finite State Machine
>> per OTG controller and manages starting/stopping the
>> host and gadget controllers based on the bus state.
>> 
>> It provides APIs for the following
>> 
>> - Registering an OTG capable controller
>> struct otg_fsm *usb_otg_register(struct device *dev,
>>  struct usb_otg_config *config);
>>
>> int usb_otg_unregister(struct device *dev);
>>
>> - Registering Host controllers to OTG core (used by hcd-core)
>> int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>>  unsigned long irqflags, struct otg_hcd_ops *ops);
>> int usb_otg_unregister_hcd(struct usb_hcd *hcd);
>>
>>
>> - Registering Gadget controllers to OTG core (used by udc-core)
>> int usb_otg_register_gadget(struct usb_gadget *gadget,
>> struct otg_gadget_ops *ops);
>> int usb_otg_unregister_gadget(struct usb_gadget *gadget);
>>
>>
>> - Providing inputs to and kicking the OTG state machine
>> void usb_otg_sync_inputs(struct otg_fsm *fsm);
>> int usb_otg_kick_fsm(struct device *hcd_gcd_device);
>>
>> - Getting controller device structure from OTG state machine instance
>> struct device *usb_otg_fsm_to_dev(struct otg_fsm *fsm);
>>
>> 'struct otg_fsm' is the interface to the OTG state machine.
>> It contains inputs to the fsm, status of the fsm and operations
>> for the OTG controller driver.
>>
>> - Helper APIs for starting/stopping host/gadget controllers
>> int usb_otg_start_host(struct otg_fsm *fsm, int on);
>> int usb_otg_start_gadget(struct otg_fsm *fsm, int on);
>>
>> Usage model:
>> ---
>>
>> - The OTG core needs to know what host and gadget controllers are
>> linked to the OTG controller. For DT boots we can provide that
>> information by adding 

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

[Peter Ujfalusi]

On 12/02/2015 04:35 PM, Andy Shevchenko wrote:
>> +const static struct dma_filter_map *dma_filter_match(struct dma_device 
>> *device,
>> +  const char *name,
>> +  struct device *dev)
>> +{
>> +   const struct dma_filter_map *map_found = NULL;
>> +   int i;
>> +
>> +   if (!device->filter_map.mapcnt)
>> +   return NULL;
>> +
>> +   for (i = 0; i < device->filter_map.mapcnt; i++) {
>> +   const struct dma_filter_map *map = 
>> >filter_map.map[i];
>> +
>> +   if (!strcmp(map->devname, dev_name(dev)) &&
>> +   !strcmp(map->slave, name)) {
>> +   map_found = map;
>> +   break;
> 
> return map?
> 
>> +   }
>> +   }
>> +
> 
> return NULL;

OK.

> 
>> +   return map_found;
>> +}
>> +
>> +/**
>> + * dma_request_chan - try to allocate an exclusive slave channel
>> + * @dev:   pointer to client device structure
>> + * @name:  slave channel name
>> + *
>> + * Returns pointer to appropriate DMA channel on success or an error 
>> pointer.
>> + */
>> +struct dma_chan *dma_request_chan(struct device *dev, const char *name)
>> +{
>> +   struct dma_device *device, *_d;
> 
> If you name *d, *_d; it would…
> 
>> +   struct dma_chan *chan = NULL;
>> +
> 
>> +   /* If device-tree is present get slave info from here */
>> +   if (dev->of_node)
>> +   chan = of_dma_request_slave_channel(dev->of_node, name);
>> +
>> +   /* If device was enumerated by ACPI get slave info from here */
>> +   if (has_acpi_companion(dev) && !chan)
>> +   chan = acpi_dma_request_slave_chan_by_name(dev, name);
> 
> This part might be a good candidate to be moved to
> drivers/base/property.c as
> struct dma_chan *device_property_dma_request_chan(…) or alike.

Not sure if it is a good idea. We want users to use the dmaengine API for
requesting DMA channels, but if we just add renamed
dma_request_slave_channel_reason() - essentially the
device_property_dma_request_chan() would be the same - what users will stop to
use some random API to request the channel?
I'm not really sure if something which is returning 'struct dma_chan *' can be
considered as property to anything. The DMA request number can be seen as a
property for a given device, but a dmaengine related pointer?

Actually I was thinking to move the declaration for these from
include/linux/of_dma.h/acpi_dma.h to a header under drivers/dma/

Also move as much local to dmaengine as it is possible to have cleaner
interface towards the client drivers.

> 
>> +
>> +   if (chan) {
>> +   /* Valid channel found */
>> +   if (!IS_ERR(chan))
>> +   return chan;
>> +
> 
> They might return EPROBE_DEFER. Is any specific handling needed here?

-EPROBE_DEFER means that the DMA driver is not yet loaded and in this case the
lookup for the filter function would also fail, but we have additional and
needless warning printed out. It is better to return with the deferred code 
also.

> 
>> +   pr_warn("%s: %s DMA request failed, falling back to 
>> legacy\n",
>> +   __func__, dev->of_node ? "OF" : "ACPI");
>> +   }
>> +
>> +   /* Try to find the channel via the DMA filter map(s) */
>> +   mutex_lock(_list_mutex);
>> +   list_for_each_entry_safe(device, _d, _device_list, global_node) {
>> +   dma_cap_mask_t mask;
>> +   const struct dma_filter_map *map = dma_filter_match(device,
>> +   name, 
>> dev);
>> +
>> +   if (!map)
>> +   continue;
>> +
>> +   dma_cap_zero(mask);
>> +   dma_cap_set(DMA_SLAVE, mask);
>> +
>> +   chan = find_candidate(device, ,
>> + device->filter_map.filter_fn, 
>> map->param);
> 
> …allow to put this on single line I believe.

if not in one line, but will look much better.

> 
>> +   if (!IS_ERR(chan))
>> +   break;
>> +   }
>> +   mutex_unlock(_list_mutex);
>> +
>> +   return chan ? chan : ERR_PTR(-EPROBE_DEFER);
>> +}
>> +EXPORT_SYMBOL_GPL(dma_request_chan);
>> +
>> +/**
>> + * dma_request_chan_by_mask - allocate a channel satisfying certain 
>> capabilities
>> + * @mask: capabilities that the channel must satisfy
>> + *
>> + * Returns pointer to appropriate DMA channel on success or an error 
>> pointer.
>> + */
>> +struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask)
>> +{
>> +   struct dma_chan *chan;
>> +
>> +   if (!mask)
>> +   return ERR_PTR(-ENODEV);
>> +
>> +   chan = __dma_request_channel(mask, NULL, NULL);
>> +   if (!chan)
>> +   chan = ERR_PTR(-ENODEV);
>> +
>> +   return chan;
>> +}
>> 

[PATCH 0/4] dmaengine: New 'universal' API for requesting channel

[Peter Ujfalusi]

Hi,

Changes since RFC v03:
- No longer RFC
- Dropped the arch/arm/mcah-davinci and daVinci MMC and SPI patches so we don't
  have inter subsystem issues.
- Comments from Andy to patch no 3 has been addressed with the exception of
  moving code over to device_property
- 'struct dma_filter_map' renamed as 'struct dma_slave_map'
- Code documentation added

Changes since RFC v02:
- Using has_acpi_companion() instead ACPI_HANDLE()
- mask matching change within private_candidate()
- Fallback in dma_request_chan() when DT/ACPI lookup fails.
- Rename dma_get_channel() -> find_candidate()
- Arch code changes as suggested by Arnd
- Some documentation updated, more need to be done.

Changes since RFC v01:
- dma_request_chan(); lost the mask parameter
- The new API does not rely on RESOURCE_DMA, instead the dma_slave_map table
  will be used to provide the needed information to the filter function in
  legacy mode
- Extended the example patches to convert most of daVinci to use the new API to
  request the DMA channels.

As it has been discussed in the following thread:
http://www.gossamer-threads.com/lists/linux/kernel/2181487#2181487

With this series I have taken a path which would result two new API, which can
be used to convert most of the current users already and with some work all
users might be able to move to this set.
With this set the filter_fn used for legacy (non DT/ACPI) channel request is no
longer needed to be exported to client drivers since the selection of the
correct filter_fn will be done in the core.

So, the first proposal is to have:

struct dma_chan *dma_request_chan(struct device *dev, const char *name);
struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);

The dma_request_chan_by_mask() is to request any channel matching with the
requested capabilities, can be used to request channel for memcpy, memset, xor,
etc where no hardware synchronization is needed.

The dma_request_chan() is to request a slave channel. The dma_request_chan()
will try to find the channel via DT, ACPI or in case if the kernel booted in non
DT/ACPI mode it will use a filter lookup table and retrieves the needed
information from the dma_slave_map provided by the DMA drivers.
This legacy mode needs changes in platform code, in dmaengine drivers and
finally the dmaengine user drivers can be converted:

For each dmaengine driver an array of DMA device, slave and the parameter
for the filter function needs to be added:

static const struct dma_slave_map da830_edma_map[] = {
{ "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 0) },
{ "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 1) },
{ "davinci-mcasp.1", "rx", EDMA_FILTER_PARAM(0, 2) },
{ "davinci-mcasp.1", "tx", EDMA_FILTER_PARAM(0, 3) },
{ "davinci-mcasp.2", "rx", EDMA_FILTER_PARAM(0, 4) },
{ "davinci-mcasp.2", "tx", EDMA_FILTER_PARAM(0, 5) },
{ "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 14) },
{ "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 15) },
{ "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 16) },
{ "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 17) },
{ "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 18) },
{ "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 19) },
};

This information is going to be used by the dmaengine driver, so
modification to the platform_data is needed, and the driver map should be
added to the pdata of the DMA driver:

da8xx_edma0_pdata.slave_map = da830_edma_map;
da8xx_edma0_pdata.slavecnt = ARRAY_SIZE(da830_edma_map);

The DMA driver then needs to configure the needed device -> filter_fn
mapping before it registers with dma_async_device_register() :

if (info->slave_map) {
ecc->dma_slave.filter_map.map = info->slave_map;
ecc->dma_slave.filter_map.mapcnt = info->slavecnt;
ecc->dma_slave.filter_map.filter_fn = edma_filter_fn;
}

When neither DT or ACPI lookup is available the dma_request_chan() will
try to match the requester's device name with the filter_map's list of
device names, when a match found it will use the information from the
dma_slave_map to get the channel with the dma_get_channel() internal
function.

Tested on OMAP-L138 (dm850) EVM, with updtaed patches from RFC v03 [1].
Both legacy and DT boot works fine.

[1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122016.html

Regards,
Peter
---
Peter Ujfalusi (4):
  dmaengine: core: Skip mask matching when it is not provided to
private_candidate
  dmaengine: core: Move and merge the code paths using private_candidate
  dmaengine: core: Introduce new, universal API to request a channel
  dmaengine: edma: Add support for DMA filter mapping to slave devices

 Documentation/dmaengine/client.txt |  23 ++---
 drivers/dma/dmaengine.c| 177 -
 drivers/dma/edma.c |   6 ++
 include/linux/dmaengine.h  |  42 +
 include/linux/platform_data/edma.h |   7 ++
 5 files changed, 198 

[PATCH 2/4] dmaengine: core: Move and merge the code paths using private_candidate

[Peter Ujfalusi]

Channel matching with private_candidate() is used in two paths, the error
checking is slightly different in them and they are duplicating code also.
Move the code under find_candidate() to provide consistent execution and
going to allow us to reuse this mode of channel lookup later.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/dmaengine.c | 81 +
 1 file changed, 42 insertions(+), 39 deletions(-)

diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 6311e1fc80be..ea9d66982d40 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -546,6 +546,42 @@ static struct dma_chan *private_candidate(const 
dma_cap_mask_t *mask,
return NULL;
 }
 
+static struct dma_chan *find_candidate(struct dma_device *device,
+  const dma_cap_mask_t *mask,
+  dma_filter_fn fn, void *fn_param)
+{
+   struct dma_chan *chan = private_candidate(mask, device, fn, fn_param);
+   int err;
+
+   if (chan) {
+   /* Found a suitable channel, try to grab, prep, and return it.
+* We first set DMA_PRIVATE to disable balance_ref_count as this
+* channel will not be published in the general-purpose
+* allocator
+*/
+   dma_cap_set(DMA_PRIVATE, device->cap_mask);
+   device->privatecnt++;
+   err = dma_chan_get(chan);
+
+   if (err) {
+   if (err == -ENODEV) {
+   pr_debug("%s: %s module removed\n", __func__,
+dma_chan_name(chan));
+   list_del_rcu(>global_node);
+   } else
+   pr_debug("%s: failed to get %s: (%d)\n",
+__func__, dma_chan_name(chan), err);
+
+   if (--device->privatecnt == 0)
+   dma_cap_clear(DMA_PRIVATE, device->cap_mask);
+
+   chan = ERR_PTR(err);
+   }
+   }
+
+   return chan ? chan : ERR_PTR(-EPROBE_DEFER);
+}
+
 /**
  * dma_get_slave_channel - try to get specific channel exclusively
  * @chan: target channel
@@ -584,7 +620,6 @@ struct dma_chan *dma_get_any_slave_channel(struct 
dma_device *device)
 {
dma_cap_mask_t mask;
struct dma_chan *chan;
-   int err;
 
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
@@ -592,23 +627,11 @@ struct dma_chan *dma_get_any_slave_channel(struct 
dma_device *device)
/* lock against __dma_request_channel */
mutex_lock(_list_mutex);
 
-   chan = private_candidate(, device, NULL, NULL);
-   if (chan) {
-   dma_cap_set(DMA_PRIVATE, device->cap_mask);
-   device->privatecnt++;
-   err = dma_chan_get(chan);
-   if (err) {
-   pr_debug("%s: failed to get %s: (%d)\n",
-   __func__, dma_chan_name(chan), err);
-   chan = NULL;
-   if (--device->privatecnt == 0)
-   dma_cap_clear(DMA_PRIVATE, device->cap_mask);
-   }
-   }
+   chan = find_candidate(device, , NULL, NULL);
 
mutex_unlock(_list_mutex);
 
-   return chan;
+   return IS_ERR(chan) ? NULL : chan;
 }
 EXPORT_SYMBOL_GPL(dma_get_any_slave_channel);
 
@@ -625,35 +648,15 @@ struct dma_chan *__dma_request_channel(const 
dma_cap_mask_t *mask,
 {
struct dma_device *device, *_d;
struct dma_chan *chan = NULL;
-   int err;
 
/* Find a channel */
mutex_lock(_list_mutex);
list_for_each_entry_safe(device, _d, _device_list, global_node) {
-   chan = private_candidate(mask, device, fn, fn_param);
-   if (chan) {
-   /* Found a suitable channel, try to grab, prep, and
-* return it.  We first set DMA_PRIVATE to disable
-* balance_ref_count as this channel will not be
-* published in the general-purpose allocator
-*/
-   dma_cap_set(DMA_PRIVATE, device->cap_mask);
-   device->privatecnt++;
-   err = dma_chan_get(chan);
+   chan = find_candidate(device, mask, fn, fn_param);
+   if (!IS_ERR(chan))
+   break;
 
-   if (err == -ENODEV) {
-   pr_debug("%s: %s module removed\n",
-__func__, dma_chan_name(chan));
-   list_del_rcu(>global_node);
-   } else if (err)
-   pr_debug("%s: failed to get %s: (%d)\n",
-__func__, 

[PATCH 4/4] dmaengine: edma: Add support for DMA filter mapping to slave devices

[Peter Ujfalusi]

Add support for providing device to filter_fn mapping so client drivers
can switch to use the dma_request_chan() API.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 6 ++
 include/linux/platform_data/edma.h | 7 +++
 2 files changed, 13 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 0675e268d577..46b305ea0d21 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -2297,6 +2297,12 @@ static int edma_probe(struct platform_device *pdev)
edma_set_chmap(>slave_chans[i], ecc->dummy_slot);
}
 
+   if (info->slave_map) {
+   ecc->dma_slave.filter_map.map = info->slave_map;
+   ecc->dma_slave.filter_map.mapcnt = info->slavecnt;
+   ecc->dma_slave.filter_map.filter_fn = edma_filter_fn;
+   }
+
ret = dma_async_device_register(>dma_slave);
if (ret) {
dev_err(dev, "slave ddev registration failed (%d)\n", ret);
diff --git a/include/linux/platform_data/edma.h 
b/include/linux/platform_data/edma.h
index e2878baeb90e..105700e62ea1 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -53,12 +53,16 @@ enum dma_event_q {
 #define EDMA_CTLR(i)   ((i) >> 16)
 #define EDMA_CHAN_SLOT(i)  ((i) & 0x)
 
+#define EDMA_FILTER_PARAM(ctlr, chan)  ((int[]) { EDMA_CTLR_CHAN(ctlr, chan) })
+
 struct edma_rsv_info {
 
const s16   (*rsv_chans)[2];
const s16   (*rsv_slots)[2];
 };
 
+struct dma_slave_map;
+
 /* platform_data for EDMA driver */
 struct edma_soc_info {
/*
@@ -76,6 +80,9 @@ struct edma_soc_info {
 
s8  (*queue_priority_mapping)[2];
const s16   (*xbar_chans)[2];
+
+   const struct dma_slave_map *slave_map;
+   int slavecnt;
 };
 
 #endif
-- 
2.6.3

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

Re: [PATCH V2 12/14] ARM: dts: sb-som: introduce SB-SOM baseboard

[Rob Herring]

On Tue, Dec 01, 2015 at 03:55:07PM +0200, Nikita Kiryanov wrote:
> CompuLab SB-SOM baseboard is a carrier board for multiple arm-based SoMs.
> It currently supports (with minor adjustments to assembly) CM-T43, CM-T54,
> and CM-QS600 modules. It is a building block in the SBC-T43 single board
> computer, which consists of cm-t43 on top of sb-som-t43.
> 
> Signed-off-by: Nikita Kiryanov 
> Cc: Tony Lindgren 
> Cc: Benoit Cousson 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Pawel Moll 
> Cc: Igor Grinberg 
> Cc: Dmitry Lifshitz 
> Cc: Ian Campbell 

Acked-by: Rob Herring 

> ---
> Changes in V2:
>   - Renamed file startek,startek-kd050c to startek,startek-kd050c.txt.
>   - s/QS-600/CM-QS600 in file compulab-boards.txt
> 
>  .../devicetree/bindings/arm/compulab-boards.txt|  5 +++
>  .../display/panel/startek,startek-kd050c.txt   |  4 +++
>  .../devicetree/bindings/vendor-prefixes.txt|  1 +
>  arch/arm/boot/dts/compulab-sb-som.dtsi | 42 
> ++
>  4 files changed, 52 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/compulab-boards.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/startek,startek-kd050c.txt
>  create mode 100644 arch/arm/boot/dts/compulab-sb-som.dtsi
> 
> diff --git a/Documentation/devicetree/bindings/arm/compulab-boards.txt 
> b/Documentation/devicetree/bindings/arm/compulab-boards.txt
> new file mode 100644
> index 000..71172d5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/compulab-boards.txt
> @@ -0,0 +1,5 @@
> +CompuLab SB-SOM is a multi-module baseboard capable of carrying CM-T43, 
> CM-T54,
> +and CM-QS600 modules with minor modifications to the SB-SOM assembly.
> +
> +Required root node properties:
> +- compatible = should be "compulab,sb-som"
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c.txt 
> b/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c.txt
> new file mode 100644
> index 000..70cd8d1
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c.txt
> @@ -0,0 +1,4 @@
> +Startek Electronic Technology Co. KD050C 5.0" WVGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "startek,startek-kd050c"
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 55df1d4..409b134 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -218,6 +218,7 @@ sony  Sony Corporation
>  spansion Spansion Inc.
>  sprd Spreadtrum Communications Inc.
>  st   STMicroelectronics
> +startek  Startek
>  ste  ST-Ericsson
>  stericsson   ST-Ericsson
>  synology Synology, Inc.
> diff --git a/arch/arm/boot/dts/compulab-sb-som.dtsi 
> b/arch/arm/boot/dts/compulab-sb-som.dtsi
> new file mode 100644
> index 000..402a143
> --- /dev/null
> +++ b/arch/arm/boot/dts/compulab-sb-som.dtsi
> @@ -0,0 +1,42 @@
> +/*
> + * Copyright (C) 2015 CompuLab, Ltd. - http://www.compulab.co.il/
> + *
> + * 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.
> + */
> +
> +/ {
> + model = "CompuLab SB-SOM";
> + compatible = "compulab,sb-som";
> +
> + vsb_3v3: fixedregulator-v3_3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vsb_3v3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + enable-active-high;
> + };
> +
> + lcd0: display {
> + compatible = "startek,startek-kd050c", "panel-dpi";
> + label = "lcd";
> +
> + panel-timing {
> + clock-frequency = <3300>;
> + hactive = <800>;
> + vactive = <480>;
> + hfront-porch = <40>;
> + hback-porch = <40>;
> + hsync-len = <43>;
> + vback-porch = <29>;
> + vfront-porch = <13>;
> + vsync-len = <3>;
> + hsync-active = <0>;
> + vsync-active = <0>;
> + de-active = <1>;
> + pixelclk-active = <1>;
> + };
> + };
> +};
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from 

Re: [4.4-rc][PATCH v2] ARM: dts: am4372: fix clock source for arm twd and global timers

[Tony Lindgren]

* Grygorii Strashko  [151130 07:58]:
> ARM TWD and Global timer are clocked by PERIPHCLK which is MPU_CLK/2.
> But now they are clocked by dpll_mpu_m2_ck == MPU_CLK and, as result.
> Timekeeping core misbehaves. For example, execution of command
> "sleep 5" will take 10 sec instead of 5.
> 
> Hence, fix it by adding mpu_periphclk ("fixed-factor-clock") and use
> it for clocking ARM TWD and Global timer (same way as on OMAP4).
> 
> Cc: Tony Lindgren 
> Cc: Felipe Balbi 
> Cc: Tero Kristo 
> Fixes:commit 8cbd4c2f6a99 ("arm: boot: dts: am4372: add ARM timers and SCU 
> nodes")
> Signed-off-by: Grygorii Strashko 

Is this fix alone enough or do you still need to disable other the ARM
timers in the board specific dts file?

Regards,

Tony

> ---
> Changes in v2:
>  - fix: mpu_periphclk should be clocked from dpll_mpu_m2_ck instead of
>dpll_mpu_ck.
> link on v1:
>  http://www.spinics.net/lists/arm-kernel/msg463898.html
> 
>  arch/arm/boot/dts/am4372.dtsi| 4 ++--
>  arch/arm/boot/dts/am43xx-clocks.dtsi | 8 
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index d83ff9c..de8791a 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -74,7 +74,7 @@
>   reg = <0x48240200 0x100>;
>   interrupts = ;
>   interrupt-parent = <>;
> - clocks = <_mpu_m2_ck>;
> + clocks = <_periphclk>;
>   };
>  
>   local_timer: timer@48240600 {
> @@ -82,7 +82,7 @@
>   reg = <0x48240600 0x100>;
>   interrupts = ;
>   interrupt-parent = <>;
> - clocks = <_mpu_m2_ck>;
> + clocks = <_periphclk>;
>   };
>  
>   l2-cache-controller@48242000 {
> diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi 
> b/arch/arm/boot/dts/am43xx-clocks.dtsi
> index cc88728..a38af2b 100644
> --- a/arch/arm/boot/dts/am43xx-clocks.dtsi
> +++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
> @@ -259,6 +259,14 @@
>   ti,invert-autoidle-bit;
>   };
>  
> + mpu_periphclk: mpu_periphclk {
> + #clock-cells = <0>;
> + compatible = "fixed-factor-clock";
> + clocks = <_mpu_m2_ck>;
> + clock-mult = <1>;
> + clock-div = <2>;
> + };
> +
>   dpll_ddr_ck: dpll_ddr_ck {
>   #clock-cells = <0>;
>   compatible = "ti,am3-dpll-clock";
> -- 
> 2.6.3
> 
--
To unsubscribe from this list: send the line "unsubscribe 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: [4.4-rc][PATCH] ARM: dts: am4372: disable arm twd and global timer's nodes

[Tony Lindgren]

* Tony Lindgren  [151203 08:34]:
>
> It seems we should apply this as a fix unless somebody has better ideas.

Actually I think the fix for now is "[4.4-rc][PATCH v2] ARM: dts: am4372: fix
clock source for arm twd and global timers" until PM starts working?

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 2/2] ARM: OMAP2+: Change core_initcall levels to postcore_initcall

[Tony Lindgren]

* Grygorii Strashko  [151203 08:35]:
> On 12/03/2015 06:00 PM, Tony Lindgren wrote:
> > * Tony Lindgren  [151130 08:29]:
> >> We want to be able to probe a few selected device drivers before hwmod
> >> code populates the clocks in omap_hwmod_setup_all(). This allows us to
> >> convert most of the clock drivers into regular device drivers.
> 
> if understand things right, ti clks now will be populated and initialized
> from 
> __omap_sync32k_timer_init
>  - omap_clk_init()
>- .. 
>- of_clk_init()
>- ..
>- omap_clk_soc_init()
> 
> and __omap_sync32k_timer_init(), in turn, will be called from:
> arch/arm/kernel/time.c
>  - time_init()
>   machine_desc->init_time();
> (without your patch 1).

Yes that's the current approach, but we can do better. We only need the 
following
clocks for system timers at that point:

- mux clocks to select between the 32k and hf oscillator source

- clkctrl driver to gate the ocp clock

All the other clocks can be initialized at core_initcall time with this change.

> So, I don't see real dependency here between clk initialization and hwmods :(

You don't because it's only implemented so far for the dm814x ADPLL clock :)

That I posted as "[PATCH 0/2] Clock driver for dm814x ADPLL". Note how it's
just a regular device driver that also works as loadable module on boards that
have all the necessary clocks enabled already by the bootloader.

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] clk: ti: omap5+: dpll: implement errata i810

[Tony Lindgren]

* Tero Kristo  [151130 06:44]:
> + /*
> +  * Errata i810 - DPLL controller can get stuck while transitioning
> +  * to a power saving state. Software must ensure the DPLL can not
> +  * transition to a low power state while changing M/N values.
> +  * Easiest way to accomplish this is to prevent DPLL autoidle
> +  * before doing the M/N re-program.
> +  */
> + errata_i810 = ti_clk_get_features()->flags & TI_CLK_ERRATA_I810;
> +
> + if (errata_i810) {
> + ai = omap3_dpll_autoidle_read(clk);
> + if (ai) {
> + omap3_dpll_deny_idle(clk);
> +
> + /* OCP barrier */
> + omap3_dpll_autoidle_read(clk);
> + }
> + }

Should we just do this unconditionally? It seems like disabling the
autoidle always before reprogramming is a good idea.

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: [4.4-rc][PATCH] ARM: dts: am4372: disable arm twd and global timer's nodes

[Tony Lindgren]

* Grygorii Strashko  [151118 07:36]:
> Hi Mark,
> 
> On 11/18/2015 04:15 PM, Mark Rutland wrote:
> > On Wed, Nov 18, 2015 at 04:01:55PM +0200, Grygorii Strashko wrote:
> >> Keep ARM TWD and Global timer's nodes disabled by default - if someone
> >> would like to use them then those nodes have to be enabled explicitly
> >> in board file.
> >>
> >> The reason for this change is:
> >> - ARM TWD is not always-on timer on am437x and it will stop in low
> >>CPUIdle states and, therefore, broadcast timer has to configured
> >>properly if CPU_IDLE=y.
> >> - ARM Global timer is not always-on timer on am437x and it can't be
> >>used as clocksource device if CPU_IDLE=y.
> > 
> > I don't understand. What timer do you use in the absence of a TWD, and
> > if it is better why is it not used even if TWD is present?
> 
> OMAP GP timer as clockevent device
> "ti,omap-counter32k" as clocksource
> both are in wakeup (always-on) PM domain.
> 
> I see some problems with selecting clocksource/event device (but may be I'm 
> mistaken):
> - Current clock event will be selected using "rating" field in 
> clock_event_device
>   structure and now ARM TWD has higer value (350) vs OMAP GP timer (300),
>   so ARM TWD will be always selected if it's present. 
> - we have to force all am437x user to use kernel cmdline parameter 
> "clocksource="
>   if ARM Global timer is present, but shouldn't be used. But even in this 
> case,
>   it will be selected as sched_clock.

Yeah makes sense to me. Eventually when I get my clocksource switch patches
updated this problem will go away and we can use a local timer clocksource
during runtime and slower always on timer during idle like we already do
for clockevents.

> We can see benefits from using these timers when Power mangement is not the 
> case,
> for example on -RT kernel where CPUIdle is not the target.

Yes we really want to use local timers for RT during runtime.

> By this change, and taking into account discovered issues, I want to make 
> people,
> who would like to use these timers on AM437x based boards, responsible for 
> such
> decision with assumption that they know what they are doing.
> And this is simplest way I found to disable those timers without modifying 
> kernel.
> 
> > 
> >> - ARM Global timer driver doesn't support CPUfreq now.
> > 
> > Surely that should be fixed in the driver (e.g. make it fail to probe if
> > CPUfreq is present)? It's broken for any other users too...
> 
> May be.

I think it's only broken for users who have PM entering deeper idle states
where the ARM core is powered off.

The selection of the timer needs to be done in the board specific dts file as we
already have cases where RT works but PM does not and should use the local 
timer,
and we have boards where PM works and we must use the always on timer.

> Also, there is additional issue with ARM global timer which I've not
> mentioned here, because I sent the fix for it already (in progress):
> https://lkml.org/lkml/2015/11/13/456
> 
> and there is ongoing discussion:
> http://www.spinics.net/lists/arm-kernel/msg459649.html

It seems we should apply this as a fix unless somebody has better ideas.

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 2/2] ARM: OMAP2+: Change core_initcall levels to postcore_initcall

[Grygorii Strashko]

On 12/03/2015 06:00 PM, Tony Lindgren wrote:
> * Tony Lindgren  [151130 08:29]:
>> We want to be able to probe a few selected device drivers before hwmod
>> code populates the clocks in omap_hwmod_setup_all(). This allows us to
>> convert most of the clock drivers into regular device drivers.

if understand things right, ti clks now will be populated and initialized
from 
__omap_sync32k_timer_init
 - omap_clk_init()
   - .. 
   - of_clk_init()
   - ..
   - omap_clk_soc_init()

and __omap_sync32k_timer_init(), in turn, will be called from:
arch/arm/kernel/time.c
 - time_init()
machine_desc->init_time();
(without your patch 1).

So, I don't see real dependency here between clk initialization and hwmods :(


>>
>> We only need a few minimal clock drivers early for the system timers to
>> select between the 32KiHz clock and the high frequency oscillator.
>>
>> With these changes, initializing the clock drivers can be just done at
>> core_initcall time with something like:
>>
>> np = of_find_node_by_name(NULL, "plls");
>> if (np)
>>  of_platform_populate(np, NULL, NULL, NULL);
>>
>> And then these clocks will be available for the interconnect code to use.
>>
>> Having most of the clock drivers being regular device drivers allows
>> us to use the nice things like devm_* functions and dev_err and dev_dbg.
>> As an extra bonus, this also allows us to develop the clock drivers for
>> new SoCs as loadable modules initially for cases where we can boot up
>> the system based on the bootloader configured clocks.
>>
>> To do this, let's change the core_initcalls to postcore_initcall under
>> mach-omap2.
> 
> FYI I'm applying this one into omap-for-v4.5/soc today, the first patch
> in this series needs more work as discussed.
> 

To be honest I don't see how this will help to convert ti clks in regular
devices right now.
Wouldn't it be better to move forward with this patch together with future 
patches?
So it will be clear what benefits will this approach provide.

In other words, I think it should be a part of some bigger series.

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

Re: [PATCH 3/4] dmaengine: core: Introduce new, universal API to request a channel

[Andy Shevchenko]

On Thu, Dec 3, 2015 at 4:33 PM, Peter Ujfalusi  wrote:
> The two API function can cover most, if not all current APIs used to
> request a channel. With minimal effort dmaengine drivers, platforms and
> dmaengine user drivers can be converted to use the two function.
>
> struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);
>
> To request any channel matching with the requested capabilities, can be
> used to request channel for memcpy, memset, xor, etc where no hardware
> synchronization is needed.
>
> struct dma_chan *dma_request_chan(struct device *dev, const char *name);
> To request a slave channel. The dma_request_chan() will try to find the
> channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode
> it will use a filter lookup table and retrieves the needed information from
> the dma_slave_map provided by the DMA drivers.
> This legacy mode needs changes in platform code, in dmaengine drivers and
> finally the dmaengine user drivers can be converted:
>
> For each dmaengine driver an array of DMA device, slave and the parameter
> for the filter function needs to be added:
>
> static const struct dma_slave_map da830_edma_map[] = {
> { "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 0) },
> { "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 1) },
> { "davinci-mcasp.1", "rx", EDMA_FILTER_PARAM(0, 2) },
> { "davinci-mcasp.1", "tx", EDMA_FILTER_PARAM(0, 3) },
> { "davinci-mcasp.2", "rx", EDMA_FILTER_PARAM(0, 4) },
> { "davinci-mcasp.2", "tx", EDMA_FILTER_PARAM(0, 5) },
> { "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 14) },
> { "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 15) },
> { "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 16) },
> { "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 17) },
> { "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 18) },
> { "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 19) },
> };
>
> This information is going to be needed by the dmaengine driver, so
> modification to the platform_data is needed, and the driver map should be
> added to the pdata of the DMA driver:
>
> da8xx_edma0_pdata.slave_map = da830_edma_map;
> da8xx_edma0_pdata.slavecnt = ARRAY_SIZE(da830_edma_map);
>
> The DMA driver then needs to configure the needed device -> filter_fn
> mapping before it registers with dma_async_device_register() :
>
> if (info->slave_map) {
> ecc->dma_slave.filter_map.map = info->slave_map;
> ecc->dma_slave.filter_map.mapcnt = info->slavecnt;
> ecc->dma_slave.filter_map.filter_fn = edma_filter_fn;

One nitpick here.

I think filter_map.filter_fn naming is duplicate.

What about

dma_device
  .filter -> filter data (or .filter_data)
.map -> mappings
.map_count -> # of entries in mappings
.fn -> filter function

What do you think?

> }
>
> When neither DT or ACPI lookup is available the dma_request_chan() will
> try to match the requester's device name with the filter_map's list of
> device names, when a match found it will use the information from the
> dma_slave_map to get the channel with the dma_get_channel() internal
> function.


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

Re: [PATCH 0/4] dmaengine: New 'universal' API for requesting channel

[Andy Shevchenko]

On Thu, Dec 3, 2015 at 4:33 PM, Peter Ujfalusi  wrote:
> Hi,

> As it has been discussed in the following thread:
> http://www.gossamer-threads.com/lists/linux/kernel/2181487#2181487
>
> With this series I have taken a path which would result two new API, which can
> be used to convert most of the current users already and with some work all
> users might be able to move to this set.
> With this set the filter_fn used for legacy (non DT/ACPI) channel request is 
> no
> longer needed to be exported to client drivers since the selection of the
> correct filter_fn will be done in the core.
>
> So, the first proposal is to have:
>
> struct dma_chan *dma_request_chan(struct device *dev, const char *name);
> struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);
>
> The dma_request_chan_by_mask() is to request any channel matching with the
> requested capabilities, can be used to request channel for memcpy, memset, 
> xor,
> etc where no hardware synchronization is needed.
>
> The dma_request_chan() is to request a slave channel. The dma_request_chan()
> will try to find the channel via DT, ACPI or in case if the kernel booted in 
> non
> DT/ACPI mode it will use a filter lookup table and retrieves the needed
> information from the dma_slave_map provided by the DMA drivers.
> This legacy mode needs changes in platform code, in dmaengine drivers and
> finally the dmaengine user drivers can be converted:
>
> For each dmaengine driver an array of DMA device, slave and the parameter
> for the filter function needs to be added:
>
> static const struct dma_slave_map da830_edma_map[] = {
> { "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 0) },
> { "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 1) },
> { "davinci-mcasp.1", "rx", EDMA_FILTER_PARAM(0, 2) },
> { "davinci-mcasp.1", "tx", EDMA_FILTER_PARAM(0, 3) },
> { "davinci-mcasp.2", "rx", EDMA_FILTER_PARAM(0, 4) },
> { "davinci-mcasp.2", "tx", EDMA_FILTER_PARAM(0, 5) },
> { "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 14) },
> { "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 15) },
> { "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 16) },
> { "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 17) },
> { "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 18) },
> { "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 19) },
> };
>
> This information is going to be used by the dmaengine driver, so
> modification to the platform_data is needed, and the driver map should be
> added to the pdata of the DMA driver:
>
> da8xx_edma0_pdata.slave_map = da830_edma_map;
> da8xx_edma0_pdata.slavecnt = ARRAY_SIZE(da830_edma_map);
>
> The DMA driver then needs to configure the needed device -> filter_fn
> mapping before it registers with dma_async_device_register() :
>
> if (info->slave_map) {
> ecc->dma_slave.filter_map.map = info->slave_map;
> ecc->dma_slave.filter_map.mapcnt = info->slavecnt;
> ecc->dma_slave.filter_map.filter_fn = edma_filter_fn;
> }
>
> When neither DT or ACPI lookup is available the dma_request_chan() will
> try to match the requester's device name with the filter_map's list of
> device names, when a match found it will use the information from the
> dma_slave_map to get the channel with the dma_get_channel() internal
> function.

For patches 1-3 with regard to comment on 3:
Reviewed-by: Andy Shevchenko 

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

Re: [PATCH] irqchip: omap-intc: fix spurious irq handling

[Sekhar Nori]

On Thursday 03 December 2015 08:32 PM, Tony Lindgren wrote:
> * Sekhar Nori  [151203 03:29]:
>> On Tuesday 20 October 2015 08:22 PM, Tony Lindgren wrote:
>>>
>>> OK thanks for testing. My guess from the above list would be EDMA
>>> or CPSW missing a flush of posted write. Maybe try adding a readback
>>> of the related device revision register after acking the interrupt into
>>> TPCC interrupt handler and CPSW interrupt handler(s)?
>>
>> I could get back to debugging this only now. I have converted
>> __raw_writel to writel() and also added readback from the same register
>> in both EDMA and CPSW drivers. But I am still able to reproduce the
>> spurious irq reports.
>>
>>> The timer2 and uart0 seem to be false positives here naturally.
>>
>> I also added readback in 8250 driver. I haven't touched the timer
>> driver, but I guess if that driver had an issue, it should have come out
>> much earlier.
>>
>> I also saw that sometimes previous irq was the TI LCDC interrupt. Added
>> readback there too. Did not help.
> 
> OK strange, so far all the ones we've seen have been fixable that way.
> 
>>> I would not yet rule out the "previous interrupt" theory until you have
>>> tried that. We really want to know the root cause of the issue, just
>>> printing out spurious interrupt does not fix the problem :)
>>
>> While we cannot rule out a software issue completely, the description in
>> TRM around spurious interrupts suggests it can happen even with no role
>> of software.
> 
> Yes maybe we more than one reason for them.
> 
>> May I suggest we go ahead and add this patch to the kernel after
>> addressing Thomas's comment? At least it will prevent kernel from
>> locking up with flood of prints when a spurious irq happens and allows
>> easier debug by others too.
> 
> Yes we should naturally fix up the kernel locking.

Alright. Thanks!

> 
> Please also add something like "enable debug for more information"
> to the warning. And then print out the current and previous interrupt

So I am unconvinced (based on the debug above) that the previous
interrupt information is actually giving any more useful information
than what can be gleaned from observing /proc/interrupts. It seems
previous interrupt noted can be any interrupt you would expect to occur
during the test case anyway.

> if DEBUG is enabled. And in the comments mention that often the spurious
> interrupts has been fixed by adding a flush of the posted write to the
> previous interrupt handler in the device driver.

I can add the comment, no problem.

> Also, do you have a reproducable test case with mainline kernel I
> could add to my collection of shell scripts?

The way I reproduce this is to run the serial port at 3Mbaud in internal
loopback mode with DMA enabled. The test program I use[1] compares the
data sent and received byte-for-byte. With current mainline, that can
mismatch pretty soon. The test will likely end before you see any
spurious irq. There are some patches John Ogness is working on
(currently included in TI's v4.1 kernel) which helps sustain the test
for long and then actually expose the spurious irq issue.

Thanks,
Sekhar

[1] https://git.breakpoint.cc/cgit/bigeasy/serialcheck.git
--
To unsubscribe from this list: send the line "unsubscribe 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] irqchip: omap-intc: fix spurious irq handling

[Tony Lindgren]

* Sekhar Nori  [151203 07:25]:
> On Thursday 03 December 2015 08:32 PM, Tony Lindgren wrote:
> > 
> > Yes we should naturally fix up the kernel locking.
> 
> Alright. Thanks!
> 
> > 
> > Please also add something like "enable debug for more information"
> > to the warning. And then print out the current and previous interrupt
> 
> So I am unconvinced (based on the debug above) that the previous
> interrupt information is actually giving any more useful information
> than what can be gleaned from observing /proc/interrupts. It seems
> previous interrupt noted can be any interrupt you would expect to occur
> during the test case anyway.

OK and the fact that I've fixed up 4-5 of these and all of them were
really caused by missing flush of posted write makes me still suspicious :)

> > if DEBUG is enabled. And in the comments mention that often the spurious
> > interrupts has been fixed by adding a flush of the posted write to the
> > previous interrupt handler in the device driver.
> 
> I can add the comment, no problem.

OK thanks. We can add more debug once you figure out what is the root
cause.

> > Also, do you have a reproducable test case with mainline kernel I
> > could add to my collection of shell scripts?
> 
> The way I reproduce this is to run the serial port at 3Mbaud in internal
> loopback mode with DMA enabled. The test program I use[1] compares the
> data sent and received byte-for-byte. With current mainline, that can
> mismatch pretty soon. The test will likely end before you see any
> spurious irq. There are some patches John Ogness is working on
> (currently included in TI's v4.1 kernel) which helps sustain the test
> for long and then actually expose the spurious irq issue.

OK. One thing you have to consider here though is that the EDMA driver
may still wrongly consider several interconnect targets as a single entity.
This can lead to issues where flushing a posted write really only flushes
one of the interconnect targets and that may not be the right one.

Peter has been patching the EDMA driver to solve this problem, but I don't
know if all of them are merged yet, I've added him to Cc.

My bets are on a lack of flush of posted write in the EDMA driver somewhere
and I suggest you investigate that a bit more considering the multiple
interconnect targets :)

Regards,

Tony

> [1] https://git.breakpoint.cc/cgit/bigeasy/serialcheck.git
--
To unsubscribe from this list: send the line "unsubscribe 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] dmaengine: edma: Add support for DMA filter mapping to slave devices

[Arnd Bergmann]

On Thursday 03 December 2015 16:33:12 Peter Ujfalusi wrote:
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index 0675e268d577..46b305ea0d21 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -2297,6 +2297,12 @@ static int edma_probe(struct platform_device *pdev)
> edma_set_chmap(>slave_chans[i], ecc->dummy_slot);
> }
>  
> +   if (info->slave_map) {
> +   ecc->dma_slave.filter_map.map = info->slave_map;
> +   ecc->dma_slave.filter_map.mapcnt = info->slavecnt;
> +   ecc->dma_slave.filter_map.filter_fn = edma_filter_fn;
> +   }
> +
> 

Just a minor comment here: I think all three assignments can be done
unconditionally. As I mentioned before, I'd also remove 'struct dma_filter'
and put the three members in struct dma_device directly. In fact, the
filter function can go with the other function pointers for consistency.

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 v3 0/3] soc: ti: Introduce wkup_m3_ipc driver

[Tony Lindgren]

* Dave Gerlach  [151202 12:30]:
> On 10/20/2015 11:18 AM, Tony Lindgren wrote:
> >* Dave Gerlach  [150922 17:20]:
> >>This series is version 3 of the code to introduce a wkup_m3_ipc driver
> >>to handle communication between the MPU and Cortex M3 present on TI AM335x
> >>and AM437x SoCs. v2 of this series can be found at [1]. Only patch 3
> >>has been changed based on a request from Tony and a few cleanups:
> >>
> >>- Rather than exporting all of the functionality of the driver, added
> >>   wkup_m3_ipc_get and wkup_m3_ipc_put to allow users to just get a handle
> >>   containing an ops structure for use.
> >>
> >>- Changed all ops (previously exported functions) to take pointer to
> >>   struct wkup_m3_ipc as an argument now that user code will get this
> >>   from wkup_m3_ipc_get.
> >>
> >>- General cleanup to probe function
> >>
> >>- Added MODULE_DEVICE_TABLE so driver can probe automatically.
> >>
> >>The series containing the DT nodes can be found here [2]. The actual dt
> >>nodes for wkup_m3_ipc (last two patches) have been merged but discussion
> >>is still open for the ti,mbox-send-noirq flag patches and depends on the
> >>comments provided for the omap-mailbox change presented in patch 1 of
> >>this series.
> >>
> >>A full branch containing all necessary PM code for both am335x and am437x
> >>has been pushed here [3] to provide a big picture view of the plan for
> >>this series.
> >>
> >>This driver relies on the firmware at [4] in the next-upstream branch
> >>being present in /lib/firmware in the rootfs or built in to the kernel.
> >
> >Anybody got comments on this one? Should I pick up this series or
> >what's the plan?
> 
> Now that Patch 1 has been merged [1] can patch 2 and 3 be picked up? These
> apply cleanly on v4.4-rc3.

OK applying 1 & 2 into omap-for-v4.5/drivers.

Regards,

Tony

> [1] 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8e3c5952144f045a0c81bf674d3f5e1d9aafceb7

--
To unsubscribe from this list: send the line "unsubscribe 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] dmaengine: core: Introduce new, universal API to request a channel

[Arnd Bergmann]

On Thursday 03 December 2015 16:33:11 Peter Ujfalusi wrote:
> +
> +/**
> + * dma_request_chan - try to allocate an exclusive slave channel
> + * @dev:   pointer to client device structure
> + * @name:  slave channel name
> + *
> + * Returns pointer to appropriate DMA channel on success or an error pointer.
> + */
> +struct dma_chan *dma_request_chan(struct device *dev, const char *name)
> +{
> +   struct dma_device *d, *_d;
> +   struct dma_chan *chan = NULL;
> +
> +   /* If device-tree is present get slave info from here */
> +   if (dev->of_node)
> +   chan = of_dma_request_slave_channel(dev->of_node, name);
> +
> +   /* If device was enumerated by ACPI get slave info from here */
> +   if (has_acpi_companion(dev) && !chan)
> +   chan = acpi_dma_request_slave_chan_by_name(dev, name);

I just noticed that you are creating this as a new interface, rather than
changing dma_request_slave_channel_reason() and making the old interface
a static inline wrapper. What is the reasoning behind that?

I think if we make both interfaces do the same thing, it's easier
to do the migration.

> +   if (chan) {
> +   /* Valid channel found */
> +   if (!IS_ERR(chan) || PTR_ERR(chan) == -EPROBE_DEFER)
> +   return chan;
> +
> +   pr_warn("%s: %s DMA request failed, falling back to legacy\n",
> +   __func__, dev->of_node ? "OF" : "ACPI");
> +   }

Maybe print the error code as well?

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

Re: [PATCH 4/4] dmaengine: edma: Add support for DMA filter mapping to slave devices

[Peter Ujfalusi]

On 12/03/2015 05:38 PM, Arnd Bergmann wrote:
> On Thursday 03 December 2015 16:33:12 Peter Ujfalusi wrote:
>> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
>> index 0675e268d577..46b305ea0d21 100644
>> --- a/drivers/dma/edma.c
>> +++ b/drivers/dma/edma.c
>> @@ -2297,6 +2297,12 @@ static int edma_probe(struct platform_device *pdev)
>> edma_set_chmap(>slave_chans[i], ecc->dummy_slot);
>> }
>>  
>> +   if (info->slave_map) {
>> +   ecc->dma_slave.filter_map.map = info->slave_map;
>> +   ecc->dma_slave.filter_map.mapcnt = info->slavecnt;
>> +   ecc->dma_slave.filter_map.filter_fn = edma_filter_fn;
>> +   }
>> +
>>
> 
> Just a minor comment here: I think all three assignments can be done
> unconditionally.

True.

> As I mentioned before, I'd also remove 'struct dma_filter'
> and put the three members in struct dma_device directly. In fact, the
> filter function can go with the other function pointers for consistency.

I just like to keep things in one place ;)
I don't have strong stand on keeping the intermediate 'struct dma_filter'
Let's hear from Vinod regarding to this

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

[Arnd Bergmann]

On Thursday 03 December 2015 17:42:31 Peter Ujfalusi wrote:
> > 
> >> +   if (chan) {
> >> +   /* Valid channel found */
> >> +   if (!IS_ERR(chan) || PTR_ERR(chan) == -EPROBE_DEFER)
> >> +   return chan;
> >> +
> >> +   pr_warn("%s: %s DMA request failed, falling back to 
> >> legacy\n",
> >> +   __func__, dev->of_node ? "OF" : "ACPI");
> >> +   }
> > 
> > Maybe print the error code as well?
> 
> Or remove the print altogether?
> In a healthy system we will either get the channel or the EPROBE_DEFER, in
> case of the platforms where the DT lookup does not work we expect errors and
> it is 'normal'.
> I think if we fail via DT/ACPI and we fail with legacy also then the client
> driver will say something about it anyways, or deal with it as it see fits.
> 

Right, that works too. It took me a while to figure out that we only get
there on systems that have ACPI or DT enabled for a particular device,
but where the normal method failed, rather than also systems with traditional
board files. Without the pr_warn, I would not have needed to think about
this ;-)

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 1/2] clk: ti: Add support for dm814x ADPLL

[Tony Lindgren]

* Tony Lindgren  [151202 17:36]:
> On dm814x we have 13 ADPLLs with 3 to 4 outputs on each. The
> ADPLLs have several dividers and muxes controlled by a shared
> control register for each PLL.
> 
> Note that for the clocks to work as device drivers for booting on
> dm814x, this patch depends on "ARM: OMAP2+: Change core_initcall
> levels to postcore_initcall".
> 
> Also note that this patch does not implement clk_set_rate,
> that will be posted later on when available.

Mike & Stephen, after review, can we have this patch alone in an
immutable branch against v4.4-rc1 that I can merge in too?

Also, the dts changes I need to queue separately FYI to avoid merge
conflicts.

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] irqchip: omap-intc: fix spurious irq handling

[Tony Lindgren]

* Sekhar Nori  [151203 03:29]:
> On Tuesday 20 October 2015 08:22 PM, Tony Lindgren wrote:
> > 
> > OK thanks for testing. My guess from the above list would be EDMA
> > or CPSW missing a flush of posted write. Maybe try adding a readback
> > of the related device revision register after acking the interrupt into
> > TPCC interrupt handler and CPSW interrupt handler(s)?
> 
> I could get back to debugging this only now. I have converted
> __raw_writel to writel() and also added readback from the same register
> in both EDMA and CPSW drivers. But I am still able to reproduce the
> spurious irq reports.
> 
> > The timer2 and uart0 seem to be false positives here naturally.
> 
> I also added readback in 8250 driver. I haven't touched the timer
> driver, but I guess if that driver had an issue, it should have come out
> much earlier.
> 
> I also saw that sometimes previous irq was the TI LCDC interrupt. Added
> readback there too. Did not help.

OK strange, so far all the ones we've seen have been fixable that way.

> > I would not yet rule out the "previous interrupt" theory until you have
> > tried that. We really want to know the root cause of the issue, just
> > printing out spurious interrupt does not fix the problem :)
> 
> While we cannot rule out a software issue completely, the description in
> TRM around spurious interrupts suggests it can happen even with no role
> of software.

Yes maybe we more than one reason for them.

> May I suggest we go ahead and add this patch to the kernel after
> addressing Thomas's comment? At least it will prevent kernel from
> locking up with flood of prints when a spurious irq happens and allows
> easier debug by others too.

Yes we should naturally fix up the kernel locking.

Please also add something like "enable debug for more information"
to the warning. And then print out the current and previous interrupt
if DEBUG is enabled. And in the comments mention that often the spurious
interrupts has been fixed by adding a flush of the posted write to the
previous interrupt handler in the device driver.

Also, do you have a reproducable test case with mainline kernel I
could add to my collection of shell scripts?

Regards,

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

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

[Tony Lindgren]

* Roger Quadros  [151203 01:02]:
> On 03/12/15 11:52, Brian Norris wrote:
> > On Thu, Dec 03, 2015 at 11:38:14AM +0530, Roger Quadros wrote:
> > 
> > I think I may have misunderstood the branch proposal. If Tony queues up:
> > 
> >   l2-mtd.git (or just up to commit a61ae81a1907)
> >   +
> >   your patches
> > 
> > and I pull that back into l2-mtd.git as well, then we don't need to
> > worry about patches that touch multiple "trees". Just do whatever makes
> > things clearest, including disregarding some of my comments along the
> > line of (3).
> 
> Tony,
> 
> Are you fine with this?

I'm fine with what you guys prefer as long as I have some immutable branch
I can merge in too in case of conflicts :)

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

[Peter Ujfalusi]

On 12/03/2015 05:32 PM, Arnd Bergmann wrote:
> On Thursday 03 December 2015 16:33:11 Peter Ujfalusi wrote:
>> +
>> +/**
>> + * dma_request_chan - try to allocate an exclusive slave channel
>> + * @dev:   pointer to client device structure
>> + * @name:  slave channel name
>> + *
>> + * Returns pointer to appropriate DMA channel on success or an error 
>> pointer.
>> + */
>> +struct dma_chan *dma_request_chan(struct device *dev, const char *name)
>> +{
>> +   struct dma_device *d, *_d;
>> +   struct dma_chan *chan = NULL;
>> +
>> +   /* If device-tree is present get slave info from here */
>> +   if (dev->of_node)
>> +   chan = of_dma_request_slave_channel(dev->of_node, name);
>> +
>> +   /* If device was enumerated by ACPI get slave info from here */
>> +   if (has_acpi_companion(dev) && !chan)
>> +   chan = acpi_dma_request_slave_chan_by_name(dev, name);
> 
> I just noticed that you are creating this as a new interface, rather than
> changing dma_request_slave_channel_reason() and making the old interface
> a static inline wrapper. What is the reasoning behind that?

Oh, it was in my plans. Will do it for v02

> I think if we make both interfaces do the same thing, it's easier
> to do the migration.
> 
>> +   if (chan) {
>> +   /* Valid channel found */
>> +   if (!IS_ERR(chan) || PTR_ERR(chan) == -EPROBE_DEFER)
>> +   return chan;
>> +
>> +   pr_warn("%s: %s DMA request failed, falling back to 
>> legacy\n",
>> +   __func__, dev->of_node ? "OF" : "ACPI");
>> +   }
> 
> Maybe print the error code as well?

Or remove the print altogether?
In a healthy system we will either get the channel or the EPROBE_DEFER, in
case of the platforms where the DT lookup does not work we expect errors and
it is 'normal'.
I think if we fail via DT/ACPI and we fail with legacy also then the client
driver will say something about it anyways, or deal with it as it see fits.

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

[PATCH 3/4] dmaengine: core: Introduce new, universal API to request a channel

[Peter Ujfalusi]

The two API function can cover most, if not all current APIs used to
request a channel. With minimal effort dmaengine drivers, platforms and
dmaengine user drivers can be converted to use the two function.

struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);

To request any channel matching with the requested capabilities, can be
used to request channel for memcpy, memset, xor, etc where no hardware
synchronization is needed.

struct dma_chan *dma_request_chan(struct device *dev, const char *name);
To request a slave channel. The dma_request_chan() will try to find the
channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode
it will use a filter lookup table and retrieves the needed information from
the dma_slave_map provided by the DMA drivers.
This legacy mode needs changes in platform code, in dmaengine drivers and
finally the dmaengine user drivers can be converted:

For each dmaengine driver an array of DMA device, slave and the parameter
for the filter function needs to be added:

static const struct dma_slave_map da830_edma_map[] = {
{ "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 0) },
{ "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 1) },
{ "davinci-mcasp.1", "rx", EDMA_FILTER_PARAM(0, 2) },
{ "davinci-mcasp.1", "tx", EDMA_FILTER_PARAM(0, 3) },
{ "davinci-mcasp.2", "rx", EDMA_FILTER_PARAM(0, 4) },
{ "davinci-mcasp.2", "tx", EDMA_FILTER_PARAM(0, 5) },
{ "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 14) },
{ "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 15) },
{ "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 16) },
{ "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 17) },
{ "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 18) },
{ "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 19) },
};

This information is going to be needed by the dmaengine driver, so
modification to the platform_data is needed, and the driver map should be
added to the pdata of the DMA driver:

da8xx_edma0_pdata.slave_map = da830_edma_map;
da8xx_edma0_pdata.slavecnt = ARRAY_SIZE(da830_edma_map);

The DMA driver then needs to configure the needed device -> filter_fn
mapping before it registers with dma_async_device_register() :

if (info->slave_map) {
ecc->dma_slave.filter_map.map = info->slave_map;
ecc->dma_slave.filter_map.mapcnt = info->slavecnt;
ecc->dma_slave.filter_map.filter_fn = edma_filter_fn;
}

When neither DT or ACPI lookup is available the dma_request_chan() will
try to match the requester's device name with the filter_map's list of
device names, when a match found it will use the information from the
dma_slave_map to get the channel with the dma_get_channel() internal
function.

Signed-off-by: Peter Ujfalusi 
---
 Documentation/dmaengine/client.txt | 23 +++---
 drivers/dma/dmaengine.c| 94 ++
 include/linux/dmaengine.h  | 42 +
 3 files changed, 142 insertions(+), 17 deletions(-)

diff --git a/Documentation/dmaengine/client.txt 
b/Documentation/dmaengine/client.txt
index d9f9f461102a..9e33189745f0 100644
--- a/Documentation/dmaengine/client.txt
+++ b/Documentation/dmaengine/client.txt
@@ -22,25 +22,14 @@ The slave DMA usage consists of following steps:
Channel allocation is slightly different in the slave DMA context,
client drivers typically need a channel from a particular DMA
controller only and even in some cases a specific channel is desired.
-   To request a channel dma_request_channel() API is used.
+   To request a channel dma_request_chan() API is used.
 
Interface:
-   struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
-   dma_filter_fn filter_fn,
-   void *filter_param);
-   where dma_filter_fn is defined as:
-   typedef bool (*dma_filter_fn)(struct dma_chan *chan, void 
*filter_param);
-
-   The 'filter_fn' parameter is optional, but highly recommended for
-   slave and cyclic channels as they typically need to obtain a specific
-   DMA channel.
-
-   When the optional 'filter_fn' parameter is NULL, dma_request_channel()
-   simply returns the first channel that satisfies the capability mask.
-
-   Otherwise, the 'filter_fn' routine will be called once for each free
-   channel which has a capability in 'mask'.  'filter_fn' is expected to
-   return 'true' when the desired DMA channel is found.
+   struct dma_chan *dma_request_chan(struct device *dev, const char *name);
+
+   Which will find and return the 'name' DMA channel associated with the 'dev'
+   device. The association is done via DT, ACPI or board file based
+   dma_slave_map matching table.
 
A channel allocated via this interface is exclusive to the caller,
until dma_release_channel() is called.
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index ea9d66982d40..fee4912d64d6 100644
--- a/drivers/dma/dmaengine.c
+++ 

[PATCH 1/4] dmaengine: core: Skip mask matching when it is not provided to private_candidate

[Peter Ujfalusi]

If mask is NULL skip the mask matching against the DMA device capabilities.

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

diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index daf54a39bcc7..6311e1fc80be 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -515,7 +515,7 @@ static struct dma_chan *private_candidate(const 
dma_cap_mask_t *mask,
 {
struct dma_chan *chan;
 
-   if (!__dma_device_satisfies_mask(dev, mask)) {
+   if (mask && !__dma_device_satisfies_mask(dev, mask)) {
pr_debug("%s: wrong capabilities\n", __func__);
return NULL;
}
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe 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: OMAP2+: Change core_initcall levels to postcore_initcall

[Tony Lindgren]

* Tony Lindgren  [151130 08:29]:
> We want to be able to probe a few selected device drivers before hwmod
> code populates the clocks in omap_hwmod_setup_all(). This allows us to
> convert most of the clock drivers into regular device drivers.
> 
> We only need a few minimal clock drivers early for the system timers to
> select between the 32KiHz clock and the high frequency oscillator.
> 
> With these changes, initializing the clock drivers can be just done at
> core_initcall time with something like:
> 
> np = of_find_node_by_name(NULL, "plls");
> if (np)
>   of_platform_populate(np, NULL, NULL, NULL);
> 
> And then these clocks will be available for the interconnect code to use.
> 
> Having most of the clock drivers being regular device drivers allows
> us to use the nice things like devm_* functions and dev_err and dev_dbg.
> As an extra bonus, this also allows us to develop the clock drivers for
> new SoCs as loadable modules initially for cases where we can boot up
> the system based on the bootloader configured clocks.
> 
> To do this, let's change the core_initcalls to postcore_initcall under
> mach-omap2.

FYI I'm applying this one into omap-for-v4.5/soc today, the first patch
in this series needs more work as discussed.

Regards,

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

Re: [PATCH V2 12/14] ARM: dts: sb-som: introduce SB-SOM baseboard

[Tony Lindgren]

* Rob Herring  [151203 06:25]:
> On Tue, Dec 01, 2015 at 03:55:07PM +0200, Nikita Kiryanov wrote:
> > CompuLab SB-SOM baseboard is a carrier board for multiple arm-based SoMs.
> > It currently supports (with minor adjustments to assembly) CM-T43, CM-T54,
> > and CM-QS600 modules. It is a building block in the SBC-T43 single board
> > computer, which consists of cm-t43 on top of sb-som-t43.
> > 
> > Signed-off-by: Nikita Kiryanov 
> > Cc: Tony Lindgren 
> > Cc: Benoit Cousson 
> > Cc: Rob Herring 
> > Cc: Mark Rutland 
> > Cc: Pawel Moll 
> > Cc: Igor Grinberg 
> > Cc: Dmitry Lifshitz 
> > Cc: Ian Campbell 
> 
> Acked-by: Rob Herring 

Applying this whole series into omap-for-v4.5/dt thanks.

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

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

[Tony Lindgren]

* Rob Herring  [151202 07:24]:
> On Tue, Dec 01, 2015 at 08:03:03PM +0200, Dmitry Lifshitz wrote:
> > Add support for CompuLab CM-SOM-AM57X board.
> > 
> > CL-SOM-AM57x is a miniature System-on-Module (SoM) based on
> > TI Sitara AM57x ARM Cortex-A15 System-on-Chip family.
> > 
> > https://www.compulab.co.il/products/computer-on-modules/cl-som-am57x-ti-am5728-am5718-system-on-module/
> > 
> > Add basic DT support for standalone module (without a carrier board):
> > 
> > * Memory configuration
> > * Heartbeat led
> > * I2C1 and I2C4
> > * PMIC
> > * SATA
> > 
> > Signed-off-by: Dmitry Lifshitz 
> > Acked-by: Igor Grinberg 
> 
> Acked-by: Rob Herring 

Applying the whole series into omap-for-v4.5/dt thanks.

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

Re: [PATCH 2/2] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Sudeep Holla]

On 03/12/15 18:13, Tony Lindgren wrote:

* Linus Walleij  [151201 06:07]:

On Fri, Nov 27, 2015 at 6:21 PM, Sudeep Holla  wrote:


From: Sudeep Holla 

The IRQF_NO_SUSPEND flag is used to identify the interrupts that should
be left enabled so as to allow them to work as expected during the
suspend-resume cycle, but doesn't guarantee that it will wake the system
from a suspended state, enable_irq_wake is recommended to be used for
the wakeup.

This patch removes the use of IRQF_NO_SUSPEND flags replacing it with
irq_set_irq_wake instead.

Cc: Linus Walleij 
Cc: linux-g...@vger.kernel.org
Signed-off-by: Sudeep Holla 


I need Tony's ACK on this as well.


At least on omaps, this controller is always powered and we never want to
suspend it as it handles wake-up events for all the IO pins. And that
usecase sounds exactly like what you're describing above.



Understood, but I assume this is a generic driver that can be used by
any pinmux.


I don't quite follow what your suggested alternative for an interrupt
controller is?



Why can't we use enable_irq_wake even for parent/interrupt controller as
they can be considered as parent wakeup irq. I agree the interrupt
controller may not be powered down, but still it's part of wakeup and
the irq core needs to identify that. By just marking IRQF_NO_SUSPEND,
you are saying that you can handle interrupt in the suspend path but not
informing that it's a wakeup interrupt.

With this change, the wakeup handler (including the parent handler) is
called when it's safe as the irq core maintains the state machine.


At least we need to have the alternative patched in with this chage before
just removing IRQF_NO_SUSPEND.



I have added irq_set_irq_wake(pcs_soc->irq, state) in pcs_irq_set_wake
which ensures it's marked for wakeup.


The enable_irq_wake is naturally used for the consumer drivers of this
interrupt controller and actually mostly done automatically now with the
dev_pm_set_dedicated_wake_irq.



Agreed, no doubt on that.

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

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

[Tony Lindgren]

* Grygorii Strashko  [151203 10:18]:
> On 12/02/2015 01:38 AM, Tony Lindgren wrote:
> 
> > Tony Lindgren (10):
> >ARM: OMAP2+: Fix timer entries for dm814x
> >clk: ti: Add few dm814x clock aliases
> >ARM: OMAP2+: Add DPPLS clock manager for dm814x
> >ARM: OMAP2+: Enable GPIO for dm814x
> >ARM: OMAP2+: Disable GPIO softreset for dm81xx
> >ARM: OMAP2+: Remove useless check for legacy booting for dm814x
> >ARM: dts: Fix dm814x entries for pllss and prcm
> >ARM: dts: Fix some mux and divider clocks to get dm814x-evm booting
> >ARM: dts: Fix dm8148 control modules ranges
> >ARM: dts: Fix dm814x pinctrl address and mask
> 
> I'm worry a bit, if you will apply this series in its current order
> - it will break git bisect.
> Patch one "ARM: OMAP2+: Fix timer entries for dm814x" will use timerX_fck, 
> but those
> clocks will be added by patches 2 "clk: ti: Add few dm814x clock aliases"
> and 8 "ARM: dts: Fix some mux and divider clocks to get dm814x-evm booting"

Yeah you have a point there. I was hoping to separate them to dts and soc
related patches but clearly that's not possible.

We can keep t410 limping along just fine with this order:

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

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 1/3] ARM: OMAP2+: Fix SoC detection for dra62x j5-eco

[Tony Lindgren]

We can boot dra62x j5-eco using the dm814x code as the clocks and
devices are mapped in the device tree. The dra62x is also known
as jacinto 5.

We may want to add separate soc_is macros for dra62x if needed,
but this gets us to the point where we can boot dra62x with just
dts changes.

Let's also print out the unknown hawkeye register to make things
a bit easier for new SoC variants.

Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/id.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 8a2ae82..d85c249 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -488,6 +488,7 @@ void __init omap3xxx_check_revision(void)
}
break;
case 0xb8f2:
+   case 0xb968:
switch (rev) {
case 0:
/* FALLTHROUGH */
@@ -511,7 +512,8 @@ void __init omap3xxx_check_revision(void)
/* Unknown default to latest silicon rev as default */
omap_revision = OMAP3630_REV_ES1_2;
cpu_rev = "1.2";
-   pr_warn("Warning: unknown chip type; assuming OMAP3630ES1.2\n");
+   pr_warn("Warning: unknown chip type: hawkeye %04x, assuming 
OMAP3630ES1.2\n",
+   hawkeye);
}
sprintf(soc_rev, "ES%s", cpu_rev);
 }
-- 
2.6.2

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

[PATCH 0/3] Add minimal support for dra62x j5-eco

[Tony Lindgren]

Hi all,

Here are minimal changes to add support for dra62x also known as
jacinto 5 or j5-eco. We can leverage the dm814x support being fixed in
mainline kernel also for dra62x. Compared to dm814x, dra62x has a
bit different clocks and devices.

To boot j5-eco evm, you need the the patches below on v4.4-rc3 with
the following additional patches posted earlier.

Basic clock driver for dm814x:

http://marc.info/?l=linux-omap=144910652029316=2

Fixes for dm814x:

http://marc.info/?l=linux-omap=144901336001085=2

And also make sure you have the initcall level change patch that
is needed for having omap clock drivers as regular Linux device
drivers:

http://marc.info/?l=linux-omap=14489008207=2

Regards,

Tony


Tony Lindgren (3):
  ARM: OMAP2+: Fix SoC detection for dra62x j5-eco
  ARM: dts: Add basic support for dra62x j5-eco SoC
  ARM: dts: Add minimal dra62x j5-eco evm support

 arch/arm/boot/dts/Makefile |  3 ++-
 arch/arm/boot/dts/dra62x-clocks.dtsi   | 49 ++
 arch/arm/boot/dts/dra62x-j5eco-evm.dts | 28 +++
 arch/arm/boot/dts/dra62x.dtsi  | 23 
 arch/arm/mach-omap2/id.c   |  4 ++-
 5 files changed, 105 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/boot/dts/dra62x-clocks.dtsi
 create mode 100644 arch/arm/boot/dts/dra62x-j5eco-evm.dts
 create mode 100644 arch/arm/boot/dts/dra62x.dtsi

-- 
2.6.2

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

[PATCH 2/3] ARM: dts: Add basic support for dra62x j5-eco SoC

[Tony Lindgren]

The dra762x j5-eco is similar to dm814x with a bit different clocks
and devices.

Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/dra62x-clocks.dtsi | 49 
 arch/arm/boot/dts/dra62x.dtsi| 23 +
 2 files changed, 72 insertions(+)
 create mode 100644 arch/arm/boot/dts/dra62x-clocks.dtsi
 create mode 100644 arch/arm/boot/dts/dra62x.dtsi

diff --git a/arch/arm/boot/dts/dra62x-clocks.dtsi 
b/arch/arm/boot/dts/dra62x-clocks.dtsi
new file mode 100644
index 000..0e49741
--- /dev/null
+++ b/arch/arm/boot/dts/dra62x-clocks.dtsi
@@ -0,0 +1,49 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "dm814x-clocks.dtsi"
+
+/* Compared to dm814x, dra62x does not have hdic, l3 or dss PLLs */
+_hdvic_ck {
+   status = "disabled";
+};
+
+_l3_ck {
+   status = "disabled";
+};
+
+_dss_ck {
+   status = "disabled";
+};
+
+/* Compared to dm814x, dra62x has interconnect clocks on isp PLL */
+_ck {
+   clocks = <_isp_ck 1>;
+};
+
+_ck {
+   clocks = <_isp_ck 1>;
+};
+
+_ck {
+   clocks = <_isp_ck 1>;
+};
+
+/*
+ * Compared to dm814x, dra62x has different shifts and more mux options.
+ * Please add the extra options for ysclk_14 and 16 if really needed.
+ */
+_fck {
+   clocks = <_ck _clkin0_ck _clkin1_ck
+ _clkin2_ck _ck _ck _ck>;
+   ti,bit-shift = <4>;
+};
+
+_fck {
+   clocks = <_ck _clkin0_ck _clkin1_ck
+ _clkin2_ck _ck _ck _ck>;
+   ti,bit-shift = <8>;
+};
diff --git a/arch/arm/boot/dts/dra62x.dtsi b/arch/arm/boot/dts/dra62x.dtsi
new file mode 100644
index 000..d3cbb4e
--- /dev/null
+++ b/arch/arm/boot/dts/dra62x.dtsi
@@ -0,0 +1,23 @@
+/*
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include "dm814x.dtsi"
+
+/ {
+   compatible = "ti,dra62x";
+};
+
+/* Compared to dm814x, dra62x has different offsets for Ethernet */
+ {
+   reg = <0x4a10 0x800
+   0x4a101200 0x100>;
+};
+
+_mdio {
+   reg = <0x4a101000 0x100>;
+};
+
+#include "dra62x-clocks.dtsi"
-- 
2.6.2

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

[PATCH 3/3] ARM: dts: Add minimal dra62x j5-eco evm support

[Tony Lindgren]

This allows us to boot dra62x j5-eco evm with NFSroot.

Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/Makefile |  3 ++-
 arch/arm/boot/dts/dra62x-j5eco-evm.dts | 28 
 2 files changed, 30 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/dra62x-j5eco-evm.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..aa237cf14 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -452,7 +452,8 @@ dtb-$(CONFIG_ARCH_OMAP3) += \
 dtb-$(CONFIG_SOC_TI81XX) += \
dm8148-evm.dtb \
dm8148-t410.dtb \
-   dm8168-evm.dtb
+   dm8168-evm.dtb \
+   dra62x-j5eco-evm.dtb
 dtb-$(CONFIG_SOC_AM33XX) += \
am335x-baltos-ir5221.dtb \
am335x-base0033.dtb \
diff --git a/arch/arm/boot/dts/dra62x-j5eco-evm.dts 
b/arch/arm/boot/dts/dra62x-j5eco-evm.dts
new file mode 100644
index 000..49a05d2
--- /dev/null
+++ b/arch/arm/boot/dts/dra62x-j5eco-evm.dts
@@ -0,0 +1,28 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include "dra62x.dtsi"
+
+/ {
+   model = "DRA62x J5 Eco EVM";
+   compatible = "ti,dra62x-j5eco-evm", "ti,dra62x", "ti,dm8148";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x4000>;  /* 1 GB */
+   };
+};
+
+_emac0 {
+   phy_id = <_mdio>, <0>;
+   phy-mode = "rgmii";
+};
+
+_emac1 {
+   phy_id = <_mdio>, <1>;
+   phy-mode = "rgmii";
+};
-- 
2.6.2

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

Re: [4.4-rc][PATCH] ARM: dts: am4372: disable arm twd and global timer's nodes

[Tony Lindgren]

* Grygorii Strashko  [151203 10:21]:
> On 12/03/2015 06:37 PM, Tony Lindgren wrote:
> > * Tony Lindgren  [151203 08:34]:
> >>
> >> It seems we should apply this as a fix unless somebody has better ideas.
> > 
> > Actually I think the fix for now is "[4.4-rc][PATCH v2] ARM: dts: am4372: 
> > fix
> > clock source for arm twd and global timers" until PM starts working?
> > 
> 
> Yes. if no PM it should work, but PM patches are on the fly for Am43.

OK let's not merge this one then.

> But, again, main reason I've posted this patch is that I do not see the
> way how to enable/disable or limit functionality of these timer by using 
> Kconfig options in case of Muliplatform builds :( (or by boot parameters).
> 
> Example 1 (this is how 4.4 kernel is working):
> 1) OMAP4 has ARM TWD timer and properly supports it, so in Kconfig we have
> "select HAVE_ARM_TWD" and corresponding "local-timer" is defined in DT.
> AM437x has ARM TWD timer, but does not support it yet, so corresponding 
> "local-timer"
> defined in DT and in Kconfig HAVE_ARM_TWD is not selected.
> (patch http://www.spinics.net/lists/arm-kernel/msg459649.html
>  is not merged yet)
> 
> Result: ARM TWD timer will be enabled on AM437x !? :(
> 
> Example 2:
> ARM Global timer can't be used as clocksource device if CPUFreq is enabled
> (this is not supported even by Timekeeping core now).
> 
> So, there are two options:
> 1) update selection for config SOC_AM43XX
> + select ARM_GLOBAL_TIMER if !CPU_FREQ
> 2) updated ARM GT driver and don't register clocksource device if CPUFreq is 
> enabled
> 
> Both options will not work:
> 1) ARM_GLOBAL_TIMER will be selected if any other SoC in multiplatform build
> will select ARM_GLOBAL_TIMER
> 2) clocksource device will never be registered if at least one SoC will
> select CPU_FREQ. And this might break SoC which expect it to be registered,
> because CPU_FREQ is not enabled on these SoCs (no CPUFreq drivers registered).
> 
> So, as alternative to this patch, ARM timers nodes can be disabled in
> platform DTS files, but then all platform DTS files will need to be updated.

Yes I don't see any other option right now until we have the clocksource
switching happening. Only then will the scoring work properly.

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 2/2] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Tony Lindgren]

* Sudeep Holla  [151203 11:00]:
> On 03/12/15 18:13, Tony Lindgren wrote:
> >At least on omaps, this controller is always powered and we never want to
> >suspend it as it handles wake-up events for all the IO pins. And that
> >usecase sounds exactly like what you're describing above.
> >
> 
> Understood, but I assume this is a generic driver that can be used by
> any pinmux.

Right no question about that, but we need to keep things working. I just
pasted the output to this thread what happens coming back up from suspend.

> >I don't quite follow what your suggested alternative for an interrupt
> >controller is?
> 
> Why can't we use enable_irq_wake even for parent/interrupt controller as
> they can be considered as parent wakeup irq. I agree the interrupt
> controller may not be powered down, but still it's part of wakeup and
> the irq core needs to identify that. By just marking IRQF_NO_SUSPEND,
> you are saying that you can handle interrupt in the suspend path but not
> informing that it's a wakeup interrupt.
> 
> With this change, the wakeup handler (including the parent handler) is
> called when it's safe as the irq core maintains the state machine.

Maybe paste a suggested patch and I can try it. I guess you mean call
that from pinctrl-single.c.

> >At least we need to have the alternative patched in with this chage before
> >just removing IRQF_NO_SUSPEND.
> >
> 
> I have added irq_set_irq_wake(pcs_soc->irq, state) in pcs_irq_set_wake
> which ensures it's marked for wakeup.

Hmm well see the error I pasted in this thread, maybe that provides
more clues.

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 2/2] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Tony Lindgren]

* Grygorii Strashko  [151203 10:36]:
> 
> I think, this patch should not break our wake-up functionality.
> It will just change the moment when pcs_irq_handler() will be called:
> 
> before this change:
> - suspend_enter()
>   
>   - arch_suspend_enable_irqs();
> - ^ right here
> 
> after this change:
> - suspend_enter()
>   
>   dpm_resume_noirq()
>   - resume_device_irqs()
> ^ here
> 
> Correct? And as for me this is more safe.

I think there's more to it though. With both applied, it produces this on
coming back up from suspend:

PM: noirq resume of devices complete after 18.127 msecs
[ cut here ]
WARNING: CPU: 0 PID: 123 at kernel/irq/manage.c:605 irq_set_irq_wake+0xbc/0xfc()
Unbalanced IRQ 375 wake disable
Modules linked in: ledtrig_default_on leds_gpio led_class rtc_twl twl4030_wdt
CPU: 0 PID: 123 Comm: bash Tainted: GW   4.4.0-rc3-dirty #2682
Hardware name: Generic OMAP36xx (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
] (show_stack) from [] (dump_stack+0x84/0x9c)
[] (dump_stack) from [] (warn_slowpath_common+0x7c/0xb8)
[] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x30/0x40)
[] (warn_slowpath_fmt) from [] (irq_set_irq_wake+0xbc/0xfc)
[] (irq_set_irq_wake) from [] 
(device_wakeup_disarm_wake_irqs+0x70/0x12c)
[] (device_wakeup_disarm_wake_irqs) from [] 
(dpm_resume_noirq+0x20c/0x2e4)
[] (dpm_resume_noirq) from [] 
(suspend_devices_and_enter+0x1e4/0x6bc)
[] (suspend_devices_and_enter) from [] 
(pm_suspend+0x358/0x4b8)
[] (pm_suspend) from [] (state_store+0x64/0xb8)
[] (state_store) from [] (kobj_attr_store+0x14/0x20)
[] (kobj_attr_store) from [] (sysfs_kf_write+0x4c/0x50)
[] (sysfs_kf_write) from [] (kernfs_fop_write+0xbc/0x1cc)
[] (kernfs_fop_write) from [] (__vfs_write+0x24/0xd8)
[] (__vfs_write) from [] (vfs_write+0x94/0x154)
[] (vfs_write) from [] (SyS_write+0x40/0x94)
[] (SyS_write) from [] (ret_fast_syscall+0x0/0x1c)
---[ end trace 321b51565e161bee ]---

And these both need to be applied together when we have a fix for the above
as otherwise we'll get the lock recursion Sudeep mentioned in patch 2/2.

Regards,

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

Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Tony Lindgren]

Hi Peter,

* Peter Ujfalusi  [151016 00:23]:

I noticed something while changing dm81xx to use the edma_xbar..

> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> +
> + edma_xbar: dma-router@44e10f90 {
> + compatible = "ti,am335x-edma-crossbar";
> + reg = <0x44e10f90 0x40>;
> +
> + #dma-cells = <3>;
> + dma-requests = <32>;
> +
> + dma-masters = <>;
>   };

The edma_xbar should now be just a child at offset 0xf90 under the
scm: scm@21. Can you please check the other patches too?

Regards,

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

Re: [4.4-rc][PATCH v2] ARM: dts: am4372: fix clock source for arm twd and global timers

[Grygorii Strashko]

On 12/03/2015 06:35 PM, Tony Lindgren wrote:
> * Grygorii Strashko  [151130 07:58]:
>> ARM TWD and Global timer are clocked by PERIPHCLK which is MPU_CLK/2.
>> But now they are clocked by dpll_mpu_m2_ck == MPU_CLK and, as result.
>> Timekeeping core misbehaves. For example, execution of command
>> "sleep 5" will take 10 sec instead of 5.
>>
>> Hence, fix it by adding mpu_periphclk ("fixed-factor-clock") and use
>> it for clocking ARM TWD and Global timer (same way as on OMAP4).
>>
>> Cc: Tony Lindgren 
>> Cc: Felipe Balbi 
>> Cc: Tero Kristo 
>> Fixes:commit 8cbd4c2f6a99 ("arm: boot: dts: am4372: add ARM timers and SCU 
>> nodes")
>> Signed-off-by: Grygorii Strashko 
> 
> Is this fix alone enough or do you still need to disable other the ARM
> timers in the board specific dts file?
> 

This one is independent and it's required for -rc, because ARM TWD timer will 
be selected
now for am43xx even if http://www.spinics.net/lists/arm-kernel/msg459649.html
is not merged yet ;) in case of omap2plus_defconfig build.


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

Re: [PATCH 0/2] ARM: dts: Use MMC pwrseq instead regulators for IGEP WiFi init

[Javier Martinez Canillas]

Hello Tony,

On 12/03/2015 03:16 PM, Tony Lindgren wrote:
> * Javier Martinez Canillas  [151203 10:03]:
>> Hello,
>>
>> This series converts the IGEPv2 (IGEP0020) and IGEP COM Module (IGEP0030)
>> Device Tree to use the MMC power sequence provider to initialize the SDIO
>> WiFi chip instead of using fake fixed regulators to just toggle the Reset
>> and Power pins in the chip.
>>
>> The patches were tested on an DM3730 IGEPv2 board but the IGEP COM Module
>> is the same with regard to the SDIO WiFi so it should be safe to land too.
>>
>> The IGEPv2 Rev.F and the IGEP COM Module Rev.G DTS were not converted due
>> using a different WiFi chip (wlcore instead of libertas) than the one in
>> the board I've access to test so I preferred to leave those untouched.
> 
> Do you have some solution for the start-up latency issue?
>

No, I don't and that's one of the reasons why I didn't want to touch the
DTS that have the wlcore chip.

The omap3-igep0020-rev-f.dts and omap3-igep0030-rev-g.dts don't have a
startup-delay-us property in the regulator for the WLAN_EN pin as is
the case for the IGEPv5 DTS but I don't know if those DTS are just wrong.

The DTS for the igep0020 and igep0030 that have the libertas chip,
did have a startup-delay-us for the WIFI_PDN but using the GPIOs
for RESET_N_W and WIFI_PDN in the mmc-pwrseq-simple reset-gpios is
enough to make the SDIO chip reset, be enumerated and WiFi to work
correctly so I don't know if that is really needed or is just a bad
description in the DTS.

Since is working for the boards with the libertas chip, I preferred
to remove the DTS hack but left the boards with wlcore chip since
you said the startup-delay-us is needed there (but probably we should
add to the regulators in the boards that don't have it then).

> Regards,
> 
> Tony
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] ARM: dts: omap3-igep0030: Use MMC pwrseq to init SDIO WiFi

[Javier Martinez Canillas]

When the WiFi support was added to the IGEP0030 board, the MMC subsystem
did not provide a mechanism to define power sequence providers. So a DT
hack was used to toggle the WiFi chip reset and power down pins by using
fake fixed regulators whose enable GPIO was the GPIOs connected to these
pins.

But now the simple MMC power sequence provider can be used for this and
the workaround removed.

Signed-off-by: Javier Martinez Canillas 

---

 arch/arm/boot/dts/omap3-igep0030.dts | 24 
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep0030.dts 
b/arch/arm/boot/dts/omap3-igep0030.dts
index 468608dab30a..55b0cc4f5ee5 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -15,25 +15,17 @@
model = "IGEP COM MODULE Rev. E (TI OMAP AM/DM37x)";
compatible = "isee,omap3-igep0030", "ti,omap36xx", "ti,omap3";
 
-   /* Regulator to trigger the WIFI_PDN signal of the Wifi module */
-   lbee1usjyc_pdn: lbee1usjyc_pdn {
+   vmmcsdio_fixed: fixedregulator-mmcsdio {
compatible = "regulator-fixed";
-   regulator-name = "regulator-lbee1usjyc-pdn";
+   regulator-name = "vmmcsdio_fixed";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
-   gpio = < 10 GPIO_ACTIVE_HIGH>;/* gpio_138 - WIFI_PDN 
*/
-   startup-delay-us = <1>;
-   enable-active-high;
};
 
-   /* Regulator to trigger the RESET_N_W signal of the Wifi module */
-   lbee1usjyc_reset_n_w: lbee1usjyc_reset_n_w {
-   compatible = "regulator-fixed";
-   regulator-name = "regulator-lbee1usjyc-reset-n-w";
-   regulator-min-microvolt = <330>;
-   regulator-max-microvolt = <330>;
-   gpio = < 11 GPIO_ACTIVE_HIGH>;/* gpio_139 - RESET_N_W 
*/
-   enable-active-high;
+   mmc2_pwrseq: mmc2_pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   reset-gpios = < 11 GPIO_ACTIVE_LOW>,  /* gpio_139 - 
RESET_N_W */
+ < 10 GPIO_ACTIVE_LOW>;  /* gpio_138 - 
WIFI_PDN */
};
 };
 
@@ -62,8 +54,8 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_pins _pins>;
-   vmmc-supply = <_pdn>;
-   vmmc_aux-supply = <_reset_n_w>;
+   vmmc-supply = <_fixed>;
+   mmc-pwrseq = <_pwrseq>;
bus-width = <4>;
non-removable;
 };
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe 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] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Tony Lindgren]

* Linus Walleij  [151201 06:07]:
> On Fri, Nov 27, 2015 at 6:21 PM, Sudeep Holla  wrote:
> 
> > From: Sudeep Holla 
> >
> > The IRQF_NO_SUSPEND flag is used to identify the interrupts that should
> > be left enabled so as to allow them to work as expected during the
> > suspend-resume cycle, but doesn't guarantee that it will wake the system
> > from a suspended state, enable_irq_wake is recommended to be used for
> > the wakeup.
> >
> > This patch removes the use of IRQF_NO_SUSPEND flags replacing it with
> > irq_set_irq_wake instead.
> >
> > Cc: Linus Walleij 
> > Cc: linux-g...@vger.kernel.org
> > Signed-off-by: Sudeep Holla 
> 
> I need Tony's ACK on this as well.

At least on omaps, this controller is always powered and we never want to
suspend it as it handles wake-up events for all the IO pins. And that
usecase sounds exactly like what you're describing above.

I don't quite follow what your suggested alternative for an interrupt
controller is?

At least we need to have the alternative patched in with this chage before
just removing IRQF_NO_SUSPEND.

The enable_irq_wake is naturally used for the consumer drivers of this
interrupt controller and actually mostly done automatically now with the
dev_pm_set_dedicated_wake_irq.

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 00/10] Patches to get dm814x-evm booting to NFSroot

[Grygorii Strashko]

On 12/02/2015 01:38 AM, Tony Lindgren wrote:
> Hi all,
> 
> Here are some fixes for v4.5 merge window to get dm814x-evm booting.
> While hp t410 boots based on the bootloader clocks, dm814x-evm needs
> more things configured. Especially the clock dts entries were all
> wrong and just happened to be harmless on hp t410.
> 
> To boot, you probably want to use v4.4-rc3 because of commit 29f5b34ca1a1
> ("arm: omap2+: add missing HWMOD_NO_IDLEST in 81xx hwmod data") and also
> manually apply commit 0db19b850468 ("net: cpsw: Fix ethernet regression
> for dm814x") from Linux next.
> 
> I have more changes coming up after this series after I clean them
> up a bit. Here's a brief status update for people:
> 
> What's working after this series on dm814x-evm and hp t410:
> 
> - Timers
> 
> - Serial
> 
> - Ethernet
> 
> - DMA
> 
> - I2C (only tested so far with i2cdetect -r 0)
> 
> - GPIO (only tested with additional MMC patches for card detect)
> 
> I have the following additional patches coming soonish:
> 
> - Basic ADPLL clock driver
> 
> - MMC support
> 
> - USB support
> 
> - Minimal j5eco-evm support
> 
> Should work with just configuration:
> 
> - [PATCH 0/3] pwm: omap: Add PWM support using dual-mode timers
> 
> I'm not working on any of the accelerators or graphics FYI. If somebody
> has patches coming for those please notify on the linux-omap and
> linux-arm-kernel mailings lists so we can avoid duplicate work.
> 

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

I'm worry a bit, if you will apply this series in its current order
- it will break git bisect.
Patch one "ARM: OMAP2+: Fix timer entries for dm814x" will use timerX_fck, but 
those
clocks will be added by patches 2 "clk: ti: Add few dm814x clock aliases"
and 8 "ARM: dts: Fix some mux and divider clocks to get dm814x-evm booting"




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

Re: [4.4-rc][PATCH] ARM: dts: am4372: disable arm twd and global timer's nodes

[Grygorii Strashko]

On 12/03/2015 06:37 PM, Tony Lindgren wrote:
> * Tony Lindgren  [151203 08:34]:
>>
>> It seems we should apply this as a fix unless somebody has better ideas.
> 
> Actually I think the fix for now is "[4.4-rc][PATCH v2] ARM: dts: am4372: fix
> clock source for arm twd and global timers" until PM starts working?
> 

Yes. if no PM it should work, but PM patches are on the fly for Am43.

But, again, main reason I've posted this patch is that I do not see the
way how to enable/disable or limit functionality of these timer by using 
Kconfig options in case of Muliplatform builds :( (or by boot parameters).

Example 1 (this is how 4.4 kernel is working):
1) OMAP4 has ARM TWD timer and properly supports it, so in Kconfig we have
"select HAVE_ARM_TWD" and corresponding "local-timer" is defined in DT.
AM437x has ARM TWD timer, but does not support it yet, so corresponding 
"local-timer"
defined in DT and in Kconfig HAVE_ARM_TWD is not selected.
(patch http://www.spinics.net/lists/arm-kernel/msg459649.html
 is not merged yet)

Result: ARM TWD timer will be enabled on AM437x !? :(

Example 2:
ARM Global timer can't be used as clocksource device if CPUFreq is enabled
(this is not supported even by Timekeeping core now).

So, there are two options:
1) update selection for config SOC_AM43XX
+ select ARM_GLOBAL_TIMER if !CPU_FREQ
2) updated ARM GT driver and don't register clocksource device if CPUFreq is 
enabled

Both options will not work:
1) ARM_GLOBAL_TIMER will be selected if any other SoC in multiplatform build
will select ARM_GLOBAL_TIMER
2) clocksource device will never be registered if at least one SoC will
select CPU_FREQ. And this might break SoC which expect it to be registered,
because CPU_FREQ is not enabled on these SoCs (no CPUFreq drivers registered).

So, as alternative to this patch, ARM timers nodes can be disabled in
platform DTS files, but then all platform DTS files will need to be updated.

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

Re: [PATCH 2/2] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Grygorii Strashko]

On 12/03/2015 08:13 PM, Tony Lindgren wrote:
> * Linus Walleij  [151201 06:07]:
>> On Fri, Nov 27, 2015 at 6:21 PM, Sudeep Holla  wrote:
>>
>>> From: Sudeep Holla 
>>>
>>> The IRQF_NO_SUSPEND flag is used to identify the interrupts that should
>>> be left enabled so as to allow them to work as expected during the
>>> suspend-resume cycle, but doesn't guarantee that it will wake the system
>>> from a suspended state, enable_irq_wake is recommended to be used for
>>> the wakeup.
>>>
>>> This patch removes the use of IRQF_NO_SUSPEND flags replacing it with
>>> irq_set_irq_wake instead.
>>>
>>> Cc: Linus Walleij 
>>> Cc: linux-g...@vger.kernel.org
>>> Signed-off-by: Sudeep Holla 
>>
>> I need Tony's ACK on this as well.
> 
> At least on omaps, this controller is always powered and we never want to
> suspend it as it handles wake-up events for all the IO pins. And that
> usecase sounds exactly like what you're describing above.
> 
> I don't quite follow what your suggested alternative for an interrupt
> controller is?
> 
> At least we need to have the alternative patched in with this chage before
> just removing IRQF_NO_SUSPEND.
> 
> The enable_irq_wake is naturally used for the consumer drivers of this
> interrupt controller and actually mostly done automatically now with the
> dev_pm_set_dedicated_wake_irq.
> 

I think, this patch should not break our wake-up functionality.
It will just change the moment when pcs_irq_handler() will be called:

before this change:
- suspend_enter()
  
  - arch_suspend_enable_irqs();
- ^ right here

after this change:
- suspend_enter()
  
  dpm_resume_noirq()
  - resume_device_irqs()
^ here

Correct? And as for me this is more safe.

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

Re: [PATCH 0/2] ARM: dts: Use MMC pwrseq instead regulators for IGEP WiFi init

[Tony Lindgren]

* Javier Martinez Canillas  [151203 10:03]:
> Hello,
> 
> This series converts the IGEPv2 (IGEP0020) and IGEP COM Module (IGEP0030)
> Device Tree to use the MMC power sequence provider to initialize the SDIO
> WiFi chip instead of using fake fixed regulators to just toggle the Reset
> and Power pins in the chip.
> 
> The patches were tested on an DM3730 IGEPv2 board but the IGEP COM Module
> is the same with regard to the SDIO WiFi so it should be safe to land too.
> 
> The IGEPv2 Rev.F and the IGEP COM Module Rev.G DTS were not converted due
> using a different WiFi chip (wlcore instead of libertas) than the one in
> the board I've access to test so I preferred to leave those untouched.

Do you have some solution for the start-up latency issue?

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 6/7] ARM: dts: Add mmc support for dra62x j5-eco evm

[Tony Lindgren]

There's mmc interface on j5-eco evm that's wired to the
sd_1 interface.

Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/dra62x-j5eco-evm.dts | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/dra62x-j5eco-evm.dts 
b/arch/arm/boot/dts/dra62x-j5eco-evm.dts
index 49a05d2..97ac839 100644
--- a/arch/arm/boot/dts/dra62x-j5eco-evm.dts
+++ b/arch/arm/boot/dts/dra62x-j5eco-evm.dts
@@ -15,6 +15,14 @@
device_type = "memory";
reg = <0x8000 0x4000>;  /* 1 GB */
};
+
+   /* MIC94060YC6 controlled by SD1_POW pin */
+   vmmcsd_fixed: fixedregulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "vmmcsd_fixed";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
 };
 
 _emac0 {
@@ -26,3 +34,26 @@
phy_id = <_mdio>, <1>;
phy-mode = "rgmii";
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_fixed>;
+   bus-width = <4>;
+   cd-gpios = < 6 GPIO_ACTIVE_LOW>;
+};
+
+ {
+   sd1_pins: pinmux_sd1_pins {
+   pinctrl-single,pins = <
+   DM814X_IOPAD(0x0800, PIN_INPUT | 0x1)   /* SD1_CLK */
+   DM814X_IOPAD(0x0804, PIN_INPUT_PULLUP |  0x1)   /* 
SD1_CMD */
+   DM814X_IOPAD(0x0808, PIN_INPUT_PULLUP |  0x1)   /* 
SD1_DAT[0] */
+   DM814X_IOPAD(0x080c, PIN_INPUT_PULLUP |  0x1)   /* 
SD1_DAT[1] */
+   DM814X_IOPAD(0x0810, PIN_INPUT_PULLUP |  0x1)   /* 
SD1_DAT[2] */
+   DM814X_IOPAD(0x0814, PIN_INPUT_PULLUP |  0x1)   /* 
SD1_DAT[3] */
+   DM814X_IOPAD(0x0924, PIN_OUTPUT |  0x40)/* 
SD1_POW */
+   DM814X_IOPAD(0x093C, PIN_INPUT_PULLUP |  0x80)  /* 
GP1[6] */
+   >;
+   };
+};
-- 
2.6.2

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

[PATCH 2/7] ARM: dts: Update edma bindings on dm814x to use edma_xbar

[Tony Lindgren]

The edma is the same as on am33xx, except it has four tptc
instances. And we need the edma_xbar for at least mmc3, so
let's use the edma_xbar and the new binding as suggested by
Peter Ujfalusi .

Cc: Peter Ujfalusi 
Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/dm814x.dtsi | 68 ---
 1 file changed, 58 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/dm814x.dtsi b/arch/arm/boot/dts/dm814x.dtsi
index ca92346..9d81980e 100644
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -126,8 +126,8 @@
interrupts = <65>;
ti,spi-num-cs = <4>;
ti,hwmods = "mcspi1";
-   dmas = < 16  17
-18  19>;
+   dmas = < 16 0  17 0
+18 0  19 0>;
dma-names = "tx0", "rx0", "tx1", "rx1";
};
 
@@ -145,7 +145,7 @@
reg = <0x2 0x2000>;
clock-frequency = <4800>;
interrupts = <72>;
-   dmas = < 26  27>;
+   dmas = < 26 0  27 0>;
dma-names = "tx", "rx";
};
 
@@ -155,7 +155,7 @@
reg = <0x22000 0x2000>;
clock-frequency = <4800>;
interrupts = <73>;
-   dmas = < 28  29>;
+   dmas = < 28 0  29 0>;
dma-names = "tx", "rx";
};
 
@@ -165,7 +165,7 @@
reg = <0x24000 0x2000>;
clock-frequency = <4800>;
interrupts = <74>;
-   dmas = < 30  31>;
+   dmas = < 30 0  31 0>;
dma-names = "tx", "rx";
};
 
@@ -205,6 +205,14 @@
};
};
 
+   edma_xbar: dma-router@f90 {
+   compatible = "ti,am335x-edma-crossbar";
+   reg = <0xf90 0x40>;
+   #dma-cells = <3>;
+   dma-requests = <32>;
+   dma-masters = <>;
+   };
+
/*
 * Note that silicon revision 2.1 and older
 * require input enabled (bit 18 set) for all
@@ -272,12 +280,52 @@
};
 
edma: edma@4900 {
-   compatible = "ti,edma3";
-   ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
-   reg =   <0x4900 0x1>,
-   <0x44e10f90 0x40>;
+   compatible = "ti,edma3-tpcc";
+   ti,hwmods = "tpcc";
+   reg =   <0x4900 0x1>;
+   reg-names = "edma3_cc";
interrupts = <12 13 14>;
-   #dma-cells = <1>;
+   interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+   dma-requests = <64>;
+   #dma-cells = <2>;
+
+   ti,tptcs = <_tptc0 7>, <_tptc1 5>,
+  <_tptc2 3>, <_tptc3 0>;
+
+   ti,edma-memcpy-channels = /bits/ 16 <20 21>;
+   };
+
+   edma_tptc0: tptc@4980 {
+   compatible = "ti,edma3-tptc";
+   ti,hwmods = "tptc0";
+   reg =   <0x4980 0x10>;
+   interrupts = <112>;
+   interrupt-names = "edma3_tcerrint";
+   };
+
+   edma_tptc1: tptc@4990 {
+   compatible = "ti,edma3-tptc";
+   ti,hwmods = "tptc1";
+   reg =   <0x4990 0x10>;
+   interrupts = <113>;
+   interrupt-names = "edma3_tcerrint";
+   };
+
+   edma_tptc2: tptc@49a0 {
+   compatible = "ti,edma3-tptc";
+   ti,hwmods = "tptc2";
+   reg =   <0x49a0 0x10>;
+   interrupts = <114>;
+   interrupt-names = "edma3_tcerrint";
+   };
+
+   edma_tptc3: tptc@49b0 {
+

[PATCH 3/7] ARM: OMAP2+: Add mmc hwmod entries for dm814x

[Tony Lindgren]

Let's add mmc entries for dm814x. To do that, we need to rename some
entries to be common for 81xx.

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

diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
index 1b96cdf..6ee5ba5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -912,7 +912,7 @@ static struct omap_hwmod_ocp_if dm816x_l4_hs__emac1 = {
.user   = OCP_USER_MPU,
 };
 
-static struct omap_hwmod_class_sysconfig dm816x_mmc_sysc = {
+static struct omap_hwmod_class_sysconfig dm81xx_mmc_sysc = {
.rev_offs   = 0x0,
.sysc_offs  = 0x110,
.syss_offs  = 0x114,
@@ -923,24 +923,94 @@ static struct omap_hwmod_class_sysconfig dm816x_mmc_sysc 
= {
.sysc_fields= _hwmod_sysc_type1,
 };
 
-static struct omap_hwmod_class dm816x_mmc_class = {
+static struct omap_hwmod_class dm81xx_mmc_class = {
.name = "mmc",
-   .sysc = _mmc_sysc,
+   .sysc = _mmc_sysc,
 };
 
-static struct omap_hwmod_opt_clk dm816x_mmc1_opt_clks[] = {
+static struct omap_hwmod_opt_clk dm81xx_mmc_opt_clks[] = {
{ .role = "dbck", .clk = "sysclk18_ck", },
 };
 
-static struct omap_hsmmc_dev_attr mmc1_dev_attr = {
-   .flags = OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
+static struct omap_hsmmc_dev_attr mmc_dev_attr = {
+};
+
+static struct omap_hwmod dm814x_mmc1_hwmod = {
+   .name   = "mmc1",
+   .clkdm_name = "alwon_l3s_clkdm",
+   .opt_clks   = dm81xx_mmc_opt_clks,
+   .opt_clks_cnt   = ARRAY_SIZE(dm81xx_mmc_opt_clks),
+   .main_clk   = "sysclk8_ck",
+   .prcm   = {
+   .omap4 = {
+   .clkctrl_offs = DM814X_CM_ALWON_MMCHS_0_CLKCTRL,
+   .modulemode = MODULEMODE_SWCTRL,
+   },
+   },
+   .dev_attr   = _dev_attr,
+   .class  = _mmc_class,
+};
+
+static struct omap_hwmod_ocp_if dm814x_l4_ls__mmc1 = {
+   .master = _l4_ls_hwmod,
+   .slave  = _mmc1_hwmod,
+   .clk= "sysclk6_ck",
+   .user   = OCP_USER_MPU,
+   .flags  = OMAP_FIREWALL_L4
+};
+
+static struct omap_hwmod dm814x_mmc2_hwmod = {
+   .name   = "mmc2",
+   .clkdm_name = "alwon_l3s_clkdm",
+   .opt_clks   = dm81xx_mmc_opt_clks,
+   .opt_clks_cnt   = ARRAY_SIZE(dm81xx_mmc_opt_clks),
+   .main_clk   = "sysclk8_ck",
+   .prcm   = {
+   .omap4 = {
+   .clkctrl_offs = DM814X_CM_ALWON_MMCHS_1_CLKCTRL,
+   .modulemode = MODULEMODE_SWCTRL,
+   },
+   },
+   .dev_attr   = _dev_attr,
+   .class  = _mmc_class,
+};
+
+static struct omap_hwmod_ocp_if dm814x_l4_ls__mmc2 = {
+   .master = _l4_ls_hwmod,
+   .slave  = _mmc2_hwmod,
+   .clk= "sysclk6_ck",
+   .user   = OCP_USER_MPU,
+   .flags  = OMAP_FIREWALL_L4
+};
+
+static struct omap_hwmod dm814x_mmc3_hwmod = {
+   .name   = "mmc3",
+   .clkdm_name = "alwon_l3_med_clkdm",
+   .opt_clks   = dm81xx_mmc_opt_clks,
+   .opt_clks_cnt   = ARRAY_SIZE(dm81xx_mmc_opt_clks),
+   .main_clk   = "sysclk8_ck",
+   .prcm   = {
+   .omap4 = {
+   .clkctrl_offs = DM814X_CM_ALWON_MMCHS_2_CLKCTRL,
+   .modulemode = MODULEMODE_SWCTRL,
+   },
+   },
+   .dev_attr   = _dev_attr,
+   .class  = _mmc_class,
+};
+
+static struct omap_hwmod_ocp_if dm814x_alwon_l3_med__mmc3 = {
+   .master = _alwon_l3_med_hwmod,
+   .slave  = _mmc3_hwmod,
+   .clk= "sysclk4_ck",
+   .user   = OCP_USER_MPU,
 };
 
 static struct omap_hwmod dm816x_mmc1_hwmod = {
.name   = "mmc1",
.clkdm_name = "alwon_l3s_clkdm",
-   .opt_clks   = dm816x_mmc1_opt_clks,
-   .opt_clks_cnt   = ARRAY_SIZE(dm816x_mmc1_opt_clks),
+   .opt_clks   = dm81xx_mmc_opt_clks,
+   .opt_clks_cnt   = ARRAY_SIZE(dm81xx_mmc_opt_clks),
.main_clk   = "sysclk10_ck",
.prcm   = {
.omap4 = {
@@ -948,8 +1018,8 @@ static struct omap_hwmod dm816x_mmc1_hwmod = {
.modulemode = MODULEMODE_SWCTRL,
},
},
-   .dev_attr   = _dev_attr,
-   .class  = _mmc_class,
+   .dev_attr   = _dev_attr,
+   .class  = _mmc_class,
 };
 
 static struct omap_hwmod_ocp_if dm816x_l4_ls__mmc1 = {
@@ -1252,6 +1322,8 @@ static struct omap_hwmod_ocp_if *dm814x_hwmod_ocp_ifs[] 
__initdata = {
_l4_ls__gpio2,
_l4_ls__elm,
_l4_ls__mcspi1,
+ 

[PATCH 4/7] ARM: dts: Add mmc device entries for dm814x

[Tony Lindgren]

Add mmc device entries for dm814x.

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

diff --git a/arch/arm/boot/dts/dm814x.dtsi b/arch/arm/boot/dts/dm814x.dtsi
index 9d81980e..18a8f0d 100644
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -183,6 +183,28 @@
ti,hwmods = "timer3";
};
 
+   mmc1: mmc@6 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc1";
+   dmas = < 24 0
+25 0>;
+   dma-names = "tx", "rx";
+   interrupts = <64>;
+   interrupt-parent = <>;
+   reg = <0x6 0x1000>;
+   };
+
+   mmc2: mmc@1d8000 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc2";
+   dmas = < 2 0
+3 0>;
+   dma-names = "tx", "rx";
+   interrupts = <28>;
+   interrupt-parent = <>;
+   reg = <0x1d8000 0x1000>;
+   };
+
control: control@14 {
compatible = "ti,dm814-scm", "simple-bus";
reg = <0x14 0x2>;
@@ -279,6 +301,15 @@
reg = <0x4820 0x1000>;
};
 
+   /* Board must configure evtmux with edma_xbar for EDMA */
+   mmc3: mmc@4781 {
+   compatible = "ti,omap4-hsmmc";
+   ti,hwmods = "mmc3";
+   interrupts = <29>;
+   interrupt-parent = <>;
+   reg = <0x4781 0x1000>;
+   };
+
edma: edma@4900 {
compatible = "ti,edma3-tpcc";
ti,hwmods = "tpcc";
-- 
2.6.2

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

[PATCH 5/7] ARM: dts: Add mmc support for dm8148-evm

[Tony Lindgren]

There is a mmc slot on the dm8148-evm that's wired to the sd_1
interface.

Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/dm8148-evm.dts | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/dm8148-evm.dts b/arch/arm/boot/dts/dm8148-evm.dts
index 109fd47..08d01c3 100644
--- a/arch/arm/boot/dts/dm8148-evm.dts
+++ b/arch/arm/boot/dts/dm8148-evm.dts
@@ -15,6 +15,14 @@
device_type = "memory";
reg = <0x8000 0x4000>;  /* 1 GB */
};
+
+   /* MIC94060YC6 controlled by SD1_POW pin */
+   vmmcsd_fixed: fixedregulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "vmmcsd_fixed";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
 };
 
 _emac0 {
@@ -26,3 +34,26 @@
phy_id = <_mdio>, <1>;
phy-mode = "rgmii";
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_fixed>;
+   bus-width = <4>;
+   cd-gpios = < 6 GPIO_ACTIVE_LOW>;
+};
+
+ {
+   sd1_pins: pinmux_sd1_pins {
+   pinctrl-single,pins = <
+   DM814X_IOPAD(0x0800, PIN_INPUT | 0x1)   /* SD1_CLK */
+   DM814X_IOPAD(0x0804, PIN_INPUT_PULLUP |  0x1)   /* 
SD1_CMD */
+   DM814X_IOPAD(0x0808, PIN_INPUT_PULLUP |  0x1)   /* 
SD1_DAT[0] */
+   DM814X_IOPAD(0x080c, PIN_INPUT_PULLUP |  0x1)   /* 
SD1_DAT[1] */
+   DM814X_IOPAD(0x0810, PIN_INPUT_PULLUP |  0x1)   /* 
SD1_DAT[2] */
+   DM814X_IOPAD(0x0814, PIN_INPUT_PULLUP |  0x1)   /* 
SD1_DAT[3] */
+   DM814X_IOPAD(0x0924, PIN_OUTPUT |  0x40)/* 
SD1_POW */
+   DM814X_IOPAD(0x093C, PIN_INPUT_PULLUP |  0x80)  /* 
GP1[6] */
+   >;
+   };
+};
-- 
2.6.2

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

[PATCH 1/7] ARM: dts: Add pinctrl macros for dm814x

[Tony Lindgren]

Let's add the DM814X_IOPAD macro the same way as we have for dm816x and
am33xx as this allows comparing the registers with the documentation easily.
The pinctrl bits are yet again different on dm814x.

Cc: Linus Walleij 
Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/dm814x.dtsi|  2 +-
 include/dt-bindings/pinctrl/dm814x.h | 48 
 include/dt-bindings/pinctrl/omap.h   |  1 +
 3 files changed, 50 insertions(+), 1 deletion(-)
 create mode 100644 include/dt-bindings/pinctrl/dm814x.h

diff --git a/arch/arm/boot/dts/dm814x.dtsi b/arch/arm/boot/dts/dm814x.dtsi
index 09a8d88..ca92346 100644
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -5,7 +5,7 @@
  */
 
 #include 
-#include 
+#include 
 
 #include "skeleton.dtsi"
 
diff --git a/include/dt-bindings/pinctrl/dm814x.h 
b/include/dt-bindings/pinctrl/dm814x.h
new file mode 100644
index 000..0f48427
--- /dev/null
+++ b/include/dt-bindings/pinctrl/dm814x.h
@@ -0,0 +1,48 @@
+/*
+ * This header provides constants specific to DM814X pinctrl bindings.
+ */
+
+#ifndef _DT_BINDINGS_PINCTRL_DM814X_H
+#define _DT_BINDINGS_PINCTRL_DM814X_H
+
+#include 
+
+#undef INPUT_EN
+#undef PULL_UP
+#undef PULL_ENA
+
+/*
+ * Note that dm814x silicon revision 2.1 and older require input enabled
+ * (bit 18 set) for all 3.3V I/Os to avoid cumulative hardware damage. For
+ * more info, see errata advisory 2.1.87. We leave bit 18 out of
+ * function-mask in dm814x.h and rely on the bootloader for it.
+ */
+#define INPUT_EN   (1 << 18)
+#define PULL_UP(1 << 17)
+#define PULL_DISABLE   (1 << 16)
+
+/* update macro depending on INPUT_EN and PULL_ENA */
+#undef PIN_OUTPUT
+#undef PIN_OUTPUT_PULLUP
+#undef PIN_OUTPUT_PULLDOWN
+#undef PIN_INPUT
+#undef PIN_INPUT_PULLUP
+#undef PIN_INPUT_PULLDOWN
+
+#define PIN_OUTPUT (PULL_DISABLE)
+#define PIN_OUTPUT_PULLUP  (PULL_UP)
+#define PIN_OUTPUT_PULLDOWN0
+#define PIN_INPUT  (INPUT_EN | PULL_DISABLE)
+#define PIN_INPUT_PULLUP   (INPUT_EN | PULL_UP)
+#define PIN_INPUT_PULLDOWN (INPUT_EN)
+
+/* undef non-existing modes */
+#undef PIN_OFF_NONE
+#undef PIN_OFF_OUTPUT_HIGH
+#undef PIN_OFF_OUTPUT_LOW
+#undef PIN_OFF_INPUT_PULLUP
+#undef PIN_OFF_INPUT_PULLDOWN
+#undef PIN_OFF_WAKEUPENABLE
+
+#endif
+
diff --git a/include/dt-bindings/pinctrl/omap.h 
b/include/dt-bindings/pinctrl/omap.h
index 1394925..d1e1512 100644
--- a/include/dt-bindings/pinctrl/omap.h
+++ b/include/dt-bindings/pinctrl/omap.h
@@ -61,6 +61,7 @@
 #define OMAP3430_CORE2_IOPAD(pa, val)  OMAP_IOPAD_OFFSET((pa), 0x25d8) (val)
 #define OMAP3630_CORE2_IOPAD(pa, val)  OMAP_IOPAD_OFFSET((pa), 0x25a0) (val)
 #define OMAP3_WKUP_IOPAD(pa, val)  OMAP_IOPAD_OFFSET((pa), 0x2a00) (val)
+#define DM814X_IOPAD(pa, val)  OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
 #define DM816X_IOPAD(pa, val)  OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
 #define AM33XX_IOPAD(pa, val)  OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
 #define AM4372_IOPAD(pa, val)  OMAP_IOPAD_OFFSET((pa), 0x0800) (val)
-- 
2.6.2

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

[PATCH 7/7] ARM: dts: Enable emmc on hp t410

[Tony Lindgren]

There's a 2GB emmc on hp t410 that's wired to the sd_2 interface.
Note that we also need to configure the evtmux using edma_xbar for
edma channels.

Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/dm8148-t410.dts | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/boot/dts/dm8148-t410.dts 
b/arch/arm/boot/dts/dm8148-t410.dts
index 79838dd..d1927a7 100644
--- a/arch/arm/boot/dts/dm8148-t410.dts
+++ b/arch/arm/boot/dts/dm8148-t410.dts
@@ -15,6 +15,13 @@
device_type = "memory";
reg = <0x8000 0x4000>;  /* 1 GB */
};
+
+   vmmcsd_fixed: fixedregulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "vmmcsd_fixed";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
 };
 
 _emac0 {
@@ -26,3 +33,31 @@
phy_id = <_mdio>, <1>;
phy-mode = "rgmii";
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_fixed>;
+   bus-width = <8>;
+   dmas = <_xbar 8 0 1/* use SDTXEVT1 instead of MCASP0TX */
+   _xbar 9 0 2>;  /* use SDRXEVT1 instead of MCASP0RX */
+   dma-names = "tx", "rx";
+};
+
+ {
+   sd2_pins: pinmux_sd2_pins {
+   pinctrl-single,pins = <
+   DM814X_IOPAD(0x09c0, PIN_INPUT_PULLUP | 0x1)/* 
SD2_DAT[7] */
+   DM814X_IOPAD(0x09c4, PIN_INPUT_PULLUP | 0x1)/* 
SD2_DAT[6] */
+   DM814X_IOPAD(0x09c8, PIN_INPUT_PULLUP | 0x1)/* 
SD2_DAT[5] */
+   DM814X_IOPAD(0x09cc, PIN_INPUT_PULLUP | 0x1)/* 
SD2_DAT[4] */
+   DM814X_IOPAD(0x09d0, PIN_INPUT_PULLUP | 0x1)/* 
SD2_DAT[3] */
+   DM814X_IOPAD(0x09d4, PIN_INPUT_PULLUP | 0x1)/* 
SD2_DAT[2] */
+   DM814X_IOPAD(0x09d8, PIN_INPUT_PULLUP | 0x1)/* 
SD2_DAT[1] */
+   DM814X_IOPAD(0x09dc, PIN_INPUT_PULLUP | 0x1)/* 
SD2_DAT[0] */
+   DM814X_IOPAD(0x09e0, PIN_INPUT | 0x1)   /* 
SD2_CLK */
+   DM814X_IOPAD(0x09f4, PIN_INPUT_PULLUP | 0x2)/* 
SD2_CMD */
+   DM814X_IOPAD(0x0920, PIN_INPUT | 40)/* SD2_SDCD */
+   >;
+   };
+};
-- 
2.6.2

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

[PATCH 0/7] Add mmc support for dm814x and dra62x

[Tony Lindgren]

Hi,

These patches add mmc support for dm814x and dra62x. These patches
depend on what's listed at:

http://marc.info/?l=linux-omap=144918431819264=2

Regards,

Tony


Tony Lindgren (7):
  ARM: dts: Add pinctrl macros for dm814x
  ARM: dts: Update edma bindings on dm814x to use edma_xbar
  ARM: OMAP2+: Add mmc hwmod entries for dm814x
  ARM: dts: Add mmc device entries for dm814x
  ARM: dts: Add mmc support for dm8148-evm
  ARM: dts: Add mmc support for dra62x j5-eco evm
  ARM: dts: Enable emmc on hp t410

 arch/arm/boot/dts/dm8148-evm.dts   |  31 +
 arch/arm/boot/dts/dm8148-t410.dts  |  35 ++
 arch/arm/boot/dts/dm814x.dtsi  | 101 +
 arch/arm/boot/dts/dra62x-j5eco-evm.dts |  31 +
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c |  93 +++---
 include/dt-bindings/pinctrl/dm814x.h   |  48 ++
 include/dt-bindings/pinctrl/omap.h |   1 +
 7 files changed, 319 insertions(+), 21 deletions(-)
 create mode 100644 include/dt-bindings/pinctrl/dm814x.h

-- 
2.6.2

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

Re: [PATCH 1/3] ARM: OMAP2+: Fix SoC detection for dra62x j5-eco

[Matthijs van Duin]

On 4 December 2015 at 00:11, Tony Lindgren  wrote:
> We can boot dra62x j5-eco using the dm814x code as the clocks and
> devices are mapped in the device tree. The dra62x is also known
> as jacinto 5.

I'm pretty sure the "eco" in the name isn't optional. As far as I know:
jacinto 5 = dra65x ~ dm814x
jacinto 5 eco = dra62x ~ dm811x
jacinto 5 entry = dra61x/60x ~ am335x

Here ~ means equivalence modulo efuse bits.

My knowledge of TI's automotive processors is limited however, as is
public documentation, so perhaps someone from TI can ack or nak this.

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

[PATCH 0/2] ARM: dts: Use MMC pwrseq instead regulators for IGEP WiFi init

[Javier Martinez Canillas]

Hello,

This series converts the IGEPv2 (IGEP0020) and IGEP COM Module (IGEP0030)
Device Tree to use the MMC power sequence provider to initialize the SDIO
WiFi chip instead of using fake fixed regulators to just toggle the Reset
and Power pins in the chip.

The patches were tested on an DM3730 IGEPv2 board but the IGEP COM Module
is the same with regard to the SDIO WiFi so it should be safe to land too.

The IGEPv2 Rev.F and the IGEP COM Module Rev.G DTS were not converted due
using a different WiFi chip (wlcore instead of libertas) than the one in
the board I've access to test so I preferred to leave those untouched.

Best regards,
Javier


Javier Martinez Canillas (2):
  ARM: dts: omap3-igep0020: Use MMC pwrseq to init SDIO WiFi
  ARM: dts: omap3-igep0030: Use MMC pwrseq to init SDIO WiFi

 arch/arm/boot/dts/omap3-igep0020.dts | 24 
 arch/arm/boot/dts/omap3-igep0030.dts | 24 
 2 files changed, 16 insertions(+), 32 deletions(-)

-- 
2.4.3

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

[PATCH 1/2] ARM: dts: omap3-igep0020: Use MMC pwrseq to init SDIO WiFi

[Javier Martinez Canillas]

When the WiFi support was added to the IGEP0020 board, the MMC subsystem
did not provide a mechanism to define power sequence providers. So a DT
hack was used to toggle the WiFi chip reset and power down pins by using
fake fixed regulators whose enable GPIO was the GPIOs connected to these
pins.

But now the simple MMC power sequence provider can be used for this and
the workaround removed.

Signed-off-by: Javier Martinez Canillas 
---

 arch/arm/boot/dts/omap3-igep0020.dts | 24 
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
b/arch/arm/boot/dts/omap3-igep0020.dts
index 3835e1569c29..33d6b4ead092 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -15,25 +15,17 @@
model = "IGEPv2 Rev. C (TI OMAP AM/DM37x)";
compatible = "isee,omap3-igep0020", "ti,omap36xx", "ti,omap3";
 
-   /* Regulator to trigger the WIFI_PDN signal of the Wifi module */
-   lbee1usjyc_pdn: lbee1usjyc_pdn {
+   vmmcsdio_fixed: fixedregulator-mmcsdio {
compatible = "regulator-fixed";
-   regulator-name = "regulator-lbee1usjyc-pdn";
+   regulator-name = "vmmcsdio_fixed";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
-   gpio = < 10 GPIO_ACTIVE_HIGH>;/* gpio_138 - WIFI_PDN 
*/
-   startup-delay-us = <1>;
-   enable-active-high;
};
 
-   /* Regulator to trigger the RESET_N_W signal of the Wifi module */
-   lbee1usjyc_reset_n_w: lbee1usjyc_reset_n_w {
-   compatible = "regulator-fixed";
-   regulator-name = "regulator-lbee1usjyc-reset-n-w";
-   regulator-min-microvolt = <330>;
-   regulator-max-microvolt = <330>;
-   gpio = < 11 GPIO_ACTIVE_HIGH>;/* gpio_139 - RESET_N_W 
*/
-   enable-active-high;
+   mmc2_pwrseq: mmc2_pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   reset-gpios = < 11 GPIO_ACTIVE_LOW>,  /* gpio_139 - 
RESET_N_W */
+ < 10 GPIO_ACTIVE_LOW>;  /* gpio_138 - 
WIFI_PDN */
};
 };
 
@@ -51,8 +43,8 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_pins _pins>;
-   vmmc-supply = <_pdn>;
-   vmmc_aux-supply = <_reset_n_w>;
+   vmmc-supply = <_fixed>;
+   mmc-pwrseq = <_pwrseq>;
bus-width = <4>;
non-removable;
 };
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe 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: OMAP2+: Change core_initcall levels to postcore_initcall

[Grygorii Strashko]

On 12/03/2015 06:41 PM, Tony Lindgren wrote:
> * Grygorii Strashko  [151203 08:35]:
>> On 12/03/2015 06:00 PM, Tony Lindgren wrote:
>>> * Tony Lindgren  [151130 08:29]:
 We want to be able to probe a few selected device drivers before hwmod
 code populates the clocks in omap_hwmod_setup_all(). This allows us to
 convert most of the clock drivers into regular device drivers.
>>
>> if understand things right, ti clks now will be populated and initialized
>> from
>> __omap_sync32k_timer_init
>>   - omap_clk_init()
>> - ..
>> - of_clk_init()
>> - ..
>> - omap_clk_soc_init()
>>
>> and __omap_sync32k_timer_init(), in turn, will be called from:
>> arch/arm/kernel/time.c
>>   - time_init()
>>  machine_desc->init_time();
>> (without your patch 1).
> 
> Yes that's the current approach, but we can do better. We only need the 
> following
> clocks for system timers at that point:
> 
> - mux clocks to select between the 32k and hf oscillator source
> 
> - clkctrl driver to gate the ocp clock
> 
> All the other clocks can be initialized at core_initcall time with this 
> change.
> 
>> So, I don't see real dependency here between clk initialization and hwmods :(
> 
> You don't because it's only implemented so far for the dm814x ADPLL clock :)
> 
> That I posted as "[PATCH 0/2] Clock driver for dm814x ADPLL". Note how it's
> just a regular device driver that also works as loadable module on boards that
> have all the necessary clocks enabled already by the bootloader.
> 

Ah. Thanks. I see it now.

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