Re: Routable IRQs

[Felipe Balbi]

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 these 64 events can be routed to any of these 10 IRQ
>> lines. This might not be very useful on UP (AM335x & AM437x) other than
>> the fact that soft-IP drivers running on Linux would need to guarantee
>> they are the ones who should handle the IRQ. However, on SMP (AM57xx) we
>> could have real tangible benefits by means of IRQ affinity, etc.
>> 
>> So, the question is, what is there in IRQ subsystem today for routable
>> IRQ support ?
>> 
>> If a Diagram helps here's a simple one. Note that I'm not showing
>> details on the PRUSS side, but that side can also map events pretty much
>> any way it wants.
>> 
>>  .. ..
>>  |  HOST CPU  | |   PRUSS|
>>  || ||
>>  || ||
>>  |   irq0 |<-.--|evt0|
>>  ||  |  ||
>>  |   irq1 |  |  .---|evt1|
>>  ||  |  |   ||
>>  |   irq2 |  '--|evt2|
>>  || |   ||
>>  |   irq3 | |   ||
>>  || |   ||
>>  |   irq4 | |   | .  |
>>  || |   ||
>>  |   irq5 | |   | .  |
>>  || |   ||
>>  |   irq6 | |   | .  |
>>  || |   ||
>>  |   irq7 |<'   ||
>>  || ||
>>  |   irq8 | ||
>>  || ||
>>  |   irq9 |<|evtN|
>>  '' ''
>> 
>> Given this setup, what I want to do, is let soft-IP drivers running on
>> linux rely on standard *request_*irq() calls and DTS descrition. But I'm
>> still considering how/if we should describe the routing itself or just
>> go round-robin (i.o.w. irq0 -> evt0, irq1 -> evt1, ..., irq9 -> evt9,
>> irq0 -> evt10, ...).
>> 
>> Thoughts ?
>
> I have a few questions:
>
>  - Is there a "mapping" block between PRUSS and the host interrupt controller
>or is this "mapping" block part of PRUSS?

The description in TRM is a bit "poor", but from what I can gather, the
mapping is done on an interrupt controller inside the PRUSS. However,
Linux is the one who's got the driver for that INTC (well, Linux will be
the one with the soft ethernet/uart/whatever IP to talk to). All of its
(INTC's) registers are memory mapped to the ARM side.

>  - We all know how well shared interrupts work. Is there a point of supporting
>64 interrupts when you only have 10 irq lines available?

I'm looking at these 64 events more like MSI kind of events. It's just
that the events themselves can be routed to any of the 10 available HW
IRQ lines.

>  - I assume that the PRUSS interrupt mapping is more or less a question of the
>firmware implementation. So you either have a fixed association in the
>firmware which is reflected in the DT description of the IP block or you
>need an interface to tell the PRUSS firmware which event it should map to
>which irq line. Is there actually a value in doing the latter?

right, I'd say the mapping is pretty static. Unless Suman has some extra
information which I don't. I guess the question was really to see if
there was an easy way for doing this so we don't have to mess with DTS
for every other FW and their neighbor.

Chances are (or at least I'm speculating) in most cases we won't use
more than 10 events anyway (Suman ?) so we might not run into any
troubles.

-- 
balbi


signature.asc
Description: PGP signature

Re: Routable IRQs

[Felipe Balbi]

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 
>> > controller
>> >or is this "mapping" block part of PRUSS?
>> 
>> The description in TRM is a bit "poor", but from what I can gather, the
>> mapping is done on an interrupt controller inside the PRUSS. However,
>> Linux is the one who's got the driver for that INTC (well, Linux will be
>> the one with the soft ethernet/uart/whatever IP to talk to). All of its
>> (INTC's) registers are memory mapped to the ARM side.
>
> Ok. And the INTC registers include the "mapping" configuration, right?

right. A bunch of 32 bit registers each with several 4 bit fields (one
for each of the 64 events) where we write the physical IRQ number.

>> >  - We all know how well shared interrupts work. Is there a point of 
>> > supporting
>> >64 interrupts when you only have 10 irq lines available?
>> 
>> I'm looking at these 64 events more like MSI kind of events. It's just
>
> Well, that's fine to look at them this way, but they will end up
> shared no matter what.

sure :-)

>> that the events themselves can be routed to any of the 10 available HW
>> IRQ lines.
>> 
>> >  - I assume that the PRUSS interrupt mapping is more or less a question of 
>> > the
>> >firmware implementation. So you either have a fixed association in the
>> >firmware which is reflected in the DT description of the IP block or you
>> >need an interface to tell the PRUSS firmware which event it should map 
>> > to
>> >which irq line. Is there actually a value in doing the latter?
>> 
>> right, I'd say the mapping is pretty static. Unless Suman has some extra
>> information which I don't. I guess the question was really to see if
>> there was an easy way for doing this so we don't have to mess with DTS
>> for every other FW and their neighbor.
>
> Well, you will need information about every other firmware simply because you
> need to know which events the firmware is actually using and what the purpose
> of the particular event is.
>
> Assume you have a simple uart with 3 events (RX, TX, status). So how will the
> firmware tell you which event is which? You have a few options:
>
>  1) DT + fixed mapping scheme: 
>
> Describe the PRUSS event number in DT and have a fixed mapping scheme like
> the one you mentioned evt0 -> irq0 .
>
>  2) DT + DT mapping scheme
>
> Describe the PRUSS event number in DT and describe the mapping scheme in
> DT as well
>
>  3) DT + dynamic mapping scheme
>
> Describe the PRUSS event number in DT and let your interrupt controller
> associate the irq number dynamically. That's kind of similar to MSI with
> the exception that it needs to support shared interrupts.
>
>  4) Fully dynamic association
>
> Have a query interface to the firmware which tells you which event it uses
> for which particular purpose (RX, TX ...) and then establish a dynamic
> mapping to one of the interrupts.
>
> Not sure which level of complexity you want :)

I guess only 1, 2 are anything worth considering, most likely. 4 would
just be too much headache :-p

3 might be doable too, though a bit more complex. Suman (who has been
working on this for much longer than I have) might have some extra info
to add, but he's on vacations for now. Hopefully, he'll add to this
thread once he's back.

cheers

-- 
balbi


signature.asc
Description: PGP signature

Re: Linux 4.2.0-rc5: am335x: musb warnings

[Felipe Balbi]

Hi,

Yegor Yefremov <yegorsli...@googlemail.com> writes:
> Hi Felipe, hi Ladislav,
>
> On Wed, Oct 14, 2015 at 1:47 AM, Ladislav Michl <la...@linux-mips.org> wrote:
>> On Mon, Aug 31, 2015 at 03:11:58PM +0200, Yegor Yefremov wrote:
>>> Hi Felipe,
>>>
>>> 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, Felipe Balbi <ba...@ti.com> wrote:
>>> >>> HI,
>>> >>>
>>> >>> On Thu, Aug 06, 2015 at 09:40:26AM +0200, Yegor Yefremov wrote:
>>> >>>> I performed a stress test with several FT4232H chips connected to a
>>> >>>
>>> >>> how many ?
>>> >>
>>> >> # lsusb -t
>>> >> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>>> >> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>>> >> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
>>> >> |__ Port 1: Dev 3, If 0, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 1: Dev 3, If 1, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 1: Dev 3, If 2, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 1: Dev 3, If 3, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 3: Dev 5, If 0, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 3: Dev 5, If 1, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 3: Dev 5, If 2, Class=, Driver=ftdi_sio, 480M
>>> >> |__ Port 3: Dev 5, If 3, Class=, Driver=ftdi_sio, 480M
>>> >>
>>> >> 3 chips a 4-ports are attached.
>>> >
>>> > Warnings appear on another device (without internal hub) with only one
>>> > FT4232H too:
>>> >
>>> > # lsusb -t
>>> > /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>>> > |__ Port 1: Dev 2, If 0, Class=, Driver=ftdi_sio, 480M
>>> > |__ Port 1: Dev 2, If 1, Class=, Driver=ftdi_sio, 480M
>>> > |__ Port 1: Dev 2, If 2, Class=, Driver=ftdi_sio, 480M
>>> > |__ Port 1: Dev 2, If 3, Class=, Driver=ftdi_sio, 480M
>>> >
>>> >>>> hub, that is attached to one of the musb ports. So far the test was
>>> >>>> successful for several hours. But I've seen following warnings:
>>> >>>>
>>> >>>> musb_host_rx 1973: Rx interrupt with no errors or packet!
>>> >>>> musb_ep_program 931: broken !rx_reinit, ep5 csr 0203
>>> >>>> musb_host_rx 1973: Rx interrupt with no errors or packet!
>>> >>>> musb_host_rx 1973: Rx interrupt with no errors or packet!
>>> >>>> musb_host_rx 1973: Rx interrupt with no errors or packet!
>>> >>>> musb_host_rx 1973: Rx interrupt with no errors or packet!
>>> >>>> musb_ep_program 931: broken !rx_reinit, ep5 csr 0003
>>> >>>> musb_host_rx 1973: Rx interrupt with no errors or packet!
>>> >>>> musb_ep_program 931: broken !rx_reinit, ep7 csr 0003
>>> >>>>
>>> >>>> Is this expected behavior?
>>> >>>
>>> >>> no, that shouldn't happen, but it does and, apparently, in more than one
>>> >>> implementation. Wondering if you're running into endpoint limitation due
>>> >>> to MUSB's poor transfer scheduling for non-bulk endpoints.
>>
>> To add more:
>> kernel 4.2.0 on AM3703 musb in DMA mode with Quectel U15 modem plugged:
>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
>> |__ Port 4: Dev 3, If 0, Class=Vendor Specific Class, Driver=option, 
>> 480M
>> |__ Port 4: Dev 3, If 1, Class=Vendor Specific Class, Driver=option, 
>> 480M
>> |__ Port 4: Dev 3, If 2, Class=Vendor Specific Class, Driver=option, 
>> 480M
>> |__ Port 4: Dev 3, If 3, Class=Vendor Specific Class, Driver=option, 
>&

Routable IRQs

[Felipe Balbi]

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 is pretty darn good for bit
banging peripherals (ETH, SPI, I2C, UART, etc). It's very predicatable
because every instruction takes 5ns and interrupts don't cause
exceptions, they just get registered.

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 to any of these 10 IRQ
lines. This might not be very useful on UP (AM335x & AM437x) other than
the fact that soft-IP drivers running on Linux would need to guarantee
they are the ones who should handle the IRQ. However, on SMP (AM57xx) we
could have real tangible benefits by means of IRQ affinity, etc.

So, the question is, what is there in IRQ subsystem today for routable
IRQ support ?

If a Diagram helps here's a simple one. Note that I'm not showing
details on the PRUSS side, but that side can also map events pretty much
any way it wants.

 .. ..
 |  HOST CPU  | |   PRUSS|
 || ||
 || ||
 |   irq0 |<-.--|evt0|
 ||  |  ||
 |   irq1 |  |  .---|evt1|
 ||  |  |   ||
 |   irq2 |  '--|evt2|
 || |   ||
 |   irq3 | |   ||
 || |   ||
 |   irq4 | |   | .  |
 || |   ||
 |   irq5 | |   | .  |
 || |   ||
 |   irq6 | |   | .  |
 || |   ||
 |   irq7 |<'   ||
 || ||
 |   irq8 | ||
 || ||
 |   irq9 |<|evtN|
 '' ''

Given this setup, what I want to do, is let soft-IP drivers running on
linux rely on standard *request_*irq() calls and DTS descrition. But I'm
still considering how/if we should describe the routing itself or just
go round-robin (i.o.w. irq0 -> evt0, irq1 -> evt1, ..., irq9 -> evt9,
irq0 -> evt10, ...).

Thoughts ?

-- 
balbi


signature.asc
Description: PGP signature

Re: debugging

[Felipe Balbi]

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:
>>> 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 me think that boot rom has loaded
>>> the xloader into sram.
>>
>> you might wanna consider openocd if your jtag interface is available
>> somewhere on your pcb. Just keep in mind that you might have to fiddle a
>> bit with some TCL config files to get openocd to behave correctly with
>> your board.
>>
>
> I managed to connect a lauterbach debugger. to my target. This is what
> i did to test
>
> 1. reset the board.  & stop at u-boot prompt
> 2. Do a system.attach on the T32 (Lauterbach says that system is ready)
> 3. I do a run on the T32. I see that the status changes on T32 to run.
> 4. Now, i try to play with the u-boot prompt and board does not
> respond.

is CPU, perhaps, halted ?

> Any idea what i am doing wrong? The PC is pointing to some address
> 0x28000 and does not change.

yeah, it's halted. I don't know much about T32, you might wanna read its
documentation, though.

> I expect the PC to be some address in the RAM since mmu is off.
>
> Also, do i need to compile the x-loader and u-boot with some special
> options & how do i tell the T32 to pick the map file for x-loader and
> u-boot?

yeah, you gotta read T32's documentation. I can't help there :-p

-- 
balbi


signature.asc
Description: PGP signature

Re: debugging

[Felipe Balbi]

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 me think that boot rom has loaded
> the xloader into sram.

you might wanna consider openocd if your jtag interface is available
somewhere on your pcb. Just keep in mind that you might have to fiddle a
bit with some TCL config files to get openocd to behave correctly with
your board.

cheers

> On Thu, Dec 10, 2015 at 1:44 AM, Tony Lindgren  wrote:
>> * Ryan  [151209 09:03]:
>>> Hello,
>>>
>>> On a custom 4460 board. The x-loader hangs at some place when we
>>> reboot. This happens occasionally on an android port by linaro.
>>>
>>> I just want to find out how to debug in this case. How can i get to
>>> know where the hang takes place. After boot rom, i can see the mmc clk
>>> toggling
>>> indicating that xloader is in sram when the hang takes place and not
>>> sure where the hang is.
>>>
>>> Do i need Lauterbach to debug - Is it possible to connect the emulator
>>> across reboot. If so, how? or is there any other way i can debug this
>>>
>>> Also, i want to check - If i can turn off the dplls? If so, how?
>>>
>>> I tried to do a disable on all the clocks in the clock list using
>>> clk_disable call just before reboot and that does not seem to help.
>>
>> You can add selected serial print statements very early into u-boot
>> MLO (and probably x-loader). You need to keep them down to minimum
>> so the image still fits into SRAM. If you enable debug, then that also
>> needs to be limited to selected files only as enabling debug for the
>> whole MLO/x-loader in the Makefile will make it too big.
>>
>> Regards,
>>
>> Tony
> --
> 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

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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()
>
> Handle the spurious interrupt condition in omap-intc
> driver to prevent this.
>
> Signed-off-by: Sekhar Nori 
> ---
> v2: increment error irq counter, use pr_err_once,
> add a comment on tips to debug spurious irq
> condition.
>
> This patch results in a checkpatch warning about
> extern definition of irq_err_count, but looks like
> thats the prevalent method of accessing that counter.
>
>  drivers/irqchip/irq-omap-intc.c | 27 ++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
> index 8587d0f8d8c0..639708de5529 100644
> --- a/drivers/irqchip/irq-omap-intc.c
> +++ b/drivers/irqchip/irq-omap-intc.c
> @@ -47,6 +47,7 @@
>  #define INTC_ILR00x0100
>  
>  #define ACTIVEIRQ_MASK   0x7f/* omap2/3 active interrupt 
> bits */
> +#define SPURIOUSIRQ_MASK (0x1ff << 7)
>  #define INTCPS_NR_ILR_REGS   128
>  #define INTCPS_NR_MIR_REGS   4
>  
> @@ -330,11 +331,35 @@ static int __init omap_init_irq(u32 base, struct 
> device_node *node)
>  static asmlinkage void __exception_irq_entry
>  omap_intc_handle_irq(struct pt_regs *regs)
>  {
> + extern unsigned long irq_err_count;
>   u32 irqnr;
>  
>   irqnr = intc_readl(INTC_SIR);
> +
> + /*
> +  * A spurious IRQ can result if interrupt that triggered the
> +  * sorting is no longer active during the sorting (10 INTC
> +  * functional clock cycles after interrupt assertion). Or a
> +  * change in interrupt mask affected the result during sorting
> +  * time. There is no special handling required except ignoring
> +  * the SIR register value just read and retrying.
> +  * See section 6.2.5 of AM335x TRM Literature Number: SPRUH73K
> +  *
> +  * Many a times, a spurious interrupt situation has been fixed
> +  * by adding a flush for the posted write acking the IRQ in
> +  * the device driver. Typically, this is going be the device
> +  * driver whose interrupt was handled just before the spurious
> +  * IRQ occurred. Pay attention to those device drivers if you
> +  * run into hitting the spurious IRQ condition below.
> +  */
> + if ((irqnr & SPURIOUSIRQ_MASK) == SPURIOUSIRQ_MASK) {

sounds like unlikely() wouldn't hurt here.

> + pr_err_once("%s: spurious irq!\n", __func__);
> + irq_err_count++;
> + omap_ack_irq(NULL);
> + return;
> + }
> +
>   irqnr &= ACTIVEIRQ_MASK;
> - WARN_ONCE(!irqnr, "Spurious IRQ ?\n");
>   handle_domain_irq(domain, irqnr, regs);

care to run kernel function profiler against omap_intc_handle_irq()
before and after this patch ?

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

Hi,

Grygorii Strashko <grygorii.stras...@ti.com> writes:
> ARM TWD and Global timer are clocked by PERIPHCLK which is MPU_CLK/2.
> But now they are clocked by dpll_mpu_m2_ck == MPU_CLK and, as result.
> Timekeeping core misbehaves. For example, execution of command
> "sleep 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>
> Cc: Tero Kristo <t-kri...@ti.com>
> Fixes:commit 8cbd4c2f6a99 ("arm: boot: dts: am4372: add ARM timers and SCU 
> nodes")
> Signed-off-by: Grygorii Strashko <grygorii.stras...@ti.com>

this seems to be the best fix for this problem, yeah.

Reviewed-by: Felipe Balbi <ba...@ti.com>

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

Hi,

Peter Ujfalusi  writes:
> @@ -174,12 +182,44 @@
>   };
>  
>   edma: edma@4900 {
> - compatible = "ti,edma3";
> - ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> - reg =   <0x4900 0x1>,
> - <0x44e10f90 0x40>;
> + compatible = "ti,edma3-tpcc";
> + ti,hwmods = "tpcc";
> + reg =   <0x4900 0x1>;
> + reg-names = "edma3_cc";
>   interrupts = <12 13 14>;
> - #dma-cells = <1>;
> + interrupt-names = "edma3_ccint", "emda3_mperr",
> +   "edma3_ccerrint";
> + dma-requests = <64>;
> + #dma-cells = <2>;
> +
> + ti,tptcs = <_tptc0 7>, <_tptc1 5>,
> +<_tptc2 0>;
> +
> + ti,edma-memcpy-channels = /bits/ 16 <20 21>;

can you explain this property here ? Are you setting bits 20 and 21 on a
16-bit field ?

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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 opcode, read
> mode(quad, dual, normal), address width and dummy bytes. Once,
> controller is in mmap mode, the whole flash memory is available as a
> memory region at SoC specific address. This region can be accessed using
> normal memcpy() (or mem-to-mem dma copy). The ti-qspi controller hardware
> will internally communicate with SPI flash over SPI bus and get the
> requested data.
>
> Implement spi_flash_read() callback to support mmap read over SPI
> flash devices. With this, the read throughput increases from ~100kB/s to
> ~2.5 MB/s.
>
> Signed-off-by: Vignesh R 
> ---
>
>  drivers/spi/spi-ti-qspi.c | 101 
> ++
>  1 file changed, 94 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
> index 64318fcfacf2..cd4e63f45e65 100644
> --- a/drivers/spi/spi-ti-qspi.c
> +++ b/drivers/spi/spi-ti-qspi.c
> @@ -56,6 +56,7 @@ struct ti_qspi {
>   u32 dc;
>  
>   bool ctrl_mod;
> + bool mmap_enabled;
>  };
>  
>  #define QSPI_PID (0x0)
> @@ -65,11 +66,8 @@ struct ti_qspi {
>  #define QSPI_SPI_CMD_REG (0x48)
>  #define QSPI_SPI_STATUS_REG  (0x4c)
>  #define QSPI_SPI_DATA_REG(0x50)
> -#define QSPI_SPI_SETUP0_REG  (0x54)
> +#define QSPI_SPI_SETUP_REG(n)((0x54 + 4 * n))
>  #define QSPI_SPI_SWITCH_REG  (0x64)
> -#define QSPI_SPI_SETUP1_REG  (0x58)
> -#define QSPI_SPI_SETUP2_REG  (0x5c)
> -#define QSPI_SPI_SETUP3_REG  (0x60)
>  #define QSPI_SPI_DATA_REG_1  (0x68)
>  #define QSPI_SPI_DATA_REG_2  (0x6c)
>  #define QSPI_SPI_DATA_REG_3  (0x70)
> @@ -109,6 +107,16 @@ struct ti_qspi {
>  
>  #define QSPI_AUTOSUSPEND_TIMEOUT 2000
>  
> +#define MEM_CS_EN(n) ((n + 1) << 8)
> +
> +#define MM_SWITCH0x1
> +
> +#define QSPI_SETUP_RD_NORMAL (0x0 << 12)
> +#define QSPI_SETUP_RD_DUAL   (0x1 << 12)
> +#define QSPI_SETUP_RD_QUAD   (0x3 << 12)
> +#define QSPI_SETUP_ADDR_SHIFT8
> +#define QSPI_SETUP_DUMMY_SHIFT   10
> +
>  static inline unsigned long ti_qspi_read(struct ti_qspi *qspi,
>   unsigned long reg)
>  {
> @@ -366,6 +374,78 @@ static int qspi_transfer_msg(struct ti_qspi *qspi, 
> struct spi_transfer *t)
>   return 0;
>  }
>  
> +static void ti_qspi_enable_memory_map(struct spi_device *spi)
> +{
> + struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
> + u32 val;
> +
> + ti_qspi_write(qspi, MM_SWITCH, QSPI_SPI_SWITCH_REG);
> + if (qspi->ctrl_mod) {
> + val = readl(qspi->ctrl_base);
> + val |= MEM_CS_EN(spi->chip_select);
> + writel(val, qspi->ctrl_base);
> + /* dummy readl to ensure bus sync */
> + readl(qspi->ctrl_base);
> + }
> + qspi->mmap_enabled = true;
> +}
> +
> +static void ti_qspi_disable_memory_map(struct spi_device *spi)
> +{
> + struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
> + u32 val;
> +
> + ti_qspi_write(qspi, 0, QSPI_SPI_SWITCH_REG);
> + if (qspi->ctrl_mod) {
> + val = readl(qspi->ctrl_base);
> + val &= ~MEM_CS_EN(spi->chip_select);
> + writel(val, qspi->ctrl_base);
> + }
> + qspi->mmap_enabled = false;
> +}
> +
> +static void ti_qspi_setup_mmap_read(struct spi_device *spi,
> + struct spi_flash_read_message *msg)
> +{
> + struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
> + u32 memval = msg->read_opcode;
> +
> + switch (msg->data_nbits) {
> + case SPI_NBITS_QUAD:
> + memval |= QSPI_SETUP_RD_QUAD;
> + break;
> + case SPI_NBITS_DUAL:
> + memval |= QSPI_SETUP_RD_DUAL;
> + break;
> + default:
> + memval |= QSPI_SETUP_RD_NORMAL;
> + break;
> + }
> + memval |= ((msg->addr_width - 1) << QSPI_SETUP_ADDR_SHIFT |
> +msg->dummy_bytes << QSPI_SETUP_DUMMY_SHIFT);
> + ti_qspi_write(qspi, memval,
> +   QSPI_SPI_SETUP_REG(spi->chip_select));
> +}
> +
> +static int ti_qspi_spi_flash_read(struct  spi_device *spi,
> +   struct spi_flash_read_message *msg)
> +{
> + struct ti_qspi *qspi = spi_master_get_devdata(spi->master);
> + int ret = 0;
> +
> + mutex_lock(>list_lock);
> +
> + if (!qspi->mmap_enabled)
> + ti_qspi_enable_memory_map(spi);
> + ti_qspi_setup_mmap_read(spi, msg);
> + memcpy_fromio(msg->buf, qspi->mmap_base + msg->from, msg->len);
> + 

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

[Felipe Balbi]

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:
>>> 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-palmas.c | 22 --
>>>  1 file changed, 20 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
>>> index 93c30a885740..7985d092c069 100644
>>> --- a/drivers/extcon/extcon-palmas.c
>>> +++ b/drivers/extcon/extcon-palmas.c
>>> @@ -296,10 +296,28 @@ static int palmas_usb_probe(struct platform_device 
>>> *pdev)
>>> }
>>>  
>>> if (palmas_usb->enable_vbus_detection) {
>>> +   int irq = platform_get_irq(pdev, 0);
>>> +
>>> +   if (irq > 0) {
>>> +   /* remux GPIO_1 as VBUSDET */
>>> +   status = palmas_update_bits(palmas, 
>>> PALMAS_PU_PD_OD_BASE,
>>> +   PALMAS_PRIMARY_SECONDARY_PAD1,
>>> +   
>>> PALMAS_PRIMARY_SECONDARY_PAD1_GPIO_1_MASK,
>>> +   (1 << 3));
>> 
>> PALMAS_PRIMARY_SECONDARY_PAD1_GPIO_1_SHIFT is appropriate instead of
>> using '3'.

good point :-)

>>> +   if (status < 0) {
>>> +   dev_err(>dev, "can't remux GPIO1\n");
>>> +   return status;
>>> +   }
>>> +
>>> +   palmas_usb->vbus_irq = irq;
>>> +   } else {
>>> +   irq = regmap_irq_get_virq(palmas->irq_data,
>>> +   PALMAS_VBUS_IRQ);
>>> +   palmas_usb->vbus_irq = irq;
>>> +   }
>>> +
>>> palmas_usb->vbus_otg_irq = regmap_irq_get_virq(palmas->irq_data,
>>>PALMAS_VBUS_OTG_IRQ);
>>> -   palmas_usb->vbus_irq = regmap_irq_get_virq(palmas->irq_data,
>>> -  PALMAS_VBUS_IRQ);
>>> status = devm_request_threaded_irq(palmas_usb->dev,
>>> palmas_usb->vbus_irq, NULL,
>>> palmas_vbus_irq_handler,
>>>
>> 
>> Thanks,
>> Chanwoo Choi
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>> 
>
> If you are OK about following patch, I'll apply it on extcon branch.

that's perfect, thanks for fixing it :-)

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

Hi,

Grygorii Strashko <grygorii.stras...@ti.com> 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 device/driver model and its PM can be
> implemented using PM runtime which is common for OMAP devices.
>
> Platform specific initialization code has to be disabled once as
> ti_32k_timer is converted to platform device - otherwise OMAP platform
> code will generate boot warnings.
>
> 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>
> ---
>  arch/arm/mach-omap2/timer.c| 16 +++
>  drivers/clocksource/timer-ti-32k.c | 58 
> --
>  2 files changed, 53 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index b18ebbe..3bfde44 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -393,23 +393,15 @@ static const struct of_device_id omap_counter_match[] 
> __initconst = {
>  static int __init __maybe_unused omap2_sync32k_clocksource_init(void)
>  {
>   int ret;
> - struct device_node *np = NULL;
>   struct omap_hwmod *oh;
>   const char *oh_name = "counter_32k";
>  
>   /*
> -  * If device-tree is present, then search the DT blob
> -  * to see if the 32kHz counter is supported.
> +  * If device-tree is present, then just exit -
> +  * 32kHz clocksource driver will handle it.
>*/
> - if (of_have_populated_dt()) {
> - np = omap_get_timer_dt(omap_counter_match, NULL);
> - if (!np)
> - return -ENODEV;
> -
> - of_property_read_string_index(np, "ti,hwmods", 0, _name);
> - if (!oh_name)
> - return -ENODEV;
> - }
> + if (of_have_populated_dt())
> + return 0;
>  
>   /*
>* First check hwmod data is available for sync32k counter
> diff --git a/drivers/clocksource/timer-ti-32k.c 
> b/drivers/clocksource/timer-ti-32k.c
> index 8518d9d..e71496f 100644
> --- a/drivers/clocksource/timer-ti-32k.c
> +++ b/drivers/clocksource/timer-ti-32k.c
> @@ -39,8 +39,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  /*
>   * 32KHz clocksource ... always available, on pretty most chips except
> @@ -88,15 +91,28 @@ static u64 notrace omap_32k_read_sched_clock(void)
>   return ti_32k_read_cycles(_32k_timer.cs);
>  }
>  
> -static void __init ti_32k_timer_init(struct device_node *np)
> +static const struct of_device_id ti_32k_of_table[] = {
> + { .compatible = "ti,omap-counter32k" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, ti_32k_of_table);
> +
> +static int __init ti_32k_probe(struct platform_device *pdev)
>  {
> + struct device *dev = >dev;
> + struct resource *res;
>   int ret;
>  
> - ti_32k_timer.base = of_iomap(np, 0);
> - if (!ti_32k_timer.base) {
> - pr_err("Can't ioremap 32k timer base\n");
> - return;
> - }
> + /* Static mapping, never released */
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + ti_32k_timer.base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(ti_32k_timer.base))
> + return PTR_ERR(ti_32k_timer.base);
> +
> + pm_runtime_enable(dev);
> + ret = pm_runtime_get_sync(dev);
> + if (ret < 0)
> + goto probe_err;
>  
>   ti_32k_timer.counter = ti_32k_timer.base;
>  
> @@ -116,11 +132,35 @@ static void __init ti_32k_timer_init(struct device_node 
> *np)
>   ret = clocksource_register_hz(_32k_timer.cs, 32768);
>   if (ret) {
>   pr_err("32k_counter: can't register clocksource\n");
> - return;
> + goto probe_err;
>   }
>  
>   sched_clock_register(omap_32k_read_sched_clock, 32, 32768);
>   pr_info("OMAP clocksource: 32k_counter at 32768 Hz\n");
> + return 0;
> +
> +probe_err:
> + pm_runtime_put_noidle(dev);
> + return ret;
> +};
> +
> +static struct platform_driver ti_32k_driver __initdata = {
> + .probe  = ti_32k_probe,
> + .driver = {
> + .name   = "ti_32k_timer",
> + 

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

[Felipe Balbi]

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 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 Kconfig logic for building the function 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>
>> 
>> no, AM43xx uses omap4_local_timer_init(), there's already a fix in
>> Tony's tree IIRC.
> ...
>  
>> care to provide a defconfig which would cause a build error ?
>
> My mistake, the code has changed several times and I adapted it to
> the latest version each time, but the version I sent out is indeed
> useless.
>
> The only hunk that still makes sense is
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index b18ebbefae09..b7ab09cc5ca2 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -494,7 +494,7 @@ void __init omap_init_time(void)
>   clocksource_probe();
>  }
>  
> -#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
> +#if defined(CONFIG_ARCH_OMAP3)
>  void __init omap3_secure_sync32k_timer_init(void)
>  {
>   __omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
>
>
> but that is harmless as it does not cause a build error, just a few extra
> bytes for an unused function in a AM43XX-only configuration.

I think that's still useful. Tony ?

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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 Kconfig logic for building the function 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 

no, AM43xx uses omap4_local_timer_init(), there's already a fix in
Tony's tree IIRC.

> +#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) || 
> defined(CONFIG_SOC_TI81XX)

[...]

> +#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || 
> defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)

someone doesn't like to run checkpatch.pl

care to provide a defconfig which would cause a build error ?

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

Hi,

Grygorii Strashko <grygorii.stras...@ti.com> writes:
> 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 ARM Global timer loses its contexts during
> System suspend:
>GT_CONTROL.TIMER_ENABLE = 0 (unbanked)
>GT_COUNTERx = 0
>
> Hence, update ARM Global timer driver to reflect above behaviour
> - save GT_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 <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/arm_global_timer.c | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/drivers/clocksource/arm_global_timer.c 
> b/drivers/clocksource/arm_global_timer.c
> index a2cb6fa..1bbaf64 100644
> --- a/drivers/clocksource/arm_global_timer.c
> +++ b/drivers/clocksource/arm_global_timer.c
> @@ -51,6 +51,8 @@ static void __iomem *gt_base;
>  static unsigned long gt_clk_rate;
>  static int gt_ppi;
>  static struct clock_event_device __percpu *gt_evt;
> +static bool gt_always_on;
> +static u32 gt_control;
>  
>  /*
>   * To get the value from the Global Timer Counter register proceed as 
> follows:
> @@ -168,6 +170,9 @@ static int gt_clockevents_init(struct clock_event_device 
> *clk)
>  {
>   int cpu = smp_processor_id();
>  
> + if (!gt_always_on)
> + clk->features |= CLOCK_EVT_FEAT_C3STOP;
> +
>   clk->name = "arm_global_timer";
>   clk->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT |
>   CLOCK_EVT_FEAT_PERCPU;
> @@ -195,12 +200,25 @@ static cycle_t gt_clocksource_read(struct clocksource 
> *cs)
>   return gt_counter_read();
>  }
>  
> +static void gt_suspend(struct clocksource *cs)
> +{
> + gt_control = readl(gt_base + GT_CONTROL);
> +}
> +
> +static void gt_resume(struct clocksource *cs)
> +{
> + /* enables timer on all the cores */
> + writel(gt_control & GT_CONTROL_TIMER_ENABLE, gt_base + GT_CONTROL);

do you really need to save context if all you restore is TIMER_ENABLE
bit ? seems like you could skip gt_suspend altogether. Is there really a
situation where this driver is running and GT isn't enabled ?

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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
>>> (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 ARM Global timer loses its contexts during
>>> System suspend:
>>> GT_CONTROL.TIMER_ENABLE = 0 (unbanked)
>>> GT_COUNTERx = 0
>>>
>>> Hence, update ARM Global timer driver to reflect above behaviour
>>> - save GT_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 <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/arm_global_timer.c | 23 +++
>>>   1 file changed, 23 insertions(+)
>>>
>>> diff --git a/drivers/clocksource/arm_global_timer.c 
>>> b/drivers/clocksource/arm_global_timer.c
>>> index a2cb6fa..1bbaf64 100644
>>> --- a/drivers/clocksource/arm_global_timer.c
>>> +++ b/drivers/clocksource/arm_global_timer.c
>>> @@ -51,6 +51,8 @@ static void __iomem *gt_base;
>>>   static unsigned long gt_clk_rate;
>>>   static int gt_ppi;
>>>   static struct clock_event_device __percpu *gt_evt;
>>> +static bool gt_always_on;
>>> +static u32 gt_control;
>>>   
>>>   /*
>>>* To get the value from the Global Timer Counter register proceed as 
>>> follows:
>>> @@ -168,6 +170,9 @@ static int gt_clockevents_init(struct 
>>> clock_event_device *clk)
>>>   {
>>> int cpu = smp_processor_id();
>>>   
>>> +   if (!gt_always_on)
>>> +   clk->features |= CLOCK_EVT_FEAT_C3STOP;
>>> +
>>> clk->name = "arm_global_timer";
>>> clk->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT |
>>> CLOCK_EVT_FEAT_PERCPU;
>>> @@ -195,12 +200,25 @@ static cycle_t gt_clocksource_read(struct clocksource 
>>> *cs)
>>> return gt_counter_read();
>>>   }
>>>   
>>> +static void gt_suspend(struct clocksource *cs)
>>> +{
>>> +   gt_control = readl(gt_base + GT_CONTROL);
>>> +}
>>> +
>>> +static void gt_resume(struct clocksource *cs)
>>> +{
>>> +   /* enables timer on all the cores */
>>> +   writel(gt_control & GT_CONTROL_TIMER_ENABLE, gt_base + GT_CONTROL);
>> 
>> do you really need to save context if all you restore is TIMER_ENABLE
>> bit ? seems like you could skip gt_suspend altogether. Is there really a
>> situation where this driver is running and GT isn't enabled ?
>
> Now It's not. It's always enabled. I did it because .suspend() is called for
> all registered clock sources regardless of their usage. So, potentially
> in the future, at the moment when .suspend() is called it might be disabled
> (for example, .enable/disable() callbacks can be added and, if ARM Global 
> timer
> will not be registered as sched_clock, it will be possible to keep it 
> disabled 
> if not used now).
>
> But It's not essentially now - I can update it and drop save restore. 
> Pls, confirm.

I think it's best to skip suspend completely. You're not restoring
anything you saved during suspend, unless you meant | where you used &.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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:
>>>>
>>>> Hi,
>>>>
>>>> Grygorii Strashko <grygorii.stras...@ti.com> writes:
>>>>> 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 ARM Global timer loses its contexts during
>>>>> System suspend:
>>>>>  GT_CONTROL.TIMER_ENABLE = 0 (unbanked)
>>>>>  GT_COUNTERx = 0
>>>>>
>>>>> Hence, update ARM Global timer driver to reflect above behaviour
>>>>> - save GT_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 <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/arm_global_timer.c | 23 +++
>>>>>1 file changed, 23 insertions(+)
>>>>>
>>>>> diff --git a/drivers/clocksource/arm_global_timer.c 
>>>>> b/drivers/clocksource/arm_global_timer.c
>>>>> index a2cb6fa..1bbaf64 100644
>>>>> --- a/drivers/clocksource/arm_global_timer.c
>>>>> +++ b/drivers/clocksource/arm_global_timer.c
>>>>> @@ -51,6 +51,8 @@ static void __iomem *gt_base;
>>>>>static unsigned long gt_clk_rate;
>>>>>static int gt_ppi;
>>>>>static struct clock_event_device __percpu *gt_evt;
>>>>> +static bool gt_always_on;
>>>>> +static u32 gt_control;
>>>>>
>>>>>/*
>>>>> * To get the value from the Global Timer Counter register proceed as 
>>>>> follows:
>>>>> @@ -168,6 +170,9 @@ static int gt_clockevents_init(struct 
>>>>> clock_event_device *clk)
>>>>>{
>>>>>   int cpu = smp_processor_id();
>>>>>
>>>>> + if (!gt_always_on)
>>>>> + clk->features |= CLOCK_EVT_FEAT_C3STOP;
>>>>> +
>>>>>   clk->name = "arm_global_timer";
>>>>>   clk->features = CLOCK_EVT_FEAT_PERIODIC | 
>>>>> CLOCK_EVT_FEAT_ONESHOT |
>>>>>   CLOCK_EVT_FEAT_PERCPU;
>>>>> @@ -195,12 +200,25 @@ static cycle_t gt_clocksource_read(struct 
>>>>> clocksource *cs)
>>>>>   return gt_counter_read();
>>>>>}
>>>>>
>>>>> +static void gt_suspend(struct clocksource *cs)
>>>>> +{
>>>>> + gt_control = readl(gt_base + GT_CONTROL);
>>>>> +}
>>>>> +
>>>>> +static void gt_resume(struct clocksource *cs)
>>>>> +{
>>>>> + /* enables timer on all the cores */
>>>>> + writel(gt_control & GT_CONTROL_TIMER_ENABLE, gt_base + GT_CONTROL);
>>>>
>>>> do you really need to save context if all you restore is TIMER_ENABLE
>>>> bit ? seems like you could skip gt_suspend altogether. Is there really a
>>>> situation where this driver is running and GT isn't enabled ?
>>>
>>> Now It's not. It's always enabled. I did it because .suspend() is called for
>>> all registered clock sources regardless of their usage. So, potentially
>>> in the future, at the moment when .suspend() is called it might be disabled
>>> (for example, .enable/disable() callbacks can be added and, if ARM Global 
>>> timer
>>> will not be registered as sched_clock, it will be possible to keep it 
>>> disabled
>>> if not used now).
>>>
>>> But It's not essentially now - I can update it and drop save restore.
>>> Pls, confirm.
>>
>> I think it's best to skip suspend completely. You're not restoring
>> anything you saved during suspend, unless you meant | where you used &.
>>
>
> I didn't get it - I'm restoring one bit(0) only.

that's the point, if you know you're restoring only that bit. Why save
anything at all ?

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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:
>>>>
>>>> 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
>>>>>>> (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 ARM Global timer loses its contexts during
>>>>>>> System suspend:
>>>>>>>   GT_CONTROL.TIMER_ENABLE = 0 (unbanked)
>>>>>>>   GT_COUNTERx = 0
>>>>>>>
>>>>>>> Hence, update ARM Global timer driver to reflect above behaviour
>>>>>>> - save GT_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 <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/arm_global_timer.c | 23 +++
>>>>>>> 1 file changed, 23 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/clocksource/arm_global_timer.c 
>>>>>>> b/drivers/clocksource/arm_global_timer.c
>>>>>>> index a2cb6fa..1bbaf64 100644
>>>>>>> --- a/drivers/clocksource/arm_global_timer.c
>>>>>>> +++ b/drivers/clocksource/arm_global_timer.c
>>>>>>> @@ -51,6 +51,8 @@ static void __iomem *gt_base;
>>>>>>> static unsigned long gt_clk_rate;
>>>>>>> static int gt_ppi;
>>>>>>> static struct clock_event_device __percpu *gt_evt;
>>>>>>> +static bool gt_always_on;
>>>>>>> +static u32 gt_control;
>>>>>>>
>>>>>>> /*
>>>>>>>  * To get the value from the Global Timer Counter register proceed 
>>>>>>> as follows:
>>>>>>> @@ -168,6 +170,9 @@ static int gt_clockevents_init(struct 
>>>>>>> clock_event_device *clk)
>>>>>>> {
>>>>>>> int cpu = smp_processor_id();
>>>>>>>
>>>>>>> +   if (!gt_always_on)
>>>>>>> +   clk->features |= CLOCK_EVT_FEAT_C3STOP;
>>>>>>> +
>>>>>>> clk->name = "arm_global_timer";
>>>>>>> clk->features = CLOCK_EVT_FEAT_PERIODIC | 
>>>>>>> CLOCK_EVT_FEAT_ONESHOT |
>>>>>>> CLOCK_EVT_FEAT_PERCPU;
>>>>>>> @@ -195,12 +200,25 @@ static cycle_t gt_clocksource_read(struct 
>>>>>>> clocksource *cs)
>>>>>>> return gt_counter_read();
>>>>>>> }
>>>>>>>
>>>>>>> +static void gt_suspend(struct clocksource *cs)
>>>>>>> +{
>>>>>>> +   gt_control = readl(gt_base + GT_CONTROL);
>>>>>>> +}
>>>>>>> +
>>>>>>> +static void gt_resume(struct clocksource *cs)
>>>>>>> +{
>>>>>>> +   /* enables timer on all the cores */
>>>>>>> +   writel(gt_control & GT_CONTROL_TIMER_ENABLE, gt_base + 
>>>>>>> GT_CONTROL);
>>>>>>
>>>>>> do you really need to save context if all you restore is TIMER_ENABLE
>>>>>> bit ? seems like you could skip gt_suspend altogether. Is there really a
>>>>>> situation where this driver is running and GT isn't enabled ?
>>>>>
>>>>> Now It's not. It's always enabled. I did it because .suspend() is called 
>>>>> for
>>>>> all registered clock sources regardless of their usage. So, potentially
>>>>> in the future, at the moment when .suspend() is called it might be 
>>>>> disabled
>>>>> (for example, .enable/disable() callbacks can be added and, if ARM Global 
>>>>> timer
>>>>> will not be registered as sched_clock, it will be possible to keep it 
>>>>> disabled
>>>>> if not used now).
>>>>>
>>>>> But It's not essentially now - I can update it and drop save restore.
>>>>> Pls, confirm.
>>>>
>>>> I think it's best to skip suspend completely. You're not restoring
>>>> anything you saved during suspend, unless you meant | where you used &.
>>>>
>>>
>>> I didn't get it - I'm restoring one bit(0) only.
>>
>> that's the point, if you know you're restoring only that bit. Why save
>> anything at all ?
>>
>
> i think there are difference between "restoring" and "re-enabling".
> "restoring" - assume saving smth.. then restore saving value.
> I'm saving & restoring one bit here.

with your current suspend/resume, they are the same thing. You save
GT_CONTROL contents, timer goes off and looses context, you set ENABLE
bit. No difference what so ever.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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:
>>>> 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/spruhl7d/spruhl7d.pdf
>>>
>>> 28.4.1.24 GPIO_DEBOUNCINGTIME Register (offset = 154h) [reset = 0h]
>>>
>>> The GPIO_DEBOUNCINGTIME register controls debouncing time (the value is
>>> global for all ports). The debouncing cell is running with the
>>> debouncing clock (32 kHz), this register represents the number of the
>>> clock cycle(s) (31 s long) to be used.
>>>
>>> Debouncing Value in 31 microsecond steps.
>>> Debouncing Value = (DEBOUNCETIME + 1) * 31 microseconds.
>>
>> DRA7xx:
>>
>> "
>> 8-bit values specifying the debouncing time. It is n-
>> periods of the muxed clock, which can come from either
>> a true 32k oscillator/pad of from the system clock. It
>> depends on which boot mode is selected. For more
>> information see Chapter 32, Initialization.
>> "
>>
>
> See
> http://www.ti.com/lit/ug/spruhz6d/spruhz6d.pdf
> 27.4.3 General-Purpose Interface Clock Configuration
> 27.4.3.1 Clocking
>
> This completely unclear. Sry, I think this patch can't be used as is,
> first of all because of backward compatibility issues.

yeah, might be. No issues, I'll just go dig older TRMs and trying to
figure this one out. Meanwhile, let's let's keep it as is.

-- 
balbi


signature.asc
Description: PGP signature

[PATCH] gpio: omap: fix debounce time calculation

[Felipe Balbi]

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(+), 7 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 56d2d026e62e..2b29fd195521 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -217,15 +217,29 @@ static void omap2_set_gpio_debounce(struct gpio_bank 
*bank, unsigned offset,
u32 val;
u32 l;
boolenable = !!debounce;
+   unsigned long   flags;
 
if (!bank->dbck_flag)
return;
 
if (enable) {
-   debounce = DIV_ROUND_UP(debounce, 31) - 1;
+   struct clk  *clk;
+   unsigned long   rate;
+
+   clk = clk_get(bank->dev, "fck");
+   if (IS_ERR(clk)) {
+   dev_err(bank->dev, "can't get clock\n");
+   return;
+   }
+
+   rate = clk_get_rate(clk);
+   clk_put(clk);
+
+   debounce = DIV_ROUND_UP(debounce, rate);
debounce &= OMAP4_GPIO_DEBOUNCINGTIME_MASK;
}
 
+   raw_spin_lock_irqsave(>lock, flags);
l = BIT(offset);
 
clk_enable(bank->dbck);
@@ -256,6 +270,7 @@ static void omap2_set_gpio_debounce(struct gpio_bank *bank, 
unsigned offset,
bank->context.debounce = debounce;
bank->context.debounce_en = val;
}
+   raw_spin_unlock_irqrestore(>lock, flags);
 }
 
 /**
@@ -1002,14 +1017,9 @@ static int omap_gpio_output(struct gpio_chip *chip, 
unsigned offset, int value)
 static int omap_gpio_debounce(struct gpio_chip *chip, unsigned offset,
  unsigned debounce)
 {
-   struct gpio_bank *bank;
-   unsigned long flags;
-
-   bank = container_of(chip, struct gpio_bank, chip);
+   struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip);
 
-   raw_spin_lock_irqsave(>lock, flags);
omap2_set_gpio_debounce(bank, offset, debounce);
-   raw_spin_unlock_irqrestore(>lock, flags);
 
return 0;
 }
-- 
2.6.2

--
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 1/2] arm: boot: dts: beaglex15: Remove ID GPIO

[Felipe Balbi]

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/am57xx-beagle-x15.dts | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 00352e761b8c..6f3a1a7ec5f9 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -560,8 +560,6 @@
extcon_usb2: tps659038_usb {
compatible = "ti,palmas-usb-vid";
ti,enable-vbus-detection;
-   ti,enable-id-detection;
-   id-gpios = < 24 GPIO_ACTIVE_HIGH>;
};
 
};
-- 
2.6.2

--
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 0/2] arm: beaglex15: fix USB Gadget

[Felipe Balbi]

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 insertion(+), 2 deletions(-)

-- 
2.6.2

--
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 2/2] arm: boot: beaglex15: pass correct interrupt

[Felipe Balbi]

According to latest schematics [1], GPIO_1/VBUSDET
on TPS659038 is tied to AM57x GPIO4_21. We can use
that as a VBUS interrupt, instead of relying on
PMIC's VBUS interrupts which don't seem to be firing
on x15 at all.

A follow up patch will add support for using this
GPIO-based 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-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 6f3a1a7ec5f9..5e47162f7883 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -560,6 +560,7 @@
extcon_usb2: tps659038_usb {
compatible = "ti,palmas-usb-vid";
ti,enable-vbus-detection;
+   interrupts-extended = < 21 IRQ_TYPE_EDGE_RISING>;
};
 
};
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Felipe Balbi]

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: pass correct interrupt

actually, one patch missing. Didn't generate it with format-patch. I'll
send as a reply to this thread.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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-palmas.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index 93c30a885740..7985d092c069 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -296,10 +296,28 @@ static int palmas_usb_probe(struct platform_device *pdev)
}
 
if (palmas_usb->enable_vbus_detection) {
+   int irq = platform_get_irq(pdev, 0);
+
+   if (irq > 0) {
+   /* remux GPIO_1 as VBUSDET */
+   status = palmas_update_bits(palmas, 
PALMAS_PU_PD_OD_BASE,
+   PALMAS_PRIMARY_SECONDARY_PAD1,
+   
PALMAS_PRIMARY_SECONDARY_PAD1_GPIO_1_MASK,
+   (1 << 3));
+   if (status < 0) {
+   dev_err(>dev, "can't remux GPIO1\n");
+   return status;
+   }
+
+   palmas_usb->vbus_irq = irq;
+   } else {
+   irq = regmap_irq_get_virq(palmas->irq_data,
+   PALMAS_VBUS_IRQ);
+   palmas_usb->vbus_irq = irq;
+   }
+
palmas_usb->vbus_otg_irq = regmap_irq_get_virq(palmas->irq_data,
   PALMAS_VBUS_OTG_IRQ);
-   palmas_usb->vbus_irq = regmap_irq_get_virq(palmas->irq_data,
-  PALMAS_VBUS_IRQ);
status = devm_request_threaded_irq(palmas_usb->dev,
palmas_usb->vbus_irq, NULL,
palmas_vbus_irq_handler,
-- 
2.6.2

--
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] arm: omap2: Kconfig: select TWD and global timer on AM43xx devices

[Felipe Balbi]

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 insertions(+)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 5076d3f334d2..bb3daf0fa7f7 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -65,6 +65,9 @@ config SOC_AM43XX
select MACH_OMAP_GENERIC
select MIGHT_HAVE_CACHE_L2X0
select HAVE_ARM_SCU
+   select HAVE_ARM_TWD
+   select ARM_GLOBAL_TIMER
+   select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
 
 config SOC_DRA7XX
bool "TI DRA7XX"
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Felipe Balbi]

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.ti.com/lit/ug/spruhl7d/spruhl7d.pdf
>
> 28.4.1.24 GPIO_DEBOUNCINGTIME Register (offset = 154h) [reset = 0h]
>
> The GPIO_DEBOUNCINGTIME register controls debouncing time (the value is
> global for all ports). The debouncing cell is running with the
> debouncing clock (32 kHz), this register represents the number of the
> clock cycle(s) (31 s long) to be used.
>
> Debouncing Value in 31 microsecond steps.
> Debouncing Value = (DEBOUNCETIME + 1) * 31 microseconds.

DRA7xx:

"
8-bit values specifying the debouncing time. It is n-
periods of the muxed clock, which can come from either
a true 32k oscillator/pad of from the system clock. It
depends on which boot mode is selected. For more
information see Chapter 32, Initialization.
"

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

From: Peter Ujfalusi <peter.ujfal...@ti.com>

McASP3 is used by default on DRA7x based boards for audio.

This fixes following error with Beagle x15:

[0.402190] platform 48468000.mcasp: Cannot lookup hwmod 'mcasp3'

which is followed by a splat:

[   11.207663] Unhandled fault: imprecise external abort (0x1406) at 0x
[   11.207670] [ cut here ]
[   11.207683] WARNING: CPU: 0 PID: 272 at 
/home/balbi/workspace/linux/drivers/bus/omap_l3_noc.c:147 
l3_interrupt_handler+0x220/0x34c()
[   11.207688] 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER2_P3 
(Read): Data Access in User mode during Functional access
[   11.207742] Modules linked in: snd_soc_simple_card(+) omapdss leds_gpio 
led_class gpio_fan extcon_usb_gpio cpufreq_dt omap_wdt phy_omap_usb2 
snd_soc_davinci_mcasp snd_soc_edma snd_soc_omap snd_soc_tlv320aic3x rtc_omap 
snd_soc_core ti_soc_thermal dwc3_omap snd_pcm_dmaengine snd_pcm extcon_palmas 
snd_timer extcon snd rtc_palmas rtc_ds1307 tmp102 palmas_pwrbutton thermal_sys 
soundcore hwmon autofs4
[   11.207748] CPU: 0 PID: 272 Comm: systemd-udevd Not tainted 
4.3.0-11482-g3d26f1f5fc82-dirty #27
[   11.207751] Hardware name: Generic DRA74X (Flattened Device Tree)
[   11.207765] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[   11.207772] [] (show_stack) from [] 
(dump_stack+0x84/0x9c)
[   11.207783] [] (dump_stack) from [] 
(warn_slowpath_common+0x78/0xb4)
[   11.207790] [] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x30/0x40)
[   11.207798] [] (warn_slowpath_fmt) from [] 
(l3_interrupt_handler+0x220/0x34c)
[   11.207805] [] (l3_interrupt_handler) from [] 
(handle_irq_event_percpu+0x44/0x1f0)
[   11.207811] [] (handle_irq_event_percpu) from [] 
(handle_irq_event+0x38/0x5c)
[   11.207818] [] (handle_irq_event) from [] 
(handle_fasteoi_irq+0xcc/0x1b0)
[   11.207824] [] (handle_fasteoi_irq) from [] 
(generic_handle_irq+0x20/0x34)
[   11.207829] [] (generic_handle_irq) from [] 
(__handle_domain_irq+0x64/0xe0)
[   11.207835] [] (__handle_domain_irq) from [] 
(gic_handle_irq+0x40/0x8c)
[   11.207842] [] (gic_handle_irq) from [] 
(__irq_usr+0x54/0x80)
[   11.207846] Exception stack(0xed143fb0 to 0xed143ff8)
[   11.207851] 3fa0: 7f69b370 7f69b368 
0370 
[   11.207857] 3fc0: b6ddb4e0 7f69b370 0016 7f69b308 be8db278 be8db2a0 
7f68b024 0001
[   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_hwmod_7xx_data.c | 41 +++
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 51d1ecb384bd..b730c582a1f7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1298,6 +1298,38 @@ static struct omap_hwmod dra7xx_mcspi4_hwmod = {
 };
 
 /*
+ * 'mcasp' class
+ *
+ */
+static struct omap_hwmod_class_sysconfig dra7xx_mcasp_sysc = {
+   .sysc_offs  = 0x0004,
+   .sysc_flags = SYSC_HAS_SIDLEMODE,
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .sysc_fields= _hwmod_sysc_type3,
+};
+
+static struct omap_hwmod_class dra7xx_mcasp_hwmod_class = {
+   .name   = "mcasp",
+   .sysc   = _mcasp_sysc,
+};
+
+/* mcasp3 */
+static struct omap_hwmod dra7xx_mcasp3_hwmod = {
+   .name   = "mcasp3",
+   .class  = _mcasp_hwmod_class,
+   .clkdm_name = "l4per2_clkdm",
+   .main_clk   = "mcasp3_ahclkx_mux",
+   .flags  = HWMOD_SWSUP_SIDLE,
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_L4PER2_MCASP3_CLKCTRL_OFFSET,
+   .context_offs = DRA7XX_RM_L4PER2_MCASP3_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_SWCTRL,
+   },
+   },
+};
+
+/*
  * 'mmc' class
  *
  */
@@ -2566,6 +2598,14 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__hdmi = 
{
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l4_per2 -> mcasp3 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per2__mcasp3 = {
+   .master = _l4_per2_hwmod,
+   .slave  = _mcasp3_hwmod,
+   .clk= "l3_iclk_div",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l4_per1 -> elm */
 static struct omap_hwmod_ocp_if dra7xx_l4_per1__elm = {
.master = _l4_per1_hwmod,
@@ -3308,6 +3348,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] 
__initdata = {
_l4_wkup__dcan1,
_l4_per2__dcan2,
_l4_per2__cpgmac0,
+   _l4_per2__mcasp3,
_gmac__mdio,
_l4_cfg__dma_system,
_l3_main_1__dss,
-- 
2.6.2

--
To unsubscribe from 

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

[Felipe Balbi]

Since commit 3fffd1283927 ("i2c: allow specifying
separate wakeup interrupt in device tree") we have
automatic wakeup irq support for i2c devices. That
commit missed the fact that rtc-1307 had its own
wakeup irq handling and ended up introducing a
kernel splat for at least Beagle x15 boards.

Fix that by reverting original commit _and_ passing
correct interrupt names on DTS so i2c-core can
choose correct IRQ as wakeup.

Now that we have automatic wakeirq support, we can
revert the original commit which did it manually.

Fixes the following warning:

[   10.346582] WARNING: CPU: 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/boot/dts/am57xx-beagle-x15.dts |  1 +
 drivers/rtc/rtc-ds1307.c| 36 +++--
 2 files changed, 4 insertions(+), 33 deletions(-)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index d9ba6b879fc1..00352e761b8c 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -604,6 +604,7 @@
reg = <0x6f>;
interrupts-extended = <_mpu GIC_SPI 2 
IRQ_TYPE_EDGE_RISING>,
  <_pmx_core 0x424>;
+   interrupt-names = "irq", "wakeup";
 
pinctrl-names = "default";
pinctrl-0 = <_pins_default>;
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index 188006c55ce0..325836818826 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -15,9 +15,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -117,7 +114,6 @@ struct ds1307 {
 #define HAS_ALARM  1   /* bit 1 == irq claimed */
struct i2c_client   *client;
struct rtc_device   *rtc;
-   int wakeirq;
s32 (*read_block_data)(const struct i2c_client *client, u8 command,
   u8 length, u8 *values);
s32 (*write_block_data)(const struct i2c_client *client, u8 command,
@@ -1146,8 +1142,6 @@ read_rtc:
}
 
if (want_irq) {
-   struct device_node *node = client->dev.of_node;
-
err = devm_request_threaded_irq(>dev,
client->irq, NULL, irq_handler,
IRQF_SHARED | IRQF_ONESHOT,
@@ -1155,34 +1149,13 @@ read_rtc:
if (err) {
client->irq = 0;
dev_err(>dev, "unable to request IRQ!\n");
-   goto no_irq;
-   }
-
-   set_bit(HAS_ALARM, >flags);
-   dev_dbg(>dev, "got IRQ %d\n", client->irq);
-
-   /* Currently supported by OF code only! */
-   if (!node)
-   goto no_irq;
-
-   err = of_irq_get(node, 1);
-   if (err <= 0) {
-   if (err == -EPROBE_DEFER)
-   goto exit;
-   goto no_irq;
-   }
-   ds1307->wakeirq = err;
+   } else {
 
-   err = dev_pm_set_dedicated_wake_irq(>dev,
-   ds1307->wakeirq);
-   if (err) {
-   dev_err(>dev, "unable to setup wakeIRQ %d!\n",
-   err);
-   goto exit;
+   set_bit(HAS_ALARM, >flags);
+   dev_dbg(>dev, "got IRQ %d\n", client->irq);
}
}
 
-no_irq:
if (chip->nvram_size) {
 
ds1307->nvram = devm_kzalloc(>dev,
@@ -1226,9 +1199,6 @@ static int ds1307_remove(struct i2c_client *client)
 {
struct ds1307 *ds1307 = i2c_get_clientdata(client);
 
-   if (ds1307->wakeirq)
-   dev_pm_clear_wake_irq(>dev);
-
if (test_and_clear_bit(HAS_NVRAM, >flags))
sysfs_remove_bin_file(>dev.kobj, ds1307->nvram);
 
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Felipe Balbi]

Hi,

Peter Ujfalusi <peter.ujfal...@ti.com> writes:
> Hi Paul, Tony,
>
> Changes since v2:
> - DTS patch added which is needed because of the clock handling changes
>
> Felip Balbi reported that linux-next is broken right now since the DTS part of
> the earlier series has been applied, but we do not have the mcasp hwmod in the
> kernel:
> ...
> [0.181029] platform 48468000.mcasp: Cannot lookup hwmod 'mcasp3'
> ...
> [6.121072] davinci-mcasp 48468000.mcasp: _od_fail_runtime_resume: FIXME: 
> missing hwmod/omap_dev info
> [6.130790] [ cut here ]
> [6.135643] WARNING: CPU: 0 PID: 244 at drivers/bus/omap_l3_noc.c:147 
> l3_interrupt_handler+0x220/0x34c()
> [6.145576] 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER2_P3 
> (Read): Data Access in User mode during Functional access
> ...
>
> This is the followup series for the hwmod changes needed to get audio working
> on DRA7xx family based boards.
> The DTS patches has been applied by Tony from the original series:
> http://www.spinics.net/lists/linux-omap/msg121473.html
>
> I have addressed your comments in the hwmod data and did some research also
> regarding to the use of ahclkx as fclk in the original submission.
> It turned out that McASP _needs_ all clocks to be enabled (fclk, iclk and
> ahclkx/r) to be able to access registers. The original patch where we handled
> the ahclkx as fclk worked, because the fclk clock got enabled in the HW w/o
> any SW interaction.
> All in all, the McASP found in DRA7 needs all clocks to be enabled.
> To satisfy this I have introduced a new flag to hwmod, which means that the
> listed optional clocks need to be handled alongside 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 today's HEAD + rtc 1307 fix. Boots fine
and I can't see the splat I was seeing with beagle x15.

Tested-by: Felipe Balbi <ba...@ti.com>

logs: http://hastebin.com/ololizojat

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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 works, it is not the correct one(s) to apply.
> https://lkml.org/lkml/2015/10/30/91
> is the series which should have been applied to 4.4.
>
> Paul acked the series, but for some reason it missed the initial ARM
> pull for 4.4

okay, cool. Hopefully Tony will apply shortly.

-- 
balbi


signature.asc
Description: PGP signature

Re: Linus HEAD build break

[Felipe Balbi]

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 linus/master ?

If it had been in next, we'd find out about it a lot sooner and avoid
the build regression. It seems author didn't build his own patch,
considering the error is clear. Here's a patch, please merge it or
provide a better version. Below has been build tested
(omap2plus_defconfig) and boot tested (am437x SK, am437x IDK, beaglebone
black) (yeah, I don't have boards which sport MADC around).

8<---

From 7af26f7123bad3e9c9dcfe9dfe9f4ad58e56f7cb Mon Sep 17 00:00:00 2001
From: Felipe Balbi <ba...@ti.com>
Date: Fri, 6 Nov 2015 08:14:45 -0600
Subject: [PATCH] ARM: dts: twl4030: fix Monitoring ADC label

commit af19161aaed7 ("ARM: dts: twl4030: Add iio
properties for bci subnode") breaks build of several
DTS files by referring to a label that doesn't
exist. Fix it.

Signed-off-by: Felipe Balbi <ba...@ti.com>
---
 arch/arm/boot/dts/twl4030.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 482b7aa37808..c8197f209efc 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -22,7 +22,7 @@
charger: bci {
compatible = "ti,twl4030-bci";
interrupts = <9>, <2>;
-   io-channels = <_madc 11>;
+   io-channels = <_madc 11>;
io-channel-name = "vac";
bci3v1-supply = <>;
};
-- 
2.6.2



-- 
balbi


signature.asc
Description: PGP signature

Re: Linus HEAD build break

[Felipe Balbi]

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 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 did post fix but Tony seems doesn't merge it:
> https://lkml.org/lkml/2015/10/13/816

looking at that thread, I have no idea how come the old version was
merged in the first place. Tony was clear that it broke build and yet
this patch has made its way to mainline and it didn't even go through
linux-next, which makes the problem worse.

Now we have a bisection point where the tree (well, some DTS files)
won't even build. This is quite messy.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

Hi,

Sebastian Reichel <s...@kernel.org> writes:
> This reverts commit af19161aaed7ff8d1a52b2e517460f2fa0774e32,
> which breaks the omap3 device tree build due to a wrong reference.
>
> I accidently queued this change via the power supply subsystem while
> telling Marek at the same time, that it should go through Tony's tree.
> Following that I did miss Stephen's messages about the build failure in
> linux-next and since he switched to merging an older snapshot nobody
> else noticed the problem in my tree. I didn't notice myself, since I
> did not build any 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.dtsi | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
> index 482b7aa37808..36ae9160b558 100644
> --- a/arch/arm/boot/dts/twl4030.dtsi
> +++ b/arch/arm/boot/dts/twl4030.dtsi
> @@ -22,8 +22,6 @@
>   charger: bci {
>   compatible = "ti,twl4030-bci";
>   interrupts = <9>, <2>;
> - io-channels = <_madc 11>;
> - io-channel-name = "vac";
>   bci3v1-supply = <>;
>   };
>  
> -- 
> 2.6.2
>

-- 
balbi


signature.asc
Description: PGP signature

Linus HEAD build break

[Felipe Balbi]

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 twl4030.dtsi because it refers to a non-existent
twl4030_madc label. Build output of make V=1 dtbs:

:1304:2: warning: #warning syscall mlock2 not implemented [-Wcpp]
ERROR (phandle_references): Reference to non-existent node or label 
"twl4030_madc"

ERROR: Input tree has errors, aborting (use -f to force output)
scripts/Makefile.lib:293: recipe for target 
'arch/arm/boot/dts/omap2430-sdp.dtb' failed
make[2]: *** [arch/arm/boot/dts/omap2430-sdp.dtb] Error 2
make[2]: *** Waiting for unfinished jobs
ERROR (phandle_references): Reference to non-existent node or label 
"twl4030_madc"

ERROR: Input tree has errors, aborting (use -f to force output)
scripts/Makefile.lib:293: recipe for target 
'arch/arm/boot/dts/omap3430-sdp.dtb' failed
make[2]: *** [arch/arm/boot/dts/omap3430-sdp.dtb] Error 2
ERROR (phandle_references): Reference to non-existent node or label 
"twl4030_madc"

ERROR (phandle_references): Reference to non-existent node or label 
"twl4030_madc"

ERROR: Input tree has errors, aborting (use -f to force output)
scripts/Makefile.lib:293: recipe for target 
'arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dtb' failed
make[2]: *** [arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dtb] Error 2
ERROR: Input tree has errors, aborting (use -f to force output)
scripts/Makefile.lib:293: recipe for target 
'arch/arm/boot/dts/omap3-beagle.dtb' failed
make[2]: *** [arch/arm/boot/dts/omap3-beagle.dtb] Error 2
ERROR (phandle_references): Reference to non-existent node or label 
"twl4030_madc"

ERROR: Input tree has errors, aborting (use -f to force output)
scripts/Makefile.lib:293: recipe for target 
'arch/arm/boot/dts/omap3-beagle-xm-ab.dtb' failed
make[2]: *** [arch/arm/boot/dts/omap3-beagle-xm-ab.dtb] Error 2
ERROR (phandle_references): Reference to non-existent node or label 
"twl4030_madc"

ERROR: Input tree has errors, aborting (use -f to force output)
scripts/Makefile.lib:293: recipe for target 
'arch/arm/boot/dts/omap3-cm-t3530.dtb' failed
make[2]: *** [arch/arm/boot/dts/omap3-cm-t3530.dtb] Error 2
ERROR (phandle_references): Reference to non-existent node or label 
"twl4030_madc"

ERROR: Input tree has errors, aborting (use -f to force output)
scripts/Makefile.lib:293: recipe for target 
'arch/arm/boot/dts/omap3-beagle-xm.dtb' failed
make[2]: *** [arch/arm/boot/dts/omap3-beagle-xm.dtb] Error 2
ERROR (phandle_references): Reference to non-existent node or label 
"twl4030_madc"

ERROR: Input tree has errors, aborting (use -f to force output)
scripts/Makefile.lib:293: recipe for target 
'arch/arm/boot/dts/omap3-devkit8000.dtb' failed
make[2]: *** [arch/arm/boot/dts/omap3-devkit8000.dtb] Error 2
ERROR (phandle_references): Reference to non-existent node or label 
"twl4030_madc"

ERROR (phandle_references): Reference to non-existent node or label 
"twl4030_madc"

ERROR: Input tree has errors, aborting (use -f to force output)
scripts/Makefile.lib:293: recipe for target 
'arch/arm/boot/dts/omap3-gta04a4.dtb' failed
make[2]: *** [arch/arm/boot/dts/omap3-gta04a4.dtb] Error 2
ERROR: Input tree has errors, aborting (use -f to force output)
scripts/Makefile.lib:293: recipe for target 
'arch/arm/boot/dts/omap3-gta04a3.dtb' failed
make[2]: *** [arch/arm/boot/dts/omap3-gta04a3.dtb] Error 2
ERROR (phandle_references): Reference to non-existent node or label 
"twl4030_madc"

ERROR (phandle_references): Reference to non-existent node or label 
"twl4030_madc"

ERROR (phandle_references): Reference to non-existent node or label 
"twl4030_madc"

ERROR: Input tree has errors, aborting (use -f to force output)
ERROR: Input tree has errors, aborting (use -f to force output)
scripts/Makefile.lib:293: recipe for target 
'arch/arm/boot/dts/omap3-evm-37xx.dtb' failed
make[2]: *** [arch/arm/boot/dts/omap3-evm-37xx.dtb] Error 2
scripts/Makefile.lib:293: recipe for target 'arch/arm/boot/dts/omap3-evm.dtb' 
failed
make[2]: *** [arch/arm/boot/dts/omap3-evm.dtb] Error 2
ERROR: Input tree has errors, aborting (use -f to force output)
scripts/Makefile.lib:293: recipe for target 
'arch/arm/boot/dts/omap3-cm-t3730.dtb' failed
make[2]: *** [arch/arm/boot/dts/omap3-cm-t3730.dtb] Error 2
ERROR (phandle_references): Reference to non-existent node or label 
"twl4030_madc"

ERROR (phandle_references): Reference to non-existent node or label 
"twl4030_madc"

ERROR: Input tree has errors, aborting (use -f to force output)
ERROR: Input tree has errors, aborting (use -f to force output)
scripts/Makefile.lib:293: recipe for target 
'arch/arm/boot/dts/omap3-gta04a5.dtb' failed
make[2]: *** [arch/arm/boot/dts/omap3-gta04a5.dtb] Error 2
scripts/Makefile.lib:293: recipe for target 
'arch/arm/boot/dts/omap3-devkit8000-lcd70.dtb' failed
make[2]: *** 

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

[Felipe Balbi]

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://pastebin.ubuntu.com/13122620/
> Reverting this patch: http://pastebin.ubuntu.com/13122621/

seems like the 32k timer isn't ticking. I don't have EPOS around, care
to confirm if that board has 32k oscillator populated ? If it doesn't,
then we should probably disable counter32k:

diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts 
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 86c2dfbe8875..e703e32b6da6 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -792,3 +792,8 @@
tx-num-evt = <32>;
rx-num-evt = <32>;
 };
+
+/* 32kHz oscillator not populated */
+ {
+   status = "disabled";
+};

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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 
>
>> ---
>>  Documentation/devicetree/bindings/spi/ti_qspi.txt | 5 +++--
>>  arch/arm/boot/dts/am4372.dtsi | 4 +++-
>>  2 files changed, 6 insertions(+), 3 deletions(-)
>> 
>> diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt 
>> b/Documentation/devicetree/bindings/spi/ti_qspi.txt
>> index f05dd631bef1..05488970060b 100644
>> --- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
>> +++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
>> @@ -17,9 +17,10 @@ Recommended properties:
>>  
>>  Example:
>>  
>> +For am4372:
>>  qspi: qspi@4b30 {
>> -compatible = "ti,dra7xxx-qspi";
>> -reg = <0x4790 0x100>, <0x3000 0x3ff>;
>> +compatible = "ti,am4372-qspi";
>> +reg = <0x4790 0x100>, <0x3000 0x400>;
>>  reg-names = "qspi_base", "qspi_mmap";
>>  #address-cells = <1>;
>>  #size-cells = <0>;

and how does the user for this look like ? Don't you need to give this a
proper 'ranges' binding ?

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

Peter Ujfalusi <peter.ujfal...@ti.com> writes:

> The eDMA3 TPTC does not need any software configuration, but it is a
> separate IP block in the SoC. In order the omap hwmod core to be able to
> handle the TPTC resources correctly in regards of PM we need to have a
> 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]

Tested-by: Felipe Balbi <ba...@ti.com>

[1] http://marc.info/?l=linux-omap=144665429032014=2

> ---
> Hi,
>
> while it would have been possible to add the edma3-tptc compatible to be 
> handled
> by the edma-tpcc driver (and when the device is tptc, do nothing) it would
> make the driver code a bit harder to follow.
> I think having separate structure for the tptc looks better and if we ever 
> need
> to have separate driver for the tptc it will be cleaner for us the separate 
> it.
>
> This patch alone w/o any hwmod flag changes will make sure that the edma-tptc 
> is
> not powered down after the kernel is finished it's booting.
>
> Regards,
> Peter
>
>  drivers/dma/edma.c | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index 31722d436a42..6b03e4e84e6b 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -269,6 +269,11 @@ static const struct of_device_id edma_of_ids[] = {
>   {}
>  };
>  
> +static const struct of_device_id edma_tptc_of_ids[] = {
> + { .compatible = "ti,edma3-tptc", },
> + {}
> +};
> +
>  static inline unsigned int edma_read(struct edma_cc *ecc, int offset)
>  {
>   return (unsigned int)__raw_readl(ecc->base + offset);
> @@ -2399,6 +2404,13 @@ static struct platform_driver edma_driver = {
>   },
>  };
>  
> +static struct platform_driver edma_tptc_driver = {
> + .driver = {
> + .name   = "edma3-tptc",
> + .of_match_table = edma_tptc_of_ids,
> + },
> +};
> +
>  bool edma_filter_fn(struct dma_chan *chan, void *param)
>  {
>   bool match = false;
> @@ -2418,6 +2430,12 @@ EXPORT_SYMBOL(edma_filter_fn);
>  
>  static int edma_init(void)
>  {
> + int ret;
> +
> + ret = platform_driver_register(_tptc_driver);
> + if (ret)
> + return ret;
> +
>   return platform_driver_register(_driver);
>  }
>  subsys_initcall(edma_init);
> @@ -2425,6 +2443,7 @@ subsys_initcall(edma_init);
>  static void __exit edma_exit(void)
>  {
>   platform_driver_unregister(_driver);
> + platform_driver_unregister(_tptc_driver);
>  }
>  module_exit(edma_exit);
>  
> -- 
> 2.6.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
balbi


signature.asc
Description: PGP signature

commit e3faf2b8826b8ac58cdaad7f801e59e389320f0e regresses AM437x SK

[Felipe Balbi]

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
reverted :  http://hastebin.com/inovevosej

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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().
>
> Sry, but why do we need to call pm_runtime_put[_sync]() here?
>
> My be just pm_runtime_disable() will be ok?

and disable with unbalanced pm_runtime_get() ?

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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 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().
>>>>>
>>>>> Sry, but why do we need to call pm_runtime_put[_sync]() here?
>>>>>
>>>>> My be just pm_runtime_disable() will be ok?
>>>>
>>>> and disable with unbalanced pm_runtime_get() ?
>>>>
>>>
>>> Which one is unbalanced pm_runtime_get()?
>>> There are no  pm_runtime_get() in probe, so there you are
>>> going to introduce unbalanced pm_runtime_put_sync() actually :(
>> 
>> look at ti_qspi_setup(). I _do_ see, however, that it calls
>> pm_runtime_put_autosuspend() in the same function; what happens if
>> driver is removed after ti_qspi_setup() runs but before
>> put_autosuspend() has time to actually run ?
>> 
>
> Seems nothing :) If I understand code in __device_release_driver()
> right: the .remove() callback will be called after
> pm_runtime_put_sync() and device should be disabled at this moment.
>
> Also, note that ti_qspi_setup() will be called for each SPI device
> attached to SPI master and further PM management of SPI master is
> performed by SPI core from __spi_pump_messages().

all right, do you want to send a patch fixing it ?

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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_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 need to call pm_runtime_put[_sync]() here?
>>>
>>> My be just pm_runtime_disable() will be ok?
>> 
>> and disable with unbalanced pm_runtime_get() ?
>> 
>
> Which one is unbalanced pm_runtime_get()?
> There are no  pm_runtime_get() in probe, so there you are
> going to introduce unbalanced pm_runtime_put_sync() actually :(

look at ti_qspi_setup(). I _do_ see, however, that it calls
pm_runtime_put_autosuspend() in the same function; what happens if
driver is removed after ti_qspi_setup() runs but before
put_autosuspend() has time to actually run ?

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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

diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index 69c1a95b0615..64318fcfacf2 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -554,16 +554,7 @@ free_master:
 
 static int ti_qspi_remove(struct platform_device *pdev)
 {
-   struct ti_qspi *qspi = platform_get_drvdata(pdev);
-   int ret;
-
-   ret = pm_runtime_get_sync(qspi->dev);
-   if (ret < 0) {
-   dev_err(qspi->dev, "pm_runtime_get_sync() failed\n");
-   return ret;
-   }
-
-   pm_runtime_put(qspi->dev);
+   pm_runtime_put_sync(>dev);
pm_runtime_disable(>dev);
 
return 0;
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Felipe Balbi]

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:03:22 -0700
>> > Subject: [PATCH] usb: musb: omap2430: Fix regression caused by driver core
>> >  change
>> >
>> > Commit ddef08dd00f5 ("Driver core: wakeup the parent device before trying
>> > probe") started automatically ensuring the parent device is enabled when
>> > the child gets probed.
>> >
>> > This however caused a regression for MUSB omap2430 interface as the
>> > runtime PM for the parent device needs the child initialized to access
>> > the MUSB hardware registers.
>> >
>> > Let's delay the enabling of PM runtime for the parent until the child
>> > has been properly initialized as suggested in an earlier patch by
>> > Grygorii Strashko <grygorii.stras...@ti.com>.
>> >
>> > In addition to delaying pm_runtime_enable, we now also need to make sure
>> > the parent is enabled during omap2430_musb_init. We also want to propagate
>> > an error from omap2430_runtime_resume if struct musb is not initialized.
>> >
>> > Note that we use pm_runtime_put_noidle here for both the child and parent
>> > to prevent an extra runtime_suspend/resume cycle.
>> >
>> > Let's also add some comments to avoid confusion between the
>> > two different devices.
>> >
>> > Fixes: ddef08dd00f5 ("Driver core: wakeup the parent device before
>> > trying probe")
>> > Suggested-by: Grygorii Strashko <grygorii.stras...@ti.com>
>> > 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>
>
> OK no response for a few days, so I'll pick this up into
> omap-for-v4.3/fixes as I have another fix there too.

all right, thanks


-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

Hi,

Tony Lindgren <t...@atomide.com> writes:
> From: Tony Lindgren <t...@atomide.com>
> Date: Fri, 23 Oct 2015 09:03:22 -0700
> Subject: [PATCH] usb: musb: omap2430: Fix regression caused by driver core
>  change
>
> Commit ddef08dd00f5 ("Driver core: wakeup the parent device before trying
> probe") started automatically ensuring the parent device is enabled when
> the child gets probed.
>
> This however caused a regression for MUSB omap2430 interface as the
> runtime PM for the parent device needs the child initialized to access
> the MUSB hardware registers.
>
> Let's delay the enabling of PM runtime for the parent until the child
> has been properly initialized as suggested in an earlier patch by
> Grygorii Strashko <grygorii.stras...@ti.com>.
>
> In addition to delaying pm_runtime_enable, we now also need to make sure
> the parent is enabled during omap2430_musb_init. We also want to propagate
> an error from omap2430_runtime_resume if struct musb is not initialized.
>
> Note that we use pm_runtime_put_noidle here for both the child and parent
> to prevent an extra runtime_suspend/resume cycle.
>
> Let's also add some comments to avoid confusion between the
> two different devices.
>
> Fixes: ddef08dd00f5 ("Driver core: wakeup the parent device before
> trying probe")
> Suggested-by: Grygorii Strashko <grygorii.stras...@ti.com>
> 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
> +++ b/drivers/usb/musb/omap2430.c
> @@ -391,9 +391,20 @@ static int omap2430_musb_init(struct musb *musb)
>   }
>   musb->isr = omap2430_musb_interrupt;
>  
> + /*
> +  * Enable runtime PM for musb parent (this driver). We can't
> +  * do it earlier as struct musb is not yet allocated and we
> +  * need to touch the musb registers for runtime PM.
> +  */
> + pm_runtime_enable(glue->dev);
> + status = pm_runtime_get_sync(glue->dev);
> + if (status < 0)
> + goto err1;
> +
>   status = pm_runtime_get_sync(dev);
>   if (status < 0) {
>   dev_err(dev, "pm_runtime_get_sync FAILED %d\n", status);
> + pm_runtime_put_sync(glue->dev);
>   goto err1;
>   }
>  
> @@ -426,6 +437,7 @@ static int omap2430_musb_init(struct musb *musb)
>   phy_power_on(musb->phy);
>  
>   pm_runtime_put_noidle(musb->controller);
> + pm_runtime_put_noidle(glue->dev);
>   return 0;
>  
>  err1:
> @@ -626,7 +638,11 @@ static int omap2430_probe(struct platform_device *pdev)
>   goto err2;
>   }
>  
> - pm_runtime_enable(>dev);
> + /*
> +  * Note that we cannot enable PM runtime yet for this
> +  * driver as we need struct musb initialized first.
> +  * See omap2430_musb_init above.
> +  */
>  
>   ret = platform_device_add(musb);
>   if (ret) {
> @@ -675,11 +691,12 @@ static int omap2430_runtime_resume(struct device *dev)
>   struct omap2430_glue*glue = dev_get_drvdata(dev);
>   struct musb *musb = glue_to_musb(glue);
>  
> - if (musb) {
> - omap2430_low_level_init(musb);
> - musb_writel(musb->mregs, OTG_INTERFSEL,
> - musb->context.otg_interfsel);
> - }
> + if (!musb)
> + return -EPROBE_DEFER;
> +
> + omap2430_low_level_init(musb);
> + musb_writel(musb->mregs, OTG_INTERFSEL,
> + musb->context.otg_interfsel);
>  
>   return 0;
>  }

-- 
balbi


signature.asc
Description: PGP signature

Regression caused by 073db4a51ee43ccb827f54a4261c0583b028d5ab

[Felipe Balbi]

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 what $commit tried to fix, of course).

More info about the regression follows, together with bisection log:

# modprobe -r m25p80
[   53.419251] 
[   53.420838] ==
[   53.427300] [ INFO: possible circular locking dependency detected ]
[   53.433865] 4.3.0-rc6 #96 Not tainted
[   53.437686] ---
[   53.444220] modprobe/372 is trying to acquire lock:
[   53.449320]  (>lock){+.+...}, at: [] 
del_mtd_blktrans_dev+0x80/0xdc
[   53.457271] 
[   53.457271] but task is already holding lock:
[   53.463372]  (mtd_table_mutex){+.+.+.}, at: [] 
del_mtd_device+0x18/0x100
[   53.471321] 
[   53.471321] which lock already depends on the new lock.
[   53.471321] 
[   53.479856] 
[   53.479856] the existing dependency chain (in reverse order) is:
[   53.487660] 
-> #1 (mtd_table_mutex){+.+.+.}:
[   53.492331][] blktrans_open+0x34/0x1a4
[   53.497879][] __blkdev_get+0xc4/0x3b0
[   53.503364][] blkdev_get+0x108/0x320
[   53.508743][] do_dentry_open+0x218/0x314
[   53.514496][] path_openat+0x4c0/0xf9c
[   53.519959][] do_filp_open+0x5c/0xc0
[   53.525336][] do_sys_open+0xfc/0x1cc
[   53.530716][] ret_fast_syscall+0x0/0x1c
[   53.536375] 
-> #0 (>lock){+.+...}:
[   53.540587][] mutex_lock_nested+0x38/0x3cc
[   53.546504][] del_mtd_blktrans_dev+0x80/0xdc
[   53.552606][] blktrans_notify_remove+0x7c/0x84
[   53.558891][] del_mtd_device+0x74/0x100
[   53.564544][] del_mtd_partitions+0x80/0xc8
[   53.570451][] mtd_device_unregister+0x24/0x48
[   53.576637][] spi_drv_remove+0x1c/0x34
[   53.582207][] __device_release_driver+0x88/0x114
[   53.588663][] device_release_driver+0x20/0x2c
[   53.594843][] bus_remove_device+0xd8/0x108
[   53.600748][] device_del+0x10c/0x210
[   53.606127][] device_unregister+0xc/0x20
[   53.611849][] __unregister+0x10/0x20
[   53.617211][] device_for_each_child+0x50/0x7c
[   53.623387][] spi_unregister_master+0x58/0x8c
[   53.629578][] release_nodes+0x15c/0x1c8
[   53.635223][] __device_release_driver+0x90/0x114
[   53.641689][] driver_detach+0xb4/0xb8
[   53.647147][] bus_remove_driver+0x4c/0xa0
[   53.652970][] SyS_delete_module+0x11c/0x1e4
[   53.658976][] ret_fast_syscall+0x0/0x1c
[   53.664621] 
[   53.664621] other info that might help us debug this:
[   53.664621] 
[   53.672979]  Possible unsafe locking scenario:
[   53.672979] 
[   53.679169]CPU0CPU1
[   53.683900]
[   53.688633]   lock(mtd_table_mutex);
[   53.692383]lock(>lock);
[   53.698306]lock(mtd_table_mutex);
[   53.704658]   lock(>lock);
[   53.707946] 
[   53.707946]  *** DEADLOCK ***
[   53.707946] 
[   53.714123] 5 locks held by modprobe/372:
[   53.718305]  #0:  (>mutex){..}, at: [] 
driver_detach+0x44/0xb8
[   53.726147]  #1:  (>mutex){..}, at: [] 
driver_detach+0x50/0xb8
[   53.733985]  #2:  (>mutex){..}, at: [] 
device_release_driver+0x18/0x2c
[   53.742541]  #3:  (mtd_partitions_mutex){+.+.+.}, at: [] 
del_mtd_partitions+0x1c/0xc8
[   53.751656]  #4:  (mtd_table_mutex){+.+.+.}, at: [] 
del_mtd_device+0x18/0x100
[   53.760048] 
[   53.760048] stack backtrace:
[   53.764591] CPU: 0 PID: 372 Comm: modprobe Not tainted 4.3.0-rc6 #96
[   53.771217] Hardware name: Generic AM43 (Flattened Device Tree)
[   53.777419] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[   53.785511] [] (show_stack) from [] 
(dump_stack+0x84/0x9c)
[   53.793063] [] (dump_stack) from [] 
(print_circular_bug+0x1c8/0x30c)
[   53.801500] [] (print_circular_bug) from [] 
(__lock_acquire+0x1a48/0x1cd8)
[   53.810480] [] (__lock_acquire) from [] 
(lock_acquire+0xac/0x12c)
[   53.818649] [] (lock_acquire) from [] 
(mutex_lock_nested+0x38/0x3cc)
[   53.827103] [] (mutex_lock_nested) from [] 
(del_mtd_blktrans_dev+0x80/0xdc)
[   53.836199] [] (del_mtd_blktrans_dev) from [] 
(blktrans_notify_remove+0x7c/0x84)
[   53.845735] [] (blktrans_notify_remove) from [] 
(del_mtd_device+0x74/0x100)
[   53.854833] [] (del_mtd_device) from [] 
(del_mtd_partitions+0x80/0xc8)
[   53.863469] [] (del_mtd_partitions) from [] 
(mtd_device_unregister+0x24/0x48)
[   53.872733] [] (mtd_device_unregister) from [] 
(spi_drv_remove+0x1c/0x34)
[   53.881633] [] (spi_drv_remove) from [] 
(__device_release_driver+0x88/0x114)
[   53.890788] [] (__device_release_driver) from [] 
(device_release_driver+0x20/0x2c)
[   53.900483] [] 

NULL pointer deref when reloading snd_soc_simple_card

[Felipe Balbi]

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 00f8
[  228.029546] pgd = ed4bc000
[  228.032375] [00f8] *pgd=
[  228.036154] Internal error: Oops: 5 [#1] SMP ARM
[  228.040968] Modules linked in: snd_soc_simple_card(+) matrix_keypad 
matrix_keymap pwm_bl xhci_plat_hcd xhci_hcd usbcore joydev m25p80 spi_nor 
lis3lv02d_i2c lis3lv02d input_polldev cpufreq_dt thermal_sys hwmon dwc3_omap 
extcon tps65218_pwrbutton omap_wdt spi_ti_qspi evdev rtc_omap leds_gpio 
led_class dwc3 udc_core usb_common omapfb cfbfillrect cfbimgblt cfbcopyarea 
panel_dpi snd_soc_tlv320aic3x snd_soc_davinci_mcasp snd_soc_edma snd_soc_omap 
snd_soc_core omapdss snd_compress snd_pcm_dmaengine snd_pcm pwm_tiecap 
snd_timer snd soundcore phy_omap_usb2 autofs4 [last unloaded: 
snd_soc_simple_card]
[  228.096008] CPU: 0 PID: 710 Comm: modprobe Not tainted 
4.3.0-rc6-1-gada6475ae6e4 #97
[  228.104436] Hardware name: Generic AM43 (Flattened Device Tree)
[  228.110608] task: ed4b9140 ti: ed52e000 task.ti: ed52e000
[  228.116370] PC is at dapm_wcache_lookup+0x50/0x7c [snd_soc_core]
[  228.122664] LR is at dapm_wcache_lookup+0x38/0x7c [snd_soc_core]
[  228.128922] pc : []lr : []psr: a0070013
[  228.128922] sp : ed52fba8  ip : 0005  fp : 
[  228.140883] r10: bf17d238  r9 : bf1f138c  r8 : bf1f616c
[  228.146327] r7 : bf1f138c  r6 : bf1f616c  r5 : ee6f5158  r4 : 00f4
[  228.153126] r3 : 0100  r2 : 0052  r1 : ed1057c1  r0 : 
[  228.159925] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  228.167354] Control: 10c5387d  Table: ad4bc059  DAC: 0051
[  228.173339] Process modprobe (pid: 710, stack limit = 0xed52e218)
[  228.179689] Stack: (0xed52fba8 to 0xed53)
[  228.184233] fba0:    ee7c58c0 bf1f6050 bf16f244 
 ed52fc28
[  228.192765] fbc0: ee577800 c1014a44  c06430d8 0001  
ee6c6e90 ee6f50a0
[  228.201294] fbe0:    c09c3354 60070013 c00943bc 
ed4b9700 0004
[  228.209835] fc00: 0004 ed4b9140 0006 bf1f138c bf1ef834 c0091884 
c063f37c ed4b9140
[  228.218365] fc20: 0001 c118a28c ed4b9140 c00919e8 ee6f506c 60070013 
ee6f5070 c063f37c
[  228.226899] fc40: 0001  bf16f430 0003 0004 ed4b9140 
0006 
[  228.235417] fc60: bf1ef834 c0091884 c0641060 bf1f138c  ee7c58c0 
0004 001b
[  228.243938] fc80: bf1f138c bf17d238  bf16f468  0012 
ee7c58c0 ee7c58c0
[  228.252463] fca0: ee6c6e90 ee6c6e90 0004 ee6c6ec0  bf1ef834 
 bf1efcec
[  228.260989] fcc0: ee7c5828  ee7c5810 ee6f5010 ee7c58c0 ee7c5858 
ed496010 bf169ef4
[  228.269506] fce0: ee6f5180 0002 0634 ee6f5010   
 
[  228.278029] fd00: ed440e0c bf16cb2c  ee6f5020 ee6f5180 bf17fd60 
0001 ee6f5028
[  228.286547] fd20: ee6f5168 60070013   3304  
ee178410 ee6f5010
[  228.295065] fd40: ed105c90 ee6f5010 ee178410 ee178410 ee178400 0001 
12f9f228 bf17968c
[  228.303583] fd60: ee6f5010 fdfb 0001 87d8 ee178410 bf0faa38 
 ee178410
[  228.312108] fd80: ee178410 ee178410 ee178410 bf0fb28c fdfb 004e 
ed060e00 c03dff28
[  228.320626] fda0: ee178410 c11be018 bf0fb28c  004e c03de5dc 
ee178410 bf0fb28c
[  228.329143] fdc0: ee178444 c098df20  c03de76c  bf0fb28c 
c03de6d8 c03dca40
[  228.337666] fde0: ee0362a4 ee179f10 bf0fb28c ed462ec0  c03ddba4 
bf0fb080 c09123a0
[  228.346188] fe00: ed060d40 bf0fb28c c09123a0 ed060d40 bf0fd000 c03defb0 
c09123a0 c09123a0
[  228.354713] fe20: ed060d40 c0009804 60070093    
000f 
[  228.363240] fe40: ef7c4464 4000 002e c0091ccc ed060e40 00d0 
00d0 c0162850
[  228.371760] fe60: ed52ff58 c0091ccc c090e108 eec0 a0070013 bf0fb300 
bf0fb300 c09c34a8
[  228.380285] fe80: ed060e40 bf0fb300 bf0fb348 0001 12f9f228 c011b55c 
ed060e08 bf0fb300
[  228.388815] fea0: ed52ff58 c09c34a8 ed060e08 c00cc6cc bf0fb30c 7fff 
 c00c9e60
[  228.397340] fec0: c119bfa4 bf0fb458 c090e990 bf0fb51c f07fa7bc bf0fb30c 
 c064c2c0
[  228.405863] fee0: f07cd000 0002d80c 02e60649  000f  
 
[  228.414388] ff00:       
 
[  228.422911] ff20:     0170  
0003 7f606ddc
[  228.431432] ff40: 017b c000f8e4 ed52e000  7f61a2e8 c00ccf24 
f07cd000 0002d80c
[  228.439952] ff60: f07fa0dc f07eebe5 f07ef600 1690 19d0  
 
[  228.448475] ff80: 002c 002d 0014 0018 000f  
7f607a28 
[  

Re: Regression caused by 073db4a51ee43ccb827f54a4261c0583b028d5ab

[Felipe Balbi]

(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, other than
> reverting $commit in HEAD (yes, that makes the problem go away, but
> regresses on what $commit tried to fix, of course).
>
> More info about the regression follows, together with bisection log:
>
> # modprobe -r m25p80
> [   53.419251] 
> [   53.420838] ==
> [   53.427300] [ INFO: possible circular locking dependency detected ]
> [   53.433865] 4.3.0-rc6 #96 Not tainted
> [   53.437686] ---
> [   53.444220] modprobe/372 is trying to acquire lock:
> [   53.449320]  (>lock){+.+...}, at: [] 
> del_mtd_blktrans_dev+0x80/0xdc
> [   53.457271] 
> [   53.457271] but task is already holding lock:
> [   53.463372]  (mtd_table_mutex){+.+.+.}, at: [] 
> del_mtd_device+0x18/0x100
> [   53.471321] 
> [   53.471321] which lock already depends on the new lock.
> [   53.471321] 
> [   53.479856] 
> [   53.479856] the existing dependency chain (in reverse order) is:
> [   53.487660] 
> -> #1 (mtd_table_mutex){+.+.+.}:
> [   53.492331][] blktrans_open+0x34/0x1a4
> [   53.497879][] __blkdev_get+0xc4/0x3b0
> [   53.503364][] blkdev_get+0x108/0x320
> [   53.508743][] do_dentry_open+0x218/0x314
> [   53.514496][] path_openat+0x4c0/0xf9c
> [   53.519959][] do_filp_open+0x5c/0xc0
> [   53.525336][] do_sys_open+0xfc/0x1cc
> [   53.530716][] ret_fast_syscall+0x0/0x1c
> [   53.536375] 
> -> #0 (>lock){+.+...}:
> [   53.540587][] mutex_lock_nested+0x38/0x3cc
> [   53.546504][] del_mtd_blktrans_dev+0x80/0xdc
> [   53.552606][] blktrans_notify_remove+0x7c/0x84
> [   53.558891][] del_mtd_device+0x74/0x100
> [   53.564544][] del_mtd_partitions+0x80/0xc8
> [   53.570451][] mtd_device_unregister+0x24/0x48
> [   53.576637][] spi_drv_remove+0x1c/0x34
> [   53.582207][] __device_release_driver+0x88/0x114
> [   53.588663][] device_release_driver+0x20/0x2c
> [   53.594843][] bus_remove_device+0xd8/0x108
> [   53.600748][] device_del+0x10c/0x210
> [   53.606127][] device_unregister+0xc/0x20
> [   53.611849][] __unregister+0x10/0x20
> [   53.617211][] device_for_each_child+0x50/0x7c
> [   53.623387][] spi_unregister_master+0x58/0x8c
> [   53.629578][] release_nodes+0x15c/0x1c8
> [   53.635223][] __device_release_driver+0x90/0x114
> [   53.641689][] driver_detach+0xb4/0xb8
> [   53.647147][] bus_remove_driver+0x4c/0xa0
> [   53.652970][] SyS_delete_module+0x11c/0x1e4
> [   53.658976][] ret_fast_syscall+0x0/0x1c
> [   53.664621] 
> [   53.664621] other info that might help us debug this:
> [   53.664621] 
> [   53.672979]  Possible unsafe locking scenario:
> [   53.672979] 
> [   53.679169]CPU0CPU1
> [   53.683900]
> [   53.688633]   lock(mtd_table_mutex);
> [   53.692383]lock(>lock);
> [   53.698306]lock(mtd_table_mutex);
> [   53.704658]   lock(>lock);
> [   53.707946] 
> [   53.707946]  *** DEADLOCK ***
> [   53.707946] 
> [   53.714123] 5 locks held by modprobe/372:
> [   53.718305]  #0:  (>mutex){..}, at: [] 
> driver_detach+0x44/0xb8
> [   53.726147]  #1:  (>mutex){..}, at: [] 
> driver_detach+0x50/0xb8
> [   53.733985]  #2:  (>mutex){..}, at: [] 
> device_release_driver+0x18/0x2c
> [   53.742541]  #3:  (mtd_partitions_mutex){+.+.+.}, at: [] 
> del_mtd_partitions+0x1c/0xc8
> [   53.751656]  #4:  (mtd_table_mutex){+.+.+.}, at: [] 
> del_mtd_device+0x18/0x100
> [   53.760048] 
> [   53.760048] stack backtrace:
> [   53.764591] CPU: 0 PID: 372 Comm: modprobe Not tainted 4.3.0-rc6 #96
> [   53.771217] Hardware name: Generic AM43 (Flattened Device Tree)
> [   53.777419] [] (unwind_backtrace) from [] 
> (show_stack+0x10/0x14)
> [   53.785511] [] (show_stack) from [] 
> (dump_stack+0x84/0x9c)
> [   53.793063] [] (dump_stack) from [] 
> (print_circular_bug+0x1c8/0x30c)
> [   53.801500] [] (print_circular_bug) from [] 
> (__lock_acquire+0x1a48/0x1cd8)
> [   53.810480] [] (__lock_acquire) from [] 
> (lock_acquire+0xac/0x12c)
> [   53.818649] [] (lock_acquire) from [] 
> (mutex_lock_nested+0x38/0x3cc)
> [   53.827103] [] (mutex_lock_nest

Re: Regression caused by 073db4a51ee43ccb827f54a4261c0583b028d5ab

[Felipe Balbi]

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,
>> 
>> 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 what $commit tried to fix, of course).
>> 
>> More info about the regression follows, together with bisection log:
>
> Not all deadlocks alleged by lockdep are true deadlocks. Are you able to
> reproduce a real deadlock? (I know, it's not always easy to hit, so I'm
> not discounting this based on lack of evidence.)
>
> In particular, I think something like this warning was mentioned
> previously, and I looked into it a bit but didn't have the time to
> figure out for sure (and figure out how to squash the potential false
> positive). Hence, I'm responding now, even if I'm not 100% sure. More
> below.
>
>> # modprobe -r m25p80
>> [   53.419251] 
>> [   53.420838] ==
>> [   53.427300] [ INFO: possible circular locking dependency detected ]
>> [   53.433865] 4.3.0-rc6 #96 Not tainted
>> [   53.437686] ---
>> [   53.444220] modprobe/372 is trying to acquire lock:
>> [   53.449320]  (>lock){+.+...}, at: [] 
>> del_mtd_blktrans_dev+0x80/0xdc
>> [   53.457271] 
>> [   53.457271] but task is already holding lock:
>> [   53.463372]  (mtd_table_mutex){+.+.+.}, at: [] 
>> del_mtd_device+0x18/0x100
>> [   53.471321] 
>> [   53.471321] which lock already depends on the new lock.
>> [   53.471321] 
>> [   53.479856] 
>> [   53.479856] the existing dependency chain (in reverse order) is:
>> [   53.487660] 
>> -> #1 (mtd_table_mutex){+.+.+.}:
>> [   53.492331][] blktrans_open+0x34/0x1a4
>> [   53.497879][] __blkdev_get+0xc4/0x3b0
>> [   53.503364][] blkdev_get+0x108/0x320
>> [   53.508743][] do_dentry_open+0x218/0x314
>> [   53.514496][] path_openat+0x4c0/0xf9c
>> [   53.519959][] do_filp_open+0x5c/0xc0
>> [   53.525336][] do_sys_open+0xfc/0x1cc
>> [   53.530716][] ret_fast_syscall+0x0/0x1c
>> [   53.536375] 
>> -> #0 (>lock){+.+...}:
>> [   53.540587][] mutex_lock_nested+0x38/0x3cc
>> [   53.546504][] del_mtd_blktrans_dev+0x80/0xdc
>> [   53.552606][] blktrans_notify_remove+0x7c/0x84
>> [   53.558891][] del_mtd_device+0x74/0x100
>> [   53.564544][] del_mtd_partitions+0x80/0xc8
>> [   53.570451][] mtd_device_unregister+0x24/0x48
>> [   53.576637][] spi_drv_remove+0x1c/0x34
>> [   53.582207][] __device_release_driver+0x88/0x114
>> [   53.588663][] device_release_driver+0x20/0x2c
>> [   53.594843][] bus_remove_device+0xd8/0x108
>> [   53.600748][] device_del+0x10c/0x210
>> [   53.606127][] device_unregister+0xc/0x20
>> [   53.611849][] __unregister+0x10/0x20
>> [   53.617211][] device_for_each_child+0x50/0x7c
>> [   53.623387][] spi_unregister_master+0x58/0x8c
>> [   53.629578][] release_nodes+0x15c/0x1c8
>> [   53.635223][] __device_release_driver+0x90/0x114
>> [   53.641689][] driver_detach+0xb4/0xb8
>> [   53.647147][] bus_remove_driver+0x4c/0xa0
>> [   53.652970][] SyS_delete_module+0x11c/0x1e4
>> [   53.658976][] ret_fast_syscall+0x0/0x1c
>
> Actually, the more I look at this, the more I think the warning is
> probably correct. I might have been thinking of a different false
> positive.
>
> Tentatively: I think the right fix might be to reverse the ordering of
> acquire/release of the mtd_table_mutex and dev->lock throughout
> mtd_blkdevs.c. See below.
>
>> [   53.664621] 
>> [   53.664621] other info that might help us debug this:
>> [   53.664621] 
>> [   53.672979]  Possible unsafe locking scenario:
>> [   53.672979] 
>> [   53.679169]CPU0CPU1
>> [   53.683900]
>> [   53.688633]   lock(mtd_table_mutex);
>> [   53.692383]lock(>lock);
>> [   53.698306]lock(mtd_table_mutex);

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

[Felipe Balbi]

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/arm/mach-omap2/board-generic.c
index fc107bdeb8ca..04a56cc04dfa 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -276,7 +276,7 @@ DT_MACHINE_START(AM43_DT, "Generic AM43 (Flattened Device 
Tree)")
.init_late  = am43xx_init_late,
.init_irq   = omap_gic_of_init,
.init_machine   = omap_generic_init,
-   .init_time  = omap3_gptimer_timer_init,
+   .init_time  = omap4_local_timer_init,
.dt_compat  = am43_boards_compat,
.restart= omap44xx_restart,
 MACHINE_END
-- 
2.6.2

--
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] clocksource: ti-32k: make it depend on GENERIC_CLOCKSOURCE

[Felipe Balbi]

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 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 98b2a9b9bfad..3a1efa3fd88d 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -117,6 +117,7 @@ config CLKSRC_PISTACHIO
 
 config CLKSRC_TI_32K
bool "Texas Instruments 32.768 Hz Clocksource" if COMPILE_TEST
+   depends on GENERIC_SCHED_CLOCK
select CLKSRC_OF if OF
help
  This option enables support for Texas Instruments 32.768 Hz 
clocksource
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Felipe Balbi]

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 Armstrong 
> ---
>  arch/arm/plat-omap/dmtimer.c | 32 ++--
>  1 file changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
> index 8ca94d3..5e8aece 100644
> --- a/arch/arm/plat-omap/dmtimer.c
> +++ b/arch/arm/plat-omap/dmtimer.c
> @@ -137,9 +137,33 @@ static int omap_dm_timer_reset(struct omap_dm_timer 
> *timer)
>   return 0;
>  }
>
> +static int omap_dm_timer_of_set_source(struct omap_dm_timer *timer)
> +{
> + int ret;
> + struct clk *parent;
> +
> + if (unlikely(!timer))
> + return -EINVAL;

IMO, let this crash. If this happens we have bigger problems.

> + if (IS_ERR(timer->fclk))
> + return -EINVAL;

We bail out if we can't get fclk, this check is unnecessary.

> + parent = clk_get(>pdev->dev, NULL);

why NULL ? You could use something more descriptive, but no strong
feelings.

> + if (IS_ERR(parent))
> + return -ENODEV;
> +
> + ret = clk_set_parent(timer->fclk, parent);
> + if (ret < 0)
> + pr_err("%s: failed to set parent\n", __func__);
> +
> + clk_put(parent);
> +
> + return ret;
> +}
> +
>  static int omap_dm_timer_prepare(struct omap_dm_timer *timer)
>  {
> - int rc;
> + int rc, ret;

doesn't seem like you need this extra 'ret' variable. Just use 'rc'.

> @@ -166,7 +190,11 @@ static int omap_dm_timer_prepare(struct omap_dm_timer 
> *timer)
>   __omap_dm_timer_enable_posted(timer);
>   omap_dm_timer_disable(timer);
>
> - return omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
> + ret = omap_dm_timer_of_set_source(timer);
> + if (ret < 0 && ret == -ENODEV)

this < 0 check is pointless if you're going to check for equality to -ENODEV

> + return omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
> +
> + return ret;
>  }
>
>  static inline u32 omap_dm_timer_reserved_systimer(int id)
> -- 
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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 driver not rely on platform
> specific functions.
>
> Cc: Grant Erickson 
> Cc: NeilBrown 
> Cc: Joachim Eastwood 
> Suggested-by: Tony Lindgren 
> Signed-off-by: Neil Armstrong 
> ---
>  .../devicetree/bindings/pwm/pwm-omap-dmtimer.txt   |  18 ++
>  drivers/pwm/Kconfig|   9 +
>  drivers/pwm/Makefile   |   1 +
>  drivers/pwm/pwm-omap-dmtimer.c | 322 
> +
>  include/linux/platform_data/pwm_omap_dmtimer.h |  69 +
>  5 files changed, 419 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt
>  create mode 100644 drivers/pwm/pwm-omap-dmtimer.c
>  create mode 100644 include/linux/platform_data/pwm_omap_dmtimer.h
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt 
> b/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt
> new file mode 100644
> index 000..7f27606
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt
> @@ -0,0 +1,18 @@
> +* OMAP PWM for dual-mode timers
> +
> +Required properties:
> +- compatible: Shall contain "ti,omap-dmtimer-pwm".
> +- ti,timers: phandle to PWM capable OMAP timer. See arm/omap/timer.txt for 
> info
> +  about these timers.
> +- #pwm-cells: Should be 3. See pwm.txt in this directory for a description of
> +  the cells format.
> +
> +Optiomal properties:
> +- ti,prescaler: Should be a value between 0 and 7, see the timers datasheet
> +
> +Example:
> + pwm: omap-pwm {
> + compatible = "ti,omap-pwm";
> + ti,timers = <>;
> + #pwm-cells = <3>;
> + };

I wonder how far are you from a generic pwm-of-timer.c. This looks
pretty close to that. You already have a pdata function pointers for
pretty much everything, all you need to do is pass a timer phandle and,
as long as the functions pointers are implemented, it should work.

You might want to get rid of pdata altogether at some point, this should
work as migration path.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

Hi Tony,

Here's the a series of timer cleanups (and a new 32k clocksource driver
which is safe to apply during v4.3 merge window. We're only missing,
now, two changes to enable TWD timer for AM437x.

All patches are also available in a branch which you can pull should you
choose. Pull request below.

The following changes since commit 049e6dde7e57f0054fdc49102e7ef4830c698b46:

  Linux 4.3-rc4 (2015-10-04 16:57:17 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git for-tony

for you to fetch changes 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 obfuscating macros
  arm: omap2: timer: add a gptimer argument to sync32k_timer_init()
  arm: omap2: timer: remove __omap_gptimer_init()
  arm: omap2: timer: provide generic sync32k_timer_init function
  arm: omap2: timer: move realtime_counter_init() around
  arm: omap2: timer: always call clocksource_of_init() when DT
  arm: omap2: timer: rename omap_sync32k_timer_init()
  clocksource: add TI 32.768 Hz counter driver
  arm: omap2+: select 32k clocksource driver
  arm: omap2: timer: limit hwmod usage to non-DT boots

 arch/arm/mach-omap2/Kconfig |   1 +
 arch/arm/mach-omap2/board-generic.c |  10 +--
 arch/arm/mach-omap2/board-ldp.c |   2 +-
 arch/arm/mach-omap2/board-rx51.c|   2 +-
 arch/arm/mach-omap2/common.h|   3 +-
 arch/arm/mach-omap2/timer.c | 162 
 drivers/clocksource/Kconfig |   7 ++
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/timer-ti-32k.c  | 126 
 9 files changed, 215 insertions(+), 99 deletions(-)
 create mode 100644 drivers/clocksource/timer-ti-32k.c

-- 
2.5.3

--
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 02/11] arm: omap2: timer: get rid of obfuscating macros

[Felipe Balbi]

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-omap2/timer.c | 70 -
 1 file changed, 43 insertions(+), 27 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 548d922cb107..23e58ea6a171 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -592,53 +592,69 @@ static inline void __init realtime_counter_init(void)
 {}
 #endif
 
-#define OMAP_SYS_GP_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop,  \
-  clksrc_nr, clksrc_src, clksrc_prop)  \
-void __init omap##name##_gptimer_timer_init(void)  \
-{  \
-   omap_clk_init();\
-   omap_dmtimer_init();\
-   omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
-   omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src, \
-   clksrc_prop);   \
+static void __init __omap_gptimer_init(int clkev_nr, const char *clkev_src,
+   const char *clkev_prop, int clksrc_nr, const char *clksrc_src,
+   const char *clksrc_prop)
+{
+   omap_clk_init();
+   omap_dmtimer_init();
+   omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
+   omap2_gptimer_clocksource_init(clksrc_nr, clksrc_src, clksrc_prop);
 }
 
-#define OMAP_SYS_32K_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop, \
-   clksrc_nr, clksrc_src, clksrc_prop) \
-void __init omap##name##_sync32k_timer_init(void)  \
-{  \
-   omap_clk_init();\
-   omap_dmtimer_init();\
-   omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
-   /* Enable the use of clocksource="gp_timer" kernel parameter */ \
-   if (use_gptimer_clksrc) \
-   omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src, \
-   clksrc_prop);   \
-   else\
-   omap2_sync32k_clocksource_init();   \
+static void __init __omap_sync32k_timer_init(int clkev_nr, const char 
*clkev_src,
+   const char *clkev_prop, int clksrc_nr, const char *clksrc_src,
+   const char *clksrc_prop)
+{
+   omap_clk_init();
+   omap_dmtimer_init();
+   omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
+
+   /* Enable the use of clocksource="gp_timer" kernel parameter */
+   if (use_gptimer_clksrc)
+   omap2_gptimer_clocksource_init(clksrc_nr, clksrc_src,
+   clksrc_prop);
+   else
+   omap2_sync32k_clocksource_init();
 }
 
 #ifdef CONFIG_ARCH_OMAP2
-OMAP_SYS_32K_TIMER_INIT(2, 1, "timer_32k_ck", "ti,timer-alwon",
+void __init omap2_sync32k_timer_init(void)
+{
+   __omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
2, "timer_sys_ck", NULL);
+}
 #endif /* CONFIG_ARCH_OMAP2 */
 
 #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
-OMAP_SYS_32K_TIMER_INIT(3, 1, "timer_32k_ck", "ti,timer-alwon",
+void __init omap3_sync32k_timer_init(void)
+{
+   __omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
2, "timer_sys_ck", NULL);
-OMAP_SYS_32K_TIMER_INIT(3_secure, 12, "secure_32k_fck", "ti,timer-secure",
+}
+
+void __init omap3_secure_sync32k_timer_init(void)
+{
+   __omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
2, "timer_sys_ck", NULL);
+}
 #endif /* CONFIG_ARCH_OMAP3 */
 
 #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
-OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL,
+void __init omap3_gptimer_timer_init(void)
+{
+   __omap_gptimer_init(2, "timer_sys_ck", NULL,
   1, "timer_sys_ck", "ti,timer-alwon");
+}
 #endif
 
 #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
-static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon",
+static void __init omap4_sync32k_timer_init(void)
+{
+   __oma

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

[Felipe Balbi]

as it turns out, __omap_gptimer_init() and
__omap_sync32k_timer_init() are essentially
the same thing, but __omap_gptimer_init() wants
to always use gptimer.

Instead of forcing all those devices to pass
a use_gptimer cmdline argument, we add a new
function argument to __omap_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.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 23e58ea6a171..f53ed049d710 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -604,14 +604,14 @@ static void __init __omap_gptimer_init(int clkev_nr, 
const char *clkev_src,
 
 static void __init __omap_sync32k_timer_init(int clkev_nr, const char 
*clkev_src,
const char *clkev_prop, int clksrc_nr, const char *clksrc_src,
-   const char *clksrc_prop)
+   const char *clksrc_prop, bool gptimer)
 {
omap_clk_init();
omap_dmtimer_init();
omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
 
/* Enable the use of clocksource="gp_timer" kernel parameter */
-   if (use_gptimer_clksrc)
+   if (use_gptimer_clksrc || gptimer)
omap2_gptimer_clocksource_init(clksrc_nr, clksrc_src,
clksrc_prop);
else
@@ -622,7 +622,7 @@ static void __init __omap_sync32k_timer_init(int clkev_nr, 
const char *clkev_src
 void __init omap2_sync32k_timer_init(void)
 {
__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
-   2, "timer_sys_ck", NULL);
+   2, "timer_sys_ck", NULL, false);
 }
 #endif /* CONFIG_ARCH_OMAP2 */
 
@@ -630,13 +630,13 @@ void __init omap2_sync32k_timer_init(void)
 void __init omap3_sync32k_timer_init(void)
 {
__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
-   2, "timer_sys_ck", NULL);
+   2, "timer_sys_ck", NULL, false);
 }
 
 void __init omap3_secure_sync32k_timer_init(void)
 {
__omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
-   2, "timer_sys_ck", NULL);
+   2, "timer_sys_ck", NULL, false);
 }
 #endif /* CONFIG_ARCH_OMAP3 */
 
@@ -653,7 +653,7 @@ void __init omap3_gptimer_timer_init(void)
 static void __init omap4_sync32k_timer_init(void)
 {
__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
-  2, "sys_clkin_ck", NULL);
+   2, "sys_clkin_ck", NULL, false);
 }
 
 void __init omap4_local_timer_init(void)
-- 
2.5.3

--
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 06/11] arm: omap2: timer: move realtime_counter_init() around

[Felipe Balbi]

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-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index ebebe1bd7237..8f2c75911179 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -476,7 +476,61 @@ static void __init omap2_gptimer_clocksource_init(int 
gptimer_id,
clocksource_gpt.name, clksrc.rate);
 }
 
-#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
+static void __init __omap_sync32k_timer_init(int clkev_nr, const char 
*clkev_src,
+   const char *clkev_prop, int clksrc_nr, const char *clksrc_src,
+   const char *clksrc_prop, bool gptimer)
+{
+   omap_clk_init();
+   omap_dmtimer_init();
+   omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
+
+   /* Enable the use of clocksource="gp_timer" kernel parameter */
+   if (use_gptimer_clksrc || gptimer)
+   omap2_gptimer_clocksource_init(clksrc_nr, clksrc_src,
+   clksrc_prop);
+   else
+   omap2_sync32k_clocksource_init();
+}
+
+void __init omap_sync32k_timer_init(void)
+{
+   __omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
+   2, "timer_sys_ck", NULL, false);
+}
+
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
+void __init omap3_secure_sync32k_timer_init(void)
+{
+   __omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
+   2, "timer_sys_ck", NULL, false);
+}
+#endif /* CONFIG_ARCH_OMAP3 */
+
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
+void __init omap3_gptimer_timer_init(void)
+{
+   __omap_sync32k_timer_init(2, "timer_sys_ck", NULL,
+   1, "timer_sys_ck", "ti,timer-alwon", true);
+}
+#endif
+
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
+   defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
+static void __init omap4_sync32k_timer_init(void)
+{
+   __omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
+   2, "sys_clkin_ck", NULL, false);
+}
+
+void __init omap4_local_timer_init(void)
+{
+   omap4_sync32k_timer_init();
+   clocksource_of_init();
+}
+#endif
+
+#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
+
 /*
  * The realtime counter also called master counter, is a free-running
  * counter, which is related to real time. It produces the count used
@@ -488,6 +542,7 @@ static void __init omap2_gptimer_clocksource_init(int 
gptimer_id,
  */
 static void __init realtime_counter_init(void)
 {
+#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
void __iomem *base;
static struct clk *sys_clk;
unsigned long rate;
@@ -586,66 +641,9 @@ sysclk1_based:
set_cntfreq();
 
iounmap(base);
-}
-#else
-static inline void __init realtime_counter_init(void)
-{}
-#endif
-
-static void __init __omap_sync32k_timer_init(int clkev_nr, const char 
*clkev_src,
-   const char *clkev_prop, int clksrc_nr, const char *clksrc_src,
-   const char *clksrc_prop, bool gptimer)
-{
-   omap_clk_init();
-   omap_dmtimer_init();
-   omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
-
-   /* Enable the use of clocksource="gp_timer" kernel parameter */
-   if (use_gptimer_clksrc || gptimer)
-   omap2_gptimer_clocksource_init(clksrc_nr, clksrc_src,
-   clksrc_prop);
-   else
-   omap2_sync32k_clocksource_init();
-}
-
-void __init omap_sync32k_timer_init(void)
-{
-   __omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
-   2, "timer_sys_ck", NULL, false);
-}
-
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
-void __init omap3_secure_sync32k_timer_init(void)
-{
-   __omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
-   2, "timer_sys_ck", NULL, false);
-}
-#endif /* CONFIG_ARCH_OMAP3 */
-
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
-void __init omap3_gptimer_timer_init(void)
-{
-   __omap_sync32k_timer_init(2, "timer_sys_ck", NULL,
-   1, "timer_sys_ck", "ti,timer-alwon", true);
-}
 #endif
-
-#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
-   defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
-static void __init omap4_sync32k_timer_init(void)
-{
-   __omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
-   

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

[Felipe Balbi]

__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>
---
 arch/arm/mach-omap2/timer.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index f53ed049d710..976ff9fa3594 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -592,16 +592,6 @@ static inline void __init realtime_counter_init(void)
 {}
 #endif
 
-static void __init __omap_gptimer_init(int clkev_nr, const char *clkev_src,
-   const char *clkev_prop, int clksrc_nr, const char *clksrc_src,
-   const char *clksrc_prop)
-{
-   omap_clk_init();
-   omap_dmtimer_init();
-   omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
-   omap2_gptimer_clocksource_init(clksrc_nr, clksrc_src, clksrc_prop);
-}
-
 static void __init __omap_sync32k_timer_init(int clkev_nr, const char 
*clkev_src,
const char *clkev_prop, int clksrc_nr, const char *clksrc_src,
const char *clksrc_prop, bool gptimer)
@@ -643,8 +633,8 @@ void __init omap3_secure_sync32k_timer_init(void)
 #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
 void __init omap3_gptimer_timer_init(void)
 {
-   __omap_gptimer_init(2, "timer_sys_ck", NULL,
-  1, "timer_sys_ck", "ti,timer-alwon");
+   __omap_sync32k_timer_init(2, "timer_sys_ck", NULL,
+   1, "timer_sys_ck", "ti,timer-alwon", true);
 }
 #endif
 
-- 
2.5.3

--
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 05/11] arm: omap2: timer: provide generic sync32k_timer_init function

[Felipe Balbi]

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 +-
 arch/arm/mach-omap2/board-rx51.c|  2 +-
 arch/arm/mach-omap2/common.h|  3 +--
 arch/arm/mach-omap2/timer.c | 10 +-
 5 files changed, 9 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 6133eaac685d..f00aa29099d4 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -46,7 +46,7 @@ DT_MACHINE_START(OMAP242X_DT, "Generic OMAP2420 (Flattened 
Device Tree)")
.map_io = omap242x_map_io,
.init_early = omap2420_init_early,
.init_machine   = omap_generic_init,
-   .init_time  = omap2_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.dt_compat  = omap242x_boards_compat,
.restart= omap2xxx_restart,
 MACHINE_END
@@ -63,7 +63,7 @@ DT_MACHINE_START(OMAP243X_DT, "Generic OMAP2430 (Flattened 
Device Tree)")
.map_io = omap243x_map_io,
.init_early = omap2430_init_early,
.init_machine   = omap_generic_init,
-   .init_time  = omap2_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.dt_compat  = omap243x_boards_compat,
.restart= omap2xxx_restart,
 MACHINE_END
@@ -82,7 +82,7 @@ DT_MACHINE_START(OMAP3_N900_DT, "Nokia RX-51 board")
.init_early = omap3430_init_early,
.init_machine   = omap_generic_init,
.init_late  = omap3_init_late,
-   .init_time  = omap3_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.dt_compat  = n900_boards_compat,
.restart= omap3xxx_restart,
 MACHINE_END
@@ -100,7 +100,7 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened Device 
Tree)")
.init_early = omap3430_init_early,
.init_machine   = omap_generic_init,
.init_late  = omap3_init_late,
-   .init_time  = omap3_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.dt_compat  = omap3_boards_compat,
.restart= omap3xxx_restart,
 MACHINE_END
@@ -116,7 +116,7 @@ DT_MACHINE_START(OMAP36XX_DT, "Generic OMAP36xx (Flattened 
Device Tree)")
.init_early = omap3630_init_early,
.init_machine   = omap_generic_init,
.init_late  = omap3_init_late,
-   .init_time  = omap3_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.dt_compat  = omap36xx_boards_compat,
.restart= omap3xxx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index c2975af4cd5d..0d3a57c6931f 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -424,6 +424,6 @@ MACHINE_START(OMAP_LDP, "OMAP LDP board")
.init_irq   = omap3_init_irq,
.init_machine   = omap_ldp_init,
.init_late  = omap3430_init_late,
-   .init_time  = omap3_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.restart= omap3xxx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 2d1e5a6beb85..830256c434ec 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -136,6 +136,6 @@ MACHINE_START(NOKIA_RX51, "Nokia RX-51 board")
.init_irq   = omap3_init_irq,
.init_machine   = rx51_init,
.init_late  = omap3430_init_late,
-   .init_time  = omap3_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.restart= omap3xxx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 92e92cfc2775..844ad031f7f0 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -88,8 +88,7 @@ static inline int omap_mux_late_init(void)
 
 extern void omap2_init_common_infrastructure(void);
 
-extern void omap2_sync32k_timer_init(void);
-extern void omap3_sync32k_timer_init(void);
+extern void omap_sync32k_timer_init(void);
 extern void omap3_secure_sync32k_timer_init(void);
 extern void omap3_gptimer_timer_init(void);
 extern void omap4_local_timer_init(void);
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 976ff9fa3594..ebebe1bd7237 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 
clkev_nr, const char *clkev_src
omap2_sync32k_clocksource_init();
 }
 
-#ifdef CONFIG_ARCH_OMAP2
-void __i

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

[Felipe Balbi]

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/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 8f2c75911179..851f3ad9e970 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -496,6 +496,9 @@ void __init omap_sync32k_timer_init(void)
 {
__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
2, "timer_sys_ck", NULL, false);
+
+   if (of_have_populated_dt())
+   clocksource_of_init();
 }
 
 #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
-- 
2.5.3

--
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 10/11] arm: omap2+: select 32k clocksource driver

[Felipe Balbi]

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 b3a0dff67e3f..dc793cc60965 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -96,6 +96,7 @@ config ARCH_OMAP2PLUS
select SOC_BUS
select TI_PRIV_EDMA
select OMAP_IRQCHIP
+   select CLKSRC_TI_32K
help
  Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
 
-- 
2.5.3

--
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 01/11] arm: omap2: timer: always define omap4_local_timer_init

[Felipe Balbi]

omap4_local_timer_init() can be used by other
platforms as is. At least AM437x wants to use
it. Instead of making omap4-only and providing
a stub for builds without OMAP4, we can just
make sure that function is always available
for all SoCs that need it.

Reported-by: Nishanth Menon <n...@ti.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/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -630,32 +630,22 @@ OMAP_SYS_32K_TIMER_INIT(3_secure, 12, "secure_32k_fck", 
"ti,timer-secure",
2, "timer_sys_ck", NULL);
 #endif /* CONFIG_ARCH_OMAP3 */
 
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) || \
-   defined(CONFIG_SOC_AM43XX)
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
 OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL,
   1, "timer_sys_ck", "ti,timer-alwon");
 #endif
 
 #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
-   defined(CONFIG_SOC_DRA7XX)
+   defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
 static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon",
   2, "sys_clkin_ck", NULL);
-#endif
 
-#ifdef CONFIG_ARCH_OMAP4
-#ifdef CONFIG_HAVE_ARM_TWD
 void __init omap4_local_timer_init(void)
 {
omap4_sync32k_timer_init();
clocksource_of_init();
 }
-#else
-void __init omap4_local_timer_init(void)
-{
-   omap4_sync32k_timer_init();
-}
-#endif /* CONFIG_HAVE_ARM_TWD */
-#endif /* CONFIG_ARCH_OMAP4 */
+#endif
 
 #if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
 void __init omap5_realtime_timer_init(void)
-- 
2.5.3

--
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 09/11] clocksource: add TI 32.768 Hz counter driver

[Felipe Balbi]

Introduce a new clocksource driver for Texas
Instruments 32.768 Hz device which is available
on most OMAP-like devices.

Cc: Daniel Lezcano <daniel.lezc...@linaro.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: linux-ker...@vger.kernel.org
Acked-by: Daniel Lezcano <daniel.lezc...@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 drivers/clocksource/timer-ti-32k.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index a7726db13abb..98b2a9b9bfad 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -115,6 +115,13 @@ config CLKSRC_PISTACHIO
bool
select CLKSRC_OF
 
+config CLKSRC_TI_32K
+   bool "Texas Instruments 32.768 Hz Clocksource" if COMPILE_TEST
+   select CLKSRC_OF if OF
+   help
+ This option enables support for Texas Instruments 32.768 Hz 
clocksource
+ available on many OMAP-like platforms.
+
 config CLKSRC_STM32
bool "Clocksource for STM32 SoCs" if !ARCH_STM32
depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 5c00863c3e33..749abc3665b3 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_VF_PIT_TIMER)+= vf_pit_timer.o
 obj-$(CONFIG_CLKSRC_QCOM)  += qcom-timer.o
 obj-$(CONFIG_MTK_TIMER)+= mtk_timer.o
 obj-$(CONFIG_CLKSRC_PISTACHIO) += time-pistachio.o
+obj-$(CONFIG_CLKSRC_TI_32K)+= timer-ti-32k.o
 
 obj-$(CONFIG_ARM_ARCH_TIMER)   += arm_arch_timer.o
 obj-$(CONFIG_ARM_GLOBAL_TIMER) += arm_global_timer.o
diff --git a/drivers/clocksource/timer-ti-32k.c 
b/drivers/clocksource/timer-ti-32k.c
new file mode 100644
index ..8518d9dfba5c
--- /dev/null
+++ b/drivers/clocksource/timer-ti-32k.c
@@ -0,0 +1,126 @@
+/**
+ * timer-ti-32k.c - OMAP2 32k Timer Support
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ *
+ * Update to use new clocksource/clockevent layers
+ * Author: Kevin Hilman, MontaVista Software, Inc. <sou...@mvista.com>
+ * Copyright (C) 2007 MontaVista Software, Inc.
+ *
+ * Original driver:
+ * Copyright (C) 2005 Nokia Corporation
+ * Author: Paul Mundt <paul.mu...@nokia.com>
+ * Juha Yrjölä <juha.yrj...@nokia.com>
+ * OMAP Dual-mode timer framework support by Timo Teras
+ *
+ * Some parts based off of TI's 24xx code:
+ *
+ * Copyright (C) 2004-2009 Texas Instruments, Inc.
+ *
+ * Roughly modelled after the OMAP1 MPU timer code.
+ * Added OMAP4 support - Santosh Shilimkar <santosh.shilim...@ti.com>
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * 32KHz clocksource ... always available, on pretty most chips except
+ * OMAP 730 and 1510.  Other timers could be used as clocksources, with
+ * higher resolution in free-running counter modes (e.g. 12 MHz xtal),
+ * but systems won't necessarily want to spend resources that way.
+ */
+
+#define OMAP2_32KSYNCNT_REV_OFF0x0
+#define OMAP2_32KSYNCNT_REV_SCHEME (0x3 << 30)
+#define OMAP2_32KSYNCNT_CR_OFF_LOW 0x10
+#define OMAP2_32KSYNCNT_CR_OFF_HIGH0x30
+
+struct ti_32k {
+   void __iomem*base;
+   void __iomem*counter;
+   struct clocksource  cs;
+};
+
+static inline struct ti_32k *to_ti_32k(struct clocksource *cs)
+{
+   return container_of(cs, struct ti_32k, cs);
+}
+
+static cycle_t ti_32k_read_cycles(struct clocksource *cs)
+{
+   struct ti_32k *ti = to_ti_32k(cs);
+
+   return (cycle_t)readl_relaxed(ti->counter);
+}
+
+static struct ti_32k ti_32k_timer = {
+   .cs = {
+   .name   = "32k_counter",
+   .rating = 250,
+   .read   = ti_32k_read_cycles,
+   .mask   = CLOCKSOURCE_MASK(32),
+   .flags  = CLOCK_SOURCE_IS_CONTINUOUS |
+   CLOCK_SOURCE_SUSPEND_NONSTOP,
+   },
+};
+
+static u64 n

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

[Felipe Balbi]

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 <ba...@ti.com>
---
 arch/arm/mach-omap2/timer.c | 33 +
 1 file changed, 13 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index d024b2bb5c4c..05c17eb2f2d9 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -183,7 +183,8 @@ static struct device_node * __init omap_get_timer_dt(const 
struct of_device_id *
  of_get_property(np, "ti,timer-secure", NULL)))
continue;
 
-   of_add_property(np, _disabled);
+   if (!of_device_is_compatible(np, "ti,omap-counter32k"))
+   of_add_property(np, _disabled);
return np;
}
 
@@ -394,7 +395,6 @@ static int __init __maybe_unused 
omap2_sync32k_clocksource_init(void)
int ret;
struct device_node *np = NULL;
struct omap_hwmod *oh;
-   void __iomem *vbase;
const char *oh_name = "counter_32k";
 
/*
@@ -420,18 +420,6 @@ static int __init __maybe_unused 
omap2_sync32k_clocksource_init(void)
 
omap_hwmod_setup_one(oh_name);
 
-   if (np) {
-   vbase = of_iomap(np, 0);
-   of_node_put(np);
-   } else {
-   vbase = omap_hwmod_get_mpu_rt_va(oh);
-   }
-
-   if (!vbase) {
-   pr_warn("%s: failed to get counter_32k resource\n", __func__);
-   return -ENXIO;
-   }
-
ret = omap_hwmod_enable(oh);
if (ret) {
pr_warn("%s: failed to enable counter_32k module (%d)\n",
@@ -439,13 +427,18 @@ static int __init __maybe_unused 
omap2_sync32k_clocksource_init(void)
return ret;
}
 
-   ret = omap_init_clocksource_32k(vbase);
-   if (ret) {
-   pr_warn("%s: failed to initialize counter_32k as a clocksource 
(%d)\n",
-   __func__, ret);
-   omap_hwmod_idle(oh);
-   }
+   if (!of_have_populated_dt()) {
+   void __iomem *vbase;
 
+   vbase = omap_hwmod_get_mpu_rt_va(oh);
+
+   ret = omap_init_clocksource_32k(vbase);
+   if (ret) {
+   pr_warn("%s: failed to initialize counter_32k as a 
clocksource (%d)\n",
+   __func__, ret);
+   omap_hwmod_idle(oh);
+   }
+   }
return ret;
 }
 
-- 
2.5.3

--
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 08/11] arm: omap2: timer: rename omap_sync32k_timer_init()

[Felipe Balbi]

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 |  2 +-
 arch/arm/mach-omap2/board-rx51.c|  2 +-
 arch/arm/mach-omap2/common.h|  2 +-
 arch/arm/mach-omap2/timer.c |  2 +-
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index f00aa29099d4..a99db5b550b7 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -46,7 +46,7 @@ DT_MACHINE_START(OMAP242X_DT, "Generic OMAP2420 (Flattened 
Device Tree)")
.map_io = omap242x_map_io,
.init_early = omap2420_init_early,
.init_machine   = omap_generic_init,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.dt_compat  = omap242x_boards_compat,
.restart= omap2xxx_restart,
 MACHINE_END
@@ -63,7 +63,7 @@ DT_MACHINE_START(OMAP243X_DT, "Generic OMAP2430 (Flattened 
Device Tree)")
.map_io = omap243x_map_io,
.init_early = omap2430_init_early,
.init_machine   = omap_generic_init,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.dt_compat  = omap243x_boards_compat,
.restart= omap2xxx_restart,
 MACHINE_END
@@ -82,7 +82,7 @@ DT_MACHINE_START(OMAP3_N900_DT, "Nokia RX-51 board")
.init_early = omap3430_init_early,
.init_machine   = omap_generic_init,
.init_late  = omap3_init_late,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.dt_compat  = n900_boards_compat,
.restart= omap3xxx_restart,
 MACHINE_END
@@ -100,7 +100,7 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened Device 
Tree)")
.init_early = omap3430_init_early,
.init_machine   = omap_generic_init,
.init_late  = omap3_init_late,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.dt_compat  = omap3_boards_compat,
.restart= omap3xxx_restart,
 MACHINE_END
@@ -116,7 +116,7 @@ DT_MACHINE_START(OMAP36XX_DT, "Generic OMAP36xx (Flattened 
Device Tree)")
.init_early = omap3630_init_early,
.init_machine   = omap_generic_init,
.init_late  = omap3_init_late,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.dt_compat  = omap36xx_boards_compat,
.restart= omap3xxx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 0d3a57c6931f..d9c3ffc39329 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -424,6 +424,6 @@ MACHINE_START(OMAP_LDP, "OMAP LDP board")
.init_irq   = omap3_init_irq,
.init_machine   = omap_ldp_init,
.init_late  = omap3430_init_late,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.restart= omap3xxx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 830256c434ec..41161ca97d74 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -136,6 +136,6 @@ MACHINE_START(NOKIA_RX51, "Nokia RX-51 board")
.init_irq   = omap3_init_irq,
.init_machine   = rx51_init,
.init_late  = omap3430_init_late,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.restart= omap3xxx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 844ad031f7f0..0cba9575d2ca 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -88,7 +88,7 @@ static inline int omap_mux_late_init(void)
 
 extern void omap2_init_common_infrastructure(void);
 
-extern void omap_sync32k_timer_init(void);
+extern void omap_init_time(void);
 extern void omap3_secure_sync32k_timer_init(void);
 extern void omap3_gptimer_timer_init(void);
 extern void omap4_local_timer_init(void);
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 851f3ad9e970..d024b2bb5c4c 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -492,7 +492,7 @@ static void __init __omap_sync32k_timer_init(int clkev_nr, 
const char *clkev_src
omap2_sync32k_clocksource_init();
 }
 
-void __init omap_sync32k_timer_init(void)
+void __init omap_init_time(void)
 {
__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
  

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

[Felipe Balbi]

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:
>>>> 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, Driver=musb-hdrc/1p, 480M
>>>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>>>>  |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
>>>>  |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M
>>>>  |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M
>>>>  |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M
>>>>  |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M
>>>>  |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M
>>>>  |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M
>>>>  |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M
>>>>  |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M
>>>>  |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M
>>>>  |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M
>>>>  |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
>>>>  |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
>>>>  |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
>>>>  |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
>>>>  |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M
>>>>  |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M
>>>>  |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M
>>>>  |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M
>
> How many EPs does each FTDI device require? at least one INT EP, right? 
> If I read it right, the topology above has 2 hubs, and 16 high-speed 
> FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT 
> EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP 
> configuration used by default. I am wondering how those devices got 
> enumerated properly.

dynamic EP allocation, but that has its own limitations.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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 <yegorsli...@googlemail.com> writes:
>>>>> On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov
>>>>> <yegorsli...@googlemail.com> 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, Driver=musb-hdrc/1p, 480M
>>>>>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>>>>>>   |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
>>>>>>   |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M
>>>>>>   |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M
>>>>>>   |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M
>>>>>>   |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M
>>>>>>   |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M
>>>>>>   |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M
>>>>>>   |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M
>>>>>>   |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M
>>>>>>   |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M
>>>>>>   |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M
>>>>>>   |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
>>>>>>   |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
>>>>>>   |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
>>>>>>   |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
>>>>>>   |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M
>>>>>>   |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M
>>>>>>   |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M
>>>>>>   |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M
>>>
>>> How many EPs does each FTDI device require? at least one INT EP, right?
>>> If I read it right, the topology above has 2 hubs, and 16 high-speed
>>> FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT
>>> EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP
>>> configuration used by default. I am wondering how those devices got
>>> enumerated properly.
>>
>> dynamic EP allocation, but that has its own limitations.
>>
> MUSB does not support dynamic EP allocation for INT/ISOCH.

I remember isoc doesn't, not sure about int. Do you remember where that
part of the code is off the top of your head ?

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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,
>>>>
>>>> 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 <yegorsli...@googlemail.com> writes:
>>>>>>>>> On Mon, Oct 12, 2015 at 11:34 AM, Yegor Yefremov
>>>>>>>>> <yegorsli...@googlemail.com> 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, Driver=musb-hdrc/1p, 480M
>>>>>>>>>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>>>>>>>>>> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
>>>>>>>>>> |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M
>>>>>>>>>> |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 
>>>>>>>>>> 12M
>>>>>>>>>> |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 
>>>>>>>>>> 480M
>>>>>>>>>> |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 
>>>>>>>>>> 480M
>>>>>>>>>> |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 
>>>>>>>>>> 480M
>>>>>>>>>> |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 
>>>>>>>>>> 480M
>>>>>>>>>> |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 
>>>>>>>>>> 480M
>>>>>>>>>> |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 
>>>>>>>>>> 480M
>>>>>>>>>> |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 
>>>>>>>>>> 480M
>>>>>>>>>> |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 
>>>>>>>>>> 480M
>>>>>>>>>> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
>>>>>>>>>> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
>>>>>>>>>> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
>>>>>>>>>> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
>>>>>>>>>> |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M
>>>>>>>>>> |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M
>>>>>>>>>> |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M
>>>>>>>>>> |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M
>>>>>>>
>>>>>>> How many EPs does each FTDI device require? at least one INT EP, right?
>>>>>>> If I read it right, the topology above has 2 hubs, and 16 high-speed
>>>>>>> FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT
>>>>>>> EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP
>>>>>>> configuration used by default. I am wondering how those devices got
>>>>>>> enumerated properly.
>>>>>>
>>>>>> dynamic EP allocation, but that has its own limitations.
>>>>>>
>>>>> MUSB does not support dynamic EP allocation for INT/ISOCH.
>>>>
>>>> I remember isoc doesn't, not sure about int. Do you remember where that
>>>> part of the code is off the top of your 

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

[Felipe Balbi]

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,
>>>>
>>>> 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:
>>>>>>>> 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, Driver=musb-hdrc/1p, 480M
>>>>>>>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>>>>>>>>|__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
>>>>>>>>|__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M
>>>>>>>>|__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M
>>>>>>>>|__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M
>>>>>>>>|__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M
>>>>>>>>|__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M
>>>>>>>>|__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M
>>>>>>>>|__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M
>>>>>>>>|__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M
>>>>>>>>|__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M
>>>>>>>>|__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M
>>>>>>>>|__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
>>>>>>>>|__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
>>>>>>>>|__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
>>>>>>>>|__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
>>>>>>>>|__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M
>>>>>>>>|__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M
>>>>>>>>|__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M
>>>>>>>>|__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M
>>>>>
>>>>> How many EPs does each FTDI device require? at least one INT EP, right?
>>>>> If I read it right, the topology above has 2 hubs, and 16 high-speed
>>>>> FTDI and 1 full-speed FTDI. So it requires at least 18 high-speed INT
>>>>> EPs. MUSB driver only has 11 high-speed EPs for mode-4 which is the EP
>>>>> configuration used by default. I am wondering how those devices got
>>>>> enumerated properly.
>>>>
>>>> dynamic EP allocation, but that has its own limitations.
>>>>
>>> MUSB does not support dynamic EP allocation for INT/ISOCH.
>>
>> I remember isoc doesn't, not sure about int. Do you remember where that
>> part of the code is off the top of your head ?
>>
>
> The MUSB EP allocation is in musb_schedule() in musb_host.c.
>
> It does not have specific policy for INT/ISOCH, but the issue is that 
> for periodic EP, it got allocated during device enumeration but freed 
> only when the device is disconnected. So practically there is no dynamic 
> EP allocation for INT/ISOCH.

This is not exactly what I can see when trying things out:

minicom.cap:56:[   90.909917] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:66:[   91.175860] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:100:[   91.697827] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 ep1in-intr, hw_ep 10, df700680/1
minicom.cap:106:[   91.818066] musb-hdrc musb-hdrc.1.auto: qh dc4eb340 urb 
df5b7e40 dev4 ep1in-intr, hw_ep 11, df5c3400/1
minicom.cap:149:[   92.475792] musb-hdrc musb-hdrc.1.auto: qh df62d240 urb 
dc4ebec0 dev3 

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

[Felipe Balbi]

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 patch adds clock definitions containing the
>>> device ID to the list in clk-3xxx.c, so the calls to clk_get() in
>>> am35x.c can succeed.
>>>
>>> Signed-off-by:  Rolf Peukert 
>>>
>>> ---
>>>   drivers/clk/ti/clk-3xxx.c | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
>>> index 8831e1a..b635deb 100644
>>> --- a/drivers/clk/ti/clk-3xxx.c
>>> +++ b/drivers/clk/ti/clk-3xxx.c
>>> @@ -507,7 +507,9 @@ static struct ti_dt_clk am35xx_clks[] = {
>>>   DT_CLK("davinci_mdio.0", NULL, "emac_fck"),
>>>   DT_CLK("vpfe-capture", "master", "vpfe_ick"),
>>>   DT_CLK("vpfe-capture", "slave", "vpfe_fck"),
>>> +DT_CLK("5c04.am35x_otg_hs", "ick", "hsotgusb_ick_am35xx"),
>>>   DT_CLK(NULL, "hsotgusb_ick", "hsotgusb_ick_am35xx"),
>>> +DT_CLK("5c04.am35x_otg_hs", "fck", "hsotgusb_fck_am35xx"),
>>>   DT_CLK(NULL, "hsotgusb_fck", "hsotgusb_fck_am35xx"),
>>>   DT_CLK(NULL, "hecc_ck", "hecc_ck"),
>>>   DT_CLK(NULL, "uart4_ick", "uart4_ick_am35xx"),
>>>
>> 
>> Adding clock aliases should be avoided, isn't there any other way to fix
>> this issue? Like adding clocks = <> references under the DT node?
>> 
>> -Tero
>> 
>
> Yes, I just tried adding the lines
>
>   clocks = <_ick_am35xx>, <_fck_am35xx>;
>   clock-names = "ick", "fck";
>
> to am3517.dtsi and this works too. But wouldn't this mean the driver
> will not work anymore in kernels without DT support?

I have this doubt myself. This will break on non-DT boots and, while
we're trying to move to DT-only, IMO meanwhile we should allow for fixes
to DT and non-DT world. Once the conversion is done, fine.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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, Driver=musb-hdrc/1p, 480M
>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
>> |__ Port 1: Dev 9, If 0, Class=, Driver=hub/4p, 480M
>> |__ Port 1: Dev 10, If 0, Class=, Driver=ftdi_sio, 12M
>> |__ Port 2: Dev 11, If 0, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 11, If 1, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 11, If 2, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 11, If 3, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 12, If 0, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 12, If 1, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 12, If 2, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 12, If 3, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 7, If 0, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 7, If 1, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 7, If 2, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 7, If 3, Class=, Driver=ftdi_sio, 480M
>>
>> When using 12 ports and performing serial test (a pair of ports is
>> connected via null-modem cable and a rather short string ca. 90
>> characters will be sent alternating at 1200 and 115200b/s, testing
>> scripts are written in Python and running as own processes per a pair
>> of ports) there are no timeouts, i.e. all sent characters will be
>> received. As soon as I open ports 13 and 14 I start to get arbitrary
>> timeouts  (from test software point of view) on all ports.
>>
>> In order to check, if ftdi_sio has primary to do with this issue, I've
>> performed the same test on a PC and PandaBoard Rev. A2 (EHCI port) and
>> there were no issues with 16 ports. So it seems to have something to
>> do with am335x + musb + number of end points.
>>
>> Any idea? Let me know, if you need our test script.
>
> From time to time I get following warnings (4.3.0-rc5):
>
> musb_host_rx 1915: RX1 dma busy, csr 2020
> musb_host_rx 1915: RX4 dma busy, csr 2020
> musb_host_rx 1915: RX7 dma busy, csr 2220
> musb_host_rx 1915: RX1 dma busy, csr 2020
>
> Though they are not timely related to serial test timeouts.

yeah, I don't think MUSB can easily handle that. IIRC, endpoint
scheduling in MUSB is rather bad. While we have enough endpoints to
handle this case, you might be running into some IP (or driver) issues.

Bin, have you ever tested this many serial devices on AM335x ?

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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, 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 patch adds clock definitions containing the
>> >>> device ID to the list in clk-3xxx.c, so the calls to clk_get() in
>> >>> am35x.c can succeed.
>> >>>
>> >>> Signed-off-by:  Rolf Peukert <rolf.peuk...@imms.de>
>> >>>
>> >>> ---
>> >>>   drivers/clk/ti/clk-3xxx.c | 2 ++
>> >>>   1 file changed, 2 insertions(+)
>> >>>
>> >>> diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
>> >>> index 8831e1a..b635deb 100644
>> >>> --- a/drivers/clk/ti/clk-3xxx.c
>> >>> +++ b/drivers/clk/ti/clk-3xxx.c
>> >>> @@ -507,7 +507,9 @@ static struct ti_dt_clk am35xx_clks[] = {
>> >>>   DT_CLK("davinci_mdio.0", NULL, "emac_fck"),
>> >>>   DT_CLK("vpfe-capture", "master", "vpfe_ick"),
>> >>>   DT_CLK("vpfe-capture", "slave", "vpfe_fck"),
>> >>> +DT_CLK("5c04.am35x_otg_hs", "ick", "hsotgusb_ick_am35xx"),
>> >>>   DT_CLK(NULL, "hsotgusb_ick", "hsotgusb_ick_am35xx"),
>> >>> +DT_CLK("5c04.am35x_otg_hs", "fck", "hsotgusb_fck_am35xx"),
>> >>>   DT_CLK(NULL, "hsotgusb_fck", "hsotgusb_fck_am35xx"),
>> >>>   DT_CLK(NULL, "hecc_ck", "hecc_ck"),
>> >>>   DT_CLK(NULL, "uart4_ick", "uart4_ick_am35xx"),
>> >>>
>> >> 
>> >> Adding clock aliases should be avoided, isn't there any other way to fix
>> >> this issue? Like adding clocks = <> references under the DT node?
>> >> 
>> >> -Tero
>> >> 
>> >
>> > Yes, I just tried adding the lines
>> >
>> >clocks = <_ick_am35xx>, <_fck_am35xx>;
>> >clock-names = "ick", "fck";
>> >
>> > to am3517.dtsi and this works too. But wouldn't this mean the driver
>> > will not work anymore in kernels without DT support?
>> 
>> I have this doubt myself. This will break on non-DT boots and, 
>> while we're trying to move to DT-only, IMO meanwhile we should
>> allow for fixes to DT and non-DT world. Once the conversion is
>> done, fine.
>
> Isn't am35xx already DT-only? The remaining omap2+ boards are both
> omap3430 based:

yeah, and this system is omap3 based, not am335x based ;-)

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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:
>> >> Rolf Peukert <rolf.peuk...@imms.de> 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 patch adds clock definitions containing 
>> >> >>> the
>> >> >>> device ID to the list in clk-3xxx.c, so the calls to clk_get() in
>> >> >>> am35x.c can succeed.
>> >> >>>
>> >> >>> Signed-off-by:  Rolf Peukert <rolf.peuk...@imms.de>
>> >> >>>
>> >> >>> ---
>> >> >>>   drivers/clk/ti/clk-3xxx.c | 2 ++
>> >> >>>   1 file changed, 2 insertions(+)
>> >> >>>
>> >> >>> diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
>> >> >>> index 8831e1a..b635deb 100644
>> >> >>> --- a/drivers/clk/ti/clk-3xxx.c
>> >> >>> +++ b/drivers/clk/ti/clk-3xxx.c
>> >> >>> @@ -507,7 +507,9 @@ static struct ti_dt_clk am35xx_clks[] = {
>> >> >>>   DT_CLK("davinci_mdio.0", NULL, "emac_fck"),
>> >> >>>   DT_CLK("vpfe-capture", "master", "vpfe_ick"),
>> >> >>>   DT_CLK("vpfe-capture", "slave", "vpfe_fck"),
>> >> >>> +DT_CLK("5c04.am35x_otg_hs", "ick", "hsotgusb_ick_am35xx"),
>> >> >>>   DT_CLK(NULL, "hsotgusb_ick", "hsotgusb_ick_am35xx"),
>> >> >>> +DT_CLK("5c04.am35x_otg_hs", "fck", "hsotgusb_fck_am35xx"),
>> >> >>>   DT_CLK(NULL, "hsotgusb_fck", "hsotgusb_fck_am35xx"),
>> >> >>>   DT_CLK(NULL, "hecc_ck", "hecc_ck"),
>> >> >>>   DT_CLK(NULL, "uart4_ick", "uart4_ick_am35xx"),
>> >> >>>
>> >> >> 
>> >> >> Adding clock aliases should be avoided, isn't there any other way to 
>> >> >> fix
>> >> >> this issue? Like adding clocks = <> references under the DT node?
>> >> >> 
>> >> >> -Tero
>> >> >> 
>> >> >
>> >> > Yes, I just tried adding the lines
>> >> >
>> >> > clocks = <_ick_am35xx>, <_fck_am35xx>;
>> >> > clock-names = "ick", "fck";
>> >> >
>> >> > to am3517.dtsi and this works too. But wouldn't this mean the driver
>> >> > will not work anymore in kernels without DT support?
>> >> 
>> >> I have this doubt myself. This will break on non-DT boots and, 
>> >> while we're trying to move to DT-only, IMO meanwhile we should
>> >> allow for fixes to DT and non-DT world. Once the conversion is
>> >> done, fine.
>> >
>> > Isn't am35xx already DT-only? The remaining omap2+ boards are both
>> > omap3430 based:
>> 
>> yeah, and this system is omap3 based, not am335x based ;-)
>
> Sure, am35xx depends on omap3 and omap3 still supports platform
> based booting because of the mentioned boards, but that does not
> mean, that am35xx also needs to support legacy booting. From what
> I can see, the last am35xx board has been removed in v4.0 [0]
> together with the am35xx platform headers.
>
> So while omap3 can still be booted the legacy way, am35xx cannot
> without modifying the kernel. Other omap3 based SoCs will initialize
> musb's omap2430 gluecode, so they are not affected.
>
> [0] 
> https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/tag/?id=omap-for-v3.20/drop-legacy-3517-v2

fair enough, that settles it. DT-only it is.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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 idle state and waits for
>>>>> an ID signal change. But on our board that never happens.
>>>>
>>>> did you route ID pin anywhere ? I hope you tied it to ground.
>>>
>>> I think so. I'll double-check that.
>> 
>> cool, thanks.
>
> The ID pin was not connected, it's tied to ground now, but still the
> same behaviour. But I can keep it from entering the musb_try_idle
> function by deactivating the vbus timeout. This can be done from
> userspace, so we don't need the additional if-statements in the code.

okay, eventually we want things to work without relying on userspace
though. For now, it should be enough to do what you're doing so we focus
on other issues.

>>> [...]
>>>>> + /* Set defaults */
>>>>> + config->num_eps = 16;
>>>>> + config->ram_bits = 12;
>>>>> + config->multipoint = true;
>>>>
>>>> all of these are board-specific.
>>>>
>>>>> +
>>>>> + bdata->interface_type = MUSB_INTERFACE_UTMI;
>>>>> + bdata->mode = MUSB_OTG;
>>>>> + bdata->power = 500;
>>>>> + bdata->extvbus = 1;
>>>>
>>>> so are these.
>
> OK, if everything is declared in the device tree, we don't need to set
> default values here.

right.

> Regarding the four am35x_... functions from omap_phy_internal.c, it's
> not easy to move them over to am35x.c.
> While they just set a few bits in some system control module registers,
> they call functions from control.c to access the SCM. The control.c
> functions are not exported either (and use some static variables and
> also local include files from mach-omap2).

yeah, there's still quite a bit left to clean up for those devices and,
unfortunately, I don't even have them available so I can't help much :-s

>>> [...]
>>>>> + phy_clk = clk_get(>dev, "hsotgusb_fck");
>>>>
>>>> why did you change the clock name ? That shouldn't be necessary.
>>>
>>> I did get "failed to get PHY clock" and "failed to get clock"
>>> messages.
>> 
>> right, this a bug elsewhere. Drivers shouldn't care about the exact
>> clock name ;-)
>> 
>
> The corresponding clock declaration seems to be in
> drivers/clk/ti/clk-3xxx.c:
>
>   DT_CLK(NULL, "hsotgusb_ick", "hsotgusb_ick_am35xx"),
>   DT_CLK(NULL, "hsotgusb_fck", "hsotgusb_fck_am35xx"),
>
> When I add two more lines there,
>
>   DT_CLK("5c04.am35x_otg_hs", "ick", "hsotgusb_ick_am35xx"),
>   DT_CLK("5c04.am35x_otg_hs", "fck", "hsotgusb_fck_am35xx"),
>
> the "ick" and "fck" clocks are found. It doesn't work without the
> address in the device name, and not with just "musb-am35x" either.

right, you need to pass the correct device name. This alone is a bug fix
worth sending. But send this two-line change as a single patch, a single
bug fix with nothing else in it.

> Still, all other device names in that file look simpler, and I'm
> wondering if I forgot a proper name declaration somewhere else?

no, you're correct. Those other devices are likely broken on DT boots
too, dunno for sure.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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 now got it working
> somehow, but I'm not sure if I'm doing it the correct way. So this post
> is not meant as a patch submission, but more as a request for comments
> or help.
>
> In the older kernel we were using before (3.2.x), some data structures
> were set up in the respective board file and then passed to the function
> am35x_probe(). For the use with DT, I added the function
> am35x_get_config, which sets up these data structures with default
> values and then tries to read settings from the DT.
> The device .compatible declaration is now "ti,am35x-musb", so it's
> separate from "ti,omap3-musb" (as used in omap2430.c).
>
> Now the two things I'm not so sure about:
>
> a) We needed to set pointers to machine-specific functions like
> am35x_musb_clear_irq etc. These functions are implemented in
> arch/arm/mach-omap2/omap_phy_internal.c, and declared in
> arch/arm/mach-omap2/usb.h.
> As this header file can't be included easily from am35x.c, I moved the
> declarations to include/linux/platform_data/usb-omap.h. I hope that's
> OK, but would be happy about suggestions.

Yeah, those functions should not be defined under arch/arm/mach-omap2,
they need to be moved to drivers/usb/musb/am35x.c. That PHY power stuff
also needs to move to some system controller driver of some sort.

> 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
> an ID signal change. But on our board that never happens.

did you route ID pin anywhere ? I hope you tied it to ground.

> So I added two checks for MUSB_OTG mode to support our hardware. Then

if your HW is host-only, why are you messing around with OTG ?

> I noticed similar code was removed from this file three years ago
> (commit 032ec49f5351e9cb242b1a1c367d14415043ab95), and I don't know if
> these lines might break something on other hardware.
>
> Best regards,
> Rolf
>
> ---
> Index: linux4/drivers/usb/musb/am35x.c
> ===
> --- linux4.orig/drivers/usb/musb/am35x.c
> +++ linux4/drivers/usb/musb/am35x.c
> @@ -188,6 +188,10 @@ static void am35x_musb_try_idle(struct m
>  {
>   static unsigned long last_timer;
>
> + /* do not try if not in OTG mode */
> + if (musb->port_mode != MUSB_OTG)
> + return;

peripheral-only and host-only configurations are valid, you should not
bail out unless OTG.

> @@ -323,8 +327,9 @@ eoi:
>   musb_writel(reg_base, USB_END_OF_INTR_REG, 0);
>   }
>
> - /* Poll for ID change */
> - if (musb->xceiv->otg->state == OTG_STATE_B_IDLE)
> + /* Poll for ID change (in OTG mode only) */
> + if (musb->port_mode == MUSB_OTG &&
> + musb->xceiv->otg->state == OTG_STATE_B_IDLE)

no, this is wrong too.

> @@ -458,6 +463,70 @@ static const struct platform_device_info
>   .dma_mask   = DMA_BIT_MASK(32),
>  };
>
> +static struct musb_hdrc_platform_data *
> +am35x_get_config(struct platform_device *pdev)
> +{
> + struct musb_hdrc_platform_data *pdata;
> + struct omap_musb_board_data *bdata;
> + struct musb_hdrc_config *config;
> + struct device_node *np;
> + int val, ret;
> +
> + pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + goto err_out;
> +
> + bdata = devm_kzalloc(>dev, sizeof(*bdata), GFP_KERNEL);
> + if (!bdata)
> + goto err_pdata;
> +
> + config = devm_kzalloc(>dev, sizeof(*config), GFP_KERNEL);
> + if (!config)
> + goto err_bdata;
> +
> + /* Set defaults */
> + config->num_eps = 16;
> + config->ram_bits = 12;
> + config->multipoint = true;

all of these are board-specific.

> +
> + bdata->interface_type = MUSB_INTERFACE_UTMI;
> + bdata->mode = MUSB_OTG;
> + bdata->power = 500;
> + bdata->extvbus = 1;

so are these.

> + bdata->set_phy_power = am35x_musb_phy_power;
> + bdata->clear_irq = am35x_musb_clear_irq;
> + bdata->set_mode = am35x_set_mode;
> + bdata->reset = am35x_musb_reset;
> +
> + pdata->mode = MUSB_OTG;
> + pdata->power = 250;

also mode and power.

> + pdata->board_data = bdata;
> + pdata->config = config;
> +
> + /* Read settings from device tree */
> + np = pdev->dev.of_node;
> + if (np) {
> + of_property_read_u32(np, "mode", (u32 *)>mode);
> + of_property_read_u32(np, "interface-type",
> + (u32 *)>interface_type);
> + of_property_read_u32(np, "num-eps", (u32 *)>num_eps);
> + of_property_read_u32(np, "ram-bits", (u32 *)>ram_bits);
> + 

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

[Felipe Balbi]

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 that should not be needed for the 32k counter. We should be able
> to do everything we want with CLOCK_SOURCE_SUSPEND_NONSTOP for the
> 32k counter.
>
> We still need ti,timer-alwon for a while for gptimers 1 and 12 as
> they are the only ones in the always-on domain. I guess that need
> will eventually go away too once we have a proper interconnect
> driver and are using genpd.

cool, thanks. I'll try to respin this series, hopefully still this week.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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:
>>>
>>> Hi,
>>>
>>> Belisko Marek <marek.beli...@gmail.com> 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 I get error:
>>>> failed to init cpufreq table: -61
>>>>
>>>> I did small investigation and seem that dev_pm_opp_init_cpufreq_table
>>>> fails at first condition dev_pm_opp_get_opp_count <= 0 and this is
>>>> because opp_list is empty. So it seems that any opp for am33xx aren't
>>>> defined if I'm getting it right. I did look to mach-omap2/opp3xxx_data
>>>> but there is nothing am33xx specific. It is known problem or exist
>>>> some patches around to fix that? Many thanks.
>>>
>>> OPP initialization is not in mainline yet, there are some out-of-tree
>>> patches which TI has been working on. If you want to use them, have a
>>> look at TI's vendor kernel at [1]
>> Thanks for link. One thing which is still not puzzled before I use 3.9
>> kernel and it was working fine
>> it's stops working when bumped to 4.1.
>
> Sorry information was incorrect. On 3.9 kernel we did use tps, pmic
> now we have only gpio regulator so this is the difference.

okay, if it's only a regulator how can you set different voltages ?
Seems like you won't be able to do anything more than enable/disable a
voltage rail.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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.
>
> Great. Is this safe to appy on it's own? We are not getting
> system timers re-inited to the default values?

not that I could notice. I booted on BBB and AM4. If you give me a few
minutes I can boot again and save console logs for reference.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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: Felipe Balbi <ba...@ti.com>
>
> Hi Felipe,
>
> With the couple of nits below fixed, you can my:
>
> Acked-by: Daniel Lezcano <daniel.lezc...@linaro.org>
>
> [ ... ]
>
>> +#define OMAP2_32KSYNCNT_REV_OFF 0x0
>> +#define OMAP2_32KSYNCNT_REV_SCHEME  (0x3 << 30)
>> +#define OMAP2_32KSYNCNT_CR_OFF_LOW  0x10
>> +#define OMAP2_32KSYNCNT_CR_OFF_HIGH 0x30
>> +
>> +struct ti_32k {
>> +void __iomem*base;
>> +void __iomem*counter;
>> +struct clocksource  cs;
>> +};
>> +#define to_ti_32k(cs)   (container_of((cs), struct ti_32k, cs))
>
> Usually a static inline is used instead of a macro for that.

not so true and also completely unnecessary, considering container_of()
already type safety ;-)

Try this:

$ git grep -e "#define.*container_of" | wc -l

no strong feelings though. I tend to prefer a macro to wrap
container_of() but won't go into an argument

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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 
>> clkev_nr, const char *clkev_src
>>  omap2_sync32k_clocksource_init();
>>  }
>>  
>> -#ifdef CONFIG_ARCH_OMAP2
>> -void __init omap2_sync32k_timer_init(void)
>> +void __init omap_sync32k_timer_init(void)
>>  {
>>  __omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
>>  2, "timer_sys_ck", NULL, false);
>>  }
>> -#endif /* CONFIG_ARCH_OMAP2 */
>>  
>>  #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
>> -void __init omap3_sync32k_timer_init(void)
>> -{
>> -__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
>> -2, "timer_sys_ck", NULL, false);
>> -}
>> -
>>  void __init omap3_secure_sync32k_timer_init(void)
>>  {
>>  __omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
>> @@ -640,15 +632,9 @@ void __init omap3_gptimer_timer_init(void)
>>  
>>  #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
>>  defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
>> -static void __init omap4_sync32k_timer_init(void)
>> -{
>> -__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
>> -2, "sys_clkin_ck", NULL, false);
>> -}
>> -
>>  void __init omap4_local_timer_init(void)
>>  {
>> -omap4_sync32k_timer_init();
>> +omap_sync32k_timer_init();
>
> Hmm, this is changing the parent clock source for the timer from
> sys_clkin_ck to timer_sys_ck for OMAP4 and OMAP5 below. I am not sure of
> the history behind the parent source, but is this what you intended to
> do here.

good catch. I'll fix this for next revision

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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 I get error:
> failed to init cpufreq table: -61
>
> I did small investigation and seem that dev_pm_opp_init_cpufreq_table
> fails at first condition dev_pm_opp_get_opp_count <= 0 and this is
> because opp_list is empty. So it seems that any opp for am33xx aren't
> defined if I'm getting it right. I did look to mach-omap2/opp3xxx_data
> but there is nothing am33xx specific. It is known problem or exist
> some patches around to fix that? Many thanks.

OPP initialization is not in mainline yet, there are some out-of-tree
patches which TI has been working on. If you want to use them, have a
look at TI's vendor kernel at [1]

[1] 
http://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-lsk-linux-4.1.y/arch/arm/mach-omap2/opp33xx_data.c

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

as it turns out, __omap_gptimer_init() and
__omap_sync32k_timer_init() are essentially
the same thing, but __omap_gptimer_init() wants
to always use gptimer.

Instead of forcing all those devices to pass
a use_gptimer cmdline argument, we add a new
function argument to __omap_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.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 23e58ea6a171..f53ed049d710 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -604,14 +604,14 @@ static void __init __omap_gptimer_init(int clkev_nr, 
const char *clkev_src,
 
 static void __init __omap_sync32k_timer_init(int clkev_nr, const char 
*clkev_src,
const char *clkev_prop, int clksrc_nr, const char *clksrc_src,
-   const char *clksrc_prop)
+   const char *clksrc_prop, bool gptimer)
 {
omap_clk_init();
omap_dmtimer_init();
omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
 
/* Enable the use of clocksource="gp_timer" kernel parameter */
-   if (use_gptimer_clksrc)
+   if (use_gptimer_clksrc || gptimer)
omap2_gptimer_clocksource_init(clksrc_nr, clksrc_src,
clksrc_prop);
else
@@ -622,7 +622,7 @@ static void __init __omap_sync32k_timer_init(int clkev_nr, 
const char *clkev_src
 void __init omap2_sync32k_timer_init(void)
 {
__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
-   2, "timer_sys_ck", NULL);
+   2, "timer_sys_ck", NULL, false);
 }
 #endif /* CONFIG_ARCH_OMAP2 */
 
@@ -630,13 +630,13 @@ void __init omap2_sync32k_timer_init(void)
 void __init omap3_sync32k_timer_init(void)
 {
__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
-   2, "timer_sys_ck", NULL);
+   2, "timer_sys_ck", NULL, false);
 }
 
 void __init omap3_secure_sync32k_timer_init(void)
 {
__omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
-   2, "timer_sys_ck", NULL);
+   2, "timer_sys_ck", NULL, false);
 }
 #endif /* CONFIG_ARCH_OMAP3 */
 
@@ -653,7 +653,7 @@ void __init omap3_gptimer_timer_init(void)
 static void __init omap4_sync32k_timer_init(void)
 {
__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
-  2, "sys_clkin_ck", NULL);
+   2, "sys_clkin_ck", NULL, false);
 }
 
 void __init omap4_local_timer_init(void)
-- 
2.5.3

--
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 11/11] arm: omap2: timer: limit hwmod usage to non-DT boots

[Felipe Balbi]

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 <ba...@ti.com>
---
 arch/arm/mach-omap2/timer.c | 33 +
 1 file changed, 13 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 01452cb190cb..7c1b13fee68f 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -183,7 +183,8 @@ static struct device_node * __init omap_get_timer_dt(const 
struct of_device_id *
  of_get_property(np, "ti,timer-secure", NULL)))
continue;
 
-   of_add_property(np, _disabled);
+   if (!of_device_is_compatible(np, "ti,omap-counter32k"))
+   of_add_property(np, _disabled);
return np;
}
 
@@ -394,7 +395,6 @@ static int __init __maybe_unused 
omap2_sync32k_clocksource_init(void)
int ret;
struct device_node *np = NULL;
struct omap_hwmod *oh;
-   void __iomem *vbase;
const char *oh_name = "counter_32k";
 
/*
@@ -420,18 +420,6 @@ static int __init __maybe_unused 
omap2_sync32k_clocksource_init(void)
 
omap_hwmod_setup_one(oh_name);
 
-   if (np) {
-   vbase = of_iomap(np, 0);
-   of_node_put(np);
-   } else {
-   vbase = omap_hwmod_get_mpu_rt_va(oh);
-   }
-
-   if (!vbase) {
-   pr_warn("%s: failed to get counter_32k resource\n", __func__);
-   return -ENXIO;
-   }
-
ret = omap_hwmod_enable(oh);
if (ret) {
pr_warn("%s: failed to enable counter_32k module (%d)\n",
@@ -439,13 +427,18 @@ static int __init __maybe_unused 
omap2_sync32k_clocksource_init(void)
return ret;
}
 
-   ret = omap_init_clocksource_32k(vbase);
-   if (ret) {
-   pr_warn("%s: failed to initialize counter_32k as a clocksource 
(%d)\n",
-   __func__, ret);
-   omap_hwmod_idle(oh);
-   }
+   if (!of_have_populated_dt()) {
+   void __iomem *vbase;
 
+   vbase = omap_hwmod_get_mpu_rt_va(oh);
+
+   ret = omap_init_clocksource_32k(vbase);
+   if (ret) {
+   pr_warn("%s: failed to initialize counter_32k as a 
clocksource (%d)\n",
+   __func__, ret);
+   omap_hwmod_idle(oh);
+   }
+   }
return ret;
 }
 
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Felipe Balbi]

Hi,

Suman Anna <s-a...@ti.com> writes:
>>>>> On 10/05/2015 02:48 PM, Balbi, Felipe wrote:
>>>>>> We actually want these devices to be created because
>>>>>> we will be moving timers to drivers/clocksource and
>>>>>> this will prevent them from probing.
>>>>>
>>>>> This logic is also used to remove the secure timer from being
>>>>> registered to the kernel on HS devices, while allowing the timer to be
>>>>> available on GP devices. Your patch actually would break that
>>>>> functionality. I suggest that you look at the history of the code that
>>>>
>>>> heh, that's a silly way of doing so. Could just detect if we're running
>>>> on HS or not.
>>>
>>> This function is invoked only after detecting that we are running on a
>>> HS device.
>> 
>> What actually disables the timer is omap_get_timer_dt() and that's
>> called in more than one place.
>
> Yes indeed, and this patch is changing the behavior of
> omap_get_timer_dt(), so you have to check all call-sites. Also, one
> another thing is that this trick was used for DT boots so that the
> timers used for clocksource and clockevent are eliminated from the
> omap_dm_timer_request() API. The legacy boot used a specific API to mark
> those as reserved so that the _request API does 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 32k
only and keeping it enabled so drivers/clocksource/ can use it.

>>>>>> Signed-off-by: Felipe Balbi <ba...@ti.com>
>>>>>> ---
>>>>>>
>>>>>> Tony, I wonder if you can get merged as a fix, or do you
>>>>>> prefer receiving it together with my timer series ?
>>>>>
>>>>> NAK for rc, as it breaks other stuff.
>>>>
>>>> a single stuff which is likely easy enough to fix. But fair enough
>>>
>>> Don't think this patch is fixing any critical bug either, better to club
>>> it with your cleanup series.
>> 
>> it is kinda critical when you consider that the timer is disabled
>> outside of the soc type detection.
>
> This has been like this since DMTimer is converted to DT (from 3.8
> kernel), and is a need for your counter32k clocksource series. The
> problem seems to stem from the reuse of omap_get_timer_dt for counter32k
> nodes. A better solution would be to remove the omap_get_timer_dt() from
> omap2_sync32k_clocksource_init() code and just replace it with
> of_find_compatible_node - you seem to be limiting the majority of that
> function to legacy mode in Patch 10 of your RFC series anyways.

I still need omap_hwmod_enable() to be called, that's why it's still
used. I don't think replacing it with of_find_compatible_node() will buy
us much, we will still need to check for of_device_is_available()
anyway. Sure we skip all the timer flags (alwon, dsp, pwm, secure), but
that really isn't big deal.

When converting gptimer to clocksource, then I'll look at what I can do
for the timer request side of things. For now, things are working,
apparently without regressions (or at least I couldn't catch any so far)
and it seems clean enough that it could possibly be queued for v4.4
merge window. For v4.5 I'll look at this again and try to figure out how
to handle gptimer.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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 Tue, Oct 6, 2015 at 4:00 PM, Felipe Balbi <ba...@ti.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Belisko Marek <marek.beli...@gmail.com> 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 I get error:
>>>>> failed to init cpufreq table: -61
>>>>>
>>>>> I did small investigation and seem that dev_pm_opp_init_cpufreq_table
>>>>> fails at first condition dev_pm_opp_get_opp_count <= 0 and this is
>>>>> because opp_list is empty. So it seems that any opp for am33xx aren't
>>>>> defined if I'm getting it right. I did look to mach-omap2/opp3xxx_data
>>>>> but there is nothing am33xx specific. It is known problem or exist
>>>>> some patches around to fix that? Many thanks.
>>>>
>>>> OPP initialization is not in mainline yet, there are some out-of-tree
>>>> patches which TI has been working on. If you want to use them, have a
>>>> look at TI's vendor kernel at [1]
>>> Thanks for link. One thing which is still not puzzled before I use 3.9
>>> kernel and it was working fine
>>> it's stops working when bumped to 4.1.
>>
>> Sorry information was incorrect. On 3.9 kernel we did use tps, pmic
>> now we have only gpio regulator so this is the difference.
>
> okay, if it's only a regulator how can you set different voltages ?
   ^
   GPIO, rather


> Seems like you won't be able to do anything more than enable/disable a
> voltage rail.
>
> -- 
> balbi

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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-ldp.c |  2 +-
 arch/arm/mach-omap2/board-rx51.c|  2 +-
 arch/arm/mach-omap2/common.h|  2 +-
 arch/arm/mach-omap2/timer.c |  4 ++--
 5 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 20d5e82ab6ee..e51fb8245704 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -46,7 +46,7 @@ DT_MACHINE_START(OMAP242X_DT, "Generic OMAP2420 (Flattened 
Device Tree)")
.map_io = omap242x_map_io,
.init_early = omap2420_init_early,
.init_machine   = omap_generic_init,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.dt_compat  = omap242x_boards_compat,
.restart= omap2xxx_restart,
 MACHINE_END
@@ -63,7 +63,7 @@ DT_MACHINE_START(OMAP243X_DT, "Generic OMAP2430 (Flattened 
Device Tree)")
.map_io = omap243x_map_io,
.init_early = omap2430_init_early,
.init_machine   = omap_generic_init,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.dt_compat  = omap243x_boards_compat,
.restart= omap2xxx_restart,
 MACHINE_END
@@ -82,7 +82,7 @@ DT_MACHINE_START(OMAP3_N900_DT, "Nokia RX-51 board")
.init_early = omap3430_init_early,
.init_machine   = omap_generic_init,
.init_late  = omap3_init_late,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.dt_compat  = n900_boards_compat,
.restart= omap3xxx_restart,
 MACHINE_END
@@ -100,7 +100,7 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened Device 
Tree)")
.init_early = omap3430_init_early,
.init_machine   = omap_generic_init,
.init_late  = omap3_init_late,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.dt_compat  = omap3_boards_compat,
.restart= omap3xxx_restart,
 MACHINE_END
@@ -116,7 +116,7 @@ DT_MACHINE_START(OMAP36XX_DT, "Generic OMAP36xx (Flattened 
Device Tree)")
.init_early = omap3630_init_early,
.init_machine   = omap_generic_init,
.init_late  = omap3_init_late,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.dt_compat  = omap36xx_boards_compat,
.restart= omap3xxx_restart,
 MACHINE_END
@@ -228,7 +228,7 @@ DT_MACHINE_START(OMAP4_DT, "Generic OMAP4 (Flattened Device 
Tree)")
.init_irq   = omap_gic_of_init,
.init_machine   = omap_generic_init,
.init_late  = omap4430_init_late,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.dt_compat  = omap4_boards_compat,
.restart= omap44xx_restart,
 MACHINE_END
@@ -272,7 +272,7 @@ DT_MACHINE_START(AM43_DT, "Generic AM43 (Flattened Device 
Tree)")
.init_late  = am43xx_init_late,
.init_irq   = omap_gic_of_init,
.init_machine   = omap_generic_init,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.dt_compat  = am43_boards_compat,
.restart= omap44xx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index 0d3a57c6931f..d9c3ffc39329 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -424,6 +424,6 @@ MACHINE_START(OMAP_LDP, "OMAP LDP board")
.init_irq   = omap3_init_irq,
.init_machine   = omap_ldp_init,
.init_late  = omap3430_init_late,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.restart= omap3xxx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 830256c434ec..41161ca97d74 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -136,6 +136,6 @@ MACHINE_START(NOKIA_RX51, "Nokia RX-51 board")
.init_irq   = omap3_init_irq,
.init_machine   = rx51_init,
.init_late  = omap3430_init_late,
-   .init_time  = omap_sync32k_timer_init,
+   .init_time  = omap_init_time,
.restart= omap3xxx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index bf42fc4e78f4..e1e274334290 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm

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

[Felipe Balbi]

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-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index d14e25b2d7a4..dcc0f032e717 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -476,7 +476,55 @@ static void __init omap2_gptimer_clocksource_init(int 
gptimer_id,
clocksource_gpt.name, clksrc.rate);
 }
 
-#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
+static void __init __omap_sync32k_timer_init(int clkev_nr, const char 
*clkev_src,
+   const char *clkev_prop, int clksrc_nr, const char *clksrc_src,
+   const char *clksrc_prop, bool gptimer)
+{
+   omap_clk_init();
+   omap_dmtimer_init();
+   omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
+
+   /* Enable the use of clocksource="gp_timer" kernel parameter */
+   if (use_gptimer_clksrc || gptimer)
+   omap2_gptimer_clocksource_init(clksrc_nr, clksrc_src,
+   clksrc_prop);
+   else
+   omap2_sync32k_clocksource_init();
+}
+
+void __init omap_sync32k_timer_init(void)
+{
+   __omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
+   2, "timer_sys_ck", NULL, false);
+}
+
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
+void __init omap3_secure_sync32k_timer_init(void)
+{
+   __omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
+   2, "timer_sys_ck", NULL, false);
+}
+#endif /* CONFIG_ARCH_OMAP3 */
+
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
+void __init omap3_gptimer_timer_init(void)
+{
+   __omap_sync32k_timer_init(2, "timer_sys_ck", NULL,
+   1, "timer_sys_ck", "ti,timer-alwon", true);
+}
+#endif
+
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
+   defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
+void __init omap4_local_timer_init(void)
+{
+   omap_sync32k_timer_init();
+   clocksource_of_init();
+}
+#endif
+
+#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
+
 /*
  * The realtime counter also called master counter, is a free-running
  * counter, which is related to real time. It produces the count used
@@ -488,6 +536,7 @@ static void __init omap2_gptimer_clocksource_init(int 
gptimer_id,
  */
 static void __init realtime_counter_init(void)
 {
+#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
void __iomem *base;
static struct clk *sys_clk;
unsigned long rate;
@@ -586,60 +635,9 @@ sysclk1_based:
set_cntfreq();
 
iounmap(base);
-}
-#else
-static inline void __init realtime_counter_init(void)
-{}
 #endif
-
-static void __init __omap_sync32k_timer_init(int clkev_nr, const char 
*clkev_src,
-   const char *clkev_prop, int clksrc_nr, const char *clksrc_src,
-   const char *clksrc_prop, bool gptimer)
-{
-   omap_clk_init();
-   omap_dmtimer_init();
-   omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
-
-   /* Enable the use of clocksource="gp_timer" kernel parameter */
-   if (use_gptimer_clksrc || gptimer)
-   omap2_gptimer_clocksource_init(clksrc_nr, clksrc_src,
-   clksrc_prop);
-   else
-   omap2_sync32k_clocksource_init();
-}
-
-void __init omap_sync32k_timer_init(void)
-{
-   __omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
-   2, "timer_sys_ck", NULL, false);
 }
 
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
-void __init omap3_secure_sync32k_timer_init(void)
-{
-   __omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
-   2, "timer_sys_ck", NULL, false);
-}
-#endif /* CONFIG_ARCH_OMAP3 */
-
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
-void __init omap3_gptimer_timer_init(void)
-{
-   __omap_sync32k_timer_init(2, "timer_sys_ck", NULL,
-   1, "timer_sys_ck", "ti,timer-alwon", true);
-}
-#endif
-
-#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
-   defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
-void __init omap4_local_timer_init(void)
-{
-   omap_sync32k_timer_init();
-   clocksource_of_init();
-}
-#endif
-
-#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
 void __init omap5_realtime_timer_init(void)
 {
omap_sync32k_timer_init();
-- 
2.5.3

--
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 04/11] arm: omap2: timer: provide generic sync32k_timer_init function

[Felipe Balbi]

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 +-
 arch/arm/mach-omap2/board-rx51.c|  2 +-
 arch/arm/mach-omap2/common.h|  3 +--
 arch/arm/mach-omap2/timer.c | 20 +++-
 5 files changed, 11 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 9df14ed7dab1..871db0f0fa66 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -46,7 +46,7 @@ DT_MACHINE_START(OMAP242X_DT, "Generic OMAP2420 (Flattened 
Device Tree)")
.map_io = omap242x_map_io,
.init_early = omap2420_init_early,
.init_machine   = omap_generic_init,
-   .init_time  = omap2_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.dt_compat  = omap242x_boards_compat,
.restart= omap2xxx_restart,
 MACHINE_END
@@ -63,7 +63,7 @@ DT_MACHINE_START(OMAP243X_DT, "Generic OMAP2430 (Flattened 
Device Tree)")
.map_io = omap243x_map_io,
.init_early = omap2430_init_early,
.init_machine   = omap_generic_init,
-   .init_time  = omap2_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.dt_compat  = omap243x_boards_compat,
.restart= omap2xxx_restart,
 MACHINE_END
@@ -82,7 +82,7 @@ DT_MACHINE_START(OMAP3_N900_DT, "Nokia RX-51 board")
.init_early = omap3430_init_early,
.init_machine   = omap_generic_init,
.init_late  = omap3_init_late,
-   .init_time  = omap3_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.dt_compat  = n900_boards_compat,
.restart= omap3xxx_restart,
 MACHINE_END
@@ -100,7 +100,7 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened Device 
Tree)")
.init_early = omap3430_init_early,
.init_machine   = omap_generic_init,
.init_late  = omap3_init_late,
-   .init_time  = omap3_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.dt_compat  = omap3_boards_compat,
.restart= omap3xxx_restart,
 MACHINE_END
@@ -116,7 +116,7 @@ DT_MACHINE_START(OMAP36XX_DT, "Generic OMAP36xx (Flattened 
Device Tree)")
.init_early = omap3630_init_early,
.init_machine   = omap_generic_init,
.init_late  = omap3_init_late,
-   .init_time  = omap3_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.dt_compat  = omap36xx_boards_compat,
.restart= omap3xxx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index c2975af4cd5d..0d3a57c6931f 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -424,6 +424,6 @@ MACHINE_START(OMAP_LDP, "OMAP LDP board")
.init_irq   = omap3_init_irq,
.init_machine   = omap_ldp_init,
.init_late  = omap3430_init_late,
-   .init_time  = omap3_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.restart= omap3xxx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 2d1e5a6beb85..830256c434ec 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -136,6 +136,6 @@ MACHINE_START(NOKIA_RX51, "Nokia RX-51 board")
.init_irq   = omap3_init_irq,
.init_machine   = rx51_init,
.init_late  = omap3430_init_late,
-   .init_time  = omap3_sync32k_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.restart= omap3xxx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 92e92cfc2775..844ad031f7f0 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -88,8 +88,7 @@ static inline int omap_mux_late_init(void)
 
 extern void omap2_init_common_infrastructure(void);
 
-extern void omap2_sync32k_timer_init(void);
-extern void omap3_sync32k_timer_init(void);
+extern void omap_sync32k_timer_init(void);
 extern void omap3_secure_sync32k_timer_init(void);
 extern void omap3_gptimer_timer_init(void);
 extern void omap4_local_timer_init(void);
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 
clkev_nr, const char *clkev_src
omap2_sync32k_clocksource_init();
 }
 
-#ifdef CONFIG_ARCH_OMAP2
-void __i

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

[Felipe Balbi]

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-32k.c | 122 +
 3 files changed, 130 insertions(+)
 create mode 100644 drivers/clocksource/timer-ti-32k.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index a7726db13abb..98b2a9b9bfad 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -115,6 +115,13 @@ config CLKSRC_PISTACHIO
bool
select CLKSRC_OF
 
+config CLKSRC_TI_32K
+   bool "Texas Instruments 32.768 Hz Clocksource" if COMPILE_TEST
+   select CLKSRC_OF if OF
+   help
+ This option enables support for Texas Instruments 32.768 Hz 
clocksource
+ available on many OMAP-like platforms.
+
 config CLKSRC_STM32
bool "Clocksource for STM32 SoCs" if !ARCH_STM32
depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 5c00863c3e33..749abc3665b3 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_VF_PIT_TIMER)+= vf_pit_timer.o
 obj-$(CONFIG_CLKSRC_QCOM)  += qcom-timer.o
 obj-$(CONFIG_MTK_TIMER)+= mtk_timer.o
 obj-$(CONFIG_CLKSRC_PISTACHIO) += time-pistachio.o
+obj-$(CONFIG_CLKSRC_TI_32K)+= timer-ti-32k.o
 
 obj-$(CONFIG_ARM_ARCH_TIMER)   += arm_arch_timer.o
 obj-$(CONFIG_ARM_GLOBAL_TIMER) += arm_global_timer.o
diff --git a/drivers/clocksource/timer-ti-32k.c 
b/drivers/clocksource/timer-ti-32k.c
new file mode 100644
index ..12e2ca7bcc49
--- /dev/null
+++ b/drivers/clocksource/timer-ti-32k.c
@@ -0,0 +1,122 @@
+/**
+ * timer-ti-32k.c - OMAP2 32k Timer Support
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ *
+ * Update to use new clocksource/clockevent layers
+ * Author: Kevin Hilman, MontaVista Software, Inc. <sou...@mvista.com>
+ * Copyright (C) 2007 MontaVista Software, Inc.
+ *
+ * Original driver:
+ * Copyright (C) 2005 Nokia Corporation
+ * Author: Paul Mundt <paul.mu...@nokia.com>
+ * Juha Yrjölä <juha.yrj...@nokia.com>
+ * OMAP Dual-mode timer framework support by Timo Teras
+ *
+ * Some parts based off of TI's 24xx code:
+ *
+ * Copyright (C) 2004-2009 Texas Instruments, Inc.
+ *
+ * Roughly modelled after the OMAP1 MPU timer code.
+ * Added OMAP4 support - Santosh Shilimkar <santosh.shilim...@ti.com>
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * 32KHz clocksource ... always available, on pretty most chips except
+ * OMAP 730 and 1510.  Other timers could be used as clocksources, with
+ * higher resolution in free-running counter modes (e.g. 12 MHz xtal),
+ * but systems won't necessarily want to spend resources that way.
+ */
+
+#define OMAP2_32KSYNCNT_REV_OFF0x0
+#define OMAP2_32KSYNCNT_REV_SCHEME (0x3 << 30)
+#define OMAP2_32KSYNCNT_CR_OFF_LOW 0x10
+#define OMAP2_32KSYNCNT_CR_OFF_HIGH0x30
+
+struct ti_32k {
+   void __iomem*base;
+   void __iomem*counter;
+   struct clocksource  cs;
+};
+#define to_ti_32k(cs)  (container_of((cs), struct ti_32k, cs))
+
+static cycle_t ti_32k_read_cycles(struct clocksource *cs)
+{
+   struct ti_32k   *ti = to_ti_32k(cs);
+
+   return (cycle_t)readl_relaxed(ti->counter);
+}
+
+static struct ti_32k ti_32k_timer = {
+   .cs = {
+   .name   = "32k_counter",
+   .rating = 250,
+   .read   = ti_32k_read_cycles,
+   .mask   = CLOCKSOURCE_MASK(32),
+   .flags  = CLOCK_SOURCE_IS_CONTINUOUS |
+   CLOCK_SOURCE_SUSPEND_NONSTOP,
+   },
+};
+
+static u64 notrace omap_32k_read_sched_clock(void)
+{
+   return ti_32k_read_cycles(_32k_timer.cs);
+}
+
+static void __init ti_32k_timer_init(struct device_node *np)
+{
+   int ret;
+
+   ti_32k_timer.base = of_iomap(np, 0

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

[Felipe Balbi]

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/arm/mach-omap2/common.h| 1 -
 arch/arm/mach-omap2/timer.c | 8 
 3 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 871db0f0fa66..20d5e82ab6ee 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -228,7 +228,7 @@ DT_MACHINE_START(OMAP4_DT, "Generic OMAP4 (Flattened Device 
Tree)")
.init_irq   = omap_gic_of_init,
.init_machine   = omap_generic_init,
.init_late  = omap4430_init_late,
-   .init_time  = omap4_local_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.dt_compat  = omap4_boards_compat,
.restart= omap44xx_restart,
 MACHINE_END
@@ -272,7 +272,7 @@ DT_MACHINE_START(AM43_DT, "Generic AM43 (Flattened Device 
Tree)")
.init_late  = am43xx_init_late,
.init_irq   = omap_gic_of_init,
.init_machine   = omap_generic_init,
-   .init_time  = omap4_local_timer_init,
+   .init_time  = omap_sync32k_timer_init,
.dt_compat  = am43_boards_compat,
.restart= omap44xx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 844ad031f7f0..bf42fc4e78f4 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -91,7 +91,6 @@ extern void omap2_init_common_infrastructure(void);
 extern void omap_sync32k_timer_init(void);
 extern void omap3_secure_sync32k_timer_init(void);
 extern void omap3_gptimer_timer_init(void);
-extern void omap4_local_timer_init(void);
 #ifdef CONFIG_CACHE_L2X0
 int omap_l2_cache_init(void);
 #define OMAP_L2C_AUX_CTRL  (L2C_AUX_CTRL_SHARED_OVERRIDE | \
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b523426f38a5..f41e526ffa46 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -517,14 +517,6 @@ void __init omap3_gptimer_timer_init(void)
 }
 #endif
 
-#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
-   defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
-void __init omap4_local_timer_init(void)
-{
-   omap_sync32k_timer_init();
-}
-#endif
-
 #if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
 
 /*
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Felipe Balbi]

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
>>> this will prevent them from probing.
>>
>> Great. Is this safe to appy on it's own? We are not getting
>> system timers re-inited to the default values?
>
> not that I could notice. I booted on BBB and AM4. If you give me a few
> minutes I can boot again and save console logs for reference.

found another dependency. This will have to be done only after my
clocksource conversion is finished. Oh well

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

Hi,

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
still platforms relying to legacy boot and because of the strong
coupling with OMAP's hwmod layer.

This has a dependency on [1]. Boot tested with AM335x and AM437x.

[1] http://marc.info/?l=linux-omap=144354336924308=2

Here are the changes since v1:

  - removed register_persistent_clock() in favor of CLOCK_SOURCE_SUSPEND_NONSTOP
  - make dropped 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
  arm: omap2: timer: add a gptimer argument to sync32k_timer_init()
  arm: omap2: timer: remove __omap_gptimer_init()
  arm: omap2: timer: provide generic sync32k_timer_init function
  arm: omap2: timer: move realtime_counter_init() around
  arm: omap2: timer: always call clocksource_of_init() when DT
  arm: omap2: timer: remove omap4_local_timer_init
  arm: omap2: timer: rename omap_sync32k_timer_init()
  clocksource: add TI 32.768 Hz counter driver
  arm: omap2+: select 32k clocksource driver
  arm: omap2: timer: limit hwmod usage to non-DT boots

 arch/arm/mach-omap2/Kconfig |   1 +
 arch/arm/mach-omap2/board-generic.c |  14 ++--
 arch/arm/mach-omap2/board-ldp.c |   2 +-
 arch/arm/mach-omap2/board-rx51.c|   2 +-
 arch/arm/mach-omap2/common.h|   4 +-
 arch/arm/mach-omap2/timer.c | 141 +++-
 drivers/clocksource/Kconfig |   7 ++
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/timer-ti-32k.c  | 122 +++
 9 files changed, 199 insertions(+), 95 deletions(-)
 create mode 100644 drivers/clocksource/timer-ti-32k.c

-- 
2.5.3

--
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 01/11] arm: omap2: timer: get rid of obfuscating macros

[Felipe Balbi]

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-omap2/timer.c | 70 -
 1 file changed, 43 insertions(+), 27 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 548d922cb107..23e58ea6a171 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -592,53 +592,69 @@ static inline void __init realtime_counter_init(void)
 {}
 #endif
 
-#define OMAP_SYS_GP_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop,  \
-  clksrc_nr, clksrc_src, clksrc_prop)  \
-void __init omap##name##_gptimer_timer_init(void)  \
-{  \
-   omap_clk_init();\
-   omap_dmtimer_init();\
-   omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
-   omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src, \
-   clksrc_prop);   \
+static void __init __omap_gptimer_init(int clkev_nr, const char *clkev_src,
+   const char *clkev_prop, int clksrc_nr, const char *clksrc_src,
+   const char *clksrc_prop)
+{
+   omap_clk_init();
+   omap_dmtimer_init();
+   omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
+   omap2_gptimer_clocksource_init(clksrc_nr, clksrc_src, clksrc_prop);
 }
 
-#define OMAP_SYS_32K_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop, \
-   clksrc_nr, clksrc_src, clksrc_prop) \
-void __init omap##name##_sync32k_timer_init(void)  \
-{  \
-   omap_clk_init();\
-   omap_dmtimer_init();\
-   omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
-   /* Enable the use of clocksource="gp_timer" kernel parameter */ \
-   if (use_gptimer_clksrc) \
-   omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src, \
-   clksrc_prop);   \
-   else\
-   omap2_sync32k_clocksource_init();   \
+static void __init __omap_sync32k_timer_init(int clkev_nr, const char 
*clkev_src,
+   const char *clkev_prop, int clksrc_nr, const char *clksrc_src,
+   const char *clksrc_prop)
+{
+   omap_clk_init();
+   omap_dmtimer_init();
+   omap2_gp_clockevent_init(clkev_nr, clkev_src, clkev_prop);
+
+   /* Enable the use of clocksource="gp_timer" kernel parameter */
+   if (use_gptimer_clksrc)
+   omap2_gptimer_clocksource_init(clksrc_nr, clksrc_src,
+   clksrc_prop);
+   else
+   omap2_sync32k_clocksource_init();
 }
 
 #ifdef CONFIG_ARCH_OMAP2
-OMAP_SYS_32K_TIMER_INIT(2, 1, "timer_32k_ck", "ti,timer-alwon",
+void __init omap2_sync32k_timer_init(void)
+{
+   __omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
2, "timer_sys_ck", NULL);
+}
 #endif /* CONFIG_ARCH_OMAP2 */
 
 #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
-OMAP_SYS_32K_TIMER_INIT(3, 1, "timer_32k_ck", "ti,timer-alwon",
+void __init omap3_sync32k_timer_init(void)
+{
+   __omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
2, "timer_sys_ck", NULL);
-OMAP_SYS_32K_TIMER_INIT(3_secure, 12, "secure_32k_fck", "ti,timer-secure",
+}
+
+void __init omap3_secure_sync32k_timer_init(void)
+{
+   __omap_sync32k_timer_init(12, "secure_32k_fck", "ti,timer-secure",
2, "timer_sys_ck", NULL);
+}
 #endif /* CONFIG_ARCH_OMAP3 */
 
 #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
-OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL,
+void __init omap3_gptimer_timer_init(void)
+{
+   __omap_gptimer_init(2, "timer_sys_ck", NULL,
   1, "timer_sys_ck", "ti,timer-alwon");
+}
 #endif
 
 #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
-static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon",
+static void __init omap4_sync32k_timer_init(void)
+{
+   __oma

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

[Felipe Balbi]

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 871d6cc450a5..9ac5909ca59d 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -99,6 +99,7 @@ config ARCH_OMAP2PLUS
select SOC_BUS
select TI_PRIV_EDMA
select OMAP_IRQCHIP
+   select CLKSRC_TI_32K
help
  Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
 
-- 
2.5.3

--
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 06/11] arm: omap2: timer: always call clocksource_of_init() when DT

[Felipe Balbi]

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

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index dcc0f032e717..b523426f38a5 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -496,6 +496,9 @@ void __init omap_sync32k_timer_init(void)
 {
__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
2, "timer_sys_ck", NULL, false);
+
+   if (of_have_populated_dt())
+   clocksource_of_init();
 }
 
 #if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM43XX)
@@ -519,7 +522,6 @@ void __init omap3_gptimer_timer_init(void)
 void __init omap4_local_timer_init(void)
 {
omap_sync32k_timer_init();
-   clocksource_of_init();
 }
 #endif
 
@@ -640,10 +642,8 @@ sysclk1_based:
 
 void __init omap5_realtime_timer_init(void)
 {
-   omap_sync32k_timer_init();
realtime_counter_init();
-
-   clocksource_of_init();
+   omap_sync32k_timer_init();
 }
 #endif /* CONFIG_SOC_OMAP5 || CONFIG_SOC_DRA7XX */
 
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Felipe Balbi]

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
>>  * @property- optional timer property to match
>>  *
>>  * Helper function to get a timer during early boot using device-tree for use
>>  * as kernel system timer. Optionally, the property argument can be used to
>>  * select a timer with a specific property. Once a timer is found then mark
>>  * the timer node in device-tree as disabled, to prevent the kernel from
>>  * registering this timer as a platform device and so no one else can use it.
>>  */
>> static struct device_node * __init omap_get_timer_dt(const struct 
>> of_device_id *match,
>>  const char *property)
>> {
>> struct device_node *np;
>> 
>> for_each_matching_node(np, match) {
>> if (!of_device_is_available(np))
>> continue;
>> 
>> if (property && !of_get_property(np, property, NULL))
>> continue;
>> 
>> if (!property && (of_get_property(np, "ti,timer-alwon", 
>> NULL) ||
>>   of_get_property(np, "ti,timer-dsp", NULL) 
>> ||
>>   of_get_property(np, "ti,timer-pwm", NULL) 
>> ||
>>   of_get_property(np, "ti,timer-secure", 
>> NULL)))
>> continue;
>> 
>> of_add_property(np, _disabled);
>> return np;
>> }
>> 
>> return NULL;
>> }
>> 
>> I'll patch this up and drop $subject
>> 
>
> Ah, good.
>
> I'm seeing the "ti,timer-alwon" property here, we probably need to take
> that into account when setting the CLOCK_SOURCE_SUSPEND_NONSTOP flag, if
> that isn't how it gets done already.

that flag is not set for 32k in any dts. Seems like it should, though,
judging by the binding documentation:

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

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

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 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 <ba...@ti.com>
> > > > 
> > > 
> > > The patch looks good, but the description is slightly incorrect:
> > > There is no reason to list "status='okay'" other than overriding
> > > the 'disabled' status.
> > > 
> > > I'd phrase it something like:
> > > 
> > > "We want the use of the 32k counter to be a per-board setting,
> > > so let's disable it by default in each dtsi file and override the
> > > setting in the boards. Any board that does not wire up the counter
> > > should leave it disabled".
> > > 
> > > However, if you really want all boards to provide the counter all
> > > the time, I'd argue that we're better off dropping this patch. We
> > > use the status="disabled" trick for anything that may or may not
> > > be working based on the board design, but things that are present
> > > everywhere don't need this.
> > 
> > okay, so here's the thing. While fiddling with the 32k counter, I noticed
> > that even though there was no status listed, the thing still initializes
> > fine. However, when moving 32k to drivers/clocksource and using
> > CLOCKSOURCE_OF_DECLARE(), 32k would *NOT* probe unless I had an explicit
> > status = "okay" in DT.
> 
> Very strange, that sounds like a bug in the clocksource probe code.
> Can you check how this happens?

seems like something overwrites counter's status field, here's a snippet of boot
log:

[0.00] ===> counter is available ??
[0.00] ===> no status -> TRUE!!
[0.00] ===> searching for timer
[0.00] ===> timer is available ??
[0.00] ===> no status -> TRUE!!
[0.05] sched_clock: 64 bits at 1000MHz, resolution 1ns, wraps every 
4398046511103ns
[0.14] clocksource: arm_global_timer: mask: 0x 
max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[0.47] ===> searching for timer
[0.51] ===> timer is available ??
[0.54] ===> no status -> TRUE!!
[0.000307] ===> searching for counter
[0.000311] ===> counter is available ??
[0.000315] ===> counter status disabled
[0.000318] > counter NOT available

note that first time around counter had no status and later it got a status
disabled from somewhere.

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

We actually want these devices to be created because
we will be moving timers to drivers/clocksource and
this will prevent them from probing.

The only situation where we want secure timers to be
actually disabled is when we *know* we're running on
non-GP (read: HS or EMU) chips, because 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 trick, just limit it to
  non-GP chips

 arch/arm/mach-omap2/timer.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 0ff676273b4b..0bd3ee4552de 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -161,9 +161,7 @@ static const struct of_device_id omap_timer_match[] 
__initconst = {
  *
  * Helper function to get a timer during early boot using device-tree for use
  * as kernel system timer. Optionally, the property argument can be used to
- * select a timer with a specific property. Once a timer is found then mark
- * the timer node in device-tree as disabled, to prevent the kernel from
- * registering this timer as a platform device and so no one else can use it.
+ * select a timer with a specific property.
  */
 static struct device_node * __init omap_get_timer_dt(const struct of_device_id 
*match,
 const char *property)
@@ -182,8 +180,6 @@ static struct device_node * __init omap_get_timer_dt(const 
struct of_device_id *
  of_get_property(np, "ti,timer-pwm", NULL) ||
  of_get_property(np, "ti,timer-secure", NULL)))
continue;
-
-   of_add_property(np, _disabled);
return np;
}
 
@@ -208,7 +204,10 @@ static void __init omap_dmtimer_init(void)
/* If we are a secure device, remove any secure timer nodes */
if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
np = omap_get_timer_dt(omap_timer_match, "ti,timer-secure");
-   of_node_put(np);
+   if (np) {
+   of_add_property(np, _disabled);
+   of_node_put(np);
+   }
}
 }
 
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Felipe Balbi]

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 the secure 32K clock.
>
> The node is marked disabled for now, and the kernel should
> refrain from using this secure timer on HS devices.
>
> Signed-off-by: Suman Anna 
> ---
>  arch/arm/boot/dts/dra7.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index e289c706d27d..37d632dad576 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -762,6 +762,16 @@
>   ti,hwmods = "timer11";
>   };
>  
> + timer12: timer@4ae2 {
> + compatible = "ti,omap5430-timer";
> + reg = <0x4ae2 0x80>;
> + interrupts = ;
> + ti,hwmods = "timer12";
> + ti,timer-alwon;
> + ti,timer-secure;
> + status = "disabled";

according to Tony we should avoid using status at all for in-SoC
devices.

Tony, can you confirm I understood you correctly ?

-- 
balbi


signature.asc
Description: PGP signature

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

[Felipe Balbi]

Suman Anna <s-a...@ti.com> writes:

> Hi Felipe,
>
>>>
>>> On 10/05/2015 02:48 PM, Balbi, Felipe wrote:
>>>> We actually want these devices to be created because
>>>> we will be moving timers to drivers/clocksource and
>>>> this will prevent them from probing.
>>>
>>> This logic is also used to remove the secure timer from being
>>> registered to the kernel on HS devices, while allowing the timer to be
>>> available on GP devices. Your patch actually would break that
>>> functionality. I suggest that you look at the history of the code that
>> 
>> heh, that's a silly way of doing so. Could just detect if we're running
>> on HS or not.
>
> This function is invoked only after detecting that we are running on a
> HS device.

What actually disables the timer is omap_get_timer_dt() and that's
called in more than one place.

>>> originally added this logic - this function seems to be designed to
>>> actually remove the node. The OMAP DMTimer provides an API to request
>>> timers, and I think this logic was used to eliminate giving out the
>>> timers used for clocksource and clockevent when the driver got adapted
>>> to DT.
>> 
>> again not the best way of achieving what you want. In any case, other
>> than ir-rx51.c who's using that API ? Seems like we could just pass a
>> phandle to ir-rx51 and be done with it.
>
> 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
> converted to DT, and also some of the 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>
>>>> ---
>>>>
>>>> Tony, I wonder if you can get merged as a fix, or do you
>>>> prefer receiving it together with my timer series ?
>>>
>>> NAK for rc, as it breaks other stuff.
>> 
>> a single stuff which is likely easy enough to fix. But fair enough
>
> Don't think this patch is fixing any critical bug either, better to club
> it with your cleanup series.

it is kinda critical when you consider that the timer is disabled
outside of the soc type detection.

-- 
balbi


signature.asc
Description: PGP signature