Re: Routable IRQs

Hi, Thomas Gleixner writes: > Felipe, > > On Wed, 30 Dec 2015, Felipe Balbi wrote: >> Thomas Gleixner writes: >> > - Is there a "mapping" block between PRUSS and the host interrupt >> > controller >> >or is this "mapping" blo

Re: Routable IRQs

Hi Thomas, Thomas Gleixner writes: > On Tue, 29 Dec 2015, Felipe Balbi wrote: >> Anyway, the interesting part is that PRUSS has 64 events (on current >> incarnations at least) and PRUSS has 10 physical IRQ lines to the ARM >> land. Each of these 64 events can be routed t

Re: Linux 4.2.0-rc5: am335x: musb warnings

gt;>> wrote: >>> > On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov >>> > wrote: >>> >> On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi wrote: >>> >>> HI, >>> >>> >>> >>> On Thu, Aug 06, 2015

Routable IRQs

Hi Thomas & Jason, I'm dealing with an interesting situation which I'm wondering if Linux already support for. Basically, in some TI SoCs we have what's referred to as Programmable Real-Time Unit SubSystem (PRUSS). That's essentially a really simple, low latency, single cycle architecture which

Re: debugging

Hi, Ryan writes: > Hi Felipe, > > On Thu, Dec 10, 2015 at 3:17 AM, Felipe Balbi wrote: >> >> Hi, >> >> (please avoid top-posting) >> >> Ryan writes: >>> Hi Tony, >>> >>> Thanks for your response. I dont see any

Re: debugging

Hi, (please avoid top-posting) Ryan writes: > Hi Tony, > > Thanks for your response. I dont see any prints. I suspect that it > might be hanging before the serial port is initialized > > All i see is after arch_reset is called. I can see that is mmc clk and > data signals toggling. This makes m

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

nstead of 5. > > Hence, fix it by adding mpu_periphclk ("fixed-factor-clock") and use > it for clocking ARM TWD and Global timer (same way as on OMAP4). > > Cc: Tony Lindgren > Cc: Felipe Balbi > Cc: Tero Kristo > Fixes:commit 8cbd4c2f6a99 ("arm: boot: d

Re: [PATCH v2] irqchip: omap-intc: add support for spurious irq handling

Hi, Sekhar Nori writes: > Under some conditions, irq sorting procedure used > by INTC can go wrong resulting in a spurious irq > getting reported. > > If this condition is not handled, it results in > endless stream of: > > unexpected IRQ trap at vector 00 > > messages from ack_bad_irq() > >

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

Hi, Peter Ujfalusi writes: > @@ -174,12 +182,44 @@ > }; > > edma: edma@4900 { > - compatible = "ti,edma3"; > - ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2"; > - reg = <0x4900 0x1>, > -

Re: [PATCH v4 2/5] spi: spi-ti-qspi: add mmap mode read support

Hi, Vignesh R writes: > ti-qspi controller provides mmap port to read data from SPI flashes. > mmap port is enabled in QSPI_SPI_SWITCH_REG. ctrl module register may > also need to be accessed for some SoCs. The QSPI_SPI_SETUP_REGx needs to > be populated with flash specific information like read

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

, all counter_32k's platform code can be removed > once all OMAP boards will be converted to DT. > > Cc: Tony Lindgren > Cc: Felipe Balbi > Signed-off-by: Grygorii Strashko > --- > arch/arm/mach-omap2/timer.c| 16 +++ > drivers/clocksource/timer-ti-3

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 a

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

Hi, Arnd Bergmann writes: > On Monday 16 November 2015 15:13:55 Felipe Balbi wrote: >> Arnd Bergmann writes: >> > AM43XX and TI81XX use omap3_gptimer_timer_init(), but that is only >> > built into the kernel for OMAP3 and AM33XX, otherwise we get: >> >

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

Hi, Arnd Bergmann 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/built-in.o:(.arch.info.init+0x124): undefined reference > to `omap3_gptimer_timer_init' > > This changes the Kco

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

Hi, Grygorii Strashko writes: > On 11/13/2015 08:15 PM, Felipe Balbi wrote: >> >> Hi, >> >> Grygorii Strashko writes: >>> On 11/13/2015 07:40 PM, Felipe Balbi wrote: >>>> >>>> Hi, >>>> >>>> Grygorii

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

Hi, Grygorii Strashko writes: > On 11/13/2015 07:40 PM, Felipe Balbi wrote: >> >> Hi, >> >> Grygorii Strashko writes: >>> On 11/13/2015 06:43 PM, Felipe Balbi wrote: >>>> >>>> Hi, >>>> >>>> Grygorii Strashko w

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

Hi, Grygorii Strashko writes: > On 11/13/2015 06:43 PM, Felipe Balbi wrote: >> >> Hi, >> >> Grygorii Strashko writes: >>> Now the System stall is observed on TI AM437x based board >>> (am437x-gp-evm) during resuming from System suspend when AR

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

CONTROL.TIMER_ENABLE during suspend and restore on resume; > - ensure clocksource and clockevent devices have coresponding flags > (CLOCK_SOURCE_SUSPEND_NONSTOP and CLOCK_EVT_FEAT_C3STOP) set > depending on presence of "always-on" DT property. > > CC: Arnd Bergmann > Cc: Jo

Re: [PATCH] gpio: omap: fix debounce time calculation

Hi, Grygorii Strashko writes: > On 11/12/2015 08:09 PM, Felipe Balbi wrote: >> >> Hi, >> >> Grygorii Strashko writes: >>> On 11/12/2015 07:50 PM, Felipe Balbi wrote: >>>> According to TRM, debounce is measured in periods of >>&

Re: [PATCH] gpio: omap: fix debounce time calculation

Hi, Grygorii Strashko writes: > On 11/12/2015 07:50 PM, Felipe Balbi wrote: >> According to TRM, debounce is measured in periods of >> the functional clock of the GPIO IP. This means that > > > What TRM? link pls. > > http://www.ti.com/lit/ug/spruh

[PATCH] arm: omap2: Kconfig: select TWD and global timer on AM43xx devices

Make sure to tell the kernel that AM437x has TWD and global timers. Signed-off-by: Felipe Balbi --- Hi Tony, now that all dependencies are in place, we can finally enable twd and global_timer for AM437x. cheers arch/arm/mach-omap2/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git

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

TPS659038 can remux its GPIO_1 as VBUSDET output, which can be tied to a SoC GPIO and used as a VBUS interrupt. Beagle X15 uses that, in fact, and without it, I could not get USB peripheral working with that board. Signed-off-by: Felipe Balbi --- drivers/extcon/extcon-palmas.c | 22

Re: [PATCH 0/2] arm: beaglex15: fix USB Gadget

Hi, Felipe Balbi writes: > Hi, > > with the following patches I can get USB Gadget working > with my beagle x15 with today's Linus' tree. > > regards > > Felipe Balbi (2): > arm: boot: dts: beaglex15: Remove ID GPIO > arm: boot: beaglex15: pass correc

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

interrupt mechanism for notifying about VBUS. [1] https://github.com/beagleboard/beagleboard-x15/blob/master/BeagleBoard-X15_RevA2.pdf Signed-off-by: Felipe Balbi --- arch/arm/boot/dts/am57xx-beagle-x15.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts

[PATCH 1/2] arm: boot: dts: beaglex15: Remove ID GPIO

According to latest schematics [1], this board leaves ID pin floating. It's not connected to anything at all. So let's remove it. [1] https://github.com/beagleboard/beagleboard-x15/blob/master/BeagleBoard-X15_RevA2.pdf Signed-off-by: Felipe Balbi --- arch/arm/boot/dts/am57xx-beag

[PATCH 0/2] arm: beaglex15: fix USB Gadget

Hi, with the following patches I can get USB Gadget working with my beagle x15 with today's Linus' tree. regards Felipe Balbi (2): arm: boot: dts: beaglex15: Remove ID GPIO arm: boot: beaglex15: pass correct interrupt arch/arm/boot/dts/am57xx-beagle-x15.dts | 3 +-- 1 file

[PATCH] gpio: omap: fix debounce time calculation

According to TRM, debounce is measured in periods of the functional clock of the GPIO IP. This means that we should divide by the rate of functional clock. Signed-off-by: Felipe Balbi --- drivers/gpio/gpio-omap.c | 24 +--- 1 file changed, 17 insertions(+), 7 deletions

Re: [PATCH v3 0/3] ARM: OMAP2+ McASP(3) support for DRA7xx family

clock. > > Regards, > Peter > --- > Peter Ujfalusi (3): > ARM: DTS: dra7: Fix McASP3 node regarding to clocks > ARM: OMAP2+: hwmod: Add hwmod flag for HWMOD_OPT_CLKS_NEEDED > ARM: OMAP: DRA7: hwmod: Add data for McASP3 I have tested these patches with today's

Re: [PATCH] ARM: OMAP: DRA7: hwmod: Add data for McASP3

Hi, Peter Ujfalusi writes: > Felipe, > > On 11/11/2015 07:07 PM, Felipe Balbi wrote: >> From: Peter Ujfalusi >> >> McASP3 is used by default on DRA7x based boards for audio. > > While this patch works, it is not the correct one(s) to apply. > https://

[PATCH] ARM: OMAP: DRA7: hwmod: Add data for McASP3

: b6ddb4e0 be8db180 b6d46a47 b6d46a50 6030 [ 11.207866] ---[ end trace 7d8de48d1bc8fbac ]--- Signed-off-by: Peter Ujfalusi Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 41 +++ 1 file changed, 41 insertions(+) diff --git

[PATCH] rtc: ds1307: fix kernel splat due to wakeup irq handling

ID: 263 at linux/drivers/base/power/wakeirq.c:43 dev_pm_attach_wake_irq+0xbc/0xd4() [ 10.359244] rtc-ds1307 2-006f: wake irq already initialized Cc: Tony Lindgren Cc: Nishanth Menon Signed-off-by: Felipe Balbi --- arch/arm/boot/dts/am57xx-beagle-x15.dts | 1 + drivers/rtc/rt

Re: [PATCH] arm: omap2: board-generic: use omap4_local_timer_init for AM437x

Hi, Lokesh Vutla writes: > On Wednesday 21 October 2015 02:35 AM, Felipe Balbi wrote: >> AM437x-based boards, can use omap4_local_timer_init() >> just fine. Let's use that instead. > > This is breaking AM43x-epos board. > Today's Linux next: http://pastebin.ubu

Re: [PATCH] Revert "ARM: dts: twl4030: Add iio properties for bci subnode"

ree files assuming none have changed by me. > > Signed-off-by: Sebastian Reichel Reported-by: Felipe Balbi Tested-by: Felipe Balbi Acked-by: Felipe Balbi > --- > arch/arm/boot/dts/twl4030.dtsi | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/arm/boot/dts/twl

Re: Linus HEAD build break

Hi, Belisko Marek writes: > Hi, > > On Fri, Nov 6, 2015 at 3:24 PM, Felipe Balbi wrote: >> >> Hi again, >> >> Felipe Balbi writes: >>> Hi Marek, >>> >>> your commit af19161aaed7 ("ARM: dts: twl4030: Add iio properties for bci

Re: Linus HEAD build break

Hi again, Felipe Balbi writes: > Hi Marek, > > your commit af19161aaed7 ("ARM: dts: twl4030: Add iio properties for bci > subnode") breaks build on current linus/master (which current sits in this commit cannot be found in next. How come it's in linus/master ? I

Linus HEAD build break

Hi Marek, your commit af19161aaed7 ("ARM: dts: twl4030: Add iio properties for bci subnode") breaks build on current linus/master (which current sits in d1e41ff11941 Merge tag 'platform-drivers-x86-v4.4-1' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86) for anybody including t

Re: [PATCH v2 5/5] ARM: dts: AM4372: add entry for qspi mmap region

Hi, Rob Herring writes: > On Tue, Nov 03, 2015 at 03:36:14PM +0530, Vignesh R wrote: >> Add qspi memory mapped region entries for AM43xx based SoCs. Also, >> update the binding documents for the controller to document this change. >> >> Signed-off-by: Vignesh R > > Acked-by: Rob Herring > >>

Re: [PATCH] dmaengine: edma: Add dummy driver skeleton for edma3-tptc

ill add a dummy driver skeleton without probe or remove > callbacks provided. > > Signed-off-by: Peter Ujfalusi > Reported-by: Olof Johansson This fixes the problem I also reported on linux-omap [1] Tested-by: Felipe Balbi [1] http://marc.info/?l=linux-omap&m=14466542903201

commit e3faf2b8826b8ac58cdaad7f801e59e389320f0e regresses AM437x SK

Hi, with today's next (which contains commit e3faf2b8826b "ARM: DTS: am437x: Use the new DT bindings for the eDMA3" above) I can't get to getty prompt on my AM437x SK. Simply reverting that commit makes it work again. Here are some boot logs: next/master : http://hastebin.com/amunusunok rever

Re: [PATCH] spi: ti-qspi: improve ->remove() callback

Hi, Grygorii Strashko writes: > On 11/02/2015 06:06 PM, Felipe Balbi wrote: >> >> hi, >> >> Grygorii Strashko writes: >>> On 11/02/2015 05:20 PM, Felipe Balbi wrote: >>>> Grygorii Strashko writes: >>>> >>>>>

Re: [PATCH] spi: ti-qspi: improve ->remove() callback

hi, Grygorii Strashko writes: > On 11/02/2015 05:20 PM, Felipe Balbi wrote: >> Grygorii Strashko writes: >> >>> On 10/29/2015 03:57 PM, Felipe Balbi wrote: >>>> there's no need to call pm_runtime_get_sync() >>>> followed by

Re: [PATCH] spi: ti-qspi: improve ->remove() callback

Grygorii Strashko writes: > On 10/29/2015 03:57 PM, Felipe Balbi wrote: >> there's no need to call pm_runtime_get_sync() >> followed by pm_runtime_put(). We should, instead, >> just call pm_runtime_put_sync() and pm_runtime_disable(). > > Sry, but why do we n

[PATCH] spi: ti-qspi: improve ->remove() callback

there's no need to call pm_runtime_get_sync() followed by pm_runtime_put(). We should, instead, just call pm_runtime_put_sync() and pm_runtime_disable(). Signed-off-by: Felipe Balbi --- drivers/spi/spi-ti-qspi.c | 11 +-- 1 file changed, 1 insertion(+), 10 deletions(-) diff --

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

Hi, Tony Lindgren writes: > * Felipe Balbi [151023 09:48]: >> >> Hi, >> >> Tony Lindgren writes: >> > From: Tony Lindgren >> > Date: Fri, 23 Oct 2015 09:03:22 -0700 >> > Subject: [PATCH] usb: musb: omap2430: Fix regression caused by

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

onfusion between the > two different devices. > > Fixes: ddef08dd00f5 ("Driver core: wakeup the parent device before > trying probe") > Suggested-by: Grygorii Strashko > Signed-off-by: Tony Lindgren I'm fine with this patch to fix this v4.3 regression. Greg, do you w

Re: Regression caused by 073db4a51ee43ccb827f54a4261c0583b028d5ab

Hi, Brian Norris writes: > Hi Felipe, > > First of all, this is only a quick response. I could easily be missing > something obvious. > > On Thu, Oct 22, 2015 at 02:01:02PM -0500, Felipe Balbi wrote: >> >> Hi, >> >> I just noticed that commit 07

Re: Regression caused by 073db4a51ee43ccb827f54a4261c0583b028d5ab

(fixing Tony's address) Felipe Balbi writes: > Hi, > > I just noticed that commit 073db4a51ee4 (mtd: fix: avoid race condition > when accessing mtd->usecount) caused a regression at least when removing > m25p80. Wonder if you guys would know of a quick fix, other than

NULL pointer deref when reloading snd_soc_simple_card

Hi, I just triggered a NULL point deref with the following commands running on AM437x SK board. This is with v4.3-rc6: modprobe -r snd_soc_simple_card sleep 1 modprobe snd_soc_simple_card sleep 1 details below: [ 228.020921] Unable to handle kernel NULL pointer dereference at virtual address

Regression caused by 073db4a51ee43ccb827f54a4261c0583b028d5ab

Hi, I just noticed that commit 073db4a51ee4 (mtd: fix: avoid race condition when accessing mtd->usecount) caused a regression at least when removing m25p80. Wonder if you guys would know of a quick fix, other than reverting $commit in HEAD (yes, that makes the problem go away, but regresses on wh

[PATCH] arm: omap2: board-generic: use omap4_local_timer_init for AM437x

AM437x-based boards, can use omap4_local_timer_init() just fine. Let's use that instead. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/board-generic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/

[PATCH] clocksource: ti-32k: make it depend on GENERIC_CLOCKSOURCE

the new ti 32k clocksource driver should depend on GENERIC_CLOCKSOURCE because of its reliance on sched_clock_register(). Let's enable that to avoid any possible build errors and/or warnings on randbuilds. Signed-off-by: Felipe Balbi --- drivers/clocksource/Kconfig | 1 + 1 file chang

[PATCH 08/11] arm: omap2: timer: rename omap_sync32k_timer_init()

this function is not only about the 32k sync timer, it's OMAP's generic init_time implementation. Let's rename it to make that detail easier to notice. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/board-generic.c | 10 +- arch/arm/mach-omap2/board-ldp.c |

[PATCH 09/11] clocksource: add TI 32.768 Hz counter driver

Introduce a new clocksource driver for Texas Instruments 32.768 Hz device which is available on most OMAP-like devices. Cc: Daniel Lezcano Cc: Thomas Gleixner Cc: linux-ker...@vger.kernel.org Acked-by: Daniel Lezcano Signed-off-by: Felipe Balbi --- drivers/clocksource/Kconfig| 7

[PATCH 10/11] arm: omap2+: select 32k clocksource driver

Now that we have a 32k clocksource driver, let's select it for OMAP2PLUS builds. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b3a0dff67e3f..dc793cc60965 1

[PATCH 05/11] arm: omap2: timer: provide generic sync32k_timer_init function

instead of constantly defining a small wrapper around __omap_sync32k_timer_init(), let's define a generic one which can be used by all OMAPs. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/board-generic.c | 10 +- arch/arm/mach-omap2/board-ldp.c | 2 +- arch/arm/mach-

[PATCH 07/11] arm: omap2: timer: always call clocksource_of_init() when DT

If booting with DT, let's make sure to always call clocksource_of_init() as this will make it easier to move timer code to drivers/clocksource in the future. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/timer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-

[PATCH 11/11] arm: omap2: timer: limit hwmod usage to non-DT boots

now that we have a working 32k clocksource driver, we can limit HWMOD usage to non-DT boots and rely on clocksource_of_init() every time we boot with DT. While at that, also make sure that we don't disable the 32-counter device so it gets probed by its driver. Signed-off-by: Felipe

[PATCH 06/11] arm: omap2: timer: move realtime_counter_init() around

no functional changes, just moving that function closer to its calling location. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/timer.c | 114 ++-- 1 file changed, 56 insertions(+), 58 deletions(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm

[PATCH 04/11] arm: omap2: timer: remove __omap_gptimer_init()

__omap_sync32k_timer_init(), now takes the clock source as a parameter. This means we no longer need __omap_gptimer_init(). Note that __omap_sync32k_timer_init() will be renamed in a follow-up patch as it's not longer 32k source specific. Signed-off-by: Felipe Balbi --- arch/arm/mach-

[PATCH 01/11] arm: omap2: timer: always define omap4_local_timer_init

: Felipe Balbi --- arch/arm/mach-omap2/timer.c | 16 +++- 1 file changed, 3 insertions(+), 13 deletions(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index a55655127ef2..548d922cb107 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c

[PATCH 03/11] arm: omap2: timer: add a gptimer argument to sync32k_timer_init()

() in preparation to deleting __omap_gptimer_init(). On a follow-up patch, we will remove uses of __omap_gptimer_init() and replace them with __omap_sync32k_timer_init() and pass the last argument as true. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/timer.c | 12 ++-- 1 file changed

[PATCH 02/11] arm: omap2: timer: get rid of obfuscating macros

those macros just make it a lot more difficult to grep around and actually find similarities. In this patch, we will simply remove them and replace with actual functions and later commits will come to further clean this up. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/timer.c | 70

[PATCH 00/11] arm: omap: timer cleanups

nges up to bf4c94490aa4491cca758d633c0e641a4419c920: arm: omap2: timer: limit hwmod usage to non-DT boots (2015-10-16 11:06:24 -0500) -------- Felipe Balbi (11): arm: omap2: timer: always define omap4_local_timer_init arm: omap2: timer: get rid of obfuscat

Re: [RFC PATCH 2/3] pwm: Add PWM driver for OMAP using dual-mode timers

Hi, Neil Armstrong writes: > Adds support for using a OMAP dual-mode timer with PWM capability > as a Linux PWM device. The driver controls the timer by using the > dmtimer API. > > Add a platform_data structure for each pwm-omap-dmtimer nodes containing > the dmtimers functions in order to get

Re: [RFC PATCH 1/3] arm: plat-omap: dmtimer: Add clock source from DT

Hi, Neil Armstrong writes: > Add a function which sets the timer source from the clocks > binding on dm_timer_prepare call. > > In case the clocks property is not valid, it falls back to > the set_source() with 32_KHZ clock as default. > > Suggested-by: Tony Lindgren > Signed-off-by: Neil Armst

Re: musb: communication issue with more than 12 FTDI ports

Hi, Bin Liu writes: > On 10/14/2015 12:05 PM, Felipe Balbi wrote: >> >> Hi, >> >> Bin Liu writes: >>> Felipe, >>> >>> On 10/14/2015 11:25 AM, Felipe Balbi wrote: >>>> >>>> Hi, >>>> >>>> Bin

Re: musb: communication issue with more than 12 FTDI ports

Hi, Bin Liu writes: > Felipe, > > On 10/14/2015 11:25 AM, Felipe Balbi wrote: >> >> Hi, >> >> Bin Liu writes: >>> On 10/14/2015 10:56 AM, Felipe Balbi wrote: >>>> >>>> Hi, >>>> >>>> Bin Liu writes: >&

Re: musb: communication issue with more than 12 FTDI ports

Hi, Bin Liu writes: > On 10/14/2015 10:56 AM, Felipe Balbi wrote: >> >> Hi, >> >> Bin Liu writes: >>> Hi, >>> >>> On 10/13/2015 01:22 PM, Felipe Balbi wrote: >>>> Yegor Yefremov writes: >>>>> On Mon, Oct 12, 20

Re: musb: communication issue with more than 12 FTDI ports

Hi, Bin Liu writes: > Hi, > > On 10/13/2015 01:22 PM, Felipe Balbi wrote: >> Yegor Yefremov writes: >>> On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov >>> wrote: >>>> We have a problem, when using more than 12 FTDI ports. Kernels tried: >

Re: [PATCH] ARM: AM35xx: Add M-USB clk device ID

Hi, Sebastian Reichel writes: > On Tue, Oct 13, 2015 at 05:57:59PM -0500, Felipe Balbi wrote: >> Sebastian Reichel writes: >> > On Tue, Oct 13, 2015 at 10:50:45AM -0500, Felipe Balbi wrote: >> >> Rolf Peukert writes: >> >> > On 13.10.2015 10:15, Te

Re: [PATCH] ARM: AM35xx: Add M-USB clk device ID

hi, Sebastian Reichel writes: > Hi, > > On Tue, Oct 13, 2015 at 10:50:45AM -0500, Felipe Balbi wrote: >> Rolf Peukert writes: >> > On 13.10.2015 10:15, Tero Kristo wrote: >> >> On 10/12/2015 06:22 PM, Rolf Peukert wrote: >> >>> The glue code

Re: musb: communication issue with more than 12 FTDI ports

Yegor Yefremov writes: > On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov > wrote: >> We have a problem, when using more than 12 FTDI ports. Kernels tried: >> 3.18.1, 4.2.3 and 4.3-rc5. SoC am335x 600MHz >> >> Below the USB topology: >> >> # lsusb -t >> /: Bus 02.Port 1: Dev 1, Class=root_hub, D

Re: [PATCH] ARM: AM35xx: Add M-USB clk device ID

Hi, Rolf Peukert writes: > On 13.10.2015 10:15, Tero Kristo wrote: >> On 10/12/2015 06:22 PM, Rolf Peukert wrote: >>> The glue code in drivers/usb/musb/am35x.c calls clk_get() to get its >>> interface and function clocks for the M-USB controller. These calls fail >>> in the current kernel. This

Re: [RFC] AM35xx glue code for M-USB driver

Hi, Rolf Peukert writes: > Hi Felipe, > > On 07.10.2015 18:22, Felipe Balbi wrote: > [...] >>>>> b) The M-USB port on our board is wired as host only. If a device is >>>>> unplugged, the driver normally goes into some idle state and waits for >&g

Re: [RFC] AM35xx glue code for M-USB driver

Hi, Rolf Peukert writes: > Hi Felipe, > > thank you for your reply. > > On 07.10.2015 15:59, Felipe Balbi wrote: >> >> Hi, >> >> (please sure you also Cc linux-...@vger.kernel.org for MUSB patches) >> >> Rolf Peukert writes: > [...] &g

Re: [RFC] AM35xx glue code for M-USB driver

Hi, (please sure you also Cc linux-...@vger.kernel.org for MUSB patches) Rolf Peukert writes: > Hi, > > we're running a 4.x kernel on a board with an AM3505 CPU and would like > to use device trees. The AM35xx glue code for the M-USB controller > didn't support configuration from a DT yet. I no

Re: [PATCH 09/11] clocksource: add TI 32.768 Hz counter driver

Hi, Daniel Lezcano writes: > On 10/06/2015 07:02 PM, Felipe Balbi wrote: >> Introduce a new clocksource driver for Texas >> Instruments 32.768 Hz device which is available >> on most OMAP-like devices. >> >> Signed-off-by: Felipe Balbi > > Hi Felipe,

Re: [PATCH 04/11] arm: omap2: timer: provide generic sync32k_timer_init function

Hi, Suman Anna writes: >> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c >> index 976ff9fa3594..d14e25b2d7a4 100644 >> --- a/arch/arm/mach-omap2/timer.c >> +++ b/arch/arm/mach-omap2/timer.c >> @@ -608,21 +608,13 @@ static void __init __omap_sync32k_timer_init(int >> clke

Re: [PATCH] arm: omap2: timer: don't disable our timers

give them out. > Granted that it may not have been the best approach, but that needs a > solution if you change the behavior of this API. no doubt this needs a solution, but seesm like a solution here will have to be incremental. See new revision of my series. I'm now skipping 32k only a

[PATCH 03/11] arm: omap2: timer: remove __omap_gptimer_init()

__omap_sync32k_timer_init(), now takes the clock source as a parameter. This means we no longer need __omap_gptimer_init(). Note that __omap_sync32k_timer_init() will be renamed in a follow-up patch as it's not longer 32k source specific. Signed-off-by: Felipe Balbi --- arch/arm/mach-

[PATCH 06/11] arm: omap2: timer: always call clocksource_of_init() when DT

If booting with DT, let's make sure to always call clocksource_of_init() as this will make it easier to move timer code to drivers/clocksource in the future. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/timer.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --

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

pped patch setting status=okay to 32k - made sure hwmod wouldn't disable 32k counter - rebased on v4.3-rc4 Boot logs: - AM437x SK: http://hastebin.com/zuvetojaqe - BBB:http://hastebin.com/ihuponayap Felipe Balbi (11): arm: omap2: timer: get rid of obfuscating macros a

[PATCH 01/11] arm: omap2: timer: get rid of obfuscating macros

those macros just make it a lot more difficult to grep around and actually find similarities. In this patch, we will simply remove them and replace with actual functions and later commits will come to further clean this up. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/timer.c | 70

[PATCH 10/11] arm: omap2+: select 32k clocksource driver

Now that we have a 32k clocksource driver, let's select it for OMAP2PLUS builds. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 871d6cc450a5..9ac5909ca59d 1

[PATCH 11/11] arm: omap2: timer: limit hwmod usage to non-DT boots

now that we have a working 32k clocksource driver, we can limit HWMOD usage to non-DT boots and rely on clocksource_of_init() every time we boot with DT. While at that, also make sure that we don't disable the 32-counter device so it gets probed by its driver. Signed-off-by: Felipe

[PATCH 08/11] arm: omap2: timer: rename omap_sync32k_timer_init()

this function is not only about the 32k sync timer, it's OMAP's generic init_time implementation. Let's rename it to make that detail easier to notice. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/board-generic.c | 14 +++--- arch/arm/mach-omap2/board-ldp.c |

[PATCH 05/11] arm: omap2: timer: move realtime_counter_init() around

no functional changes, just moving that function closer to its calling location. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/timer.c | 102 ++-- 1 file changed, 50 insertions(+), 52 deletions(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm

[PATCH 04/11] arm: omap2: timer: provide generic sync32k_timer_init function

instead of constantly defining a small wrapper around __omap_sync32k_timer_init(), let's define a generic one which can be used by all OMAPs. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/board-generic.c | 10 +- arch/arm/mach-omap2/board-ldp.c | 2 +- arch/arm/mach-

[PATCH 09/11] clocksource: add TI 32.768 Hz counter driver

Introduce a new clocksource driver for Texas Instruments 32.768 Hz device which is available on most OMAP-like devices. Signed-off-by: Felipe Balbi --- drivers/clocksource/Kconfig| 7 +++ drivers/clocksource/Makefile | 1 + drivers/clocksource/timer-ti-32k.c | 122

[PATCH 07/11] arm: omap2: timer: remove omap4_local_timer_init

We're now always calling clocksource_of_init() whenever booting with DT, so we can use the generic omap_sync32k_timer_init() (which will be renamed in a follow-up patch) for OMAP4 as well. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/board-generic.c | 4 ++-- arch/arm/mach-omap2/com

[PATCH 02/11] arm: omap2: timer: add a gptimer argument to sync32k_timer_init()

() in preparation to deleting __omap_gptimer_init(). On a follow-up patch, we will remove uses of __omap_gptimer_init() and replace them with __omap_sync32k_timer_init() and pass the last argument as true. Signed-off-by: Felipe Balbi --- arch/arm/mach-omap2/timer.c | 12 ++-- 1 file changed

Re: cpufreq-dt error: failed to init cpufreq table: -61

Felipe Balbi writes: > Belisko Marek writes: > >> Hi, >> >> On Tue, Oct 6, 2015 at 4:03 PM, Belisko Marek >> wrote: >>> Hi Felipe, >>> >>> On Tue, Oct 6, 2015 at 4:00 PM, Felipe Balbi wrote: >>>> >>>> Hi, &g

Re: [PATCH v2] arm: omap2: timer: don't disable our timers

Felipe Balbi writes: > Tony Lindgren writes: > >> * Felipe Balbi [151005 17:49]: >>> We actually want these devices to be created because >>> we will be moving timers to drivers/clocksource and >>> this will prevent them from probing. >> >>

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

Hi, Tony Lindgren writes: > * Felipe Balbi [151006 08:02]: >> - ti,timer-alwon:Indicates the timer is in an alway-on power >> domain. >> >> Tony, care to comment if we should add timer-alwon to 32k ? > > No that should not be needed for the 32k c

Re: cpufreq-dt error: failed to init cpufreq table: -61

Belisko Marek writes: > Hi, > > On Tue, Oct 6, 2015 at 4:03 PM, Belisko Marek wrote: >> Hi Felipe, >> >> On Tue, Oct 6, 2015 at 4:00 PM, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Belisko Marek writes: >>>> Hi Tony, >&

Re: [PATCH v2] arm: omap2: timer: don't disable our timers

Tony Lindgren writes: > * Felipe Balbi [151005 17:49]: >> We actually want these devices to be created because >> we will be moving timers to drivers/clocksource and >> this will prevent them from probing. > > Great. Is this safe to appy on it's own? We are not g

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

Arnd Bergmann writes: > 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 pro

Re: cpufreq-dt error: failed to init cpufreq table: -61

Hi, Belisko Marek writes: > Hi Tony, > > I'm using custom am33xx board where mpu voltage can be changed through > gpio regulator on 4.1 (latest stable) kernel. I defined gpio-regulator > node and also operating-points to DT. Gpio regulator seems to be > working fine but during probing cpufreq-dt

Re: [PATCH] arm: omap2: timer: don't disable our timers

Hi, Sebastian Reichel writes: > On Mon, Oct 05, 2015 at 06:41:37PM -0500, Suman Anna wrote: >> We will gain a user from OMAP remoteproc driver as well (out of tree at >> the moment, but it does follow the DT phandle and >> omap_dm_timer_request_by_node semantics). I do not think ir-rx51.c is >>

Re: [PATCH] arm: omap2: timer: don't disable our timers

alive just because of the > continued OMAP3 legacy boot support. Guess, it is a just a question of > not breaking existing API until we kill some of them. sure, but until remoteproc gets upstream, it's only 1 user ;-) >>>> Signed-off-by: Felipe Balbi >>>> --- &g

  1   2   3   4   5   6   7   8   9   10   >