Re: [PATCH v4 00/14] m68k: Drop arch_gettimeoffset and adopt clocksource API
On Tue, Mar 5, 2019 at 10:55 AM Finn Thain wrote: > That leaves bvme6000, hp300, mvme147 and mvme16x. Those have not been > tested. Here are some options for those platforms: > > 1) Apply the patches untested (gaining new clocksources and some API > modernization for m68k, while fixing old bugs and potentially introducing > new bugs). This is what I usually do with ARM machines when I don't get any tests or reviews after a reasonable time lap, > month for sure is a reasonable time for users to have all opportunity in the world to test patches. If things break, users will report it as is custom and the author will be expected to work with them to fix them then, we do this all the time. Those users who want everything tested before it gets merged should provide resources or time for testing. Just my €0.01 Linus Walleij
Re: [RFC PATCH v2 10/14] m68k: mac: Convert to clocksource API
On Tue, Nov 20, 2018 at 10:00 AM Finn Thain wrote: > If you use one timer as a clock event device and the other as a > clocksource, there are no timers left to run the existing > timer_interrupt() handler. So this arrangement would require > GENERIC_CLOCKEVENTS=y, right? I think so, yes. > Then, wouldn't all relevant platforms have to support > GENERIC_CLOCKEVENTS=y, if a single binary was to support all of those > platforms? Good point. I wonder of there is a path forward where we could have peaceful GENERIC_CLOCKEVENTS and !GENERIC_CLOCKEVENTS co-existence. Yours, Linus Walleij
Re: [RFC PATCH v2 07/14] m68k: atari: Convert to clocksource API
On Tue, Nov 20, 2018 at 10:30 AM Finn Thain wrote: > On Tue, 20 Nov 2018, Linus Walleij wrote: > > As with the Amiga, this chip also has an RTC clock that should go to the > > RTC subsystem, naturally. > > I think some Atari's have an MC146818, which is drivers/rtc/rtc-cmos.c, > arch/alpha/kernel/rtc.c etc. Indeed, some systems have more than one RTC, often one in their SoC silicon and one battery backed elsewhere (like a dedicated chip on I2C or inside a PMIC). We usually just register more of them. The RTC subsystem can handle any amount. It's up to userspace to figure out which RTC to actually use, which is not so good, we should probably have some heuristic like a quality indicator on them. Yours, Linus Walleij
Re: [RFC PATCH v2 10/14] m68k: mac: Convert to clocksource API
On Mon, Nov 19, 2018 at 2:22 AM Finn Thain wrote: > Add a platform clocksource by adapting the existing arch_gettimeoffset > implementation. > > Signed-off-by: Finn Thain > Acked-by: Linus Walleij > Tested-by: Stan Johnson As noted for the Amiga CIA (which is pretty much a sibling to this MOS 6522 VIA) this chip also has two counters and could use one as clocksource and the other as clock event. Again I bet this is just using one timer out of habit. It will be an easy feat to make a clean clocksource+clock event for this hardware as well once this refactoring is complete. Yours, Linus Walleij
Re: [RFC PATCH v2 07/14] m68k: atari: Convert to clocksource API
On Mon, Nov 19, 2018 at 2:22 AM Finn Thain wrote: > Add a platform clocksource by adapting the existing arch_gettimeoffset > implementation. > > Normally the MFP timer C interrupt flag would be used to check for > timer counter wrap-around. Unfortunately, that flag gets cleared by the > MFP itself (due to automatic EOI mode). This means that > mfp_timer_c_handler() and atari_read_clk() must race when accounting > for counter wrap-around. > > That problem is avoided here by effectively stopping the clock when it > might otherwise jump backwards. This harms clock accuracy; the result > is not much better than the jiffies clocksource. Also, clock error is > no longer uniformly distributed. > > Signed-off-by: Finn Thain > Acked-by: Linus Walleij > --- > TODO: find a spare counter for the clocksource, rather than hanging > it off the HZ timer. Yes you already see the same as I see: this chip MK68901 has no less than four timers. I bet the kernel is just using one of them, out of habit. By just setting another timer as free-running we get a classic and clean Linux clocksource for the Atari. This is however a very good start in untangling the mess (as is the whole patch series). As with the Amiga, this chip also has an RTC clock that should go to the RTC subsystem, naturally. Yours, Linus Walleij
Re: [RFC PATCH v2 06/14] m68k: amiga: Convert to clocksource API
On Mon, Nov 19, 2018 at 2:22 AM Finn Thain wrote: > Add a platform clocksource by adapting the existing arch_gettimeoffset > implementation. > > Signed-off-by: Finn Thain > Acked-by: Linus Walleij > --- > Changed since v1: > - Moved clk_total access to within the irq lock. Came to think of it, Geert can probably answer to the use cases for the CIAs in Linux: the Amiga CIA has two counters. It would make sense to use one as a free-runing clocksource and the other one as clock event. Then Linux is extremely happy without any complex workarounds trying to use just one timer for both jobs. Is there some specific reason why we can't use both counters like this, except for legacy? (I am thinking it would be an improvement on top of Finn's series once they go in.) Yours, Linus Walleij
Re: m68k using deprecated internal APIs?
On Fri, Nov 16, 2018 at 8:44 PM Geert Uytterhoeven wrote: > On Fri, Nov 16, 2018 at 12:13 PM Linus Walleij > wrote: > > I mean that whole thing should go away by abstracting those LEDs > > (for the systems that have them) using the struct led_classdev, > > populating a proper platform device for it and instantiate using > > a driver in drivers/leds/*, and the function to provide the heartbeat > > be replaced with the existing heartbeat trigger in > > drivers/leds/trigger/ledtrig-heartbeat.c assigned as default > > trigger for that LED. > > > > I think that is WAY out of the focus for your current work (which, > > by the way, is a piece of art) but more something for the m68k > > maintainers to look into. > > Just going with struct led_classdev is probably doable. Would be nice. > Going for the full monty, using leds-gpio, probably requires moving m68k > to DT. Which would not be that ... uninteresting ;-) If the line with the LED is not general purpose but an actual register bit for the LED it should not be using legs-gpio anyway. But something similar to Russells neat drivers/gpio/gpio-reg.c but for LED classdevs in drivers/leds/leds-reg.c would be a really tempting option I think. Yours, Linus Walleij
Re: m68k using deprecated internal APIs?
On Fri, Nov 16, 2018 at 1:31 AM Finn Thain wrote: > On Wed, 14 Nov 2018, Linus Walleij wrote: > > Apart from this (which is the most important step!) I think the custom > > LED heartbeat code in kernel/time.c needs to be replaced with a standard > > drivers/leds driver for each LED using the "heartbeat" trigger as is > > custom these days. > > > > That should clean out another chunk of legacy time-related code. > > > > Are you referring to LED heartbeat code in arch/m68k/kernel/time.c? > > > I suppose you are currently keeping the call to timer_interrupt() for > > exactly this reason (i.e. keep the heartbeat LED blinking)? > > It would be great to have that call inlined, which the compiler can't do > at the moment, because timer_interrupt() is in a different compilation > unit (arch/m68k/kernel/time.c). > > Is there some other benefit to eliminating the call to timer_interrupt() > that I've overlooked? I mean that whole thing should go away by abstracting those LEDs (for the systems that have them) using the struct led_classdev, populating a proper platform device for it and instantiate using a driver in drivers/leds/*, and the function to provide the heartbeat be replaced with the existing heartbeat trigger in drivers/leds/trigger/ledtrig-heartbeat.c assigned as default trigger for that LED. I think that is WAY out of the focus for your current work (which, by the way, is a piece of art) but more something for the m68k maintainers to look into. Yours, Linus Walleij
Re: m68k using deprecated internal APIs?
On Sat, Nov 10, 2018 at 10:47 PM Arnd Bergmann wrote:
> On Fri, Nov 9, 2018 at 12:42 AM Finn Thain wrote:
> > On Sun, 28 Oct 2018, Geert Uytterhoeven wrote:
> > > > > The example I gave was GENERIC_CLOCKEVENTS on m68, which is
> > > > > supported on most but not all machines there.
> > > >
> > > > That suggests that the removal of just those machines would suffice
> > > > (as opposed to the removal of the entire arch).
> > > >
> > > > Also, Documentation/features/time/clockevents/arch-support.txt says,
> > > > |m68k: | ok |
> > > >
> > > > These two observations make me wonder whether the clockevents feature
> > > > is related to the discussion quoted above (?)
> > >
> > > GENERIC_CLOCKEVENTS is selected only for a few Coldfire CPU types.
> > >
> >
> > !GENERIC_CLOCKEVENTS implies PREEMPT_NONE, and disables the "Timers
> > subsystem" (i.e. the NO_HZ config options), but it works fine -- I was
> > able to convert the Mac port to !ARCH_USES_GETTIMEOFFSET &&
> > !GENERIC_CLOCKEVENTS. (Like many of the Coldfire CPU types.)
> >
> > You can see those patches here,
> > https://github.com/fthain/linux/commits/mac68k-queue/
This is looking very good. FWIW:
Acked-by: Linus Walleij
Apart from this (which is the most important step!) I think the custom
LED heartbeat code in kernel/time.c needs to be replaced with a standard
drivers/leds driver for each LED using the "heartbeat" trigger as is custom
these days.
That should clean out another chunk of legacy time-related code.
I suppose you are currently keeping the call to timer_interrupt() for
exactly this reason (i.e. keep the heartbeat LED blinking)?
> > Note that !ARCH_USES_GETTIMEOFFSET is a build-time choice, meaning that
> > all platforms need to be converted together.
> >
> > Also, some platforms will need to adopt the clocksource API, otherwise the
> > built-in "jiffies" clocksource will get used, causing a regression in
> > timer accuracy.
> >
> > Conversion to the clocksource API is straight-forward where the platform
> > already implements arch_gettimeoffset. The conversion is discussed in
> > include/linux/time.h:
> >
> > /* Some architectures do not supply their own clocksource.
> > * This is mainly the case in architectures that get their
> > * inter-tick times by reading the counter on their interval
> > * timer. Since these timers wrap every tick, they're not really
> > * useful as clocksources. Wrapping them to act like one is possible
> > * but not very efficient. So we provide a callout these arches
> > * can implement for use with the jiffies clocksource to provide
> > * finer then tick granular time.
> > */
> >
> > (Not sure what is meant by "not very efficient" here.)
> >
> > Certain 680x0 platforms do not implement arch_gettimeoffset: apollo, q40,
> > sun3, sun3x. These platforms can fall back on the "jiffies" clocksource
> > with no loss of timer accuracy, so conversion for these platforms is
> > trivial.
> >
> > Should I continue with the clocksource API conversion for the other
> > platforms: amiga, atari, bvme6000, hp300, mvme147, mvme16x? This would
> > allow for removal of "select ARCH_USES_GETTIMEOFFSET" (and satisfy
> > Documentation/features/time/modern-timekeeping) without loss of timer
> > accuracy.
If you ask me: forge ahead.
> > Alternatively, we could defer the clocksource API conversion, leaving it
> > up to the platform maintainers (who can actually test the driver changes).
> > But that would mean that many platforms would suffer a regression in timer
> > accuracy upon removal of arch_gettimeoffset.
>
> Adding the timekeeping maintainers and Linus Walleij to Cc. Linus
> worked on removing ARCH_USES_GETTIMEOFFSET on ARM
> several platforms in the past.
>
> I noticed that the last timer rework involving
> CONFIG_ARCH_USES_GETTIMEOFFSET was back in 2012 with
> commit 7b1f62076bba ("time: convert arch_gettimeoffset to a pointer").
> At the time, we had cris, m32r, blackfin, m68k and lots of ARM
> platforms, now it's only two StrongARM platforms (RPC and
> ARCH_EBSA110) and classic m68k.
Believe it or not, I managed to procure both machines (RPC and
EBSA110). Whether I can get them to boot Linux is still an open
question.
I suppose it would be possible to use a conversion strategy
similar to Finn's and get rid of gettimeoffset altogether, if I could
only test it on these boards.
Yours.
Linus Walleij
Re: [PATCH] microblaze: Remove architecture heart beat code
On Mon, Jun 11, 2018 at 8:09 AM, Michal Simek wrote: > There is no reason to keep this gpio based code in architecture. Use > ledtrig-heartbeat.c instead which is much more flexible then this > ancient code. > > Signed-off-by: Michal Simek Reviewed-by: Linus Walleij Maybe the arch maintainers will complain that the corresponding new heartbeat code is not put in place in the same patch, but I think the change is so much overdue that I don't see why they can't do that themselves if they have interest in it. BTW: m68k has the same kind of luggage, in the middle of it timekeeping code: arch/m68k/kernel/time.c Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RFC] clocksource: improve GENERIC_CLOCKEVENTS dependency
On Tue, Sep 12, 2017 at 11:10 AM, Russell King - ARM Linux <li...@armlinux.org.uk> wrote: > On Tue, Sep 12, 2017 at 10:09:51AM +0200, Linus Walleij wrote: >> For ARM we now have two subarchs not using generic clockevents: >> RISC PC and EBSA110. >> >> I think Russell stated these two cannot be converted to generic clockevents >> because of hardware limitations I guess, no timer interrupt, simply, which >> means no clockevents, or unreliable or not granular enough timers. >> >> IIUC the SA110 does not contain the built-in SoC goodies of the SA1100 >> so it needs external timer blocks, and those two machines don't have >> good enough timers. > > That's hardly surprising because SA1100 is a SoC, SA110 is just a CPU, > containing no peripherals at all. > > EBSA110 only has one usable timer, which must be programmed to produce > a regular timer tick to the OS: it's no good trying to double up the > clocksource and a periodic clockevent onto one counter register - the > clock source will see the same timer value +/- interrupt latency, and > in any case it won't wrap in a power-of-2 manner. > > This breaks the assumptions behind the clocksource and timekeeping > code, which are that we have a timer that wraps in a power-of-2 > manner, and which takes much longer than the desired period to wrap. Aha, that makes perfect sense. Now I finally understand the exact nature of this problem. > I think RiscPC may be convertable as there are two timers, and I think > the second timer is unused (so could be programmed to the requirements > of a clocksource) but is there much reason to bother given the EBSA110? > I think there isn't. The one reason I've seen is that converting to generic clockevents often makes it simple to also introduce a delay timer at the same time by just reusing the clocksource timer for it, and that saves the boot-time loop calibration. (The MOXA ART and Aspeed saw this when I unified the Faraday timers.) But in general no. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [RFC] clocksource: improve GENERIC_CLOCKEVENTS dependency
On Tue, Sep 5, 2017 at 5:04 PM, Arnd Bergmann <a...@arndb.de> wrote: > We regularly run into build errors when a clocksource driver selects > CONFIG_TIMER_OF while CONFIG_GENERIC_CLOCKEVENTS is disabled: > > In file included from drivers/clocksource/timer-of.c:25:0: > drivers/clocksource/timer-of.h:35:28: error: field 'clkevt' has incomplete > type > > At the moment, three drivers can show this behavior: ARMV7M_SYSTICK, > CLKSRC_ST_LPC and CLKSRC_NPS. We could add further dependencies as we did > many times, but I have looked a little bit more at what architectures > are left that don't use GENERIC_CLOCKEVENTS, and this shows that there > is a better solution. > > On arch/frv and arch/ia64, we never select CONFIG_GENERIC_CLOCKEVENTS > and we also don't use ARCH_USES_GETTIMEOFFSET, which would > block the clocksource Kconfig menu. On m68k, some platforms use > CONFIG_GENERIC_CLOCKEVENTS, some use ARCH_USES_GETTIMEOFFSET, and some > use neither of them. The good news is that there is no configuration that > does not set CONFIG_GENERIC_CLOCKEVENTS but that wants to enable any of > the Kconfig symbols in the menu, so we can simply replace the dependency > with the stricter one. While in theory one could have a clocksource > driver without the clockevent infrastructure, this seems unlikely > to be relevant in the future any more. As far as I can see this works and makes sense. Reviewed-by: Linus Walleij <linus.wall...@linaro.org> > We can probably drop some of the other dependencies as well now, > e.g. there should generally be no reason to depend on CONFIG_ARM > unless the driver uses architecture specific assembly. I think they are just there to cut down on the available menu choices when doing manual configuration. Which is moot since the machine/subarch likely selects the right clocksource driver anyway. About ARM: For ARM we now have two subarchs not using generic clockevents: RISC PC and EBSA110. I think Russell stated these two cannot be converted to generic clockevents because of hardware limitations I guess, no timer interrupt, simply, which means no clockevents, or unreliable or not granular enough timers. IIUC the SA110 does not contain the built-in SoC goodies of the SA1100 so it needs external timer blocks, and those two machines don't have good enough timers. That is a bit annoying since even the Commodore 64 has good enough timers to run generic clock events, had it only had compiler support and enough memory to run Linux... Anyways, I'm too ignorant to even fully understand what happens on a system with just GETTIMEOFFSET and not clockevents, does the OS just run in an eternal loop and advancing any event in the system using that time offset? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/23] m68k: do away with ARCH_REQUIRE_GPIOLIB
Replace "select ARCH_REQUIRE_GPIOLIB" with "select GPIOLIB" as this can now be selected directly. Cc: Michael Büsch <m...@bues.ch> Cc: Geert Uytterhoeven <ge...@linux-m68k.org> Cc: linux-m...@lists.linux-m68k.org Signed-off-by: Linus Walleij <linus.wall...@linaro.org> --- Various arch maintainers: either ACK this and I will merge it into the GPIO tree for v4.7 anticipating no clashes, or you wait until I have the enabling patch upstream (patch 1 in this series, removing deps on ARCH_[WANTS_OPTIONAL|REQUIRES]_GPIOLIB), and you will be able to merge it to your arch trees yourselves for late v4.7 (post GPIO tree merge) or for v4.8. You can also ask me for an immutable branch if you prefer that, I will put the enabling patch on a branch and the patch for your arch on top and ask you to pull it. Select your option from the menu, silence probably means I will merge it to the GPIO tree. Unless you are X86 or ARM in which case I will be cautious. --- arch/m68k/Kconfig.cpu | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu index 0dfcf1281e9c..c1beb5ae181f 100644 --- a/arch/m68k/Kconfig.cpu +++ b/arch/m68k/Kconfig.cpu @@ -22,11 +22,11 @@ config M68KCLASSIC config COLDFIRE bool "Coldfire CPU family support" - select ARCH_REQUIRE_GPIOLIB select ARCH_HAVE_CUSTOM_GPIO_H select CPU_HAS_NO_BITFIELDS select CPU_HAS_NO_MULDIV64 select GENERIC_CSUM + select GPIOLIB select HAVE_CLK endchoice -- 2.4.11 -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] m68k/gpio: remove arch specific sysfs bus device
On Wed, Apr 6, 2016 at 4:32 AM, Greg Ungerer <g...@uclinux.org> wrote:
> From: Greg Ungerer <gerg@gumby.(none)>
>
> The ColdFire architecture specific gpio support code registers a sysfs
> bus device named "gpio". This clashes with the new generic API device
> added in commit 3c702e99 ("gpio: add a userspace chardev ABI for GPIOs").
>
> The old ColdFire sysfs gpio device was never used for anything specific,
> and no links or other nodes were created under it. The new API sysfs gpio
> device has all the same default sysfs links (device, drivers, etc) and
> they are properly populated.
>
> Remove the old ColdFire sysfs gpio registration.
>
> Signed-off-by: Greg Ungerer <g...@uclinux.org>
Acked-by: Linus Walleij <linus.wall...@linaro.org>
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: m68k build regression
On Mon, Apr 8, 2013 at 6:32 AM, Greg Ungerer gregunge...@westnet.com.au wrote: Or we could fix like this, keeping the existing local functions intact for this one last kernel version. Regards Greg [PATCH] m68k: define a local gpio_request_one() function Compiling for linux-3.9-rc1 and later fails with: drivers/gpio/devres.c: In function 'devm_gpio_request_one': drivers/gpio/devres.c:90:2: error: implicit declaration of function 'gpio_request_one' [-Werror=implicit-function-declaration] So provide a local gpio_request_one() function. Code largely borrowed from blackfin's local gpio_request_one() function. Signed-off-by: Greg Ungerer g...@uclinux.org Acked-by: Linus Walleij linus.wall...@linaro.org Greg, are you pushing this patch then? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: m68k build regression
On Fri, Apr 5, 2013 at 12:39 PM, Bityutskiy, Artem artem.bityuts...@intel.com wrote: starting from 3.9-rc1 one of my m68k configurations does not build, which is a regression. The configuration is attached. I build with W=1. I did not look at the details, just shooting a bug report. drivers/gpio/devres.c: In function 'devm_gpio_request_one': drivers/gpio/devres.c:90:2: error: implicit declaration of function 'gpio_request_one' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[3]: *** [drivers/gpio/devres.o] Error 1 Somehow GPIO_DEVRES get selected, m68k is using GENERIC_GPIO but not GPIOLIB, so devres.c include linux/gpio.h which includes asm/gpio.h as the arch has CONFIG_ARCH_HAVE_CUSTOM_GPIO_H. So to use the devres facility arch/m68k/include/asm/gpio.h needs to provide gpio_request_one(). Which it doesn't and thus fails. Did some driver you're using start to use devm_gpio_request_one() recently? I vaguely remember Alexandre looking into things like this so adding him... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
