search for: msi_chip

...without IRQ numbers. > I don't think we should touch the PCI interfaces at this point. OK, I got it. >>> What I'd envision as the API from the device driver perspective is something >>> as simple like this: >>> >>> struct msi_desc *msi_request(struct msi_chip *chip, irq_handler_t handler, >>> unsigned long flags, const char *name, struct device *dev); >>> >>> which would get an msi descriptor that is valid for this device (dev) >>> connected to a particular msi_chip, and associate a handler function >>> wi...

...without IRQ numbers. > I don't think we should touch the PCI interfaces at this point. OK, I got it. >>> What I'd envision as the API from the device driver perspective is something >>> as simple like this: >>> >>> struct msi_desc *msi_request(struct msi_chip *chip, irq_handler_t handler, >>> unsigned long flags, const char *name, struct device *dev); >>> >>> which would get an msi descriptor that is valid for this device (dev) >>> connected to a particular msi_chip, and associate a handler function >>> wi...

...ge() maybe necessary, some xxx_set_affinity() functions and restore functions need the msi_write_message() to rewrite the address and data. > What I'd envision as the API from the device driver perspective is something > as simple like this: > > struct msi_desc *msi_request(struct msi_chip *chip, irq_handler_t handler, > unsigned long flags, const char *name, struct device *dev); > > which would get an msi descriptor that is valid for this device (dev) > connected to a particular msi_chip, and associate a handler function > with it. The device driver can call that...

...ge() maybe necessary, some xxx_set_affinity() functions and restore functions need the msi_write_message() to rewrite the address and data. > What I'd envision as the API from the device driver perspective is something > as simple like this: > > struct msi_desc *msi_request(struct msi_chip *chip, irq_handler_t handler, > unsigned long flags, const char *name, struct device *dev); > > which would get an msi descriptor that is valid for this device (dev) > connected to a particular msi_chip, and associate a handler function > with it. The device driver can call that...

...er does not have to worry about it. We can add additional wrappers like that as needed. > >>> What I'd envision as the API from the device driver perspective is something > >>> as simple like this: > >>> > >>> struct msi_desc *msi_request(struct msi_chip *chip, irq_handler_t handler, > >>> unsigned long flags, const char *name, struct device *dev); > >>> > >>> which would get an msi descriptor that is valid for this device (dev) > >>> connected to a particular msi_chip, and associate a handler func...

...ata. Makes sense. I'd have to think about it more, but I think you are right about the affinity APIs needing this. > > What I'd envision as the API from the device driver perspective is something > > as simple like this: > > > > struct msi_desc *msi_request(struct msi_chip *chip, irq_handler_t handler, > > unsigned long flags, const char *name, struct device *dev); > > > > which would get an msi descriptor that is valid for this device (dev) > > connected to a particular msi_chip, and associate a handler function > > with it. The dev...

...gt; > My question is do we necessarily want to rework so much of the PCI-MSI layer to support non PCI devices? Or will it be sufficient to create a framework to allow non PCI devices to hook up with a device that can convert their writes to an IRQ to the core. > > As I understand it, the msi_chip is (almost) such a framework. The only problem being that it makes some PCI specific assumptions (such as PCI specific writes from within msi_chip functions). Won't it be sufficient to make the msi_chip framework generic enough to be used by non-PCI devices and let each bus/device manage any ad...

...nctions and >> restore functions need the msi_write_message() to rewrite the address and data. >> >>> What I'd envision as the API from the device driver perspective is something >>> as simple like this: >>> >>> struct msi_desc *msi_request(struct msi_chip *chip, irq_handler_t handler, >>> unsigned long flags, const char *name, struct device *dev); >>> >>> which would get an msi descriptor that is valid for this device (dev) >>> connected to a particular msi_chip, and associate a handler function >>> wi...

...s of the MSI spec. My question is do we necessarily want to rework so much of the PCI-MSI layer to support non PCI devices? Or will it be sufficient to create a framework to allow non PCI devices to hook up with a device that can convert their writes to an IRQ to the core. As I understand it, the msi_chip is (almost) such a framework. The only problem being that it makes some PCI specific assumptions (such as PCI specific writes from within msi_chip functions). Won't it be sufficient to make the msi_chip framework generic enough to be used by non-PCI devices and let each bus/device manage any ad...

...s of the MSI spec. My question is do we necessarily want to rework so much of the PCI-MSI layer to support non PCI devices? Or will it be sufficient to create a framework to allow non PCI devices to hook up with a device that can convert their writes to an IRQ to the core. As I understand it, the msi_chip is (almost) such a framework. The only problem being that it makes some PCI specific assumptions (such as PCI specific writes from within msi_chip functions). Won't it be sufficient to make the msi_chip framework generic enough to be used by non-PCI devices and let each bus/device manage any ad...

...e xxx_set_affinity() functions and > restore functions need the msi_write_message() to rewrite the address and data. > >> What I'd envision as the API from the device driver perspective is something >> as simple like this: >> >> struct msi_desc *msi_request(struct msi_chip *chip, irq_handler_t handler, >> unsigned long flags, const char *name, struct device *dev); >> >> which would get an msi descriptor that is valid for this device (dev) >> connected to a particular msi_chip, and associate a handler function >> with it. The device dr...

...e xxx_set_affinity() functions and > restore functions need the msi_write_message() to rewrite the address and data. > >> What I'd envision as the API from the device driver perspective is something >> as simple like this: >> >> struct msi_desc *msi_request(struct msi_chip *chip, irq_handler_t handler, >> unsigned long flags, const char *name, struct device *dev); >> >> which would get an msi descriptor that is valid for this device (dev) >> connected to a particular msi_chip, and associate a handler function >> with it. The device dr...

...do we necessarily want to rework so much of the PCI-MSI layer > to support non PCI devices? Or will it be sufficient to create a framework to > allow non PCI devices to hook up with a device that can convert their writes to > an IRQ to the core. > > > > As I understand it, the msi_chip is (almost) such a framework. The only > problem being that it makes some PCI specific assumptions (such as PCI specific > writes from within msi_chip functions). Won't it be sufficient to make the > msi_chip framework generic enough to be used by non-PCI devices and let each > bus/...

...do we necessarily want to rework so much of the PCI-MSI layer > to support non PCI devices? Or will it be sufficient to create a framework to > allow non PCI devices to hook up with a device that can convert their writes to > an IRQ to the core. > > > > As I understand it, the msi_chip is (almost) such a framework. The only > problem being that it makes some PCI specific assumptions (such as PCI specific > writes from within msi_chip functions). Won't it be sufficient to make the > msi_chip framework generic enough to be used by non-PCI devices and let each > bus/...

...nclude <linux/errno.h> +#include <linux/io.h> +#include <linux/slab.h> +#include <linux/device.h> +#include <linux/pci.h> + +/* Arch hooks */ + +int __weak arch_setup_msi_irq(struct msi_irqs *msi, struct msi_desc *desc) +{ + struct pci_dev *dev = msi->data; + struct msi_chip *chip = dev->bus->msi; //TO BE DONE: rework msi_chip to support Non-PCI MSI + int err; + + if (!chip || !chip->setup_irq) + return -EINVAL; + + err = chip->setup_irq(chip, dev, desc); + if (err < 0) + return err; + + irq_set_chip_data(desc->irq, chip); + return 0; +} + +void __w...

...o.h> > +#include <linux/slab.h> > +#include <linux/device.h> > +#include <linux/pci.h> > + > +/* Arch hooks */ > + > +int __weak arch_setup_msi_irq(struct msi_irqs *msi, struct msi_desc *desc) > +{ > + struct pci_dev *dev = msi->data; > + struct msi_chip *chip = dev->bus->msi; //TO BE DONE: rework msi_chip to > support Non-PCI MSI > + int err; > + > + if (!chip || !chip->setup_irq) > + return -EINVAL; > + > + err = chip->setup_irq(chip, dev, desc); > + if (err < 0) > + return err; > + > + irq_set_ch...

...o.h> > +#include <linux/slab.h> > +#include <linux/device.h> > +#include <linux/pci.h> > + > +/* Arch hooks */ > + > +int __weak arch_setup_msi_irq(struct msi_irqs *msi, struct msi_desc *desc) > +{ > + struct pci_dev *dev = msi->data; > + struct msi_chip *chip = dev->bus->msi; //TO BE DONE: rework msi_chip to > support Non-PCI MSI > + int err; > + > + if (!chip || !chip->setup_irq) > + return -EINVAL; > + > + err = chip->setup_irq(chip, dev, desc); > + if (err < 0) > + return err; > + > + irq_set_ch...

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

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