aboutsummaryrefslogtreecommitdiff
path: root/Kconfig
diff options
context:
space:
mode:
authorCédric Le Goater <clg@kaod.org>2022-08-17 17:08:18 +0200
committerDaniel Henrique Barboza <danielhb413@gmail.com>2022-08-31 14:08:06 -0300
commit629cae617039e03d5bfdc0120ade69135a009d33 (patch)
treed6a696bf72e8a27017b89b6674eb7efa1a766bf0 /Kconfig
parentb42ad437562f72b31e5743db4ddf183a8e810eb2 (diff)
downloadqemu-629cae617039e03d5bfdc0120ade69135a009d33.zip
qemu-629cae617039e03d5bfdc0120ade69135a009d33.tar.gz
qemu-629cae617039e03d5bfdc0120ade69135a009d33.tar.bz2
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>
Diffstat (limited to 'Kconfig')
0 files changed, 0 insertions, 0 deletions