svn commit: r244899 - head/sys/mips/beri

[Andrew Turner]

On Wed, 2 Jan 2013 11:01:27 +0000
"Robert N. M. Watson" <rwatson at FreeBSD.org> wrote:

> 
> On 1 Jan 2013, at 22:08, Andrew Turner wrote:
> 
> >> On a semi-related note: the current obstacle to moving more devices
> >> over to using FDT on BERI is that our FDT implementation appears to
> >> require a PIC to be configured. We're not actually using a PIC on
> >> BERI currently. It works fine attached to nexus, as the implied
> >> fallback for not having a PIC is to simply use the suitably
> >> numbered interrupt wires direct into the MIPS. However, trying the
> >> same setup described using FDT leads to an interrupt-related
> >> warning at boot, and no interrupt being provided to the driver. I
> >> suspect I need to provide a PIC-alike software component as a
> >> fall-back for the non-PIC case. From a brief e-mail exchange with
> >> JC, it sounds like the XLP FDT setup is actually not using
> >> interrupts either, currently.
> > 
> > I'm not sure if a PIC is required. From my reading of the code it
> > appears not. By the look of it if you are using the nexus to
> > handle interrupts you need to put an interrupts property in the
> > device and "#interrupt-cells = <1>;" in the soc node.
> > 
> > You will also need to implement an interrupt decode function and
> > add it to the fdt_pic_table array. ARM has a number of almost
> > identical copies of this function you can use for inspration.
> 
> 
> This seemed to do the trick; what do you think of the attached? This
> isn't a board-specific change, so I dropped it into the common
> fdt_mips.c code. On the other hand, this left it a bit open as to
> what the right compatible= line to use was, so feedback there most
> welcome.

The patch looks good. From my reading of [1] the compatible value
should be something like "mips,mips4k" as it's value is of the form
"<manufacturer>,<model>".

I have been thinking the best way of merging these almost identical
decode functions. Linux appears to do it by providing a per-controller
function that can translate between the interrupt spec and the
configuration allowing them to have a generic parsing function that
doesn't need to check if the controller is compatible. I would like us
to have something similar as it will remove the duplicate function.

Andrew

[1] http://www.devicetree.org/Device_Tree_Usage