All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amol <suratiamol@gmail.com>
To: qemu-devel@nongnu.org
Cc: suratiamol <suratiamol@gmail.com>
Subject: [ppc/pnv9] clarification on QEMU's dtb
Date: Wed, 16 Mar 2022 20:35:38 +0530	[thread overview]
Message-ID: <CA+nuEB-fNNSgZKPzWR4Ord2QmCrsnpY9Y7Erzw1RLob+eY9ksw@mail.gmail.com> (raw)

Hello,

Below is a part of the dtb file as generated by
qemu's powernv9 emulation:

/ {
	....
	compatible = "qemu,powernv9\0ibm,powernv";
	model = "IBM PowerNV (emulated by qemu)";
	pciex@600c3c0000000 {
		compatible = "ibm,power9-pciex\0ibm,ioda3-phb";
		device_type = "pciex";
		....
		#address-cells = <0x03>;
		#size-cells = <0x02>;
		#interrupt-cells = <0x01>;
		interrupt-parent = <0x804e>;
		ranges = <0x2000000 0x00 0x80000000 0x600c0 0x00 0x00 0x7fff0000>;
		....
		pci@0 {
			interrupts = <0x01>;
			#address-cells = <0x03>;
			#size-cells = <0x02>;
			#interrupt-cells = <0x01>;
			interrupt-map-mask = <0x00 0x00 0x00 0x07>;
			interrupt-map =
<0x00 0x00 0x00 0x01 0x804e 0xfeff8 0x01
 0x00 0x00 0x00 0x02 0x804e 0xfeff9 0x01
 0x00 0x00 0x00 0x03 0x804e 0xfeffa 0x01
 0x00 0x00 0x00 0x04 0x804e 0xfeffb 0x01>;
			ranges = <0x2000000 0x00 0x00 0x2000000 0x00 0x00 0xf0000000 0x00>;
		};
	};

Of interest is the "interrupts = <0x01>;" property of the pci@0 node.
Its parent, the
ioda3 node, has an "#interrupt-cells = <0x01>;" property which I
believe drives the
interrupts specification within the pci@0 node.

Then, shouldn't the parent also drive the mapping of pci@0's
"interrupts = <0x01>;"
property? That is, shouldn't the parent (ioda3) contain the
interrupt-map and not
pci@0?

If pci@0 is the proper place to contain the interrupt-map, doesn't
that conflict with
the generic handling of its "interrupts" property, since I believe,
one looks for the
interrupt-parent to determine the format. Here, the interrupt parent,
0x804e, has
#interrupt-cells set to 2, so the "interrupts" specifier of a single
cell inside pci@0
seems to be in direct conflict with that handling.

Or is the spec defined such that if a node has interrupt-map property,
that node's
interrupt spec need not be according to the parent interrupt
controllers requirement?
But then the example inside "Advanced Interrupt Mapping" section of
[1] seems to be
wrong.

I checked a dtb, linked at at [2], seemingly captured from a hardware
machine, and
found no such violation at least among the pci nodes. In it, there is
a pci@0 node with
"interrupts = <0x01>", but it does have a parent with interrupt-map
which can translate
that specifier into one which can be understood by the target
interrupt controller.

It seems that qemu is generating (or basing its modifications on) an
incorrectly specified
dtb.

Thanks,
Amol

[1] https://elinux.org/Device_Tree_Usage#Advanced_Interrupt_Mapping
[2] https://people.freebsd.org/~jhibbits/p9_vga_out_devtree.txt


             reply	other threads:[~2022-03-16 15:13 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-16 15:05 Amol [this message]
2022-03-16 15:47 ` [ppc/pnv9] clarification on QEMU's dtb Amol

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+nuEB-fNNSgZKPzWR4Ord2QmCrsnpY9Y7Erzw1RLob+eY9ksw@mail.gmail.com \
    --to=suratiamol@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.