| 6b5cf264 | 19-Sep-2022 |
Bernhard Beschow <shentey@gmail.com> |
hw/ppc/spapr: Fix code style problems reported by checkpatch
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20220919231
hw/ppc/spapr: Fix code style problems reported by checkpatch
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-Id: <20220919231720.163121-5-shentey@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
show more ...
|
| cba58aa7 | 17-Aug-2022 |
BALATON Zoltan <balaton@eik.bme.hu> |
ppc4xx: Rename ppc405-ebc to ppc4xx-ebc
This device is shared between different 4xx socs.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme
ppc4xx: Rename ppc405-ebc to ppc4xx-ebc
This device is shared between different 4xx socs.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <63d9b14c8ff5f73e35bffca1036394b5235735ee.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
show more ...
|
| 127ba8d0 | 17-Aug-2022 |
BALATON Zoltan <balaton@eik.bme.hu> |
ppc4xx: Move EBC model to ppc4xx_devs.c
The EBC is shared between 405 and 440 so move it to shared file.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: BALATON Zoltan <
ppc4xx: Move EBC model to ppc4xx_devs.c
The EBC is shared between 405 and 440 so move it to shared file.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <10eae70509ca4bd74858fc2c0a0f0e4eb9330199.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
show more ...
|
| 052c779b | 17-Aug-2022 |
BALATON Zoltan <balaton@eik.bme.hu> |
ppc4xx: Rename ppc405-plb to ppc4xx-plb
This device is shared between different 4xx socs.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme
ppc4xx: Rename ppc405-plb to ppc4xx-plb
This device is shared between different 4xx socs.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <5b13ebfd12a71a28035bed5a915cbeee81cf21d1.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
show more ...
|
| 2d54aaf1 | 17-Aug-2022 |
BALATON Zoltan <balaton@eik.bme.hu> |
ppc4xx: Move PLB model to ppc4xx_devs.c
The PLB is shared between 405 and 440 so move it to the shared file.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: BALATON Zolt
ppc4xx: Move PLB model to ppc4xx_devs.c
The PLB is shared between 405 and 440 so move it to the shared file.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <2498384bf3e18959ee8cb984d72fb66b8a6ecadc.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
show more ...
|
| da116a8a | 17-Aug-2022 |
Cédric Le Goater <clg@kaod.org> |
ppc/ppc405: QOM'ify MAL
The Memory Access Layer (MAL) controller is currently modeled as a DCR device with 4 IRQs. Also drop the ppc4xx_mal_init() helper and adapt the sam460ex machine.
Reviewed-by
ppc/ppc405: QOM'ify MAL
The Memory Access Layer (MAL) controller is currently modeled as a DCR device with 4 IRQs. Also drop the ppc4xx_mal_init() helper and adapt the sam460ex machine.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> [balaton: ppc4xx_dcr_register changes, add finalize method] Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <d54a243dff94d95ba30dbcc09c27700a90ade932.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
show more ...
|
| 629cae61 | 17-Aug-2022 |
Cédric Le Goater <clg@kaod.org> |
ppc/ppc4xx: Introduce a DCR device model
The Device Control Registers (DCR) of on-SoC devices are accessed by software through the use of the mtdcr and mfdcr instructions. These are converted in tra
ppc/ppc4xx: Introduce a DCR device model
The Device Control Registers (DCR) of on-SoC devices are accessed by software through the use of the mtdcr and mfdcr instructions. These are converted in transactions on a side band bus, the DCR bus, which connects the on-SoC devices to the CPU.
Ideally, we should model these accesses with a DCR namespace and DCR memory regions but today the DCR handlers are installed in a DCR table under the CPU. Instead, introduce a little device model wrapper to hold a CPU link and handle registration of DCR handlers.
The DCR device inherits from SysBus because most of these devices also have MMIO regions and/or IRQs. Being a SysBusDevice makes things easier to install the device model in the overall SoC.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> [balaton: Explicit opaque parameter for dcr callbacks] Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <9b21bdf55e0a728f093bad299e030d98f302ded0.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
show more ...
|
| b42ad437 | 09-Aug-2022 |
Cédric Le Goater <clg@kaod.org> |
ppc/ppc405: QOM'ify CPU
Drop the use of ppc4xx_init() and duplicate a bit of code related to clocks in the SoC realize routine. We will clean that up in the following patches.
ppc_dcr_init() simply
ppc/ppc405: QOM'ify CPU
Drop the use of ppc4xx_init() and duplicate a bit of code related to clocks in the SoC realize routine. We will clean that up in the following patches.
ppc_dcr_init() simply allocates default DCR handlers for the CPU. Maybe this could be done in model initializer of the CPU families needing it.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20220809153904.485018-8-clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
show more ...
|
| 0d512c71 | 11-Aug-2022 |
Daniel Henrique Barboza <danielhb413@gmail.com> |
ppc/pnv: turn chip8->phbs[] into a PnvPHB* array
When enabling user created PHBs (a change reverted by commit 9c10d86fee) we were handling PHBs created by default versus by the user in different man
ppc/pnv: turn chip8->phbs[] into a PnvPHB* array
When enabling user created PHBs (a change reverted by commit 9c10d86fee) we were handling PHBs created by default versus by the user in different manners. The only difference between these PHBs is that one will have a valid phb3->chip that is assigned during pnv_chip_power8_realize(), while the user created needs to search which chip it belongs to.
Aside from that there shouldn't be any difference. Making the default PHBs behave in line with the user created ones will make it easier to re-introduce them later on. It will also make the code easier to follow since we are dealing with them in equal manner.
The first step is to turn chip8->phbs[] into a PnvPHB3 pointer array. This will allow us to assign user created PHBs into it later on. The way we initilize the default case is now more in line with that would happen with the user created case: the object is created, parented by the chip because pnv_xscom_dt() relies on it, and then assigned to the array.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-6-danielhb413@gmail.com>
show more ...
|
| ba47c3a4 | 11-Aug-2022 |
Daniel Henrique Barboza <danielhb413@gmail.com> |
ppc/pnv: add helpers for pnv-phb user devices
pnv_parent_qom_fixup() and pnv_parent_bus_fixup() are versions of the helpers that were reverted by commit 9c10d86fee "ppc/pnv: Remove user-created PHB{
ppc/pnv: add helpers for pnv-phb user devices
pnv_parent_qom_fixup() and pnv_parent_bus_fixup() are versions of the helpers that were reverted by commit 9c10d86fee "ppc/pnv: Remove user-created PHB{3,4,5} devices". They are needed to amend the QOM and bus hierarchies of user created pnv-phbs, matching them with default pnv-phbs.
A new helper pnv_phb_user_device_init() is created to handle user-created devices setup. We're going to call it inside pnv_phb_realize() in case we're realizing an user created device. This will centralize all user device realated in a single spot, leaving the realize functions of the phb3/phb4 backends untouched.
Another helper called pnv_chip_add_phb() was added to handle the particularities of each chip version when adding a new PHB.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220811163950.578927-5-danielhb413@gmail.com>
show more ...
|
| e5ea9436 | 24-Jun-2022 |
Daniel Henrique Barboza <danielhb413@gmail.com> |
ppc/pnv: move attach_root_port helper to pnv-phb.c
The helper is only used in this file.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.i
ppc/pnv: move attach_root_port helper to pnv-phb.c
The helper is only used in this file.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-13-danielhb413@gmail.com>
show more ...
|
| 17c681e9 | 24-Jun-2022 |
Daniel Henrique Barboza <danielhb413@gmail.com> |
ppc/pnv: remove root port name from pnv_phb_attach_root_port()
We support only a single root port, PNV_PHB_ROOT_PORT.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Fre
ppc/pnv: remove root port name from pnv_phb_attach_root_port()
We support only a single root port, PNV_PHB_ROOT_PORT.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-10-danielhb413@gmail.com>
show more ...
|
| 1f5d6b2a | 24-Jun-2022 |
Daniel Henrique Barboza <danielhb413@gmail.com> |
ppc/pnv: turn PnvPHB3 into a PnvPHB backend
We need a handful of changes that needs to be done in a single swoop to turn PnvPHB3 into a PnvPHB backend.
In the PnvPHB3, since the PnvPHB device imple
ppc/pnv: turn PnvPHB3 into a PnvPHB backend
We need a handful of changes that needs to be done in a single swoop to turn PnvPHB3 into a PnvPHB backend.
In the PnvPHB3, since the PnvPHB device implements PCIExpressHost and will hold the PCI bus, change PnvPHB3 parent to TYPE_DEVICE. There are a couple of instances in pnv_phb3.c that needs to access the PCI bus, so a phb_base pointer is added to allow access to the parent PnvPHB. The PnvPHB3 root port will now be connected to a PnvPHB object.
In pnv.c, the powernv8 machine chip8 will now hold an array of PnvPHB objects. pnv_get_phb3_child() needs to be adapted to return the PnvPHB3 backend from the PnvPHB child. A global property is added in pnv_machine_power8_class_init() to ensure that all PnvPHBs are created with phb->version = 3.
After all these changes we're still able to boot a powernv8 machine with default settings. The real gain will come with user created PnvPHB devices, coming up next.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220624084921.399219-4-danielhb413@gmail.com>
show more ...
|
| 0bf4d77e | 11-Aug-2022 |
Nicholas Piggin <npiggin@gmail.com> |
ppc/pnv: Add initial P9/10 SBE model
The SBE (Self Boot Engine) are on-chip microcontrollers that perform early boot steps, as well as provide some runtime facilities (e.g., timer, secure register a
ppc/pnv: Add initial P9/10 SBE model
The SBE (Self Boot Engine) are on-chip microcontrollers that perform early boot steps, as well as provide some runtime facilities (e.g., timer, secure register access, MPIPL). The latter facilities are accessed mostly via a message system called SBEFIFO.
This driver provides initial emulation for the SBE runtime registers and a very basic SBEFIFO implementation that provides the timer command. This covers the basic SBE behaviour expected by skiboot when booting.
Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20220811093726.1442343-1-npiggin@gmail.com> [danielhb: fixed SBE_HOST_RESPONSE_MASK long line] Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
show more ...
|
| 81b205ce | 22-Jun-2022 |
Alexey Kardashevskiy <aik@ozlabs.ru> |
ppc/spapr: Implement H_WATCHDOG
The new PAPR 2.12 defines a watchdog facility managed via the new H_WATCHDOG hypercall.
This adds H_WATCHDOG support which a proposed driver for pseries uses: https:
ppc/spapr: Implement H_WATCHDOG
The new PAPR 2.12 defines a watchdog facility managed via the new H_WATCHDOG hypercall.
This adds H_WATCHDOG support which a proposed driver for pseries uses: https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=303120
This was tested by running QEMU with a debug kernel and command line: -append \ "pseries-wdt.timeout=60 pseries-wdt.nowayout=1 pseries-wdt.action=2"
and running "echo V > /dev/watchdog0" inside the VM.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220622051008.1067464-1-aik@ozlabs.ru> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
show more ...
|
| 31cc81f7 | 22-Jun-2022 |
Alexey Kardashevskiy <aik@ozlabs.ru> |
spapr/ddw: Reset DMA when the last non-default window is removed
PAPR+/LoPAPR says: === The platform must restore the default DMA window for the PE on a call to the ibm,remove-pe-dma-window RTAS cal
spapr/ddw: Reset DMA when the last non-default window is removed
PAPR+/LoPAPR says: === The platform must restore the default DMA window for the PE on a call to the ibm,remove-pe-dma-window RTAS call when all of the following are true: a. The call removes the last DMA window remaining for the PE. b. The DMA window being removed is not the default window
===
This resets DMA as PAPR mandates.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220622052955.1069903-1-aik@ozlabs.ru> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
show more ...
|
| 792e8bb6 | 21-Jun-2022 |
Daniel Henrique Barboza <danielhb413@gmail.com> |
ppc/pnv: assign pnv-phb-root-port chassis/slot earlier
It is not advisable to execute an object_dynamic_cast() to poke into bus->qbus.parent and follow it up with a C cast into the PnvPHB type we th
ppc/pnv: assign pnv-phb-root-port chassis/slot earlier
It is not advisable to execute an object_dynamic_cast() to poke into bus->qbus.parent and follow it up with a C cast into the PnvPHB type we think we got.
In fact this is not needed. There is nothing sophisticated being done with the PHB object retrieved during root_port_realize() for both PHB3 and PHB4. We're retrieving a PHB reference just to access phb->chip_id and phb->phb_id and use them to define the chassis/slot of the root port.
phb->phb_id is already being passed to pnv_phb_attach_root_port() via the 'index' parameter. Let's also add a 'chip_id' parameter to this function and assign chassis and slot right there. This will spare us from the hassle of accessing the PHB object inside realize().
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220621173436.165912-4-danielhb413@gmail.com>
show more ...
|
| 8625164a | 21-Jun-2022 |
Daniel Henrique Barboza <danielhb413@gmail.com> |
ppc/pnv: attach phb3/phb4 root ports in QOM tree
At this moment we leave the pnv-phb3(4)-root-port unattached in QOM:
/unattached (container) (...) /device[2] (pnv-phb3-root-port) /bus
ppc/pnv: attach phb3/phb4 root ports in QOM tree
At this moment we leave the pnv-phb3(4)-root-port unattached in QOM:
/unattached (container) (...) /device[2] (pnv-phb3-root-port) /bus master container[0] (memory-region) /bus master[0] (memory-region) /pci_bridge_io[0] (memory-region) /pci_bridge_io[1] (memory-region) /pci_bridge_mem[0] (memory-region) /pci_bridge_pci[0] (memory-region) /pci_bridge_pref_mem[0] (memory-region) /pci_bridge_vga_io_hi[0] (memory-region) /pci_bridge_vga_io_lo[0] (memory-region) /pci_bridge_vga_mem[0] (memory-region) /pcie.0 (PCIE)
Let's make changes in pnv_phb_attach_root_port() to attach the created root ports to its corresponding PHB.
This is the result afterwards:
/pnv-phb3[0] (pnv-phb3) /lsi (ics) /msi (phb3-msi) /msi32[0] (memory-region) /msi64[0] (memory-region) /pbcq (pnv-pbcq) (...) /phb3_iommu[0] (pnv-phb3-iommu-memory-region) /pnv-phb3-root.0 (pnv-phb3-root) /pnv-phb3-root-port[0] (pnv-phb3-root-port) /bus master container[0] (memory-region) /bus master[0] (memory-region) /pci_bridge_io[0] (memory-region) /pci_bridge_io[1] (memory-region) /pci_bridge_mem[0] (memory-region) /pci_bridge_pci[0] (memory-region) /pci_bridge_pref_mem[0] (memory-region) /pci_bridge_vga_io_hi[0] (memory-region) /pci_bridge_vga_io_lo[0] (memory-region) /pci_bridge_vga_mem[0] (memory-region) /pcie.0 (PCIE)
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220621173436.165912-3-danielhb413@gmail.com>
show more ...
|
| f73eb948 | 07-May-2022 |
Paolo Bonzini <pbonzini@redhat.com> |
pseries: allow setting stdout-path even on machines with a VGA
-machine graphics=off is the usual way to tell the firmware or the OS that the user wants a serial console. The pseries machine howeve
pseries: allow setting stdout-path even on machines with a VGA
-machine graphics=off is the usual way to tell the firmware or the OS that the user wants a serial console. The pseries machine however does not support this, and never adds the stdout-path node to the device tree if a VGA device is provided. This is in addition to the other magic behavior of VGA devices, which is to add a keyboard and mouse to the default USB bus.
Split spapr->has_graphics in two variables so that the two behaviors can be separated: the USB devices remains the same, but the stdout-path is added even with "-device VGA -machine graphics=off".
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20220507054826.124936-1-pbonzini@redhat.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
show more ...
|
| 9c092804 | 06-May-2022 |
Markus Armbruster <armbru@redhat.com> |
Clean up ill-advised or unusual header guards
Leading underscores are ill-advised because such identifiers are reserved. Trailing underscores are merely ugly. Strip both.
Our header guards common
Clean up ill-advised or unusual header guards
Leading underscores are ill-advised because such identifiers are reserved. Trailing underscores are merely ugly. Strip both.
Our header guards commonly end in _H. Normalize the exceptions.
Macros should be ALL_CAPS. Normalize the exception.
Done with scripts/clean-header-guards.pl.
include/hw/xen/interface/ and tools/virtiofsd/ left alone, because these were imported from Xen and libfuse respectively.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20220506134911.2856099-3-armbru@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
show more ...
|
| f6577211 | 29-Apr-2022 |
Frederic Barrat <fbarrat@linux.ibm.com> |
ppc/xive: Update the state of the External interrupt signal
When pulling or pushing an OS context from/to a CPU, we should re-evaluate the state of the External interrupt signal. Otherwise, we can e
ppc/xive: Update the state of the External interrupt signal
When pulling or pushing an OS context from/to a CPU, we should re-evaluate the state of the External interrupt signal. Otherwise, we can end up catching the External interrupt exception in hypervisor mode, which is unexpected.
The problem is best illustrated with the following scenario:
1. an External interrupt is raised while the guest is on the CPU.
2. before the guest can ack the External interrupt, an hypervisor interrupt is raised, for example the Hypervisor Decrementer or Hypervisor Virtualization interrupt. The hypervisor interrupt forces the guest to exit while the External interrupt is still pending.
3. the hypervisor handles the hypervisor interrupt. At this point, the External interrupt is still pending. So it's very likely to be delivered while the hypervisor is running. That's unexpected and can result in an infinite loop where the hypervisor catches the External interrupt, looks for an interrupt in its hypervisor queue, doesn't find any, exits the interrupt handler with the External interrupt still raised, repeat...
The fix is simply to always lower the External interrupt signal when pulling an OS context. It means it needs to be raised again when re-pushing the OS context. Fortunately, it's already the case, as we now always call xive_tctx_ipb_update(), which will raise the signal if needed.
Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20220429071620.177142-3-fbarrat@linux.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
show more ...
|
| 2d94af4b | 11-Apr-2022 |
Guo Zhi <qtxuning1999@sjtu.edu.cn> |
hw/ppc: change indentation to spaces from TABs
There are still some files in the QEMU PPC code base that use TABs for indentation instead of using spaces. The TABs should be replaced so that we hav
hw/ppc: change indentation to spaces from TABs
There are still some files in the QEMU PPC code base that use TABs for indentation instead of using spaces. The TABs should be replaced so that we have a consistent coding style.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/374 Signed-off-by: Guo Zhi <qtxuning1999@sjtu.edu.cn> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20220412021240.2080218-1-qtxuning1999@sjtu.edu.cn> [danielhb: trimmed commit msg to 72 chars per line] Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
show more ...
|
| dcf4ca45 | 23-Mar-2022 |
Cédric Le Goater <clg@kaod.org> |
ppc/pnv: Remove PnvPsiClas::irq_set
All devices raising PSI interrupts are now converted to use GPIO lines and the pnv_psi_irq_set() routines have become useless. Drop them.
Reviewed-by: Daniel Hen
ppc/pnv: Remove PnvPsiClas::irq_set
All devices raising PSI interrupts are now converted to use GPIO lines and the pnv_psi_irq_set() routines have become useless. Drop them.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220323072846.1780212-5-clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
show more ...
|
| b0ae5c69 | 23-Mar-2022 |
Cédric Le Goater <clg@kaod.org> |
ppc/pnv: Remove PnvOCC::psi link
Use an anonymous output GPIO line to connect the OCC device with the PSIHB device and raise the appropriate PSI IRQ line depending on the processor model.
Reviewed-
ppc/pnv: Remove PnvOCC::psi link
Use an anonymous output GPIO line to connect the OCC device with the PSIHB device and raise the appropriate PSI IRQ line depending on the processor model.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220323072846.1780212-4-clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
show more ...
|
| c05aa140 | 23-Mar-2022 |
Cédric Le Goater <clg@kaod.org> |
ppc/pnv: Remove PnvLpcController::psi link
Create an anonymous output GPIO line to connect the LPC device with the PSIHB device and raise the appropriate PSI IRQ line depending on the processor mode
ppc/pnv: Remove PnvLpcController::psi link
Create an anonymous output GPIO line to connect the LPC device with the PSIHB device and raise the appropriate PSI IRQ line depending on the processor model.
A temporary __pnv_psi_irq_set() routine is introduced to handle the transition. It will be removed when all devices raising PSI interrupts are converted to use GPIOs.
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20220323072846.1780212-3-clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
show more ...
|