From: Hanjun Guo <guohanjun@huawei.com>
To: "Pankaj Bansal (OSS)" <pankaj.bansal@oss.nxp.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Marc Zyngier <maz@kernel.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Makarand Pawagi <makarand.pawagi@nxp.com>,
Calvin Johnson <calvin.johnson@nxp.com>,
"stuyoder@gmail.com" <stuyoder@gmail.com>,
"nleeder@codeaurora.org" <nleeder@codeaurora.org>,
Ioana Ciornei <ioana.ciornei@nxp.com>,
Cristi Sovaiala <cristian.sovaiala@nxp.com>,
"Will Deacon" <will@kernel.org>,
"jon@solid-run.com" <jon@solid-run.com>,
"Russell King" <linux@armlinux.org.uk>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Len Brown <lenb@kernel.org>, Jason Cooper <jason@lakedaemon.net>,
Andy Wang <Andy.Wang@arm.com>, Varun Sethi <V.Sethi@nxp.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
Laurentiu Tudor <laurentiu.tudor@nxp.com>,
Paul Yang <Paul.Yang@arm.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>,
Sudeep Holla <sudeep.holla@arm.com>,
Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
Date: Tue, 18 Feb 2020 20:24:56 +0800 [thread overview]
Message-ID: <615c6807-c018-92c9-b66a-8afdda183699@huawei.com> (raw)
In-Reply-To: <VI1PR04MB5135D7D8597D33DB76DA05BDB0110@VI1PR04MB5135.eurprd04.prod.outlook.com>
Hi Pankaj,
On 2020/2/18 16:00, Pankaj Bansal (OSS) wrote:
[...]
>>>> Side note: would you mind removing the email headers (as above) in your
>>>> replies please ?
>>
>> Read the question above please.
>>
>> [...]
>>
>>>>> As stated above, in Linux MC is a bus (just like PCI bus, AMBA bus etc)
>>>>> There can be multiple devices attached to this bus. Moreover, we can
>>>> dynamically create/destroy these devices.
>>>>> Now, we want to represent this BUS (not individual devices connected to
>> bus)
>>>> in IORT table.
>>>>> The only possible way right now we see is that we describe it as Named
>>>> components having a pool of ID mappings.
>>>>> As and when devices are created and attached to bus, we sift through this
>> pool
>>>> to correctly determine the output ID for the device.
>>>>> Now the input ID that we provide, can come from device itself.
>>>>> Then we can use the Platform MSI framework for MC bus devices.
>>>>
>>>> So are you asking me if that's OK ? Or there is something you can't
>>>> describe with IORT ?
>>>
>>> I am asking if that would be acceptable?
>>> i.e. we represent MC bus as Named component is IORT table with a pool of IDs
>> (without single ID mapping flag)
>>> and then we use the Platform MSI framework for all children devices of MC
>> bus.
>>> Note that it would require the Platform MSI layer to correctly pass an input id
>> for a platform device to IORT layer.
>>
>> How is this solved in DT ? You don't seem to need any DT binding on top
>> of the msi-parent property, which is equivalent to IORT single mappings
>> AFAICS so I would like to understand the whole DT flow (so that I
>> understand how this FSL bus works) before commenting any further.
>
> In DT case, we create the domain DOMAIN_BUS_FSL_MC_MSI for MC bus and it's children.
> And then when MC child device is created, we search the "msi-parent" property from the MC
> DT node and get the ITS associated with MC bus. Then we search DOMAIN_BUS_FSL_MC_MSI
> on that ITS. Once we find the domain, we can call msi_domain_alloc_irqs for that domain.
>
> This is exactly what we tried to do initially with ACPI. But the searching DOMAIN_BUS_FSL_MC_MSI
> associated to an ITS, is something that is part of drivers/acpi/arm64/iort.c.
> (similar to DOMAIN_BUS_PLATFORM_MSI and DOMAIN_BUS_PCI_MSI)
Can you have a look at mbigen driver (drivers/irqchip/irq-mbigen.c) to see if
it helps you?
mbigen is an irq converter to convert device's wired interrupts into MSI
(connecting to ITS), which will alloc a bunch of MSIs from ITS platform MSI
domain at the setup.
Thanks
Hanjun
next prev parent reply other threads:[~2020-02-18 12:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-18 8:00 Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc Pankaj Bansal (OSS)
2020-02-18 12:24 ` Hanjun Guo [this message]
2020-02-18 12:48 ` Pankaj Bansal (OSS)
2020-02-18 14:46 ` Lorenzo Pieralisi
2020-02-18 15:15 ` Robin Murphy
2020-02-19 3:33 ` Pankaj Bansal (OSS)
2020-02-18 15:24 ` Diana Craciun OSS
-- strict thread matches above, loose matches on Subject: below --
2020-01-28 8:08 Makarand Pawagi
2020-01-28 10:58 ` Marc Zyngier
2020-01-28 11:09 ` Lorenzo Pieralisi
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=615c6807-c018-92c9-b66a-8afdda183699@huawei.com \
--to=guohanjun@huawei.com \
--cc=Andy.Wang@arm.com \
--cc=Paul.Yang@arm.com \
--cc=V.Sethi@nxp.com \
--cc=ard.biesheuvel@linaro.org \
--cc=calvin.johnson@nxp.com \
--cc=cristian.sovaiala@nxp.com \
--cc=ioana.ciornei@nxp.com \
--cc=jason@lakedaemon.net \
--cc=jon@solid-run.com \
--cc=laurentiu.tudor@nxp.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=lorenzo.pieralisi@arm.com \
--cc=makarand.pawagi@nxp.com \
--cc=maz@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nleeder@codeaurora.org \
--cc=pankaj.bansal@oss.nxp.com \
--cc=rjw@rjwysocki.net \
--cc=robin.murphy@arm.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=stuyoder@gmail.com \
--cc=sudeep.holla@arm.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).