linux-kernel - Re: [PATCH 02/17] clocksource: davinci-timer: new driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMRc=McPCJxd7i7Ei+xOKOXYhYZgC=MYYFwyn2zAjStQov91fw@mail.gmail.com>
Date:   Thu, 17 Jan 2019 15:01:01 +0100
From:   Bartosz Golaszewski <brgl@...ev.pl>
To:     Sekhar Nori <nsekhar@...com>
Cc:     Kevin Hilman <khilman@...nel.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>
Subject: Re: [PATCH 02/17] clocksource: davinci-timer: new driver

czw., 17 sty 2019 o 13:42 Sekhar Nori <nsekhar@...com> napisał(a):
>
> On 16/01/19 2:48 PM, Sekhar Nori wrote:
> > On 14/01/19 10:09 PM, Bartosz Golaszewski wrote:
> >> pon., 14 sty 2019 o 13:20 Sekhar Nori <nsekhar@...com> napisał(a):
> >>>
> >>> Hi Bartosz,
> >>>
> >>> On 11/01/19 10:51 PM, Bartosz Golaszewski wrote:
> >>>> From: Bartosz Golaszewski <bgolaszewski@...libre.com>
> >>>>
> >>>> Currently the clocksource and clockevent support for davinci platforms
> >>>> lives in mach-davinci. It hard-codes many things, used global variables,
> >>>> implements functionalities unused by any platform and has code fragments
> >>>> scattered across many (often unrelated) files.
> >>>>
> >>>> Implement a new, modern and simplified timer driver and put it into
> >>>> drivers/clocksource. We still need to support legacy board files so
> >>>> export a config structure and a function that allows machine code to
> >>>> register the timer.
> >>>>
> >>>> We don't check the return values of regmap reads and writes since with
> >>>> mmio it's only likely to fail due to programmer's errors.
> >>>>
> >>>> We also don't bother freeing resources on errors in
> >>>> davinci_timer_register() as the system won't boot without a timer anyway.
> >>>>
> >>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@...libre.com>
> >>>
> >>> With this series, DA830 fails to boot. Rest of the devices are okay from
> >>> boot perspective.
> >>>
> >>> DA830 is pretty unique because it uses the same timer-half for both
> >>> clocksource and clockevent. May be you can set the same configuration on
> >>> your DA850 to see the same issue? Else, I will enable low-level debug
> >>> and try to provide more debug data.
> >>>
> >>
> >> I can't boot da850 with the same config as da830 (0x60 compare
> >> register, compare irq 74) even with the old timer code. Just to make
> >> sure: does da830 boot fine with mainline v5.0-rc2?
> >
> > Yeah, I did check that without the patch DA830 does boot.
>
> You are right that DA850 lacks compare interrupts for timers 0 and 1.
> So, yes, it seems like we will have to shift to timer2 to test
> compare interrupts on DA850.
>

Timers 2 and 3 are a bit different on da850 - for instance they don't
have separate interrupts for bottom and top halfs.

I configured the old code to use timer 2 - bottom half only with
compare register 0x60 and compare intterupt 74. It boots although very
slowly and something's broken with timekeeping as the clock goes
backwards and forward (seemingly) randomly.

Kevin has an OMAP-L137 starter kit - is this the same as da830-evm? If
so, then I can get remote access to it and work on this problem.
Otherwise, I can prepare something that works on da850 with broken
timekeeping and let you see if it works correctly on da830.

Bart

> Just to confirm, DA830 boots fine with the compare section removed:
>
> ---8<---
> diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
> index 0d81a8fdd9e6..f34398a7e47c 100644
> --- a/arch/arm/mach-davinci/da830.c
> +++ b/arch/arm/mach-davinci/da830.c
> @@ -788,14 +788,6 @@ static const struct davinci_timer_cfg da830_timer_cfg = {
>                         .flags  = IORESOURCE_IRQ,
>                 },
>         },
> -       .cmp = {
> -               .irq = {
> -                       .start  = IRQ_DA830_T12CMPINT0_0,
> -                       .end    = IRQ_DA830_T12CMPINT0_0,
> -                       .flags  = IORESOURCE_IRQ,
> -               },
> -               .offset         = DA830_CMP12_0,
> -       }
>  };
>
>  static const struct davinci_soc_info davinci_soc_info_da830 = {
> ---8<---
>
> And the low-level debug with your patches shows that its hanging at
> delay loop calibration.
>
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 5.0.0-rc1-08699-gc87d386784f3-dirty (a0875516@...linux063) (gcc v9
> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
> CPU: VIVT data cache, VIVT instruction cache
> Machine: DaVinci DA830/OMAP-L137/AM17x EVM
> Memory policy: Data cache writethrough
> cma: Reserved 16 MiB at 0xc2800000
> DaVinci da830/omap-l137 rev2.0 variant 0x9
> On node 0 totalpages: 14336
>   DMA zone: 112 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 14336 pages, LIFO batch:3
> random: get_random_bytes called from start_kernel+0x80/0x3ec with crng_init=0
> pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> pcpu-alloc: [0] 0
> Built 1 zonelists, mobility grouping on.  Total pages: 14224
> Kernel command line: console=ttyS2,115200n8
> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Memory: 33876K/57344K available (4607K kernel code, 308K rwdata, 1072K rodata, )
> Virtual kernel memory layout:
>     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
>     vmalloc : 0xc4000000 - 0xff800000   ( 952 MB)
>     lowmem  : 0xc0000000 - 0xc3800000   (  56 MB)
>     modules : 0xbf000000 - 0xc0000000   (  16 MB)
>       .text : 0x(ptrval) - 0x(ptrval)   (4609 kB)
>       .init : 0x(ptrval) - 0x(ptrval)   ( 212 kB)
>       .data : 0x(ptrval) - 0x(ptrval)   ( 309 kB)
>        .bss : 0x(ptrval) - 0x(ptrval)   ( 137 kB)
> SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> rcu: Preemptible hierarchical RCU implementation.
>         Tasks RCU enabled.
> rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
> NR_IRQS: 245
> clocksource: timer0_0: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79s
> sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
> Console: colour dummy device 80x30
> Calibrating delay loop...
> <hangs>
>
> Thanks,
> Sekhar