Message ID | f22e65faa7d86074cda27973f83d7a52@advem.lv |
---|---|
State | New |
Headers | show |
On Thursday 09 July 2015 01:29:39 Roman Yeryomin wrote: > > OK, here are the minimal changes required (see attachment). Tested on > 4.1.1 > Let me know if you want me to submit it in some other way. > The changes look ok to me. Please submit them as two separate patches (1. set up and use timer3, 2. register sched_clock) according to the Documentation/SubmittingPatches description. Thanks, Arnd
Hi On Thu, 9 Jul 2015, Arnd Bergmann wrote: > On Thursday 09 July 2015 01:29:39 Roman Yeryomin wrote: > > > > OK, here are the minimal changes required (see attachment). Tested on > > 4.1.1 > > Let me know if you want me to submit it in some other way. > > > > The changes look ok to me. Please submit them as two separate > patches (1. set up and use timer3, 2. register sched_clock) according > to the Documentation/SubmittingPatches description. > > Thanks, > > Arnd > have you seen this thread ... [PATCH 00/18] ARM: Migrate clockevent drivers to 'set-state http://permalink.gmane.org/gmane.linux.ports.arm.kernel/423992 arch/arm/mach-gemini/time.c | 69 ++++++++++++------------ Two or more weeks ago I send a patchset fixing this problem. At this time Arnd was in holiday and until today I was very busy at work. I can rework my patches on top of Viresh's patchset and Roman please fix the subject. Ulli
On Thu, Jul 9, 2015 at 3:02 PM, Roman Yeryomin <roman@advem.lv> wrote: > On 2015-07-09 14:58, Hans Ulli Kroll wrote: >> >> Hi >> >> On Thu, 9 Jul 2015, Arnd Bergmann wrote: >> >>> On Thursday 09 July 2015 01:29:39 Roman Yeryomin wrote: >>> > >>> > OK, here are the minimal changes required (see attachment). Tested on >>> > 4.1.1 >>> > Let me know if you want me to submit it in some other way. >>> > >>> >>> The changes look ok to me. Please submit them as two separate >>> patches (1. set up and use timer3, 2. register sched_clock) according >>> to the Documentation/SubmittingPatches description. >>> >>> Thanks, >>> >>> Arnd >>> >> >> have you seen this thread ... >> [PATCH 00/18] ARM: Migrate clockevent drivers to 'set-state >> http://permalink.gmane.org/gmane.linux.ports.arm.kernel/423992 >> >> arch/arm/mach-gemini/time.c | 69 ++++++++++++------------ >> >> Two or more weeks ago I send a patchset fixing this problem. >> At this time Arnd was in holiday and until today I was very busy at work. > > > Sorry, I didn't see your patches. > Arnd requested minimal changes and until yesterday I was very busy too. > >> I can rework my patches on top of Viresh's patchset > > > It looks that this patchset doesn't conflict with the fix needed. Can any of you guys just look at this thing from OpenWRT: http://git.openwrt.org/?p=openwrt.git;a=blob;f=target/linux/gemini/patches-3.18/160-gemini-timers.patch;h=4b0edb45d162f751bfb7475f5b3158f28d69fe84;hb=HEAD As usual they are just keeping it out of mainline, and this is adding sched_clock() and other goodies so should probably be upstreamed ASAP. Yours, Linus Walleij
On 2015-07-09 18:48, Linus Walleij wrote: > On Thu, Jul 9, 2015 at 3:02 PM, Roman Yeryomin <roman@advem.lv> wrote: >> On 2015-07-09 14:58, Hans Ulli Kroll wrote: >>> >>> Hi >>> >>> On Thu, 9 Jul 2015, Arnd Bergmann wrote: >>> >>>> On Thursday 09 July 2015 01:29:39 Roman Yeryomin wrote: >>>> > >>>> > OK, here are the minimal changes required (see attachment). Tested on >>>> > 4.1.1 >>>> > Let me know if you want me to submit it in some other way. >>>> > >>>> >>>> The changes look ok to me. Please submit them as two separate >>>> patches (1. set up and use timer3, 2. register sched_clock) >>>> according >>>> to the Documentation/SubmittingPatches description. >>>> >>>> Thanks, >>>> >>>> Arnd >>>> >>> >>> have you seen this thread ... >>> [PATCH 00/18] ARM: Migrate clockevent drivers to 'set-state >>> http://permalink.gmane.org/gmane.linux.ports.arm.kernel/423992 >>> >>> arch/arm/mach-gemini/time.c | 69 >>> ++++++++++++------------ >>> >>> Two or more weeks ago I send a patchset fixing this problem. >>> At this time Arnd was in holiday and until today I was very busy at >>> work. >> >> >> Sorry, I didn't see your patches. >> Arnd requested minimal changes and until yesterday I was very busy >> too. >> >>> I can rework my patches on top of Viresh's patchset >> >> >> It looks that this patchset doesn't conflict with the fix needed. > > Can any of you guys just look at this thing from OpenWRT: > http://git.openwrt.org/?p=openwrt.git;a=blob;f=target/linux/gemini/patches-3.18/160-gemini-timers.patch;h=4b0edb45d162f751bfb7475f5b3158f28d69fe84;hb=HEAD > > As usual they are just keeping it out of mainline, and this > is adding sched_clock() and other goodies so should > probably be upstreamed ASAP. This is what I initially submitted here. But Arnd wanted to see a smaller patch which only fixes gemini timer issue (t.i. shed clock being 100Hz instead of 25MHz). Also I've submitted 4.1 support yesterday, but patches didn't change much comparing to 3.18 I would love to see all those patches/drivers in mainline - tell me where do I submit all that :) Regards, Roman
On 2015-07-09 11:04, Arnd Bergmann wrote: > On Thursday 09 July 2015 01:29:39 Roman Yeryomin wrote: >> >> OK, here are the minimal changes required (see attachment). Tested on >> 4.1.1 >> Let me know if you want me to submit it in some other way. >> > > The changes look ok to me. Please submit them as two separate > patches (1. set up and use timer3, 2. register sched_clock) according > to the Documentation/SubmittingPatches description. > So what do we do? Do you still want me to split this as you said and submit or you want Hans's patches rebased/resubmitted? Regards, Roman
On Thu, Jul 9, 2015 at 6:48 PM, Roman Yeryomin <roman@advem.lv> wrote: > [Me] >> As usual they are just keeping it out of mainline, and this >> is adding sched_clock() and other goodies so should >> probably be upstreamed ASAP. > > > This is what I initially submitted here. Ah. I missed part of the start of the discussion it seems. > But Arnd wanted to see a smaller patch which only fixes gemini timer issue > (t.i. shed clock being 100Hz instead of 25MHz). > Also I've submitted 4.1 support yesterday, but patches didn't change much > comparing to 3.18 On the other hand I think the bigger patch is OK actually. I rewrote the timer support some time back and did not get anyone to test it properly at the time, so the patch went in untested. So this is a fix. I think this should be applied as-is since you can actually test the whole thing on real hardware, and also add: Fixes: f3372c01816e "ARM: gemini: convert to GENERIC_CLOCKEVENTS" Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > I would love to see all those patches/drivers in mainline - tell me where do > I submit all that :) I recently looked at some of the patch stacks in OpenWRT and get a bit sad that the stuff did not go upstream, so I am ready to help in any way I can. Anything GPIO related I am ready to help in reviewing/applying and I will also help out with ARM32 if I can. Sadly I do not have a Gemini system. Yours, Linus Walleij
On Friday 10 July 2015 10:48:26 Linus Walleij wrote: > On Thu, Jul 9, 2015 at 6:48 PM, Roman Yeryomin <roman@advem.lv> wrote: > > [Me] > >> As usual they are just keeping it out of mainline, and this > >> is adding sched_clock() and other goodies so should > >> probably be upstreamed ASAP. > > > > > > This is what I initially submitted here. > > Ah. I missed part of the start of the discussion it seems. > > > But Arnd wanted to see a smaller patch which only fixes gemini timer issue > > (t.i. shed clock being 100Hz instead of 25MHz). > > Also I've submitted 4.1 support yesterday, but patches didn't change much > > comparing to 3.18 > > On the other hand I think the bigger patch is OK actually. > > I rewrote the timer support some time back and did not get > anyone to test it properly at the time, so the patch went in > untested. So this is a fix. The bigger patch seemed a little too verbose to have it backported to stable kernels, so I asked for a minimal fix that could be marked as stable, with the other changes applied on top for the current arm-soc tree. I'm still on parental leave and not dealing with patches directly, so whichever patch we want should get routed through Ulli to arm@kernel.org Arnd
Hi On Thu, 9 Jul 2015, Roman Yeryomin wrote: > On 2015-07-09 11:04, Arnd Bergmann wrote: > > On Thursday 09 July 2015 01:29:39 Roman Yeryomin wrote: > > > > > > OK, here are the minimal changes required (see attachment). Tested on > > > 4.1.1 > > > Let me know if you want me to submit it in some other way. > > > > > > > The changes look ok to me. Please submit them as two separate > > patches (1. set up and use timer3, 2. register sched_clock) according > > to the Documentation/SubmittingPatches description. > > > > So what do we do? > Do you still want me to split this as you said and submit or you want Hans's > patches rebased/resubmitted? > > Regards, > Roman > can you rebase your patches againt my branch at git://github.com/ulli-kroll/linux.git gemini/clockevents/4.3 I've added here the clockevents changes for 4.3 and patch fory arch/arm/mach-gemini This changes will then go arm@kernel.org. Hans Ulli
--- a/arch/arm/mach-gemini/time.c +++ b/arch/arm/mach-gemini/time.c @@ -15,6 +15,7 @@ #include <asm/mach/time.h> #include <linux/clockchips.h> #include <linux/clocksource.h> +#include <linux/sched_clock.h> /* * Register definitions for the timers @@ -34,9 +35,17 @@ #define TIMER_3_CR_ENABLE (1 << 6) #define TIMER_3_CR_CLOCK (1 << 7) #define TIMER_3_CR_INT (1 << 8) +#define TIMER_1_CR_UPDOWN (1 << 9) +#define TIMER_2_CR_UPDOWN (1 << 10) +#define TIMER_3_CR_UPDOWN (1 << 11) static unsigned int tick_rate; +static u64 notrace gemini_read_sched_clock(void) +{ + return readl(TIMER_COUNT(IO_ADDRESS(GEMINI_TIMER3_BASE))); +} + static int gemini_timer_set_next_event(unsigned long cycles, struct clock_event_device *evt) { @@ -155,14 +164,18 @@ void __init gemini_timer_init(void) */ setup_irq(IRQ_TIMER2, &gemini_timer_irq); - /* Enable and use TIMER1 as clock source */ - writel(0xffffffff, TIMER_COUNT(IO_ADDRESS(GEMINI_TIMER1_BASE))); - writel(0xffffffff, TIMER_LOAD(IO_ADDRESS(GEMINI_TIMER1_BASE))); - writel(TIMER_1_CR_ENABLE, TIMER_CR(IO_ADDRESS(GEMINI_TIMER_BASE))); - if (clocksource_mmio_init(TIMER_COUNT(IO_ADDRESS(GEMINI_TIMER1_BASE)), - "TIMER1", tick_rate, 300, 32, + /* Enable and use TIMER3 as clock source */ + writel(0, TIMER_COUNT(IO_ADDRESS(GEMINI_TIMER3_BASE))); + writel(0, TIMER_LOAD(IO_ADDRESS(GEMINI_TIMER3_BASE))); + writel(0, TIMER_MATCH1(IO_ADDRESS(GEMINI_TIMER3_BASE))); + writel(0, TIMER_MATCH2(IO_ADDRESS(GEMINI_TIMER3_BASE))); + writel(TIMER_3_CR_ENABLE | TIMER_3_CR_UPDOWN, + TIMER_CR(IO_ADDRESS(GEMINI_TIMER_BASE))); + if (clocksource_mmio_init(TIMER_COUNT(IO_ADDRESS(GEMINI_TIMER3_BASE)), + "TIMER3", tick_rate, 300, 32, clocksource_mmio_readl_up)) pr_err("timer: failed to initialize gemini clock source\n"); + sched_clock_register(gemini_read_sched_clock, 32, tick_rate); /* Configure and register the clockevent */ clockevents_config_and_register(&gemini_clockevent, tick_rate,