>> Provide the private MSI setup functions in bus-driver layer can't apply to
>> all
>> Non-PCI MSI devices, because we can not guarantee Non-PCI MSI devices are
>> always
>> on a bus. The existing HPET, DMAR device both have no bus bind.
>
> Yes, that's why I was not sure of bus-driver or devic
>>> We in Freescale will be using MSI for the devices behind a new-bus (which is
>> not PCI based), We have a separate bus driver for same. And this new bus
>> driver
>> register/provide its own address/data write function which is based on that
>> specific bus protocol.
>>
>> Hi Bharat, I'm glad
..@vger.kernel.org;
> paul.mu...@huawei.com; James E.J. Bottomley; Marc Zyngier; linux-arm-
> ker...@lists.infradead.org; Russell King; linux-a...@vger.kernel.org;
> virtualization@lists.linux-foundation.org; Hanjun Guo; linux-
> ker...@vger.kernel.org
> Subject: Re: [RFC PATCH 00/11
>> The key difference between PCI device and Non-PCI MSI is the interfaces to
>> access hardware MSI registers.
>> for instance, currently, msi_chip->setup_irq() to setup MSI irq and configure
>> the MSI address/data registers, so we need to provide device specific
>> write_msi_msg() interface, the
nel.org;
> paul.mu...@huawei.com; James E.J. Bottomley; Marc Zyngier; linux-arm-
> ker...@lists.infradead.org; Russell King; linux-a...@vger.kernel.org;
> virtualization@lists.linux-foundation.org; Hanjun Guo; linux-
> ker...@vger.kernel.org
> Subject: Re: [RFC PATCH 00/11] Refactor MSI to suppo
On 2014/8/4 22:45, Arnd Bergmann wrote:
> On Monday 04 August 2014, Yijing Wang wrote:
>> I have another question is some drivers will request more than one
>> MSI/MSI-X IRQ, and the driver will use them to process different things.
>> Eg. network driver generally uses one of them to process trivia
>>> The method you describe here makes sense for PCI devices that are required
>>> to support
>>> legacy interrupts and may or may not support MSI on a given system, but not
>>> so much
>>> for platform devices for which we know exactly whether we want to use MSI
>>> or legacy interrupts.
>>>
>>>
arc Zyngier; linux-arm-
> ker...@lists.infradead.org; Russell King; linux-a...@vger.kernel.org;
> Basu Arnab-B45036; virtualization@lists.linux-foundation.org; Hanjun Guo;
> Yijing Wang
> Subject: [RFC PATCH 00/11] Refactor MSI to support Non-PCI device
>
> Hi all,
> The
On Monday 04 August 2014, Yijing Wang wrote:
> On 2014/8/1 21:52, Arnd Bergmann wrote:
> > On Wednesday 30 July 2014, Yijing Wang wrote:
> >> On 2014/7/29 22:08, Arnd Bergmann wrote:
> >>> The other part I'm not completely sure about is how you want to
> >>> have MSIs map into normal IRQ descriptor
On Monday 04 August 2014, Yijing Wang wrote:
> I have another question is some drivers will request more than one
> MSI/MSI-X IRQ, and the driver will use them to process different things.
> Eg. network driver generally uses one of them to process trivial network
> thins,
> and others to transmit/
On 2014/8/1 21:52, Arnd Bergmann wrote:
> On Wednesday 30 July 2014, Yijing Wang wrote:
>> On 2014/7/29 22:08, Arnd Bergmann wrote:
>>> On Saturday 26 July 2014 11:08:37 Yijing Wang wrote:
The new data struct for generic MSI driver.
struct msi_irqs {
u8 msi_enabled:1; /*
On 2014/8/1 21:16, Arnd Bergmann wrote:
> On Wednesday 30 July 2014, Yijing Wang wrote:
>
> The other part I'm not completely sure about is how you want to
> have MSIs map into normal IRQ descriptors. At the moment, all
> MSI users are based on IRQ numbers, but this has known scalab
>> MSI was introduced in PCI Spec 2.2. Currently, kernel MSI driver codes
>> are bonding with PCI device. Because MSI has a lot advantages in design.
>> More and more non-PCI devices want to use MSI as their default interrupt.
>> The existing MSI device include HPET. HPET driver provide its own MSI
On Wednesday 30 July 2014, Yijing Wang wrote:
> On 2014/7/29 22:08, Arnd Bergmann wrote:
> > On Saturday 26 July 2014 11:08:37 Yijing Wang wrote:
> >>
> >> The new data struct for generic MSI driver.
> >> struct msi_irqs {
> >> u8 msi_enabled:1; /* Enable flag */
> >> u8 msix_enable
On Wednesday 30 July 2014, Yijing Wang wrote:
> >>>
> >>> The other part I'm not completely sure about is how you want to
> >>> have MSIs map into normal IRQ descriptors. At the moment, all
> >>> MSI users are based on IRQ numbers, but this has known scalability
> >>> problems.
> >>
> >> Hmmm, I s
On 2014/7/30 10:45, Yijing Wang wrote:
> On 2014/7/29 22:08, Arnd Bergmann wrote:
>> On Saturday 26 July 2014 11:08:37 Yijing Wang wrote:
>>> The series is a draft of generic MSI driver that supports PCI
>>> and Non-PCI device which have MSI capability. If you're not interested
>>> it, so
On 2014/7/30 14:47, Jiang Liu wrote:
>
>
> On 2014/7/30 10:45, Yijing Wang wrote:
>> On 2014/7/29 22:08, Arnd Bergmann wrote:
>>> On Saturday 26 July 2014 11:08:37 Yijing Wang wrote:
The series is a draft of generic MSI driver that supports PCI
and Non-PCI device which have MSI
On 2014/7/29 22:08, Arnd Bergmann wrote:
> On Saturday 26 July 2014 11:08:37 Yijing Wang wrote:
>> The series is a draft of generic MSI driver that supports PCI
>> and Non-PCI device which have MSI capability. If you're not interested
>> it, sorry for the noise.
>
> I've finally managed to
On Saturday 26 July 2014 11:08:37 Yijing Wang wrote:
> The series is a draft of generic MSI driver that supports PCI
> and Non-PCI device which have MSI capability. If you're not interested
> it, sorry for the noise.
I've finally managed to take some time to look at the series. Overall,
th
Hi all,
The series is a draft of generic MSI driver that supports PCI
and Non-PCI device which have MSI capability. If you're not interested
it, sorry for the noise.
The series is based on Linux-3.16-rc1.
MSI was introduced in PCI Spec 2.2. Currently, kernel MSI
driver codes are bonding
20 matches
Mail list logo
