[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen on ARM GIC setup
On Wed, 2013-06-05 at 10:29 +0200, Sander Bogaert wrote: > On 4 June 2013 23:23, Julien Grall <julien.grall@xxxxxxxxxx> wrote: > > I forgot to cc Sander. > > > > On 06/04/2013 10:21 PM, Julien Grall wrote: > > > >> On 06/04/2013 08:42 PM, Sander Bogaert wrote: > >> > >>> Hi, > >> > >> Hi, > >> > >>> I was going over this part of the gic setup code ( gic.c:gic_dist_init ): > >>> > >>> type = GICD[GICD_TYPER]; > >>> gic.lines = 32 * (type & GICD_TYPE_LINES); > >>> .... > >>> /* Disable all global interrupts */ > >>> for ( i = 32; i < gic.lines; i += 32 ) > >>> GICD[GICD_ICENABLER + i / 32] = (uint32_t)~0ul; > >> > >> It seems you have an old tree :). A commit (2f2a3e31) was pushed at the > >> end of april to fix this issue. > > Ok I see :) Having different trees because of the other issue I mailed > about and I was looking in the wrong one. But now that I'm at it > anyway, same part of the code: > > /* Default all global IRQs to level, active low */ > for ( i = 32; i < gic.lines; i += 16 ) > GICD[GICD_ICFGR + i / 16] = 0x0; > > /* Route all global IRQs to this CPU */ > for ( i = 32; i < gic.lines; i += 4 ) > GICD[GICD_ICFGR + i / 4] = cpumask; > > Shouldn't that second loop use the GICD_ITARGETSR register? Just > aksing :-) Seems strange to set the same field with different values > right after eachother also the += 4 loop doesn't make sense for it > since it's two bit each interrupt line. It would make sense for > ITARGETSR. Yeah, that looks like a bug... _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |