[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53F44022.6030706@huawei.com>
Date: Wed, 20 Aug 2014 14:28:50 +0800
From: Yijing Wang <wangyijing@...wei.com>
To: "Bharat.Bhushan@...escale.com" <Bharat.Bhushan@...escale.com>,
"arnab.basu@...escale.com" <arnab.basu@...escale.com>
CC: Xinwei Hu <huxinwei@...wei.com>, Wuyun <wuyun.wu@...wei.com>,
"Bjorn Helgaas" <bhelgaas@...gle.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"Paul.Mundt@...wei.com" <Paul.Mundt@...wei.com>,
"James E.J. Bottomley" <jejb@...isc-linux.org>,
Marc Zyngier <marc.zyngier@....com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Russell King <linux@....linux.org.uk>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"virtualization@...ts.linux-foundation.org"
<virtualization@...ts.linux-foundation.org>,
Hanjun Guo <guohanjun@...wei.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 00/11] Refactor MSI to support Non-PCI device
>> 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, then when we call msi_chip->setup_irq(), the device
>> MSI registers can be configured appropriately.
>
> What if we can register/override the setup_irq() from bus-driver (not sure, but may be device-driver itself). Example PCI bus-driver will provide setup_irq() (or the part of setup_irq which set address and data in h/w) by PCI bus, which configure address/data in h/w as per PCI standard.
>
> 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 to know your MSI device working mode.
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. I'm working on a new MSI setup framework, as you mentioned before, in device-driver model.
I abstracted a new virtual device (called struct msi_dev), this msi_dev will manage all MSI info, and a new bus
named msi_bus, also introduced a new driver msi_driver, msi_bus is responsible for binding msi_dev and msi_driver.
All MSI devices will be classified into different MSI device types, like MSI_TYPE_PCI, MSI_TYPE_HPET, MSI_TYPE_DMAR, etc..
Each MSI type device should provide a private struct msi_driver. msi_driver should contain the type specific
MSI ops functions to help setup and enable MSI device, request MSI irq.
I almost finish the first draft, and will post out next week in plan :)
Thanks!
Yijing.
>
> Thanks
> -Bharat
>
>>
>> My patchset is just a RFC draft, I will update it later, all we want to do is
>> make kernel support Non-PCI MSI devices.
>>
>> Thanks!
>> Yijing.
>>
>>
>>>
>>> Thanks
>>> Arnab
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-kernel" in the body of a message to majordomo@...r.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>>>
>>> .
>>>
>>
>>
>> --
>> Thanks!
>> Yijing
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body
>> of a message to majordomo@...r.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
>
> .
>
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists