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

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

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

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

Re: [PATCH 1/2] clk: ti: Add support for dm814x ADPLL

* 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

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

* 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

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

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

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

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

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

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

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

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

Re: [PATCH 2/2] ARM: OMAP2+: Change core_initcall levels to postcore_initcall

* 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* 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

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

* 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

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

* 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(); >

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

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

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

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

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

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

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

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.

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

* 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

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

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

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

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

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

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

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

* 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

[PATCH 6/7] ARM: dts: Add mmc support for dra62x j5-eco evm

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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:

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

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

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

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.

Re: [PATCH 2/2] ARM: OMAP2+: Change core_initcall levels to postcore_initcall

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

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

On Tue, Dec 01, 2015 at 08:03:13PM +0200, Dmitry Lifshitz wrote: > SBC-AM57x is a single board computer designed for industrial and > embedded applications. It is based on the Texas Instruments Sitara AM57x > system-on-chip family. SBC-AM57x is implemented with the CL-SOM-AM57x >

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

* Peter Ujfalusi [151202 02:01]: > On 12/01/2015 07:00 PM, Tony Lindgren wrote: > >> I see. The dm81xx basically am33xx/am43xx? > > > > Yeah similar to am33xx with different clocks and with a bunch of > > accelerators. > > > >> Actually I would prefer to use the

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

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

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

On Wed, Dec 2, 2015 at 3:59 PM, Peter Ujfalusi wrote: > Hi, > > I keep this still as RFC. > > 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

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

On Wed, Dec 2, 2015 at 3:59 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. > >

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

* Tony Lindgren [151201 17:23]: > * Matthijs van Duin [151201 17:15]: > > On 2 December 2015 at 01:46, Tony Lindgren wrote: > > > Ouch. We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3 > > > dts macros that ensure

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

* Matthijs van Duin [151201 17:23]: > On 2 December 2015 at 01:46, Tony Lindgren wrote: > > We should probably have separate PIN_INPUT_3V3 and PIN_OUTPUT_3V3 > > dts macros that ensure that? > > I'm in general no fan of such macros: it feels really

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

On Wed, Dec 02, 2015 at 07:03:17AM -0800, Tony Lindgren wrote: > * Roger Quadros [151201 21:13]: > > On 02/12/15 08:56, Brian Norris wrote: > > > > > > I'll take another pass over your patch set, but if things are looking > > > better, how do you expect to merge this? There are

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

Hi Roger, On Wed, Dec 02, 2015 at 10:42:12AM +0530, Roger Quadros wrote: > On 02/12/15 08:56, Brian Norris wrote: > > On Tue, Dec 01, 2015 at 04:41:16PM +0200, Roger Quadros wrote: > >> On 30/11/15 21:54, Brian Norris wrote: > >>> But anyway, I'm not sure that completely answered my question. My

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

* Brian Norris [151202 10:14]: > On Wed, Dec 02, 2015 at 07:03:17AM -0800, Tony Lindgren wrote: > > * Roger Quadros [151201 21:13]: > > > On 02/12/15 08:56, Brian Norris wrote: > > > > > > > > I'll take another pass over your patch set, but if things

Re: [PATCH v4 1/5] spi: introduce accelerated read support for spi flash devices

On Mon, Nov 30, 2015 at 10:45:11AM +0530, Vignesh R wrote: > In addition to providing direct access to SPI bus, some spi controller > hardwares (like ti-qspi) provide special port (like memory mapped port) > that are optimized to improve SPI flash read performance. I'm reasonably OK with this

Re: [PATCH v3 0/3] soc: ti: Introduce wkup_m3_ipc driver

Hi, On 10/20/2015 11:18 AM, Tony Lindgren wrote: Hi all, * Dave Gerlach [150922 17:20]: Hi, 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

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

On Wednesday 02 December 2015 10:22:09 Vinod Koul wrote: > > > > > > This legacy mode needs changes in platform code, in dmaengine drivers > > > > and > > > > finally the dmaengine user drivers can be converted: > > > > > > Are you marking the current APIs as dericated in the end of this series

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

mtd_to_nand() now uses the container_of() approach to transform an mtd_info pointer into a nand_chip one. Drop useless mtd->priv assignments from NAND controller drivers. Signed-off-by: Boris Brezillon --- Patch generated with the following coccinelle script:

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

Hi Brian, On Tue, 1 Dec 2015 14:17:47 -0800 Brian Norris wrote: > On Tue, Dec 01, 2015 at 12:03:14PM +0100, Boris Brezillon wrote: > > mtd_to_nand() now uses the container_of() approach to transform an > > mtd_info pointer into a nand_chip one. Drop useless

Re: [PATCH v4 11/27] mtd: nand: omap: Clean up device tree support

Hi Roger, On Tue, Oct 06, 2015 at 01:35:48PM +0300, Roger Quadros wrote: > Move NAND specific device tree parsing to NAND driver. > > The NAND controller node must have a compatible id, register space > resource and interrupt resource. > > Signed-off-by: Roger Quadros This

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

Brian, On 03/12/15 10:39, Brian Norris wrote: > Hi, > > On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote: >> Hi, >> >> 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

Re: [PATCH v4 11/27] mtd: nand: omap: Clean up device tree support

On Thu, Dec 03, 2015 at 11:27:13AM +0530, Roger Quadros wrote: > On 03/12/15 09:59, Brian Norris wrote: > > On Tue, Oct 06, 2015 at 01:35:48PM +0300, Roger Quadros wrote: > >> arch/arm/mach-omap2/gpmc-nand.c | 5 +- > >> drivers/memory/omap-gpmc.c | 143 > >>

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

Hi, On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote: > Hi, > > 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. > >

Re: [PATCH v4 11/27] mtd: nand: omap: Clean up device tree support

Brian, On 03/12/15 09:59, Brian Norris wrote: > Hi Roger, > > On Tue, Oct 06, 2015 at 01:35:48PM +0300, Roger Quadros wrote: >> Move NAND specific device tree parsing to NAND driver. >> >> The NAND controller node must have a compatible id, register space >> resource and interrupt resource. >>

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

(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

Re: [PATCH v3 04/27] mtd: nand: omap2: Use gpmc_omap_get_nand_ops() to get NAND registers

On Fri, Sep 18, 2015 at 05:53:26PM +0300, Roger Quadros wrote: > Deprecate nand register passing via platform data and use > gpmc_omap_get_nand_ops() instead. > > Signed-off-by: Roger Quadros > --- > arch/arm/mach-omap2/gpmc-nand.c | 2 -- > drivers/mtd/nand/omap2.c

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

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

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

On 12/02/2015 06:37 AM, Vinod Koul wrote: > On Tue, Dec 01, 2015 at 09:20:28PM +0100, Arnd Bergmann wrote: >> On Tuesday 01 December 2015 22:52:12 Vinod Koul wrote: >>> On Mon, Nov 30, 2015 at 03:45:34PM +0200, Peter Ujfalusi wrote: Add support for providing device to filter_fn mapping so

Re: [PATCH v2 1/6] ARM: OMAP2+: dts: cm-t335: add initial support

Hi Tony, On 11/30/2015 09:51 PM, Tony Lindgren wrote: * Uri Mashiach [151124 06:03]: --- /dev/null +++ b/arch/arm/boot/dts/am335x-cm-t335.dts ... + { + pinctrl-names = "default"; + pinctrl-0 = <_pins>; + + status = "okay"; +}; + FYI, the

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

On 12/01/2015 07:00 PM, Tony Lindgren wrote: >> I see. The dm81xx basically am33xx/am43xx? > > Yeah similar to am33xx with different clocks and with a bunch of accelerators. > >> Actually I would prefer to use the dmaengine's event router framework and we >> do have support for the am33xx/am43xx

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

On 12/01/2015 04:24 PM, Arnd Bergmann wrote: > On Tuesday 01 December 2015 15:45:32 Peter Ujfalusi wrote: static struct dma_filter_map da830_edma_map[] = { DMA_FILTER_ENTRY("davinci-mcasp.0", "rx", EDMA_CTLR_CHAN(0, 0)), DMA_FILTER_ENTRY("davinci-mcasp.0", "tx",

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

On 12/01/2015 10:17 PM, Arnd Bergmann wrote: > On Tuesday 01 December 2015 22:29:54 Vinod Koul wrote: >> On Mon, Nov 30, 2015 at 03:45:30PM +0200, Peter Ujfalusi wrote: >>> channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode >>> it will use a filter lookup table and retrieves

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

On Wednesday 02 December 2015 12:51:43 Peter Ujfalusi wrote: > On 12/01/2015 04:24 PM, Arnd Bergmann wrote: > > On Tuesday 01 December 2015 15:45:32 Peter Ujfalusi wrote: > static struct dma_filter_map da830_edma_map[] = { > DMA_FILTER_ENTRY("davinci-mcasp.0", "rx",

[RFC v03 01/15] dmaengine: core: Skip mask matching when it is not provided to private_candidate

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

[RFC v03 12/15] ARM: davinci: devices-da8xx: Remove DMA resources for MMC and SPI

The drivers are now converted to not use the DMA resource. Signed-off-by: Peter Ujfalusi --- arch/arm/mach-davinci/devices-da8xx.c | 49 --- 1 file changed, 49 deletions(-) diff --git a/arch/arm/mach-davinci/devices-da8xx.c

[RFC v03 15/15] ARM: davinci: dm365: Remove DMA resources for SPI

The driver is converted to not use the DMA resource. Signed-off-by: Peter Ujfalusi --- arch/arm/mach-davinci/dm365.c | 8 1 file changed, 8 deletions(-) diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index e794bff7d589..664ee6bbef22

[RFC v03 10/15] mmc: davinci_mmc: Use dma_request_chan() to requesting DMA channel

With the new dma_request_chan() the clinet driver does not need to look for the DMA resource and it does not need to pass filter_fn anymore. By switching to the new API the davinci_mmc driver can now support deferred probing against DMA. Signed-off-by: Peter Ujfalusi ---

[RFC v03 14/15] ARM: davinci: dm355: Remove DMA resources for SPI

The driver is converted to not use the DMA resource. Signed-off-by: Peter Ujfalusi --- arch/arm/mach-davinci/dm355.c | 8 1 file changed, 8 deletions(-) diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c index ee7656fa0c52..bed8f49eb60c

[RFC v03 06/15] ARM: davinci: dm355: Add dma_filter_map to edma

Provide the dma_filter_map to edma which will allow us to move the drivers to the new, simpler dmaengine API and we can remove the DMA resources also for the devices. Signed-off-by: Peter Ujfalusi --- arch/arm/mach-davinci/dm355.c | 20 1 file

[RFC v03 09/15] ARM: davinci: dm646x: Add dma_filter_map to edma

Provide the dma_filter_map to edma which will allow us to move the drivers to the new, simpler dmaengine API and we can remove the DMA resources also for the devices. Signed-off-by: Peter Ujfalusi --- arch/arm/mach-davinci/dm646x.c | 11 +++ 1 file changed, 11

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

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

[RFC v03 07/15] ARM: davinci: dm365: Add dma_filter_map to edma

Provide the dma_filter_map to edma which will allow us to move the drivers to the new, simpler dmaengine API and we can remove the DMA resources also for the devices. Signed-off-by: Peter Ujfalusi --- arch/arm/mach-davinci/dm365.c | 22 ++ 1 file

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

Hi, I keep this still as RFC. 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

[RFC v03 05/15] ARM: davinci: devices-da8xx: Add dma_filter_map to edma

Provide the dma_filter_map to edma which will allow us to move the drivers to the new, simpler dmaengine API and we can remove the DMA resources also for the devices. Signed-off-by: Peter Ujfalusi --- arch/arm/mach-davinci/devices-da8xx.c | 46

[RFC v03 08/15] ARM: davinci: dm644x: Add dma_filter_map to edma

Provide the dma_filter_map to edma which will allow us to move the drivers to the new, simpler dmaengine API and we can remove the DMA resources also for the devices. Signed-off-by: Peter Ujfalusi --- arch/arm/mach-davinci/dm644x.c | 12 1 file changed, 12

[RFC v03 13/15] ARM: davinci: devices: Remove DMA resources for MMC

The driver is converted to not use the DMA resource. Signed-off-by: Peter Ujfalusi --- arch/arm/mach-davinci/devices.c | 19 --- 1 file changed, 19 deletions(-) diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c index

[RFC v03 11/15] spi: davinci: Use dma_request_chan() to requesting DMA channel

With the new dma_request_chan() the clinet driver does not need to look for the DMA resource and it does not need to pass filter_fn anymore. By switching to the new API the davinci_mmc driver can now support deferred probing against DMA. Signed-off-by: Peter Ujfalusi ---

[RFC v03 02/15] dmaengine: core: Move and merge the code paths using private_candidate

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.

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

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

[PATCH 0/2] Clock driver for dm814x ADPLL

Hi all, Here's a clock driver for the ADPLL on dm814x. It's still in read-only mode for the PLL, but is already usable with the gates and dividers and allows us to add devices like MMC and USB. To test this please apply the patches from below on v4.4-rc3:

[PATCH 2/2] ARM: dts: Add clocks for dm814x ADPLL

These use the standard clock bindings and now we can make some of the fixed clocks into real clocks. Cc: Tero Kristo Signed-off-by: Tony Lindgren --- arch/arm/boot/dts/dm814x-clocks.dtsi | 256 ++- 1 file changed, 225

[PATCH 1/2] clk: ti: Add support for dm814x ADPLL

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

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

On Tue, Dec 01, 2015 at 10:10:21AM -0600, Nishanth Menon wrote: > TMP102 works based on conversions done periodically. However, as per > the TMP102 data sheet[1] the first conversion is triggered immediately > after we program the configuration register. The temperature data > registers do not

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

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

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

On Tue, Dec 01, 2015 at 12:03:09PM +0100, Boris Brezillon wrote: > struct nand_chip now embeds an mtd device. Patch all drivers to make use > of this mtd instance instead of using the instance embedded in their > private struct or dynamically allocated. > > Signed-off-by: Boris Brezillon

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

On Tuesday 01 December 2015 22:29:54 Vinod Koul wrote: > On Mon, Nov 30, 2015 at 03:45:30PM +0200, Peter Ujfalusi wrote: > > channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode > > it will use a filter lookup table and retrieves the needed information from > > the

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

Hi Boris, On Tue, Dec 01, 2015 at 12:03:09PM +0100, Boris Brezillon wrote: > struct nand_chip now embeds an mtd device. Patch all drivers to make use > of this mtd instance instead of using the instance embedded in their > private struct or dynamically allocated. > > Signed-off-by: Boris

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

On Tue, Dec 01, 2015 at 12:03:14PM +0100, Boris Brezillon wrote: > mtd_to_nand() now uses the container_of() approach to transform an > mtd_info pointer into a nand_chip one. Drop useless mtd->priv > assignments from NAND controller drivers. > > Signed-off-by: Boris Brezillon

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

Hi Nishanth, [auto build test WARNING on: v4.4-rc3] [also build test WARNING on: next-20151127] url: https://github.com/0day-ci/linux/commits/Nishanth-Menon/reset-Introduce-static-inline-dummy-function-when-CONFIG_RESET_CONTROLLER/20151201-233708 reproduce: # apt-get install sparse

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

There's a mux after the oscillator similar to am335x. I did not notice this on hp t410 as it boots even with no clocks configured. Cc: Paul Walmsley Signed-off-by: Tony Lindgren --- arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 8 1 file changed, 4

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

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

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

* Matthijs van Duin [151201 16:11]: > On 2 December 2015 at 00:38, Tony Lindgren wrote: > > Looks like GPIO softreset status bit on both dm8168 and dm8148 > > is broken and only goes high initially. After writing to sysc > > softreset bit, the

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

* Matthijs van Duin [151201 16:26]: > On 2 December 2015 at 00:38, Tony Lindgren wrote: > > - pinctrl-single,function-mask = > > <0x300ff>; > > + pinctrl-single,function-mask

<    4   5   6   7   8   9   10   11   12   13   >