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

On Fri, Nov 20, 2015 at 12:58 PM, Arnd Bergmann wrote: > On Friday 20 November 2015 12:25:06 Peter Ujfalusi wrote: >> On 11/19/2015 01:25 PM, Arnd Bergmann wrote: > Another idea would be to remove the filter function from struct dma_chan_map > and pass the map through platform

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

On 11/20/2015 02:24 PM, Andy Shevchenko wrote: > On Fri, Nov 20, 2015 at 12:58 PM, Arnd Bergmann wrote: >> On Friday 20 November 2015 12:25:06 Peter Ujfalusi wrote: >>> On 11/19/2015 01:25 PM, Arnd Bergmann wrote: > >> Another idea would be to remove the filter function from

Re: [PATCH] extcon: palmas: add support for using VBUSDET output

Hi Felipe, On Fri, Nov 20, 2015 at 11:37 PM, Felipe Balbi wrote: > > Hi Chanwoo, > > Chanwoo Choi writes: >> Hi Felipe, >> >> On 2015년 11월 20일 14:33, Chanwoo Choi wrote: >>> Hi Felipe, >>> >>> Looks good to me. But I have one comment. >>> >>> On 2015년 11월

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

[PATCH v2] PCI: dra7xx: mark dra7xx_pcie_msi irq as IRQF_NO_THREAD

On -RT, TI DRA7 PCIe driver always produces below backtrace when the first PCI interrupt is triggered: [ cut here ] WARNING: CPU: 1 PID: 82 at kernel/irq/handle.c:150 handle_irq_event_percpu+0x14c/0x174() irq 460 handler irq_default_primary_handler+0x0/0x14 enabled

[PATCH v2] clocksource: arm_global_timer: fix suspend resume

Now the System stall is observed on TI AM437x based board (am437x-gp-evm) during resuming from System suspend when ARM Global timer is selected as clocksource device - SysRq are working, but nothing else. The reason of stall is that ARM Global timer loses its contexts. The reason of stall is that

[4.4-rc][PATCH] gpio: omap: drop omap1 mpuio specific irq_mask/unmask callbacks

Originally OMAP MPUIO GPIO irqchip was implemented using Generic irq chip, but after set of reworks Generic irq chip code was replaced by common OMAP GPIO implementation and finally removed by commit d2d05c65c40e ("gpio: omap: Fix regression for MPUIO interrupts"). Unfortunately, above commit left

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

On Fri, Nov 20, 2015 at 2:30 PM, Peter Ujfalusi wrote: > On 11/20/2015 02:24 PM, Andy Shevchenko wrote: >> On Fri, Nov 20, 2015 at 12:58 PM, Arnd Bergmann wrote: >>> On Friday 20 November 2015 12:25:06 Peter Ujfalusi wrote: On 11/19/2015 01:25 PM, Arnd

Re: [PATCH] extcon: palmas: add support for using VBUSDET output

Hi Chanwoo, Chanwoo Choi writes: > Hi Felipe, > > On 2015년 11월 20일 14:33, Chanwoo Choi wrote: >> Hi Felipe, >> >> Looks good to me. But I have one comment. >> >> On 2015년 11월 13일 02:57, Felipe Balbi wrote: >>> TPS659038 can remux its GPIO_1 as VBUSDET output, >>> which

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 > >> names would mean changes all over

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

On 11/20/2015 12:58 PM, Arnd Bergmann wrote: >>> That way the vast majority of drivers can use one of the two nice interfaces >>> and the rest can be converted to use __dma_request_chan(). >>> >>> On a related topic, we had in the past considered providing a way for >>> platform code to register a

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

On 11/19/2015 01:25 PM, Arnd Bergmann wrote: >> If we have two main APIs, one to request slave channels and one to get any >> channel with given capability >> dma_request_slave_channel(NULL, NULL, , fn, fn_param); /* Legacy slave >> */ >> dma_request_slave_channel(dev, name, NULL, NULL, NULL); /*

Re: [PATCH] extcon: palmas: add support for using VBUSDET output

Hi Felipe, On 2015. 11. 20. 오후 11:37, Felipe Balbi wrote: > > Hi Chanwoo, > > Chanwoo Choi writes: >> Hi Felipe, >> >> On 2015년 11월 20일 14:33, Chanwoo Choi wrote: >>> Hi Felipe, >>> >>> Looks good to me. But I have one comment. >>> >>> On 2015년 11월 13일 02:57, Felipe

Re: [PATCH] extcon: palmas: add support for using VBUSDET output

Hi, On Sat, Nov 21, 2015 at 12:05 AM, Chanwoo Choi wrote: > Hi Felipe, > > On Fri, Nov 20, 2015 at 11:37 PM, Felipe Balbi wrote: >> >> Hi Chanwoo, >> >> Chanwoo Choi writes: >>> Hi Felipe, >>> >>> On 2015년 11월 20일 14:33, Chanwoo Choi

Re: [PATCH 2/2] arm: boot: beaglex15: pass correct interrupt

Hi, On Sat, Nov 21, 2015 at 1:42 AM, Chanwoo Choi wrote: > Hi, > > On 2015. 11. 20. 오후 2:39, Chanwoo Choi wrote: >> Hi, >> >> On 2015년 11월 13일 02:53, Felipe Balbi wrote: >>> According to latest schematics [1], GPIO_1/VBUSDET >>> on TPS659038 is tied to AM57x GPIO4_21. We can

Re: [PATCH] net: cpsw: Fix ethernet regression for dm814x

From: Tony Lindgren Date: Wed, 18 Nov 2015 17:27:25 -0800 > Commit b6745f6e4e63 ("drivers: net: cpsw: davinci_emac: move reading mac > id to common file") started using of_machine_is_compatible for detecting > type but missed at dm8148 causing Ethernet to stop working. > >

Re: [RFC PATCH] clocksource: ti-32k: convert to platform device

Hi, Grygorii Strashko writes: > Since system clocksource is finally selected by Clocksource core at > fs_initcall stage during boot there are no reasons to initialize > ti_32k_timer at early boot stages. Hence, ti_32k_timer can be > converted to use platform

[RFC PATCH] clocksource: ti-32k: convert to platform device

Since system clocksource is finally selected by Clocksource core at fs_initcall stage during boot there are no reasons to initialize ti_32k_timer at early boot stages. Hence, ti_32k_timer can be converted to use platform device/driver model and its PM can be implemented using PM runtime which is

Re: [PATCH v2] clocksource: arm_global_timer: fix suspend resume

On 20/11/15 18:35, Grygorii Strashko wrote: > Hi Santosh, > > On 11/20/2015 07:23 PM, santosh shilimkar wrote: >> + Thomas, Marc >> >> On 11/20/2015 5:57 AM, Grygorii Strashko wrote: >>> Now the System stall is observed on TI AM437x based board >>> (am437x-gp-evm) during resuming from System

Re: [PATCH v2] clocksource: arm_global_timer: fix suspend resume

Hi Santosh, On 11/20/2015 07:23 PM, santosh shilimkar wrote: > + Thomas, Marc > > On 11/20/2015 5:57 AM, Grygorii Strashko wrote: >> Now the System stall is observed on TI AM437x based board >> (am437x-gp-evm) during resuming from System suspend when ARM Global >> timer is selected as

Re: [4.4-rc][PATCH] gpio: omap: drop omap1 mpuio specific irq_mask/unmask callbacks

On 11/20/2015 5:35 AM, Grygorii Strashko wrote: Originally OMAP MPUIO GPIO irqchip was implemented using Generic irq chip, but after set of reworks Generic irq chip code was replaced by common OMAP GPIO implementation and finally removed by commit d2d05c65c40e ("gpio: omap: Fix regression for

Re: [PATCH v2] clocksource: arm_global_timer: fix suspend resume

+ Thomas, Marc On 11/20/2015 5:57 AM, Grygorii Strashko wrote: Now the System stall is observed on TI AM437x based board (am437x-gp-evm) during resuming from System suspend when ARM Global timer is selected as clocksource device - SysRq are working, but nothing else. The reason of stall is that

Re: [PATCH v2] clocksource: arm_global_timer: fix suspend resume

On 11/20/2015 10:46 AM, Marc Zyngier wrote: On 20/11/15 18:35, Grygorii Strashko wrote: Hi Santosh, On 11/20/2015 07:23 PM, santosh shilimkar wrote: + Thomas, Marc On 11/20/2015 5:57 AM, Grygorii Strashko wrote: Now the System stall is observed on TI AM437x based board (am437x-gp-evm)

Re: [PATCH v2] clocksource: arm_global_timer: fix suspend resume

On Fri, Nov 20, 2015 at 10:35 AM, Grygorii Strashko wrote: > Hi Santosh, > > On 11/20/2015 07:23 PM, santosh shilimkar wrote: >> + Thomas, Marc >> >> On 11/20/2015 5:57 AM, Grygorii Strashko wrote: >>> Now the System stall is observed on TI AM437x based board >>>

Re: [PATCH v2] clocksource: arm_global_timer: fix suspend resume

On Fri, Nov 20, 2015 at 11:28 AM, Grygorii Strashko wrote: > On 11/20/2015 09:09 PM, John Stultz wrote: >> On Fri, Nov 20, 2015 at 10:35 AM, Grygorii Strashko >> wrote: >>> Hi Santosh, >>> >>> On 11/20/2015 07:23 PM, santosh shilimkar wrote:

Re: [4.4-rc][PATCH] gpio: omap: drop omap1 mpuio specific irq_mask/unmask callbacks

Hi, On Fri, Nov 20, 2015 at 03:35:14PM +0200, Grygorii Strashko wrote: > Originally OMAP MPUIO GPIO irqchip was implemented using Generic irq > chip, but after set of reworks Generic irq chip code was replaced by > common OMAP GPIO implementation and finally removed by > commit d2d05c65c40e

Re: [PATCH v2] clocksource: arm_global_timer: fix suspend resume

On Fri, Nov 20, 2015 at 10:46 AM, Marc Zyngier wrote: > > This patch has a very specific purpose: instructing the core code that > this timer will never stop ticking, ever. It is really targeted at > virtual machines, whose timer is backed by the host timer, even when the >

Re: [PATCH v2] clocksource: arm_global_timer: fix suspend resume

On 11/20/2015 09:09 PM, John Stultz wrote: > On Fri, Nov 20, 2015 at 10:35 AM, Grygorii Strashko > wrote: >> Hi Santosh, >> >> On 11/20/2015 07:23 PM, santosh shilimkar wrote: >>> + Thomas, Marc >>> >>> On 11/20/2015 5:57 AM, Grygorii Strashko wrote: Now the System

Re: [PATCH v2] clocksource: arm_global_timer: fix suspend resume

On 11/20/2015 08:52 PM, santosh shilimkar wrote: > On 11/20/2015 10:46 AM, Marc Zyngier wrote: >> On 20/11/15 18:35, Grygorii Strashko wrote: >>> Hi Santosh, >>> >>> On 11/20/2015 07:23 PM, santosh shilimkar wrote: + Thomas, Marc On 11/20/2015 5:57 AM, Grygorii Strashko wrote: >

Re: [PATCH v2] clocksource: arm_global_timer: fix suspend resume

On Fri, 20 Nov 2015, John Stultz wrote: > So its unlikely that the hardware both stays running through suspend, > but also might halt in idle. That would be "unique". The amount of creativity put into the next variants of differently broken timers is amazing. So I wouldn't be too surprised if

Re: [PATCH v2] clocksource: arm_global_timer: fix suspend resume

On 11/20/2015 09:32 PM, John Stultz wrote: > On Fri, Nov 20, 2015 at 11:28 AM, Grygorii Strashko > wrote: >> On 11/20/2015 09:09 PM, John Stultz wrote: >>> On Fri, Nov 20, 2015 at 10:35 AM, Grygorii Strashko >>> wrote: Hi Santosh,

Re: [PATCH] clk: ti: dra7: constify clk_hw_omap_ops structure

On 11/15, Julia Lawall wrote: > The clk_hw_omap_ops structures are never modified, so declare this one as > const, like the others. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall > > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is