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

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

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: [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 for 4.4 0/2] DT/dmaengine: edma: Convert 16bit arrays to 32bit

e filter function mapping support). Hrm, > there might be trivial conflict in the include/linux/platform_data/edma.h with > the "dmaengine 'universal' API". Both patches Acked-by: Arnd Bergmann <a...@arndb.de> > Tony, Arnd, Vinod: Can you agree on the practicalities on h

Re: [PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

On Tuesday 08 December 2015 09:42:26 Peter Ujfalusi wrote: > On 12/04/2015 11:51 PM, Tony Lindgren wrote: > >> > >> Please just drop the /bits/ 16 and use normal cells. > > > > Yeah agreed, makes things less confusing for sure > > 4.4 will be the first kernel where we will have the new eDMA

Re: [PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

On Tuesday 08 December 2015 12:22:09 Peter Ujfalusi wrote: > On 12/08/2015 11:51 AM, Arnd Bergmann wrote: > > On Tuesday 08 December 2015 09:42:26 Peter Ujfalusi wrote: > >> On 12/04/2015 11:51 PM, Tony Lindgren wrote: > >>>> > >>>> Ple

[PATCH] 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> --- drivers/mtd/nand/omap_elm.c | 2 +-

Re: [PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

On Friday 04 December 2015 10:47:07 Tony Lindgren wrote: > > Peter Ujfalusi writes: > > > @@ -174,12 +182,44 @@ > > > }; > > > > > > edma: edma@4900 { > > > - compatible = "ti,edma3"; > > > - ti,hwmods =

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

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

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

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

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

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: [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: [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: [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 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)), > >>

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

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

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

On Wednesday 18 November 2015 16:41:35 Peter Ujfalusi wrote: > On 11/18/2015 04:29 PM, Arnd Bergmann wrote: > > On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote: > >> 2. non slave channel requests, where only the functionality matters, like > >> memcpy, interl

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

On Wednesday 18 November 2015 17:43:04 Andy Shevchenko wrote: > > > > I assume that the sst-firmware.c case is a mistake, it should just use a > > plain DMA_SLAVE and not DMA_MEMCPY. > > Other way around. > Ok, I see. In that case I guess it also shouldn't call dmaengine_slave_config(), right?

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 v2 3/3] [media] include/media: move platform_data to linux/platform_data/media

On Monday 16 November 2015 09:00:45 Mauro Carvalho Chehab wrote: > Let's not mix platform_data headers with the core headers. Instead, let's > create a subdir at linux/platform_data and move the headers to that > common place, adding it to MAINTAINERS. > Acked-by: Arnd Bergmann &l

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

to match the callers. Consequently, we no longer need to build the omap3_secure_sync32k_timer_init and omap4_local_timer_init for the platforms that have been moved over to other functions. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- The code has changed a couple of times, but this v

Re: [PATCH 2/2] [media] include/media: move platform driver headers to a separate dir

On Friday 13 November 2015 17:13:41 Mauro Carvalho Chehab wrote: > Em Wed, 11 Nov 2015 21:26:31 +0100 > Arnd Bergmann <a...@arndb.de> escreveu: > > include/media/{ => drv-intf}/cx2341x.h | 0 > include/media/{ => drv-intf}/cx25840.h

Re: [PATCH 2/2] [media] include/media: move platform driver headers to a separate dir

On Wednesday 11 November 2015 15:14:48 Mauro Carvalho Chehab wrote: > rename include/media/{ => platform}/exynos-fimc.h (100%) > rename include/media/{ => platform}/mmp-camera.h (100%) > rename include/media/{ => platform}/omap1_camera.h (100%) > rename include/media/{ => platform}/omap4iss.h

Re: [PATCH] dmaengine: edma: fix build without CONFIG_OF

On Wednesday 04 November 2015 09:42:35 Peter Ujfalusi wrote: > On 11/03/2015 04:00 PM, Arnd Bergmann wrote: > > During the edma rework, a build error was introduced for the > > case that CONFIG_OF is disabled: > > > > drivers/built-in.o: In function `edma_tc_set_pm_

Re: [PATCH] dmaengine: edma: fix build without CONFIG_OF

On Wednesday 04 November 2015 11:05:54 Peter Ujfalusi wrote: > > > > I think that would be less readable, and gives no compile-time coverage > > to the contents of the edma_tc_set_pm_state function. > > Hrm, if the compiler knows that there is no need to compile the code after > the: > if

[PATCH] dmaengine: edma: fix build without CONFIG_OF

without OF, this adds an IS_ENABLED() check that turns the function into an empty stub then and avoids the link error. Signed-off-by: Arnd Bergmann <a...@arndb.de> Fixes: ca304fa9bb76 ("ARM/dmaengine: edma: Public API to use private struct pointer") --- Found on ARM randconfig builds wi

Re: [GIT PULL] omap dts changes for v4.4 merge window, part 2

On Tuesday 20 October 2015 12:35:02 Tony Lindgren wrote: > Few more omap dts changes for v4.4 merge window, mostly to fix and clean > up some omap5 issues to allow adding other omap5 boards. Also some other > fixes and clean-up: > > - Fix SDIO WLAN for omap5 that's been broken for a while. As

Re: [GIT PULL] two omap fixes for v4.3-rc cycle

On Tuesday 20 October 2015 12:34:01 Tony Lindgren wrote: > The following changes since commit d8e1f5ed11a39a68da00f05000466c4f6db4456e: > > Documentation: ARM: List new omap MMC requirements (2015-10-12 16:23:34 > -0700) > > are available in the git repository at: > >

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

On Thursday 15 October 2015 14:04:26 Tony Lindgren wrote: > * Arnd Bergmann <a...@arndb.de> [151015 13:40]: > > On Wednesday 14 October 2015 14:38:59 Tony Lindgren wrote: > > > > > Note that this branch is against v4.3-rc4 as that contains critical > > > MMC

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

On Wednesday 14 October 2015 13:03:36 Tony Lindgren wrote: > Fixes for omap against v4.3-rc5: > > - Regulator fix for beagle-x15 to fix HDMI without a SD card being > inserted > > - GPMC fix for showing proper timings and to allow enabling debug > options that somehow was unselectable

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

On Wednesday 14 October 2015 14:38:59 Tony Lindgren wrote: > Device tree changes for omaps for v4.4 merge window: > > - DCAN sleep pins for am437x-gp-evm > > - A series of changes to add audio support for dra7 > > - Add support for gpio keys and LEDs on dra7 > > - Regulator clean-up for

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

On Wednesday 14 October 2015 14:38:58 Tony Lindgren wrote: > Clean-up for omaps for v4.4 merge window: > > - Remove legacy omap3 ISP code as the driver is DT only > > - Remove VoiceBlue board support as it's been unused over > 10 years now > > - Remove unused polarity control macros for TWL >

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

On Tuesday 13 October 2015 16:13:20 Tony Lindgren wrote: > On boards with more than 2GB of RAM booting goes wrong with things not working > and we're getting lots of l3 warnings: > > WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 > l3_interrupt_handler+0x260/0x384() > 4400.ocp:L3

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

On Wednesday 14 October 2015 09:17:56 Tony Lindgren wrote: > * Arnd Bergmann <a...@arndb.de> [151014 02:20]: > > On Tuesday 13 October 2015 16:13:20 Tony Lindgren wrote: > > > On boards with more than 2GB of RAM booting goes wrong with things not > > > working &

[PATCH] genirq: export handle_bad_irq

l in order to allow the use in modules. Signed-off-by: Arnd Bergmann <a...@arndb.de> Fixes: 450fa54cfd66 ("gpio: omap: convert to use generic irq handler") diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c index ea7b5fd99ba5..142bbf3b607f 100644 --- a/kernel/irq/handle.c +++ b/ke

[PATCH] genirq: fix handle_bad_irq kerneldoc comment

A recent cleanup removed the 'irq' parameter from many functions, but left the documentation for this in place for at least one function. This removes it. Signed-off-by: Arnd Bergmann <a...@arndb.de> Fixes: bd0b9ac405e1 ("genirq: Remove irq argument from irq flow handlers") ---

Re: [RFC/PATCH 11/11] arm: boot: dts: omap: add missing default status for 32k counter

On Monday 05 October 2015 14:41:07 Felipe Balbi wrote: > > /** > * omap_get_timer_dt - get a timer using device-tree > * @match - device-tree match structure for matching a device type > * @property- optional timer property to match > * > * Helper function to get a timer during

Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

On Monday 05 October 2015 04:13:41 Tony Lindgren wrote: > * Arnd Bergmann <a...@arndb.de> [151005 04:08]: > > On Monday 05 October 2015 03:55:55 Tony Lindgren wrote: > > > * Daniel Lezcano <daniel.lezc...@linaro.org> [151001 15:16]: > > > > O

Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

On Monday 05 October 2015 03:55:55 Tony Lindgren wrote: > * Daniel Lezcano <daniel.lezc...@linaro.org> [151001 15:16]: > > On 09/30/2015 04:49 PM, Arnd Bergmann wrote: > > >On Wednesday 30 September 2015 16:42:21 Arnd Bergmann wrote: > > >> > > >

Re: [RFC/PATCH 11/11] arm: boot: dts: omap: add missing default status for 32k counter

On Tuesday 29 September 2015 15:44:06 Felipe Balbi wrote: > All devices should have a default status. Ignoring > the arguments if it should be 'okay' or 'disabled' > by default, let's set them all the 'disabled' and > have boards enable 32k counter. > > Signed-off-by: Felipe Balbi

Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

On Tuesday 29 September 2015 15:43:55 Felipe Balbi wrote: > > the following patches de-obfuscate arch/arm/mach-omap2/timer.c > and start moving code to drivers/clocksource. So far only counter32k > has been moved over. > > Note that we can't get rid of all the code (yet) because there are >

Re: [RFC/PATCH 11/11] arm: boot: dts: omap: add missing default status for 32k counter

On Wednesday 30 September 2015 09:12:09 Felipe Balbi wrote: > On Wed, Sep 30, 2015 at 10:15:25AM +0200, Arnd Bergmann wrote: > > On Tuesday 29 September 2015 15:44:06 Felipe Balbi wrote: > > > All devices should have a default status. Ignoring > > > the argu

Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

On Wednesday 30 September 2015 16:42:21 Arnd Bergmann wrote: > > TEGRA folks: the tegra_read_persistent_clock() implementation apparently > predates the Tegra RTC driver and I wonder if they actually do the > right thing in combination. Could it be that the wall time forwards >

Re: [RFC/PATCH 00/11] arm: omap: counter32k rework

On Wednesday 30 September 2015 09:13:38 Felipe Balbi wrote: > On Wed, Sep 30, 2015 at 10:22:46AM +0200, Arnd Bergmann wrote: > > On Tuesday 29 September 2015 15:43:55 Felipe Balbi wrote: > > > > > > the following patches de-obfuscate arch/arm/mach-omap2/timer.c

Re: [PATCH 08/21] ARM/dmaengine: edma: Remove limitation on the number of eDMA controllers

On Thursday 10 September 2015 11:37:37 Peter Ujfalusi wrote: > bla-bla and bla > > Signed-off-by: Peter Ujfalusi You may want to expand on that a bit. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to

Re: [PATCH 00/21] dmaengine/ARM: Merge the edma drivers into one

On Thursday 10 September 2015 11:37:29 Peter Ujfalusi wrote: > > with this series the edma two driver setup will be changed to have only one > driver to support eDMA3. The legacy edma interface will be removed and eDMA > can > only be used via dmaengine API from this point on. > In order to do

Re: [PATCH 09/21] ARM: davinci: Add set dma_mask to eDMA devices

On Thursday 10 September 2015 11:37:38 Peter Ujfalusi wrote: > +static u64 da8xx_edma0_dmamask = DMA_BIT_MASK(32); > + > static struct platform_device da8xx_edma0_device = { > .name = "edma", > .id = 0, > .dev = { > .platform_data =

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

On Wednesday 24 June 2015 21:54:01 Vinod Koul wrote: It would be nice to find another name for the dma_request_slave_channel_compat() so with the new name we could have chance to rearrange the parameters: (dev, name, mask, fn, fn_param) We would end up with the following APIs, all

Re: [RFC/NOT FOR MERGING] HACK: add global/private timers for A9

On Wednesday 03 June 2015 15:32:45 Felipe Balbi wrote: Hi Tony and Russell, AM43xx, even though it's a single processor A9, it still has TWD and global timer. I was doing some profiling with RT v4.0 and latency is 3.5x lower just by switching from gptimer to twd/global. The only problem

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

On Friday 22 May 2015 13:20:28 Tony Lindgren wrote: Device tree related changes for omaps: - Configure MMC data lines 4..8 for 1.8V IO on boards that are using them as GPIOs instead of MMC data lines - Add support for

Re: [RFC] Fix omap3 booting with thumb2 compiled kernel

On Thursday 28 May 2015 09:36:05 Tony Lindgren wrote: * Dave Martin dave.mar...@arm.com [150528 09:19]: On Thu, May 28, 2015 at 07:21:25AM -0700, Tony Lindgren wrote: --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -203,23 +203,8 @@ save_context_wfi:

Re: [GIT PULL 2.1/2] fixed up omap1 sparse irq support for v4.2

On Thursday 21 May 2015 15:59:38 Tony Lindgren wrote: Here's this pull request updated for the randconfig errors found by Arnd. The following changes since commit 030bbdbf4c833bc69f502eae58498bc5572db736: Linux 4.1-rc3 (2015-05-10 15:12:29 -0700) are available in the git repository

[PATCH] video: omap/h3: fix tps65010 dependency

-in. Signed-off-by: Arnd Bergmann a...@arndb.de diff --git a/drivers/video/fbdev/omap/Kconfig b/drivers/video/fbdev/omap/Kconfig index 18c4cb0d5690..29d250da8a3e 100644 --- a/drivers/video/fbdev/omap/Kconfig +++ b/drivers/video/fbdev/omap/Kconfig @@ -42,7 +42,7 @@ config FB_OMAP_LCD_MIPID config

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

On Wednesday 20 May 2015 15:36:04 Tony Lindgren wrote: Clean-up for omaps for v4.2 merge window: Drop more omap3 legacy board-*.c files for v4.2. This time we're dropping the board files for beagle, overo and cm-t35. The reason for dropping these now rather than later is that now we can

Re: [GIT PULL 2/2] omap1 sparse irq support for v4.2

On Wednesday 20 May 2015 15:36:05 Tony Lindgren wrote: Add support for CONFIG_SPARSE_IRQ for omap1. This takes us a bit closer to making omap1 support multiarch. After this series we still need to make omap1 use the common clock framework and fix up the drivers to not rely on includes from

Re: [GIT PULL 2/2] omap1 sparse irq support for v4.2

A number of header files in mach-omap1 are never included from outside of mach-omap1, so we can move them directly to that directory. Signed-off-by: Arnd Bergmann a...@arndb.de diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c index a95499ea8706

Re: [GIT PULL 2/2] omap1 sparse irq support for v4.2

On Thursday 21 May 2015 14:14:12 Arnd Bergmann wrote: On Wednesday 20 May 2015 15:36:05 Tony Lindgren wrote: Add support for CONFIG_SPARSE_IRQ for omap1. This takes us a bit closer to making omap1 support multiarch. After this series we still need to make omap1 use the common clock

  1   2   3   4   5   6   7   8   >