aboutsummaryrefslogtreecommitdiff
path: root/include/hw/ppc
AgeCommit message (Collapse)Author
2023-09-25hw/ppc: Reset timebase facilities on machine resetNicholas Piggin
Lower interrupts, delete timers, and set time facility registers back to initial state on machine reset. This is not so important for record-replay since timebase and decrementer are migrated, but it gives a cleaner reset state. Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> [ clg: checkpatch.pl fixes ] Signed-off-by: Cédric Le Goater <clg@kaod.org> (cherry picked from commit 30d0647bcfa99d4a141eaa843a9fb5b091ddbb76) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-07-07ppc/pnv: Add QME region for P10Joel Stanley
The Quad Management Engine (QME) manages power related settings for its quad. The xscom region is separate from the quad xscoms, therefore a new region is added. The xscoms in a QME select a given core by selecting the forth nibble. Implement dummy reads for the stop state history (SSH) and special wakeup (SPWU) registers. This quietens some sxcom errors when skiboot boots on p10. Power9 does not have a QME. Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Joel Stanley <joel@jms.id.au> Message-ID: <20230707071213.9924-1-joel@jms.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2023-07-07ppc/pnv: Set P10 core xscom region size to match hardwareNicholas Piggin
The P10 core xscom memory regions overlap because the size is wrong. The P10 core+L2 xscom region size is allocated as 0x1000 (with some unused ranges). "EC" is used as a closer match, as "EX" includes L3 which has a disjoint xscom range that would require a different region if it were implemented. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Message-ID: <20230706053923.115003-2-npiggin@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2023-07-07ppc440_pcix: Rename QOM type define abd move it to common headerBALATON Zoltan
Rename TYPE_PPC440_PCIX_HOST_BRIDGE to better match its string value, move it to common header and use it also in sam460ex to replace hard coded type name. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-ID: <1a1c3fe4b120f345d1005ad7ceca4500783691f7.1688641673.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2023-07-07ppc4xx_pci: Add define for ppc4xx-host-bridge type nameBALATON Zoltan
Add a QOM type name define for ppc4xx-host-bridge in the common header and replace direct use of the string name with the constant. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-ID: <f6e2956b3a09ee481b970ef7873b374c846ba0a8.1688641673.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2023-07-07ppc4xx_pci: Rename QOM type name defineBALATON Zoltan
Rename the TYPE_PPC4xx_PCI_HOST_BRIDGE define and its string value to match each other and other similar types and to avoid confusion with "ppc4xx-host-bridge" type defined in same file. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-ID: <c59c28ef440633dbd1de0bda0a93b7862ef91104.1688641673.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2023-07-07ppc440: Remove ppc460ex_pcie_init legacy init functionBALATON Zoltan
After previous changes we can now remove the legacy init function and move the device creation to board code. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <29aafeea9f1c871c739600a7b093c5456e8a1dc8.1688586835.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2023-07-07ppc/pnv: Add P10 quad xscom modelJoel Stanley
Add a PnvQuad class for the P10 powernv machine. No xscoms are implemented yet, but this allows them to be added. The size is reduced to avoid the quad region from overlapping with the core region. address-space: xscom-0 0000000000000000-00000003ffffffff (prio 0, i/o): xscom-0 0000000100000000-00000001000fffff (prio 0, i/o): xscom-quad.0 0000000100108000-0000000100907fff (prio 0, i/o): xscom-core.3 0000000100110000-000000010090ffff (prio 0, i/o): xscom-core.2 0000000100120000-000000010091ffff (prio 0, i/o): xscom-core.1 0000000100140000-000000010093ffff (prio 0, i/o): xscom-core.0 Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-ID: <20230704054204.168547-4-joel@jms.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2023-07-07ppc/pnv: Subclass quad xscom callbacksJoel Stanley
Make the existing pnv_quad_xscom_read/write be P9 specific, in preparation for a different P10 callback. Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-ID: <20230704054204.168547-3-joel@jms.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2023-07-07pnv/xive: Add property on xive sources to define PQ state on resetFrederic Barrat
The PQ state of a xive interrupt is always initialized to Q=1, which means the interrupt is disabled. Since a xive source can be embedded in many objects, this patch adds a property to allow that behavior to be refined if needed. Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230703081215.55252-2-fbarrat@linux.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2023-06-25pnv/xive2: Add a get_config() method on the presenter classFrederic Barrat
The presenters for xive on P9 and P10 are mostly similar but the behavior can be tuned through a few CQ registers. This patch adds a "get_config" method, which will allow to access that config from the presenter in a later patch. For now, just define the config for the TIMA version. Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-06-25target/ppc: Add msgsnd/p and DPDES SMT supportNicholas Piggin
Doorbells in SMT need to coordinate msgsnd/msgclr and DPDES access from multiple threads that affect the same state. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-06-25ppc/spapr: Move spapr nested HV to a new fileNicholas Piggin
Create spapr_nested.c for most of the nested HV implementation. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-06-25ppc/spapr: Add a nested state structNicholas Piggin
Rather than use a copy of CPUPPCState to store the host state while the environment has been switched to the L2, use a new struct for this purpose. Have helper functions to save and load this host state. Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2023-06-10hw/ppc/openpic: Do not open-code ROUND_UP() macroPhilippe Mathieu-Daudé
While reviewing, the ROUND_UP() macro is easier to figure out. Besides, the comment confirms we want to round up here. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-Id: <20230523061546.49031-1-philmd@linaro.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2023-06-10pnv/xive2: Introduce macros to manipulate TIMA addressesFrederic Barrat
TIMA addresses are somewhat special and are split in several bit fields with different meanings. This patch describes it and introduce macros to more easily access the various fields. Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20230601121331.487207-5-fbarrat@linux.ibm.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2023-05-28target/ppc: Add POWER9 DD2.2 modelNicholas Piggin
POWER9 DD2.1 and earlier had significant limitations when running KVM, including lack of "mixed mode" MMU support (ability to run HPT and RPT mode on threads of the same core), and a translation prefetch issue which is worked around by disabling "AIL" mode for the guest. These processors are not widely available, and it's difficult to deal with all these quirks in qemu +/- KVM, so create a POWER9 DD2.2 CPU and make it the default POWER9 CPU. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Message-Id: <20230515160201.394587-1-npiggin@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2023-05-28spapr: Add SPAPR_CAP_AIL_MODE_3 for AIL mode 3 support for H_SET_MODE hcallNicholas Piggin
The behaviour of the Address Translation Mode on Interrupt resource is not consistently supported by all CPU versions or all KVM versions: KVM HV does not support mode 2, and does not support mode 3 on POWER7 or early POWER9 processesors. KVM PR only supports mode 0. TCG supports all modes (0, 2, 3) on CPUs with support for the corresonding LPCR[AIL] mode. This leads to inconsistencies in guest behaviour and could cause problems migrating guests. This was not noticable for Linux guests for a long time because the kernel only uses modes 0 and 3, and it used to consider AIL-3 to be advisory in that it would always keep the AIL-0 vectors around, so it did not matter whether or not interrupts were delivered according to the AIL mode. Recent Linux guests depend on AIL mode 3 working as specified in order to support the SCV facility interrupt. If AIL-3 can not be provided, then H_SET_MODE must return an error to Linux so it can disable the SCV facility (failure to do so can lead to userspace being able to crash the guest kernel). Add the ail-mode-3 capability to specify that AIL-3 is supported. AIL-0 is implied as the baseline, and AIL-2 is no longer supported by spapr. AIL-2 is not known to be used by any software, but support in TCG could be restored with an ail-mode-2 capability quite easily if a regression is reported. Modify the H_SET_MODE Address Translation Mode on Interrupt resource handler to check capabilities and correctly return error if not supported. KVM has a cap to advertise support for AIL-3. Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20230515160216.394612-1-npiggin@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2023-03-03pnv_phb4_pec: Simplify/align code to parent user-created PHBsFrederic Barrat
When instantiating a user-created PHB on P9/P10, we don't really have a reason any more to go through an indirection in pnv_chip_add_phb() in pnv.c, we can go straight to the right function in pnv_phb4_pec.c. That way, default PHBs and user-created PHBs are all handled in the same file. This patch also renames pnv_phb4_get_pec() to pnv_pec_add_phb() to better reflect that it "hooks" a PHB to a PEC. For P8, the PHBs are parented to the chip directly, so it makes sense to keep calling pnv_chip_add_phb() in pnv.c, to also be consistent with where default PHBs are handled. The only change here is that, since that function is now only used for P8, we can refine the return type. So overall, the PnvPHB front-end now has a pnv_phb_user_get_parent() function which handles the parenting of the user-created PHBs by calling the right function in the right file based on the processor version. It's also easily extensible if we ever need to support a different parent object. Signed-off-by: Frederic Barrat <fbarrat@linux.ibm.com> Message-Id: <20230302163715.129635-5-fbarrat@linux.ibm.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2023-01-20include/hw/ppc include/hw/pci-host: Drop extra typedefsMarkus Armbruster
PnvChip is typedef'ed in five places, and PnvPhb4PecState in two. Keep one, drop the others. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20221222104628.659681-5-armbru@redhat.com>
2023-01-20include/hw/ppc: Don't include hw/pci-host/pnv_phb.h from pnv.hMarkus Armbruster
The next commit needs to include hw/ppc/pnv.h from hw/pci-host/pnv_phb.h. Avoid an inclusion loop. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20221222104628.659681-4-armbru@redhat.com>
2023-01-20include/hw/ppc: Supply a few missing includesMarkus Armbruster
A few headers neglect to include headers they need. They compile only if something else includes the required header(s) first. Fix that. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20221222104628.659681-3-armbru@redhat.com>
2023-01-20include/hw/ppc: Split pnv_chip.h off pnv.hMarkus Armbruster
PnvChipClass, PnvChip, Pnv8Chip, Pnv9Chip, and Pnv10Chip are defined in pnv.h. Many users of the header don't actually need them. One instance is this inclusion loop: hw/ppc/pnv_homer.h includes hw/ppc/pnv.h for typedef PnvChip, and vice versa for struct PnvHomer. Similar structs live in their own headers: PnvHomerClass and PnvHomer in pnv_homer.h, PnvLpcClass and PnvLpcController in pci_lpc.h, PnvPsiClass, PnvPsi, Pnv8Psi, Pnv9Psi, Pnv10Psi in pnv_psi.h, ... Move PnvChipClass, PnvChip, Pnv8Chip, Pnv9Chip, and Pnv10Chip to new pnv_chip.h, and adjust include directives. This breaks the inclusion loop mentioned above. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20221222104628.659681-2-armbru@redhat.com>
2023-01-08include: Include headers where neededMarkus Armbruster
A number of headers neglect to include everything they need. They compile only if the headers they need are already included from elsewhere. Fix that. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20221222120813.727830-3-armbru@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-12-21hw/ppc/spapr: Reduce "vof.h" inclusionPhilippe Mathieu-Daudé
Currently objects including "hw/ppc/spapr.h" are forced to be target specific due to the inclusion of "vof.h" in "spapr.h". "spapr.h" only uses a Vof pointer, so doesn't require the structure declaration. The only place where Vof structure is accessed is in spapr.c, so include "vof.h" there, and forward declare the structure in "spapr.h". Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20221213123550.39302-4-philmd@linaro.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-12-21hw/ppc/vof: Do not include the full "cpu.h"Philippe Mathieu-Daudé
"vof.h" doesn't need the full "cpu.h" to get the target_ulong definition, including "exec/cpu-defs.h" is enough. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20221213123550.39302-3-philmd@linaro.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-12-16hw/pci-host/pnv_phb3_msi: Convert TYPE_PHB3_MSI to 3-phase resetPeter Maydell
Convert the TYPE_PHB3_MSI class to 3-phase reset, so we can avoid using the device_class_set_parent_reset() function. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20221125115240.3005559-8-peter.maydell@linaro.org
2022-10-28ppc4xx_sdram: Move ppc4xx_sdram_banks() to ppc4xx_sdram.cBALATON Zoltan
This function is only used by the ppc4xx memory controller models so it can be made static. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <b1504a82157a586aa284e8ee3b427b9a07b24169.1666194485.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc440_uc.c: Move some macros to ppc4xx.hBALATON Zoltan
These are used by both the SDRAM controller model and system DCRs. In preparation to move SDRAM controller in its own file move these macros to the ppc4xx.h header. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <74d9bf4891e2ccceb52bb6ca6b54fd3f37a9fb04.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc440_sdram: QOM'ifyBALATON Zoltan
Change the ppc440_sdram model to a QOM class derived from the PPC4xx-dcr-device and name it ppc4xx-sdram-ddr2. This is mostly modelling the DDR2 SDRAM controller found in the 460EX (used on the sam460ex board). Newer SoCs (regardless of their PPC core, e.g. 405EX) may have this controller but we only emulate enough of it for the sam460ex u-boot firmware. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <3e82ae575c7c41e464a0082d55ecb4ebcc4d4329.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc4xx_sdram: Rename functions to prevent name clashesBALATON Zoltan
Rename functions to avoid name clashes when moving the DDR2 controller model currently called ppc440_sdram to ppc4xx_devs. This also more clearly shows which function belongs to which model. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <9c09d10fbf36940ebbe30d7038d69cf3f2e58371.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc440_sdram: Get rid of the init RAM hackBALATON Zoltan
Remove the do_init parameter of ppc440_sdram_init and enable SDRAM controller from the board. Firmware does this so it may only be needed when booting with -kernel without firmware but we enable SDRAM unconditionally to preserve previous behaviour. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <c2eda8f83c82f655aa7821a5a8c9310484bd6a1d.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc4xx_sdram: QOM'ifyBALATON Zoltan
Change the ppc4xx_sdram model to a QOM class derived from the PPC4xx-dcr-device and name it ppc4xx-sdram-ddr. This is mostly modelling the DDR SDRAM controller found in the 440EP (used on the bamboo board) but also backward compatible with the older DDR controllers on some 405 SoCs so we also use it for those now. This likely does not cause problems for guests we run as the new features are just not accessed but to model 405 SoC accurately some features may have to be disabled or the model split between 440 and older. Newer SoCs (regardless of their PPC core, e.g. 405EX) may have an updated DDR2 SDRAM controller implemented by the ppc440_sdram model (only partially, enough for the 460EX on the sam460ex) that is not yet QOM'ified in this patch. That is intended to become ppc4xx-sdram-ddr2 when QOM'ified later. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <8f820487fc9011343032c422ecdf3e8ee74d8c11.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc4xx_sdram: Move size check to ppc4xx_sdram_init()BALATON Zoltan
Instead of checking if memory size is valid in board code move this check to ppc4xx_sdram_init() as this is a restriction imposed by the SDRAM controller. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <39e5129dd095b285676a6267c5753786da1bc30d.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc4xx: Use Ppc4xxSdramBank in ppc4xx_sdram_banks()BALATON Zoltan
Change ppc4xx_sdram_banks() to take one Ppc4xxSdramBank array instead of the separate arrays and adjust ppc4xx_sdram_init() and ppc440_sdram_init() accordingly as well as machines using these. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <e3a1fea51f29779fd6a61be90a29c684f3299544.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc4xx_sdram: Get rid of the init RAM hackBALATON Zoltan
The do_init parameter of ppc4xx_sdram_init() is used to map memory regions that is normally done by the firmware by programming the SDRAM controller. Do this from board code emulating what firmware would do when booting a kernel directly from -kernel without a firmware so we can get rid of this do_init hack. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <d6c44c870befa1a075e21f1a59926dcdaff63f6b.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc4xx: Introduce Ppc4xxSdramBank structBALATON Zoltan
Instead of storing sdram bank parameters in unrelated arrays put them in a struct so it's clear they belong to the same bank and simplify the state struct using this bank type. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <5eb82d0424c584b2b9e6f7bc51560f8189ed21bb.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-09-20hw/ppc/spapr: Fix code style problems reported by checkpatchBernhard Beschow
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>
2022-08-31ppc4xx: Rename ppc405-ebc to ppc4xx-ebcBALATON Zoltan
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>
2022-08-31ppc4xx: Move EBC model to ppc4xx_devs.cBALATON Zoltan
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>
2022-08-31ppc4xx: Rename ppc405-plb to ppc4xx-plbBALATON Zoltan
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>
2022-08-31ppc4xx: Move PLB model to ppc4xx_devs.cBALATON Zoltan
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>
2022-08-31ppc/ppc405: QOM'ify MALCédric Le Goater
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>
2022-08-31ppc/ppc4xx: Introduce a DCR device modelCédric Le Goater
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>
2022-08-31ppc/ppc405: QOM'ify CPUCédric Le Goater
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>
2022-08-31ppc/pnv: turn chip8->phbs[] into a PnvPHB* arrayDaniel Henrique Barboza
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>
2022-08-31ppc/pnv: add helpers for pnv-phb user devicesDaniel Henrique Barboza
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>
2022-08-31ppc/pnv: move attach_root_port helper to pnv-phb.cDaniel Henrique Barboza
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>
2022-08-31ppc/pnv: remove root port name from pnv_phb_attach_root_port()Daniel Henrique Barboza
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>
2022-08-31ppc/pnv: turn PnvPHB3 into a PnvPHB backendDaniel Henrique Barboza
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>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-17 04:27:41 +0000