[J-core] How the IRQ/timer stuff works.

[Joh-Tob Schäg]

On Mon, 28 Oct 2019 at 23:46, Rob Landley <rob at landley.net> wrote:
[...]
>
> And the guts of jcore_pit_local_init() are:
>
>         buspd = readl(pit->base + REG_BUSPD);
>         freq = DIV_ROUND_CLOSEST(NSEC_PER_SEC, buspd);
>         pit->periodic_delta = DIV_ROUND_CLOSEST(NSEC_PER_SEC, HZ * buspd);
>
>         clockevents_config_and_register(&pit->ced, freq, 1, ULONG_MAX);

This initialization seems very useful.

>
> And then here are the set/disable functions that actually seem to switch the PIT
> on and off:
>
> static int jcore_pit_disable(struct jcore_pit *pit)
> {
>         writel(0, pit->base + REG_PITEN);
>         return 0;
> }
>
> static int jcore_pit_set(unsigned long delta, struct jcore_pit *pit)
> {
>         jcore_pit_disable(pit);
>         writel(delta, pit->base + REG_THROT);
>         writel(pit->enable_val, pit->base + REG_PITEN);
>         return 0;
> }
>
About as i had it in mind. Although there is a different way to
disable interrupts by setting the mask in status register (SR) to 15
(only Non mask-able interrupts are possible then). It is not obvious
to me what way is preferred or superior.

> (Note: that enable_val is the one we worked out in the init function, it gets
> marshalled into the structure in that percpu stuff I glossed over.)
>
> And here's a BIG COMMENT in the file that's hopefully helpful:
[...]
> * However only traps 64-127 an be programmed (the high 2 bits of i are ignored)
This claim needs to be checked. I think it only applies to linux since
i do not remember having trouble with TRAPA or interrupts with high
numbers. Needs checking
[..]
>
> There's one important unanswered question, which is when an interrupt gets
> called, where is the address of the function to jump to?

I know this. There is register called VBR, Vector Base Register and it
contains the pointer of an array of function pointers. Nth interrupt
executes function which is pointed to by nth array slot.

>
> Kinda buries where that address gets written, I can try to dig it up if that's
> helpful? I'm guessing it's in
> https://www.renesas.com/us/en/doc/products/mpumcu/001/rej09b0171_superh.pdf
> somewhere though?
>
> Rob
>
>
>
> -------- Forwarded Message --------
> Subject: Re: It looks like my Mimas runs an AIC2 (the second version)???
> Date: Thu, 8 Aug 2019 19:45:30 -0500
> From: Rob Landley <rob at landley.net>
> To: Joh-Tob Schäg <johtobsch at gmail.com>, D. Jeff Dionne <jeff at coresemi.io>
>
> On 8/8/19 5:51 PM, Joh-Tob Schäg wrote:
> > Rob in all his magic could dig out some old code for the AIC1.
>
> I think it's for AIC2? I dug through the _current_ linux source (from torvalds'
> github which is updated daily-ish), which I know runs on the bitstreams I sent
> you. (Or did last month anyway.)
>


> > struct aic_regs {
> >   uint32_t ctrl0;
> >   uint32_t brkadd;
> >   uint32_t ilevels;
> >   uint32_t ctrl1;
> >   uint32_t pit_throttle;
> >   uint32_t pit_counter;
> >   uint32_t clock_period; // read-only
> >   uint32_t ignore0;
> >   uint32_t rtc_sec_hi;
> >   uint32_t rtc_sec_lo;
> >   uint32_t rtc_nsec;
> > };
> >  0  0000 - "00000" & pit_enable & count_enable & brk_enable & testvect & count
> >  1  0001 - brkadd
> >  2  0010 - ilevels
> >  3  0011 - irq_i & q_irqs & pit_flag & db_ackcount & db_count
> >  4  0100 - PIT throttle
> >  5  0101 - PIT counter
> >  6  0110 - Bus clock period in nanoseconds
> >  7  0111 - zero
> >  8  1000 - RTC seconds upper 32 bits
> >  9  1001 - RTC seconds lower 32 bits
> > 10  1010 - RTC nanoseconds
> > 11  1011 - zero
>
^^ These structures are for reading only, ilevels are still set via
the first control register.

> There's actually only 10 that matter because 2 are hardwired to 0, so:
>
> #define AIC_CTRL1     0 // pit_enable, count_enable, brk_enable, testvect, count
> #define AIC_BRKADD    1
> #define AIC_ILEVELS   2
> #define AIC_CTRL2     3 // irq_i, q_irqs, pit_flag, db_ackcount, db_count
> #define AIC_PIT_THROT 4 // PIT throttle
> #define AIC_PIT_CNT   5 // PIT counter
> #define AIC_BUS_CLK   6 // bus clock period in nanoseconds
> #define AIC_RTC_EPOCH 8 // RTC seconds upper 32 bits
> #define AIC_RTC_SEC   9 // RTC seconds lower 32 bits
> #define AIC_RTC_NANO 10 // RTC nanoseconds
>
> And _really_, AIC is at 0xabcd0200 and RTC is at 0xabcd0220 so remove the last 3
> from there and instead define a second pointer, and index it with:
>
> #define RTC_EPOCH 0
> #define RTC_SEC   1
> #define RTC_NANO  2
>
> > matches the structure described in aic_regs from board.h.  What leaves
> > my puzzled is that there is another file called "aic2.vhd" . Maybe
> > "aic.vhd" describes the first version instead???
>
> Could be there was a complete rewrite started and then we wound up just
> modifying the original one instead of replacing it? Dunno, you'd have to ask
> Niishi or Arakawa. (Or look in the repository history to see what the checkin
> comments were when the file was created. There were some tight deadlines to get
> demos out before tradeshows and such...)
It is currently not a priority. I just wanted to know whether i missed
anything about cyclic interrupts.
>
> Jeff said he had something like 22 hours of travel ahead of him and should next
> be available sometime late saturday, but hopefully that gets you unblocked?
This is not what i was blocked with but it will help in the future.
>
> Now we have to work out how the AIC_CTRL1 and AIC_CTRL2 work because it looks
> like lots of control bits packed together into the same field. (More VHDL
> reading I expect...) Also, what are BRKADD, ILEVELS, and PIT_THROT? (I can see
> PIT_CNT letting you know if you missed an interrupt?)
BRKADD is the address of the break point but i could never got this
working by mere poking.
ILEVELS is the priority of the interrupt, this is compared against a
part of some CPU system register. The interrupt only happens when is
bigger(?) than the content of the register.