All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Thierry Reding <thierry.reding@avionic-design.de>
Cc: Andrew Murray <andrew.murray@arm.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Arnd Bergmann <arnd@arndb.de>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC 0/2] PCI: Introduce MSI chip infrastructure
Date: Mon, 25 Mar 2013 09:38:47 +0100	[thread overview]
Message-ID: <20130325093847.7474dc0e@skate> (raw)
In-Reply-To: <20130325075810.GA28935@avionic-0098.mockup.avionic-design.de>

Dear Thierry Reding,

Thanks for your feedback!

On Mon, 25 Mar 2013 08:58:10 +0100, Thierry Reding wrote:

> That sounds very much like one of the use-cases that were discussed. The
> easiest solution would probably be to add an API to look up an MSI chip
> from a DT phandle, so that the PCIe controller's device node could have
> it as a property, somewhat like this:
> 
> 	msi: interrupt-controller {
> 	};
> 
> 	pcie-controller {
> 		...
> 		marvell,msi = <&msi>;
> 		...
> 	};

I'm not sure how to handle this msi interrupt controller with the main
interrupt controller. For now, I have:

        mpic: interrupt-controller@d0020000 {
              reg = <0xd0020a00 0x2d0>,
                    <0xd0021070 0x58>;
        };

	[...]

	soc {
                interrupt-parent = <&mpic>;
		[...]
	};

And the MSI interrupt controller shares the same registers as the MPIC.
So should it be something like:

	interrupt-controller {
		reg = <0xd0020a00 0x2d0>,
                    <0xd0021070 0x58>;

		mpic {
			/* Not sure what to have here */
		};

		msi {

			/* Here either */
		};
	};

	soc {
                interrupt-parent = <&mpic>;

		pcie-controller {
			marvell,msi = <&msi>;
		};
	};

Or some other idea?

> Then add some basic infrastructure to register the MSI chip with a
> global list, call that from the interrupt controller initialization:
> 
> 	...
> 	msi_chip_add(&msi);
> 	...
> 
> And finally look it up from the PCIe controller driver:
> 
> 	node = of_parse_phandle(dev->of_node, "marvell,msi", 0);
> 	if (node)
> 		msi = of_find_msi_chip_by_node(node);
> 
> That's roughly what other subsystems do. I wrote something similar once
> for backlight devices, though the registration step (msi_chip_add)
> wasn't necessary there since backlight devices all go into a common
> struct class so class_find_device() can be used instead of going through
> a separate registry.

Ok, that part sounds good to me. I'm still unsure about the DT
representation, though (see above), and experience has shown that's
it's a pretty good idea to discuss a little bit the DT representation
before going on with some code :)

Thanks again for your feedback!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2013-03-25  8:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-22  8:51 [RFC 0/2] PCI: Introduce MSI chip infrastructure Thierry Reding
2013-03-22  8:51 ` [RFC 1/2] PCI: Introduce new " Thierry Reding
2013-03-22  9:37   ` Andrew Murray
2013-03-22 10:00     ` Thierry Reding
2013-03-22  8:51 ` [RFC 2/2] PCI: tegra: Use " Thierry Reding
2013-03-25 17:01   ` Stephen Warren
2013-03-25 20:02     ` Thierry Reding
2013-03-22  9:30 ` [RFC 0/2] PCI: Introduce " Andrew Murray
2013-03-24 11:06   ` Thomas Petazzoni
2013-03-25  7:58     ` Thierry Reding
2013-03-25  8:38       ` Thomas Petazzoni [this message]
2013-03-25  9:15         ` Thierry Reding
2013-03-25  9:29           ` Arnd Bergmann

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=20130325093847.7474dc0e@skate \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=andrew.murray@arm.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=thierry.reding@avionic-design.de \
    /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.