[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53dc1088-41bb-f272-2aa8-f0ade762d6d5@kaod.org>
Date: Thu, 18 May 2017 15:12:23 +0200
From: Cédric Le Goater <clg@...d.org>
To: Linus Walleij <linus.walleij@...aro.org>,
Joel Stanley <joel@....id.au>
Cc: Daniel Lezcano <daniel.lezcano@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Jonas Jensen <jonas.jensen@...il.com>,
Janos Laube <janos.dev@...il.com>,
Paulius Zaleckas <paulius.zaleckas@...il.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Hans Ulli Kroll <ulli.kroll@...glemail.com>,
Florian Fainelli <f.fainelli@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Ryan Chen <ryan_chen@...eedtech.com>
Subject: Re: [PATCH 7/8] clocksource/drivers/fttmr010: Merge Moxa into
FTTMR010
>> As an aside, we have a pretty decent model for the Aspeed SoCs in
>> Qemu. If you want to use it to smoketest your rework:
>>
>> $ qemu-system-arm -m 512 -M ast2500-evb -nodefaults -nographic
>> -serial stdio -kernel arch/arm/boot/zImage -dtb
>> arch/arm/boot/dts/aspeed-ast2500-evb.dtb
>>
>> I tested with Ubuntu's qemu v2.8. It looks like we have a bug when the
>> kernel tries to use the clock the way your driver works, so we will
>> look at that. It does function properly for the current upstream code.
>
> Oh that's sweet! I'll test it if I can get it working like this.
In case you need a small ramfs, here is one :
https://openpower.xyz/job/openbmc-build/distro=ubuntu,target=evb-ast2500/lastSuccessfulBuild/artifact/images/evb-ast2500/obmc-phosphor-initramfs-evb-ast2500.cpio.lzma
Cheers,
C.
Powered by blists - more mailing lists