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[] = { > >>>>

Re: [GIT PULL 2/2] omap device tree changes for v4.5, part 1

On Thursday 10 December 2015 16:03:09 Tony Lindgren wrote: > Device tree changes for omaps for v4.5 merge window: > > - Update all omaps to use pinctrl macros. This makes comparing the pinmux > settings against the documentation much earlier. Javier compared the > checksums of the generated

Re: [PATCH 00/10] drivers/pci: avoid module_init in non-modular host/pci*

On Monday 14 December 2015 10:19:40 Thierry Reding wrote: > > PCIe host driver that use fixup (DECLARE_PCI_FIXUP_*) can't use tristate. > > Fixup region is in kernel region and this region if not updated when > > loading a module. > > Interesting, I hadn't thought about that. I suppose this means

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

setup to the core > - dma_request_slave_channel_reason() remeved and it is now defines as > dma_request_chan() > - Print of warning removed when DT or ACPI lookup fails and we are going to > Fallback to legacy lookup > - members of struct dma_filter has been revised for simplicity. Whole s

Re: [PATCH v3 0/9] phy: use syscon framework APIs to set ctrl mod reg

On Tuesday 15 December 2015 14:45:59 Kishon Vijay Abraham I wrote: > This series is basically to deprecate using phy-omap-control and use > syscon APIs to program the control module registers. > > Changes from v2: > No changes. > > Changes from v1: > *) cleanup ti_pipe3_probe in multiple steps >

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

On Tuesday 15 December 2015 10:33:25 Pali Rohár wrote: > On Monday 30 November 2015 11:09:42 Nicolas Pitre wrote: > > On Mon, 30 Nov 2015, Pali Rohár wrote: > > > On Monday 30 November 2015 07:23:53 Tony Lindgren wrote: > > > > * Pali Rohár [151129 16:16]: > > > > > On

Re: [PATCH v3 0/9] phy: use syscon framework APIs to set ctrl mod reg

On Tuesday 15 December 2015 16:44:41 Kishon Vijay Abraham I wrote: > Hi Arnd, > > On Tuesday 15 December 2015 04:26 PM, Arnd Bergmann wrote: > > On Tuesday 15 December 2015 14:45:59 Kishon Vijay Abraham I wrote: > >> This series is basically to deprecate using phy-omap-con

Re: [PATCH] mtd: omap_elm: print interrupt resource using %pr

On Friday 11 December 2015 17:10:56 Brian Norris wrote: > Hi Arnd, > > On Tue, Dec 08, 2015 at 04:39:45PM +0100, Arnd Bergmann wrote: > > When CONFIG_LPAE is set on ARM, resource_size_t is 64-bit wide > > and we get a warning about an incorrect format string for printing >

[PATCH v2] mtd: omap_elm: print interrupt resource using %pr

of type 'int', but argument 3 has type 'resource_size_t {aka long long unsigned int}' [-Wformat=] This patch avoids the type mismatch by printing the interrupt as a resource using the %pr format string. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- v2: pass correct pointer diff --git a/d

Re: [GIT PULL 1/2] omap fixes for 81xx for v4.5 merge window

On Thursday 10 December 2015 16:03:08 Tony Lindgren wrote: > Fixes for ti81xx for v4.5 merge window. We have hp t410 already booting > in mainline kernel with it's bootloader configured clocks. However, > trying to boot dm814x-evm uncovered all kind of issues with the timer > clock. To keep t410

Re: [GIT PULL] omap fixes against v4.4-rc4

On Thursday 10 December 2015 15:39:08 Tony Lindgren wrote: > Few fixes for omaps for v4.4-rc cycle: > > - Fix clock source for ARM TWD and global timers on am437x > > - Always select REGULATOR_FIXED_VOLTAGE for omap2+ instead of > when MACH_OMAP3_PANDORA is selected > > - Fix SPI DMA handles

Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT

On Saturday 02 January 2016 16:22:03 Pali Rohár wrote: > On Monday 28 December 2015 15:55:28 Arnd Bergmann wrote: > > On Monday 28 December 2015 15:54:35 Pali Rohár wrote: > > > > > > > > I mean you can add the platform data to the omap_auxdata_look

Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT

On Sunday 03 January 2016 00:03:54 Pali Rohár wrote: > On Saturday 02 January 2016 23:57:47 Arnd Bergmann wrote: > > On Saturday 02 January 2016 16:22:03 Pali Rohár wrote: > > > On Monday 28 December 2015 15:55:28 Arnd Bergmann wrote: > > > > On Monday 28 December

Re: [GIT PULL 2/3] reworked soc changes for ti81xx devices and minimal dra62x j5ec-evm support

On Tuesday 22 December 2015 17:44:46 Tony Lindgren wrote: > Add minimal SoC support for dra62x also known as j5eco. As it's closely > related to dm814x, we can treat it as a dm814x variant for now and do > rest of the configuration with DTS just files. And let's add hwmod > support for MMC and USB

Re: [GIT PULL 3/3] reworked dts changes for ti81xx devices and minimal dra62x j5ec-evm support

On Tuesday 22 December 2015 17:44:47 Tony Lindgren wrote: > Add minimal device tree support for dra62x also known j5eco. It is > related to dm814x, just the clocks are a bit different and it has a > different set of integrated devices. And let's get some basic dm814x > and dra62x devices working

Re: [GIT PULL 1/3] reworked fix for earlier ti81xx changes for v4.5 merge window

On Tuesday 22 December 2015 17:44:45 Tony Lindgren wrote: > Here are reworked pull requests to separate the dts changes as requested > by Olof. > > The pull request below, and the third pull request in this series, > still depend on the earlier branch omap-for-v4.5/81xx-fixes-signed. > The pull

Re: [PATCH 1/5] arm: devtree: Set system_rev from DT "/revision"

On Tuesday 05 January 2016 12:37:50 Pali Rohár wrote: > On Monday 28 December 2015 23:27:17 Arnd Bergmann wrote: > > On Monday 28 December 2015 13:01:22 Frank Rowand wrote: > > > > > > Patch 2/5 copies the value from ATAG_REVISION into the fdt "/revision" &g

Re: [PATCH 1/5] arm: devtree: Set system_rev from DT "/revision"

On Monday 28 December 2015 13:01:22 Frank Rowand wrote: > > Patch 2/5 copies the value from ATAG_REVISION into the fdt "/revision" > property. > > If the use of /revision is limited to being a location to hold an ATAG > value to pass to the global variable system_rev, then it would make > sense

Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT

On Friday 25 December 2015 13:53:11 Pali Rohár wrote: > On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote: > > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote: > > > * Arnd Bergmann <a...@arndb.de> [150515 14:26]: > > > > On Friday 15 May 2015 23:22:37 P

Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT

On Monday 28 December 2015 15:28:48 Pali Rohár wrote: > On Monday 28 December 2015 15:14:50 Arnd Bergmann wrote: > > On Friday 25 December 2015 13:53:11 Pali Rohár wrote: > > > On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote: > > > > On Monday 18 May 201

Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT

On Monday 28 December 2015 15:54:35 Pali Rohár wrote: > On Monday 28 December 2015 15:41:01 Arnd Bergmann wrote: > > On Monday 28 December 2015 15:28:48 Pali Rohár wrote: > > > On Monday 28 December 2015 15:14:50 Arnd Bergmann wrote: > > > > On Friday 25 December

Re: [PATCH 0/3] OMAP: RX51: save atags data to be exported on /proc/atags

be exported in /proc/atags later Looks ok to me. Acked-by: Arnd Bergmann <a...@arndb.de> 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: [RFC 3/6] dmaengine: core: Introduce new, universal API to request a channel

On Friday 27 November 2015 13:16:37 Peter Ujfalusi wrote: > On 11/27/2015 01:00 PM, Arnd Bergmann wrote: > > On Friday 27 November 2015 10:29:39 Peter Ujfalusi wrote: > >> struct dma_chan *dma_request_chan(struct device *dev, const char *name, > >>

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

On Friday 27 November 2015 10:29:39 Peter Ujfalusi wrote: > struct dma_chan *dma_request_chan(struct device *dev, const char *name, > const dma_cap_mask_t *mask); > To request a slave channel. The mask parameter is optional and it is used > to check if the received

Re: [GIT PULL] omap fixes against v4.4-rc2

On Wednesday 25 November 2015 14:37:04 Tony Lindgren wrote: > Fixes for omaps for v4.4-rc cycle: > > - A series of audio changes for dra7 that missed the merge window but turned > out to be necessary to fix a boot time imprecise external abort error and to > getaudio working > > - Fix l4

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote: > * Pali Rohár [151123 06:46]: > > On Sunday 22 November 2015 07:51:46 Pavel Machek wrote: > > > On Wed 2015-11-11 17:10:46, Frank Rowand wrote: > > > > Adding devicetree list. > > > > > > > > Thread starts at > >

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

On Wednesday 25 November 2015 22:44:28 Pali Rohár wrote: > > Arnd, my question about proper solution reminds... Proprietary > bootloader which cannot be replaced (e.g. it is signed or do unknown > magic) provides information to booted kernel via custom specific ATAGs > fields. How userspace

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

On Wednesday 25 November 2015 13:03:10 Tony Lindgren wrote: > * Arnd Bergmann <a...@arndb.de> [151125 11:50]: > > On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote: > > > At least I don't have better solutions in mind. > > > > I would be happi

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

On Friday 27 November 2015 19:51:48 Russell King - ARM Linux wrote: > On Fri, Nov 27, 2015 at 01:27:23PM +, Russell King - ARM Linux wrote: > > It is possible to redirect any program to open any other file. You can > > do it via a LD preload, and intercepting the open(), and possibly the > >

Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry

On Friday 27 November 2015 18:28:50 Nicolas Pitre wrote: > On Fri, 27 Nov 2015, Arnd Bergmann wrote: > > > I don't mind creating the /proc/atags compatibility hack from the kernel > > for a DT based N700 kernel, as long as we limit it as much as we can > > to the machin

[PATCH 4/7] ARM: iop13xx: make headers more local

Some header files are never included outside of a mach-iop13xx 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 <a...@arndb.de> --- arch/arm/mach-iop13xx/include/mach/pci.h

[PATCH 3/7] ARM: davinci: make headers more local

Some header files are never included outside of a mach-davinci 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 <a...@arndb.de> --- arch/arm/mach-davinci/board-da830-evm.c| 2 +- arch/ar

[PATCH 7/7] ARM: netx: remove unused mach/param.h

I could not find any users of this file, past or present, and it contains only a comment, so let's remove it. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/arm/mach-netx/include/mach/param.h | 18 -- 1 file changed, 18 deletions(-) delete mode 100644 arch/arm/mac

[PATCH 1/7] ARM: omap1: make headers more local

Some header files are never included outside of a mach-omap1 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 <a...@arndb.de> --- arch/arm/mach-omap1/board-ams-delta.c | 2 +- arch/arm/mach

[PATCH 6/7] ARM: mvebu: remove unused mach/gpio.h

This file was left over from a cleanup of asm/gpio.h and has not been used in a while. Let's just remove it now, so the arch/arm/mach-mvebu/include/ directory can also disappear. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- arch/arm/mach-mvebu/include/mach/gpio.h | 1 - 1 file chan

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

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 <a...@arndb.de> --- arch/arm/mach-w90x900/cpu.c | 4 ++-- arch/ar

[PATCH 2/7] ARM: ks8695: make headers more local

Some header files are never included outside of a mach-ks8695 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 <a...@arndb.de> --- arch/arm/mach-ks8695/board-acs5k.c | 2 +- arch/ar

[PATCH 0/7] ARM: make mach/*.h headers more local

with them applied, so I'm rather sure that they are all harmless. Arnd Bergmann (7): ARM: omap1: make headers more local ARM: ks8695: make headers more local ARM: davinci: make headers more local ARM: iop13xx: make headers more local ARM: w90x900: make headers more local ARM: mvebu

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

On Tuesday 01 December 2015 11:58:53 Peter Ujfalusi wrote: > On 11/30/2015 04:11 PM, Arnd Bergmann wrote: > > On Monday 30 November 2015 15:45:34 Peter Ujfalusi wrote: > >> @@ -2428,6 +2436,22 @@ bool edma_filter_fn(struct dma_chan *chan, void > >> *param)

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

On Tuesday 01 December 2015 12:12:47 Peter Ujfalusi wrote: > > We would need: > { "da830-mmc.0", "rx", (void*)EDMA_CTLR_CHAN(0, 16) }, > { "da830-mmc.0", "tx", (void*)EDMA_CTLR_CHAN(0, 17) }, > > as we need to cast the param. > It is still compact, but having to add the (void*)

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

On Monday 30 November 2015 15:45:33 Peter Ujfalusi wrote: > const char *name); > struct dma_chan *dma_request_slave_channel(struct device *dev, const char > *name); > + > +struct dma_chan *dma_request_chan(struct device *dev, const char *name); >

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

On Monday 30 November 2015 15:45:34 Peter Ujfalusi wrote: > @@ -2428,6 +2436,22 @@ bool edma_filter_fn(struct dma_chan *chan, void *param) > } > EXPORT_SYMBOL(edma_filter_fn); > > +static bool edma_filter_for_map(struct dma_chan *chan, void *param) > +{ > + bool match = false; > + > +

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

On Monday 30 November 2015 15:45:30 Peter Ujfalusi wrote: > Changes since RFC v01: >- dma_request_chan(); lost the mask parameter >- The new API does not rely on RESOURCE_DMA, instead the dma_filter_map table > will be used to provide the needed information to the filter function in > legacy

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

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", EDMA_CTLR_CHAN(0, 1)), > >>

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote: > 2. non slave channel requests, where only the functionality matters, like > memcpy, interleaved, memset, etc. > We could have a simple: > dma_request_channel(mask); > > But looking at the drivers using dmaengine legacy

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

On Friday 20 November 2015 14:52:03 Peter Ujfalusi wrote: > > >> For legacy the filter function is pretty much needed to handle the > >> differences > >> between the platforms as not all of them does the filtering in a same way. > >> So > >> the first type of map would be feasible IMHO. > > >

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

On Friday 20 November 2015 12:25:06 Peter Ujfalusi wrote: > On 11/19/2015 01:25 PM, Arnd Bergmann wrote: > >> dma_request_channel(mask); /* memcpy. etc, non slave mostly */ > >> > >> Not sure how to name this as reusing existing (good, descriptive) function > >

Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

On Thursday 19 November 2015 12:34:22 Peter Ujfalusi wrote: > > I think we can go with a single API, but I don't really like that: > dma_request_channel(dev, name, *mask, fn, fn_param); > > This would cover all current uses being legacy, DT/ACPI, compat, etc: > dma_request_channel(NULL, NULL, ,

Re: [PATCH] ARM: OMAP2: use correct timer function for AM43XX and TI81XX

On Monday 16 November 2015 15:13:55 Felipe Balbi wrote: > Arnd Bergmann <a...@arndb.de> writes: > > AM43XX and TI81XX use omap3_gptimer_timer_init(), but that is only > > built into the kernel for OMAP3 and AM33XX, otherwise we get: > > > > arch/arm/mach-omap2/

<    3   4   5   6   7   8