hw/i386/pc_piix.c | 16 ++++++++++++++++ hw/i386/pc_q35.c | 4 ++-- hw/isa/piix3.c | 17 ++--------------- hw/isa/piix4.c | 27 +-------------------------- hw/mips/malta.c | 28 ++++++++++++++++++++++++++++ hw/pci-host/raven.c | 3 ++- hw/pci-host/versatile.c | 3 ++- hw/pci/pci.c | 12 +++++++++--- hw/remote/machine.c | 3 ++- include/hw/pci/pci.h | 3 ++- 10 files changed, 66 insertions(+), 50 deletions(-)
v1: === During my PIIX consolidation work [1] I've noticed that both PIIX models have quite different pci_slot_get_pirq() implementations. These functions seem to map PCI INTx pins to input pins of a programmable interrupt router which is AFAIU board-specific. IOW, board-specific assumptions are baked into the device models which prevent e.g. the whole PIIX4 south bridge to be reusable in the PC machine. This series first factors out pci_bus_map_irqs() from pci_bus_irqs() which then allowes for moving the two board-specific PIIX pci_slot_get_pirq() funtions into their respective boards. With these changes, the PIIX4 south bridge could eventually become an alternative to the PIIX3-Frankenstein solution in the PC machine. v2: === * Remove RFC tag from whole series * New patch to split pci_bus_irqs() * Remove VT82xx patch which was just a demonstration Testing done: * `make check` * `make check-avocado` * `qemu-system-mips64el -M malta -kernel vmlinux-3.2.0-4-5kc-malta -hda debian_wheezy_mipsel_standard.qcow2 -append "root=/dev/sda1 console=ttyS0"` * `qemu-system-x86_64 -M pc -m 2G -cdrom manjaro-kde-21.3.2-220704-linux515.iso` Thanks, Bernhard [1] https://lists.nongnu.org/archive/html/qemu-devel/2022-10/msg03941.html Bernhard Beschow (3): hw/pci/pci: Factor out pci_bus_map_irqs() from pci_bus_irqs() hw/isa/piix3: Decouple INTx-to-LNKx routing which is board-specific hw/isa/piix4: Decouple INTx-to-LNKx routing which is board-specific hw/i386/pc_piix.c | 16 ++++++++++++++++ hw/i386/pc_q35.c | 4 ++-- hw/isa/piix3.c | 17 ++--------------- hw/isa/piix4.c | 27 +-------------------------- hw/mips/malta.c | 28 ++++++++++++++++++++++++++++ hw/pci-host/raven.c | 3 ++- hw/pci-host/versatile.c | 3 ++- hw/pci/pci.c | 12 +++++++++--- hw/remote/machine.c | 3 ++- include/hw/pci/pci.h | 3 ++- 10 files changed, 66 insertions(+), 50 deletions(-) -- 2.38.1
On 20/11/22 16:05, Bernhard Beschow wrote: > Bernhard Beschow (3): > hw/pci/pci: Factor out pci_bus_map_irqs() from pci_bus_irqs() > hw/isa/piix3: Decouple INTx-to-LNKx routing which is board-specific > hw/isa/piix4: Decouple INTx-to-LNKx routing which is board-specific Thanks, series queued to mips-next.
On Sun, Nov 20, 2022 at 04:05:47PM +0100, Bernhard Beschow wrote: > v1: > === > > During my PIIX consolidation work [1] I've noticed that both PIIX models have > quite different pci_slot_get_pirq() implementations. These functions seem to > map PCI INTx pins to input pins of a programmable interrupt router which is > AFAIU board-specific. IOW, board-specific assumptions are baked into the device > models which prevent e.g. the whole PIIX4 south bridge to be reusable in the PC > machine. > > This series first factors out pci_bus_map_irqs() from pci_bus_irqs() which > then allowes for moving the two board-specific PIIX pci_slot_get_pirq() > funtions into their respective boards. With these changes, the PIIX4 south > bridge could eventually become an alternative to the PIIX3-Frankenstein > solution in the PC machine. Reviewed-by: Michael S. Tsirkin <mst@redhat.com> > v2: > === > * Remove RFC tag from whole series > * New patch to split pci_bus_irqs() > * Remove VT82xx patch which was just a demonstration > > Testing done: > * `make check` > * `make check-avocado` > * `qemu-system-mips64el -M malta -kernel vmlinux-3.2.0-4-5kc-malta -hda debian_wheezy_mipsel_standard.qcow2 -append "root=/dev/sda1 console=ttyS0"` > * `qemu-system-x86_64 -M pc -m 2G -cdrom manjaro-kde-21.3.2-220704-linux515.iso` > > Thanks, > Bernhard > > [1] https://lists.nongnu.org/archive/html/qemu-devel/2022-10/msg03941.html > > Bernhard Beschow (3): > hw/pci/pci: Factor out pci_bus_map_irqs() from pci_bus_irqs() > hw/isa/piix3: Decouple INTx-to-LNKx routing which is board-specific > hw/isa/piix4: Decouple INTx-to-LNKx routing which is board-specific > > hw/i386/pc_piix.c | 16 ++++++++++++++++ > hw/i386/pc_q35.c | 4 ++-- > hw/isa/piix3.c | 17 ++--------------- > hw/isa/piix4.c | 27 +-------------------------- > hw/mips/malta.c | 28 ++++++++++++++++++++++++++++ > hw/pci-host/raven.c | 3 ++- > hw/pci-host/versatile.c | 3 ++- > hw/pci/pci.c | 12 +++++++++--- > hw/remote/machine.c | 3 ++- > include/hw/pci/pci.h | 3 ++- > 10 files changed, 66 insertions(+), 50 deletions(-) > > -- > 2.38.1 >
On 20/11/22 16:05, Bernhard Beschow wrote: > v1: > === > > During my PIIX consolidation work [1] I've noticed that both PIIX models have > quite different pci_slot_get_pirq() implementations. These functions seem to > map PCI INTx pins to input pins of a programmable interrupt router which is > AFAIU board-specific. IOW, board-specific assumptions are baked into the device > models which prevent e.g. the whole PIIX4 south bridge to be reusable in the PC > machine. > > This series first factors out pci_bus_map_irqs() from pci_bus_irqs() which > then allowes for moving the two board-specific PIIX pci_slot_get_pirq() > funtions into their respective boards. With these changes, the PIIX4 south > bridge could eventually become an alternative to the PIIX3-Frankenstein > solution in the PC machine. Series: Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Am 9. Dezember 2022 15:23:59 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>: >On 20/11/22 16:05, Bernhard Beschow wrote: >> v1: >> === >> >> During my PIIX consolidation work [1] I've noticed that both PIIX models have >> quite different pci_slot_get_pirq() implementations. These functions seem to >> map PCI INTx pins to input pins of a programmable interrupt router which is >> AFAIU board-specific. IOW, board-specific assumptions are baked into the device >> models which prevent e.g. the whole PIIX4 south bridge to be reusable in the PC >> machine. >> >> This series first factors out pci_bus_map_irqs() from pci_bus_irqs() which >> then allowes for moving the two board-specific PIIX pci_slot_get_pirq() >> funtions into their respective boards. With these changes, the PIIX4 south >> bridge could eventually become an alternative to the PIIX3-Frankenstein >> solution in the PC machine. > >Series: >Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Ping Who will pull this?
On Sun, Dec 18, 2022 at 10:21:49AM +0000, Bernhard Beschow wrote: > > > Am 9. Dezember 2022 15:23:59 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>: > >On 20/11/22 16:05, Bernhard Beschow wrote: > >> v1: > >> === > >> > >> During my PIIX consolidation work [1] I've noticed that both PIIX models have > >> quite different pci_slot_get_pirq() implementations. These functions seem to > >> map PCI INTx pins to input pins of a programmable interrupt router which is > >> AFAIU board-specific. IOW, board-specific assumptions are baked into the device > >> models which prevent e.g. the whole PIIX4 south bridge to be reusable in the PC > >> machine. > >> > >> This series first factors out pci_bus_map_irqs() from pci_bus_irqs() which > >> then allowes for moving the two board-specific PIIX pci_slot_get_pirq() > >> funtions into their respective boards. With these changes, the PIIX4 south > >> bridge could eventually become an alternative to the PIIX3-Frankenstein > >> solution in the PC machine. > > > >Series: > >Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> > > Ping > > Who will pull this? To clarify, you want this dropped for now? -- MST
Am 20. Dezember 2022 23:10:45 UTC schrieb "Michael S. Tsirkin" <mst@redhat.com>: >On Sun, Dec 18, 2022 at 10:21:49AM +0000, Bernhard Beschow wrote: >> >> >> Am 9. Dezember 2022 15:23:59 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>: >> >On 20/11/22 16:05, Bernhard Beschow wrote: >> >> v1: >> >> === >> >> >> >> During my PIIX consolidation work [1] I've noticed that both PIIX models have >> >> quite different pci_slot_get_pirq() implementations. These functions seem to >> >> map PCI INTx pins to input pins of a programmable interrupt router which is >> >> AFAIU board-specific. IOW, board-specific assumptions are baked into the device >> >> models which prevent e.g. the whole PIIX4 south bridge to be reusable in the PC >> >> machine. >> >> >> >> This series first factors out pci_bus_map_irqs() from pci_bus_irqs() which >> >> then allowes for moving the two board-specific PIIX pci_slot_get_pirq() >> >> funtions into their respective boards. With these changes, the PIIX4 south >> >> bridge could eventually become an alternative to the PIIX3-Frankenstein >> >> solution in the PC machine. >> > >> >Series: >> >Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> >> >> Ping >> >> Who will pull this? > >To clarify, you want this dropped for now? Yeah, let's merge via mips-next since this series is related to the PIIX consolidation series (see above) and mips-next is planned to be pulled soon. Thanks, Bernhard
On Tue, Dec 20, 2022 at 11:26:42PM +0000, Bernhard Beschow wrote: > > > Am 20. Dezember 2022 23:10:45 UTC schrieb "Michael S. Tsirkin" <mst@redhat.com>: > >On Sun, Dec 18, 2022 at 10:21:49AM +0000, Bernhard Beschow wrote: > >> > >> > >> Am 9. Dezember 2022 15:23:59 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>: > >> >On 20/11/22 16:05, Bernhard Beschow wrote: > >> >> v1: > >> >> === > >> >> > >> >> During my PIIX consolidation work [1] I've noticed that both PIIX models have > >> >> quite different pci_slot_get_pirq() implementations. These functions seem to > >> >> map PCI INTx pins to input pins of a programmable interrupt router which is > >> >> AFAIU board-specific. IOW, board-specific assumptions are baked into the device > >> >> models which prevent e.g. the whole PIIX4 south bridge to be reusable in the PC > >> >> machine. > >> >> > >> >> This series first factors out pci_bus_map_irqs() from pci_bus_irqs() which > >> >> then allowes for moving the two board-specific PIIX pci_slot_get_pirq() > >> >> funtions into their respective boards. With these changes, the PIIX4 south > >> >> bridge could eventually become an alternative to the PIIX3-Frankenstein > >> >> solution in the PC machine. > >> > > >> >Series: > >> >Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> > >> > >> Ping > >> > >> Who will pull this? > > > >To clarify, you want this dropped for now? > > Yeah, let's merge via mips-next since this series is related to the PIIX consolidation series (see above) and mips-next is planned to be pulled soon. > > Thanks, > Bernhard For that Acked-by: Michael S. Tsirkin <mst@redhat.com>
On Sun, Dec 18, 2022 at 10:21:49AM +0000, Bernhard Beschow wrote: > > > Am 9. Dezember 2022 15:23:59 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>: > >On 20/11/22 16:05, Bernhard Beschow wrote: > >> v1: > >> === > >> > >> During my PIIX consolidation work [1] I've noticed that both PIIX models have > >> quite different pci_slot_get_pirq() implementations. These functions seem to > >> map PCI INTx pins to input pins of a programmable interrupt router which is > >> AFAIU board-specific. IOW, board-specific assumptions are baked into the device > >> models which prevent e.g. the whole PIIX4 south bridge to be reusable in the PC > >> machine. > >> > >> This series first factors out pci_bus_map_irqs() from pci_bus_irqs() which > >> then allowes for moving the two board-specific PIIX pci_slot_get_pirq() > >> funtions into their respective boards. With these changes, the PIIX4 south > >> bridge could eventually become an alternative to the PIIX3-Frankenstein > >> solution in the PC machine. > > > >Series: > >Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> > > Ping > > Who will pull this? I'll merge this, thanks!
© 2016 - 2024 Red Hat, Inc.