Re: Routable IRQs

Hi Thomas, Thomas Gleixner <t...@linutronix.de> 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 th

Re: Routable IRQs

Hi, Thomas Gleixner <t...@linutronix.de> writes: > Felipe, > > On Wed, 30 Dec 2015, Felipe Balbi wrote: >> Thomas Gleixner <t...@linutronix.de> writes: >> > - Is there a "mapping" block between PRUSS and the host interrupt >> > cont

Re: Linux 4.2.0-rc5: am335x: musb warnings

t; >>> On Fri, Aug 7, 2015 at 12:57 PM, Yegor Yefremov >>> <yegorsli...@googlemail.com> wrote: >>> > On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov >>> > <yegorsli...@googlemail.com> wrote: >>> >> On Thu, Aug 6, 2015 at 4:21 PM, Felip

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 <ryanphilip...@googlemail.com> writes: > Hi Felipe, > > On Thu, Dec 10, 2015 at 3:17 AM, Felipe Balbi <ba...@ti.com> wrote: >> >> Hi, >> >> (please avoid top-posting) >> >> Ryan <ryanphilip...@googlemail.com> writes: >&

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

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

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

eep 5" will take 10 sec instead 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 <t...@atomide.com> > Cc: Felipe Balbi <ba...@ti.com> &

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 =

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

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

Hi Chanwoo, Chanwoo Choi <cw00.c...@samsung.com> 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: >>> TPS65

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

nings. > > After this change, all counter_32k's platform code can be removed > once all OMAP boards will be converted to DT. > > Cc: Tony Lindgren <t...@atomide.com> > Cc: Felipe Balbi <ba...@ti.com> > Signed-off-by: Grygorii Strashko <grygorii.stras...@ti.com>

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

Hi, Arnd Bergmann <a...@arndb.de> writes: > 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 A

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

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

gt; > CC: Arnd Bergmann <a...@arndb.de> > Cc: John Stultz <john.stu...@linaro.org> > Cc: Felipe Balbi <ba...@ti.com> > Cc: Tony Lindgren <t...@atomide.com> > Signed-off-by: Grygorii Strashko <grygorii.stras...@ti.com> > --- > drivers/clocksource/ar

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

Hi, Grygorii Strashko <grygorii.stras...@ti.com> writes: > On 11/13/2015 06:43 PM, Felipe Balbi wrote: >> >> Hi, >> >> Grygorii Strashko <grygorii.stras...@ti.com> writes: >>> Now the System stall is observed on TI AM437x based board >>>

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

Hi, Grygorii Strashko <grygorii.stras...@ti.com> writes: > On 11/13/2015 07:40 PM, Felipe Balbi wrote: >> >> Hi, >> >> Grygorii Strashko <grygorii.stras...@ti.com> writes: >>> On 11/13/2015 06:43 PM, Felipe Balbi wrote: >>>> >>&g

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

Hi, Grygorii Strashko <grygorii.stras...@ti.com> writes: > On 11/13/2015 08:15 PM, Felipe Balbi wrote: >> >> Hi, >> >> Grygorii Strashko <grygorii.stras...@ti.com> writes: >>> On 11/13/2015 07:40 PM, Felipe Balbi wrote: >>>> >>&g

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

Hi, Grygorii Strashko <grygorii.stras...@ti.com> writes: > On 11/12/2015 08:09 PM, Felipe Balbi wrote: >> >> Hi, >> >> Grygorii Strashko <grygorii.stras...@ti.com> writes: >>> On 11/12/2015 07:50 PM, Felipe Balbi wrote: >&g

[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 <ba...@ti.com> --- drivers/gpio/gpio-omap.c | 24 +--- 1 file changed, 17 insertions

[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 <ba...@ti.com> --- arch/arm/boot/dts/

[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 changed, 1

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

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

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

Hi, Felipe Balbi <ba...@ti.com> 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: p

[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 <ba...@ti.com> --- drivers/extcon/extcon-pa

[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 <ba...@ti.com> --- 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 inse

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

Hi, Grygorii Strashko <grygorii.stras...@ti.com> 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

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

01 [ 11.207863] 3fe0: b6ddb4e0 be8db180 b6d46a47 b6d46a50 6030 [ 11.207866] ---[ end trace 7d8de48d1bc8fbac ]--- Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com> Signed-off-by: Felipe Balbi <ba...@ti.com> --- arch/arm/mach-omap2/omap_hwm

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

1 PID: 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 <t...@atomide.com> Cc: Nishanth Menon <n...@ti.com> Signed-off-by: Felipe Balbi <ba...@ti.com> --- arch/arm/bo

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

de with the fclk 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 to

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

Hi, Peter Ujfalusi <peter.ujfal...@ti.com> writes: > Felipe, > > On 11/11/2015 07:07 PM, Felipe Balbi wrote: >> From: Peter Ujfalusi <peter.ujfal...@ti.com> >> >> McASP3 is used by default on DRA7x based boards for audio. > > While this patch

Re: Linus HEAD build break

Hi again, Felipe Balbi <ba...@ti.com> 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 li

Re: Linus HEAD build break

Hi, Belisko Marek <marek.beli...@gmail.com> writes: > Hi, > > On Fri, Nov 6, 2015 at 3:24 PM, Felipe Balbi <ba...@ti.com> wrote: >> >> Hi again, >> >> Felipe Balbi <ba...@ti.com> writes: >>> Hi Marek, >>> >>> your c

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

y device tree files assuming none have changed by me. > > Signed-off-by: Sebastian Reichel <s...@kernel.org> Reported-by: Felipe Balbi <ba...@ti.com> Tested-by: Felipe Balbi <ba...@ti.com> Acked-by: Felipe Balbi <ba...@ti.com> > --- > arch/arm/boot/dts/twl4030.dt

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

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

Hi, Lokesh Vutla <a0131...@ti.com> 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:

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

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

> driver loaded for it. > This patch will add a dummy driver skeleton without probe or remove > callbacks provided. > > Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com> > Reported-by: Olof Johansson <o...@lixom.net> This fixes the problem I also reported on linux-omap [1] Tes

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

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

Grygorii Strashko <grygorii.stras...@ti.com> 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(). > >

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

Hi, Grygorii Strashko <grygorii.stras...@ti.com> writes: > On 11/02/2015 06:06 PM, Felipe Balbi wrote: >> >> hi, >> >> Grygorii Strashko <grygorii.stras...@ti.com> writes: >>> On 11/02/2015 05:20 PM, Felipe Balbi wrote: >>>> Grygorii

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

hi, Grygorii Strashko <grygorii.stras...@ti.com> writes: > On 11/02/2015 05:20 PM, Felipe Balbi wrote: >> Grygorii Strashko <grygorii.stras...@ti.com> writes: >> >>> On 10/29/2015 03:57 PM, Felipe Balbi wrote: >>>> there's no need to call pm_ru

[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 <ba...@ti.com> --- drivers/spi/spi-ti-qspi.c | 11 +-- 1 file changed, 1 insertion(+), 10 del

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

Hi, Tony Lindgren <t...@atomide.com> writes: > * Felipe Balbi <ba...@ti.com> [151023 09:48]: >> >> Hi, >> >> Tony Lindgren <t...@atomide.com> writes: >> > From: Tony Lindgren <t...@atomide.com> >> > Date: Fri, 23 Oct 2015 09:

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

; Signed-off-by: Tony Lindgren <t...@atomide.com> I'm fine with this patch to fix this v4.3 regression. Greg, do you want a pull request or can you take this in as a patch ? In any case: Acked-by: Felipe Balbi <ba...@ti.com> > --- a/drivers/usb/musb/omap2430.c > +++

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

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

Re: Regression caused by 073db4a51ee43ccb827f54a4261c0583b028d5ab

(fixing Tony's address) Felipe Balbi <ba...@ti.com> 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

Re: Regression caused by 073db4a51ee43ccb827f54a4261c0583b028d5ab

Hi, Brian Norris <computersforpe...@gmail.com> 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, >> >&

[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 <ba...@ti.com> --- 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/ar

[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 <ba...@ti.com> --- drivers/clocksource/Kconfig | 1 +

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

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

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

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

[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 <ba...@ti.com> --- arch/arm/mach

[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 <ba...@ti.com> --- arch/arm/mach-omap2/timer.

[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 <ba...@ti.com> --- arch/arm/mach-omap2/timer.c | 114 ++-- 1 file changed, 56 insertions(+), 58 deletions(-) diff --git a/arch/arm/mach

[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 <ba...@ti.com> --- ar

[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 <ba...@ti.com> --- arch/arm/mach-omap2/board-generic.c | 10 +- arch/arm/mach-omap2/board-ldp.c | 2 +- ar

[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 <ba...@ti.com> --- arch/arm/mach-omap2/timer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ar

[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 <ba...@ti.com> --- 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 b3a0df

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

com> Signed-off-by: Felipe Balbi <ba...@ti.com> --- 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/t

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

c...@linaro.org> Signed-off-by: Felipe Balbi <ba...@ti.com> --- drivers/clocksource/Kconfig| 7 +++ drivers/clocksource/Makefile | 1 + drivers/clocksource/timer-ti-32k.c | 126 + 3 files changed, 134 insertions(+) create mode 100644 driv

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

[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 <ba...@ti.com> --- arch/arm/mach-omap2/board-generic.c | 10 +- arch/arm/mach-omap2/board-ldp.c

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

Hi, Bin Liu <b-...@ti.com> writes: > Hi, > > On 10/13/2015 01:22 PM, Felipe Balbi wrote: >> Yegor Yefremov <yegorsli...@googlemail.com> writes: >>> On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov >>> <yegorsli...@googlemail.com> wrote: >>

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

Hi, Bin Liu <b-...@ti.com> writes: > On 10/14/2015 10:56 AM, Felipe Balbi wrote: >> >> Hi, >> >> Bin Liu <b-...@ti.com> writes: >>> Hi, >>> >>> On 10/13/2015 01:22 PM, Felipe Balbi wrote: >>>> Yegor Yefremov <

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

Hi, Bin Liu <b-...@ti.com> writes: > On 10/14/2015 12:05 PM, Felipe Balbi wrote: >> >> Hi, >> >> Bin Liu <b-...@ti.com> writes: >>> Felipe, >>> >>> On 10/14/2015 11:25 AM, Felipe Balbi wrote: >>>> >>>> Hi,

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

Hi, Bin Liu <b-...@ti.com> writes: > Felipe, > > On 10/14/2015 11:25 AM, Felipe Balbi wrote: >> >> Hi, >> >> Bin Liu <b-...@ti.com> writes: >>> On 10/14/2015 10:56 AM, Felipe Balbi wrote: >>>> >>>> Hi, >>>>

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

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

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

hi, Sebastian Reichel <s...@kernel.org> writes: > Hi, > > On Tue, Oct 13, 2015 at 10:50:45AM -0500, Felipe Balbi wrote: >> Rolf Peukert <rolf.peuk...@imms.de> writes: >> > On 13.10.2015 10:15, Tero Kristo wrote: >> >> On 10/12/2015 06:22 PM, Rol

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

Hi, Sebastian Reichel <s...@kernel.org> writes: > On Tue, Oct 13, 2015 at 05:57:59PM -0500, Felipe Balbi wrote: >> Sebastian Reichel <s...@kernel.org> writes: >> > On Tue, Oct 13, 2015 at 10:50:45AM -0500, Felipe Balbi wrote: >> >>

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

Hi, Rolf Peukert <rolf.peuk...@imms.de> 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 id

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

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

Hi, Tony Lindgren <t...@atomide.com> writes: > * Felipe Balbi <ba...@ti.com> [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

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

Belisko Marek <marek.beli...@gmail.com> writes: > Hi, > > On Tue, Oct 6, 2015 at 4:03 PM, Belisko Marek <marek.beli...@gmail.com> wrote: >> Hi Felipe, >> >> On Tue, Oct 6, 2015 at 4:00 PM, Felipe Balbi <ba...@ti.com> wrote: >>> >>

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

Tony Lindgren <t...@atomide.com> writes: > * Felipe Balbi <ba...@ti.com> [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. > > Grea

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

Hi, Daniel Lezcano <daniel.lezc...@linaro.org> 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: Fe

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

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

[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 <ba...@ti.com> --- arch/arm/mach-omap2/timer.

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

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

not 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

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

Felipe Balbi <ba...@ti.com> writes: > Belisko Marek <marek.beli...@gmail.com> writes: > >> Hi, >> >> On Tue, Oct 6, 2015 at 4:03 PM, Belisko Marek <marek.beli...@gmail.com> >> wrote: >>> Hi Felipe, >>> >>> On T

[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 <ba...@ti.com> --- arch/arm/mach-omap2/board-generic.c | 14 +++--- arch/arm/mach-omap2/board

[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 <ba...@ti.com> --- arch/arm/mach-omap2/timer.c | 102 ++-- 1 file changed, 50 insertions(+), 52 deletions(-) diff --git a/arch/arm/mach

[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 <ba...@ti.com> --- arch/arm/mach-omap2/board-generic.c | 10 +- arch/arm/mach-omap2/board-ldp.c | 2 +- ar

[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 <ba...@ti.com> --- drivers/clocksource/Kconfig| 7 +++ drivers/clocksource/Makefile | 1 + drivers/clocksource/timer-ti

[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 <ba...@ti.com> --- arch/arm/mach-omap2/board-generic.c | 4 ++-- arch/ar

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

Felipe Balbi <ba...@ti.com> writes: > Tony Lindgren <t...@atomide.com> writes: > >> * Felipe Balbi <ba...@ti.com> [151005 17:49]: >>> We actually want these devices to be created because >>> we will be moving timers to drivers/clocksource and >

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

=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 arm: omap2: timer: add a gptimer

[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 <ba...@ti.com> --- arch/arm/mach

[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 <ba...@ti.com> --- 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 871d6c

[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 <ba...@ti.com> --- arch/arm/mach-omap2/timer.c | 8 1 file changed, 4 insertions(+), 4 del

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

Arnd Bergmann <a...@arndb.de> 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 >> * @propert

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

On Wed, Sep 30, 2015 at 11:58:16PM +0200, Arnd Bergmann wrote: > 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

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

the secure timer will NOT be available for the public world. This patch is just moving the call to of_add_property to its rightful place. Signed-off-by: Felipe Balbi <ba...@ti.com> --- Okay, seems like this is a saner approach. changes since v1: - don't completely remove the status disabled

Re: [PATCH v2 3/4] ARM: dts: DRA7: Add timer12 node

Suman Anna writes: > Add the DT node for Timer12 present on DRA7 family of > SoCs. Timer12 is present in PD_WKUPAON power domain, and > has the same capabilities as the other timers, except for > the fact that it serves as a secure timer on HS devices > and is clocked only from

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

API are 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 <ba...@ti.com> >&g

  1   2   3   4   5   6   7   8   9   10   >