On 01/17/2014 03:04 AM, Nathan Whitehorn wrote:
On 01/16/14 18:36, Julien Grall wrote:

The specification is actually a little unclear on this point, but
FreeBSD follows the same rules as Linux in any case. Most, if not all,
FreeBSD code should check any ancestor at this point as well. In
particular fdt_intr_to_rl does this. What it *doesn't* do is allow
#interrupt-cells to be larger than 2. I'll fix this this weekend.

Thanks, for working on this part.

Another things to take into account: the first cell doesn't always contain the interrupt.
With the Linux binding (#interrupt-cells == 3)
  - cell 1: 1 or 0 (PPI vs SPI)
  - cell 2: relative IRQ number to the start of PPI/SPI
  - cell 3: cpu mask + interrupt flags (edge/level...)

On the subject of simple-bus, they usually aren't necessary. For
example, all hypervisor devices on IBM hardware live under /vdevice,
which is attached to the device tree root. They don't use MMIO, so
simple-bus doesn't really make sense. How does Xen communicate with the
OS in these devices?

As I understand, only the simple bus code (see simplebus_attach) is
translating the interrupts in the device on a resource.
So if you have a node directly attached to the root node with
interrupts and MMIO, the driver won't be able to retrieve and
translate the interrupts via bus_alloc_resources.

Why not? nexus on ARM, MIPS, PowerPC, and sparc64 can do this.

I have noticed at least one issue (which is not related to my problem):
- When the OFW nexus translate IRQ (with #interrupt-cells > 1), the rid will be equal to 0, 0 + #interrupt-cells, ... So the number will be discontinued. Rather than on simple-bus for the same device, the rid will be 0, 1, 2...

For my issue, I will look at it again this week-end.

BTW when I look to the FDT (sys/dev/fdt_common.c) and the ofw (sys/dev/ofw_nexus.c) code, I have notice that lots of code are duplicated.

It would be nice to have common helper to avoid duplicate code and issue for the future :).

Julien Grall
freebsd-xen@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Reply via email to