search for: msi_dev

...bus. The existing HPET, DMAR device both have no bus bind. Yes, that's why I was not sure of bus-driver or device-driver model. > 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, Will this "struct msi_dev" will be part of "struct device"? > 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 cla...

...bus. The existing HPET, DMAR device both have no bus bind. Yes, that's why I was not sure of bus-driver or device-driver model. > 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, Will this "struct msi_dev" will be part of "struct device"? > 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 cla...

Hi Yijing > -----Original Message----- > From: linux-pci-owner at vger.kernel.org [mailto:linux-pci-owner at vger.kernel.org] > On Behalf Of Yijing Wang > Sent: Monday, August 04, 2014 8:34 AM > To: Basu Arnab-B45036 > Cc: Xinwei Hu; Wuyun; Bjorn Helgaas; linux-pci at vger.kernel.org; > Paul.Mundt at huawei.com; James E.J. Bottomley; Marc Zyngier; linux-arm- > kernel at

Hi Yijing > -----Original Message----- > From: linux-pci-owner at vger.kernel.org [mailto:linux-pci-owner at vger.kernel.org] > On Behalf Of Yijing Wang > Sent: Monday, August 04, 2014 8:34 AM > To: Basu Arnab-B45036 > Cc: Xinwei Hu; Wuyun; Bjorn Helgaas; linux-pci at vger.kernel.org; > Paul.Mundt at huawei.com; James E.J. Bottomley; Marc Zyngier; linux-arm- > kernel at

...ly 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...

...it with void *data, because some MSI devices don't have a struct device *dev, like the existing hpet device, dmar msi device, and OF device, like the ARM consolidator. Of course, we can make the MSI devices have their own struct device, and register to device tree, eg, add a class device named MSI_DEV. But I'm not sure whether it is appropriate. > > 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 still use th...

...it with void *data, because some MSI devices don't have a struct device *dev, like the existing hpet device, dmar msi device, and OF device, like the ARM consolidator. Of course, we can make the MSI devices have their own struct device, and register to device tree, eg, add a class device named MSI_DEV. But I'm not sure whether it is appropriate. > > 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 still use th...

...because some MSI devices don't have a struct device *dev, > like the existing hpet device, dmar msi device, and OF device, like the ARM consolidator. > > Of course, we can make the MSI devices have their own struct device, and register to > device tree, eg, add a class device named MSI_DEV. But I'm not sure whether it is appropriate. It doesn't have to be in the (OF) device tree, but I think it absolutely makes sense to use the 'struct device' infrastructure here, as almost everything uses a device, and the ones that don't do that today can be easily changed. &g...

...I devices don't have a struct device *dev, >> like the existing hpet device, dmar msi device, and OF device, like the ARM consolidator. >> >> Of course, we can make the MSI devices have their own struct device, and register to >> device tree, eg, add a class device named MSI_DEV. But I'm not sure whether it is appropriate. >> >>> >>> 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 scal...

...because some MSI devices don't have a struct device *dev, > like the existing hpet device, dmar msi device, and OF device, like the ARM consolidator. > > Of course, we can make the MSI devices have their own struct device, and register to > device tree, eg, add a class device named MSI_DEV. But I'm not sure whether it is appropriate. > >> >> 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. &...

...because some MSI devices don't have a struct device *dev, > like the existing hpet device, dmar msi device, and OF device, like the ARM consolidator. > > Of course, we can make the MSI devices have their own struct device, and register to > device tree, eg, add a class device named MSI_DEV. But I'm not sure whether it is appropriate. > >> >> 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. &...

...I devices don't have a struct device *dev, >> like the existing hpet device, dmar msi device, and OF device, like the ARM consolidator. >> >> Of course, we can make the MSI devices have their own struct device, and register to >> device tree, eg, add a class device named MSI_DEV. But I'm not sure whether it is appropriate. > > It doesn't have to be in the (OF) device tree, but I think it absolutely makes > sense to use the 'struct device' infrastructure here, as almost everything uses > a device, and the ones that don't do that today can be...

...I devices don't have a struct device *dev, >> like the existing hpet device, dmar msi device, and OF device, like the ARM consolidator. >> >> Of course, we can make the MSI devices have their own struct device, and register to >> device tree, eg, add a class device named MSI_DEV. But I'm not sure whether it is appropriate. > > It doesn't have to be in the (OF) device tree, but I think it absolutely makes > sense to use the 'struct device' infrastructure here, as almost everything uses > a device, and the ones that don't do that today can be...

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 with PCI device. Because MSI has a lot advantages in design. More and more non-PCI devices want to use

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 with PCI device. Because MSI has a lot advantages in design. More and more non-PCI devices want to use