All of lore.kernel.org
 help / color / mirror / Atom feed
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


WARNING: multiple messages have this Message-ID (diff)
From: Hanjun Guo <guohanjun@huawei.com>
To: "Pankaj Bansal (OSS)" <pankaj.bansal@oss.nxp.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Calvin Johnson <calvin.johnson@nxp.com>,
	"stuyoder@gmail.com" <stuyoder@gmail.com>,
	"nleeder@codeaurora.org" <nleeder@codeaurora.org>,
	Cristi Sovaiala <cristian.sovaiala@nxp.com>,
	Ioana Ciornei <ioana.ciornei@nxp.com>,
	Will Deacon <will@kernel.org>, Marc Zyngier <maz@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>,
	Makarand Pawagi <makarand.pawagi@nxp.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>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	"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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-02-18 12:26 UTC|newest]

Thread overview: 19+ 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:24   ` Hanjun Guo
2020-02-18 12:48   ` Pankaj Bansal (OSS)
2020-02-18 12:48     ` Pankaj Bansal (OSS)
2020-02-18 14:46     ` Lorenzo Pieralisi
2020-02-18 14:46       ` Lorenzo Pieralisi
2020-02-18 15:15       ` Robin Murphy
2020-02-18 15:15         ` Robin Murphy
2020-02-19  3:33         ` Pankaj Bansal (OSS)
2020-02-19  3:33           ` Pankaj Bansal (OSS)
2020-02-18 15:24       ` Diana Craciun 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  8:08 ` Makarand Pawagi
2020-01-28 10:58 ` Marc Zyngier
2020-01-28 10:58   ` Marc Zyngier
2020-01-28 11:09 ` Lorenzo Pieralisi
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 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.