[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [patch 1/2] qemu-xen: pass-through: move pci_read_intx() and pci_intx()
Move pci_read_intx() and pci_intx() to above pt_irqpin_reg_init(). This is requred for a subsequent patch where pt_irqpin_reg_init() calls pci_read_intx(). Cc: Tom Rotenberg <tom.rotenberg@xxxxxxxxx> Cc: Edwin Zhai <edwin.zhai@xxxxxxxxx> Signed-off-by: Simon Horman <horms@xxxxxxxxxxxx> Index: ioemu-remote/hw/pass-through.c =================================================================== --- ioemu-remote.orig/hw/pass-through.c 2009-12-31 17:04:08.000000000 +0900 +++ ioemu-remote/hw/pass-through.c 2009-12-31 17:07:22.000000000 +0900 @@ -1021,6 +1021,64 @@ int bdf_to_devfn(char *bdf_str) return -1; } +/* The PCI Local Bus Specification, Rev. 3.0, + * Section 6.2.4 Miscellaneous Registers, pp 223 + * outlines 5 valid values for the intertupt pin (intx). + * 0: For devices (or device functions) that don't use an interrupt in + * 1: INTA# + * 2: INTB# + * 3: INTC# + * 4: INTD# + * + * Xen uses the following 4 values for intx + * 0: INTA# + * 1: INTB# + * 2: INTC# + * 3: INTD# + * + * Observing that these list of values are not the same, pci_read_intx() + * uses the following mapping from hw to xen values. + * This seems to reflect the current usage within Xen. + * + * PCI hardware | Xen | Notes + * ----------------+-----+---------------------------------------------------- + * 0 | 0 | No interrupt + * 1 | 0 | INTA# + * 2 | 1 | INTB# + * 3 | 2 | INTC# + * 4 | 3 | INTD# + * any other value | 0 | This should never happen, log error message + */ +static uint8_t pci_read_intx(struct pt_dev *ptdev) +{ + uint8_t r_val = pci_read_byte(ptdev->pci_dev, PCI_INTERRUPT_PIN); + + PT_LOG("intx=%i\n", r_val); + if (r_val < 1 || r_val > 4) + { + PT_LOG("Interrupt pin read from hardware is out of range: " + "value=%i, acceptable range is 1 - 4\n", r_val); + r_val = 0; + } + else + { + r_val -= 1; + } + + return r_val; +} + +/* + * For virtual function 0, always use INTA#, + * otherwise use the hardware value + */ +uint8_t pci_intx(struct pt_dev *ptdev) +{ + if (!PCI_FUNC(ptdev->dev.devfn)) + return 0; + return pci_read_intx(ptdev); +} + /* Being called each time a mmio region has been updated */ static void pt_iomem_map(PCIDevice *d, int i, uint32_t e_phys, uint32_t e_size, int type) @@ -4470,61 +4528,3 @@ int pt_init(PCIBus *e_bus) return 0; } - -/* The PCI Local Bus Specification, Rev. 3.0, - * Section 6.2.4 Miscellaneous Registers, pp 223 - * outlines 5 valid values for the intertupt pin (intx). - * 0: For devices (or device functions) that don't use an interrupt in - * 1: INTA# - * 2: INTB# - * 3: INTC# - * 4: INTD# - * - * Xen uses the following 4 values for intx - * 0: INTA# - * 1: INTB# - * 2: INTC# - * 3: INTD# - * - * Observing that these list of values are not the same, pci_read_intx() - * uses the following mapping from hw to xen values. - * This seems to reflect the current usage within Xen. - * - * PCI hardware | Xen | Notes - * ----------------+-----+---------------------------------------------------- - * 0 | 0 | No interrupt - * 1 | 0 | INTA# - * 2 | 1 | INTB# - * 3 | 2 | INTC# - * 4 | 3 | INTD# - * any other value | 0 | This should never happen, log error message - */ -static uint8_t pci_read_intx(struct pt_dev *ptdev) -{ - uint8_t r_val = pci_read_byte(ptdev->pci_dev, PCI_INTERRUPT_PIN); - - PT_LOG("intx=%i\n", r_val); - if (r_val < 1 || r_val > 4) - { - PT_LOG("Interrupt pin read from hardware is out of range: " - "value=%i, acceptable range is 1 - 4\n", r_val); - r_val = 0; - } - else - { - r_val -= 1; - } - - return r_val; -} - -/* - * For virtual function 0, always use INTA#, - * otherwise use the hardware value - */ -uint8_t pci_intx(struct pt_dev *ptdev) -{ - if (!PCI_FUNC(ptdev->dev.devfn)) - return 0; - return pci_read_intx(ptdev); -} _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |