The ``-portrait`` and ``-rotate`` options were documented as only
working with the PXA LCD device, and all the machine types using
that display device were removed in 9.2.
These options were intended to simulate a mobile device being
rotated by the user, and had three effects:
* the display output was rotated by 90, 180 or 270 degrees
(implemented in the PXA display device models)
* the mouse/trackpad input was rotated the opposite way
(implemented in generic code)
* the machine model would signal to the guest about its
orientation
(implemented by e.g. the spitz machine model)
Of these three things, the input-rotation was coded without being
restricted to boards which supported the full set of device-rotation
handling, so in theory the options were usable on other machine
models with odd effects (rotating input but not display output). But
this was never intended or documented behaviour, so we can reasonably
drop these command line arguments without a formal deprecate-and-drop
cycle for them.
Remove the options, and their implementation and documentation.
Describe the removal in removed-features.rst.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20241003140010.1653808-7-peter.maydell@linaro.org
The ecc.c code was used only by the PXA2xx and OMAP2 SoC devices,
which we have removed, so it is now completely unused.
Note that hw/misc/eccmemctl.c does not in fact use any of the
code frome ecc.c, so that KConfig dependency was incorrect.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20241003140010.1653808-6-peter.maydell@linaro.org
The only PCMCIA subsystem was the PXA2xx SoC and the machines
using it, which have now been removed. Although in theory
we have a few machine types which have PCMCIA (e.g. kzm,
the strongarm machines, sh4's sh7750), none of those machines
implement their PCMCIA controller, and they're all old and
no longer very interesting machine types.
Rather than keeping all the PCMCIA code in-tree without any
active users of it, delete it. If we need PCMCIA in future
we can always resurrect it.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20241003140010.1653808-5-peter.maydell@linaro.org
The MAX7310 GPIO controller was used only by the XScale-based Zaurus
machine types. Now they have been removed we can remove this device
model as well.
Because this device is an I2C device, in theory it could be created
by users on the command line for boards with a different I2c
controller, but we don't believe users are doing this -- it would be
impossible on the command line to connect up the GPIO inputs/outputs.
The only example a web search produces for "device max7310" is a user
trying to create this because they didn't realize that there was no
way to manipulate the GPIO lines.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20241003140010.1653808-3-peter.maydell@linaro.org
The MAX111X ADC device was used only by the XScale-based
Zaurus machine types. Now they have all been removed, we can
drop this device model too.
Because this device is an SSI device, in theory it could be created
by users on the command line for boards with a different SSI
controller, but we don't believe users are doing this -- it would be
impossible on the command line to connect up the GPIO inputs which
correspond to ADC inputs, or the GPIO output which is an interrupt
line. The only example a web search produces for "device max1111" or
"device max1110" is our own bug report
https://gitlab.com/qemu-project/qemu/-/issues/2228
where it's used as an example of a bogus command that causes an
assertion in an aspeed machine type that wasn't expecting anything
other than flash devices on its SMC bus.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20241003140010.1653808-2-peter.maydell@linaro.org
Currently the QemuLockCnt data structure and associated functions are
in the include/qemu/thread.h header. Move them to their own
qemu/lockcnt.h. The main reason for doing this is that it means we
can autogenerate the documentation comments into the docs/devel
documentation.
The copyright/author in the new header is drawn from lockcnt.c,
since the header changes were added in the same commit as
lockcnt.c; since neither thread.h nor lockcnt.c state an explicit
license, the standard default of GPL-2-or-later applies.
We include the new header (and the .c file, which was accidentally
omitted previously) in the "RCU" part of MAINTAINERS, since that
is where the lockcnt.rst documentation is categorized.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20240816132212.3602106-7-peter.maydell@linaro.org
The OMAP interrupt controller code used to have an omap-intc
class and an omap2-intc class, which shared common code via
the abstract class common-omap-intc. Now we have deleted
omap2-intc, we don't need the separate abstract base class;
fold int into omap-intc.
Suggested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20241003135323.1653230-1-peter.maydell@linaro.org
This patch implements Allwinner A10 SPI controller emulation.
Only master-mode functionality is implemented.
Since U-Boot and Linux SPI drivers for Allwinner A10 perform only
byte-wide CPU access (no DMA) to the transmit and receive registers of
the peripheral, the emulated controller does not implement DMA control,
and supports only byte-wide access to transmit and receive registers
(half-word and word accesses will be treated as byte accesses).
Signed-off-by: Strahinja Jankovic <strahinja.p.jankovic@gmail.com>
Message-id: 20241001221349.8319-2-strahinja.p.jankovic@gmail.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The result of 1 << regbit with regbit==31 has a 1 in the 32nd bit.
When cast to uint64_t (for further bitwise OR), the 32 most
significant bits will be filled with 1s. However, the documentation
states that the upper 32 bits of ICH_AP[0/1]R<n>_EL2 are reserved.
Add an explicit cast to match the documentation.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Cc: qemu-stable@nongnu.org
Fixes: c3f21b065a ("hw/intc/arm_gicv3_cpuif: Support vLPIs")
Signed-off-by: Alexandra Diupina <adiupina@astralinux.ru>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The result of 1 << regbit with regbit==31 has a 1 in the 32nd bit.
When cast to uint64_t (for further bitwise OR), the 32 most
significant bits will be filled with 1s. However, the documentation
states that the upper 32 bits of ICC_AP[0/1]R<n>_EL2 are reserved.
Add an explicit cast to match the documentation.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Cc: qemu-stable@nongnu.org
Fixes: 28cca59c46 ("hw/intc/arm_gicv3: Add NMI handling CPU interface registers")
Signed-off-by: Alexandra Diupina <adiupina@astralinux.ru>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The result of 1 << regbit with regbit==31 has a 1 in the 32nd bit.
When cast to uint64_t (for further bitwise OR), the 32 most
significant bits will be filled with 1s. However, the documentation
states that the upper 32 bits of ICH_AP[0/1]R<n>_EL2 are reserved.
Add an explicit cast to match the documentation.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Cc: qemu-stable@nongnu.org
Fixes: d2c0c6aab6 ("hw/intc/arm_gicv3: Handle icv_nmiar1_read() for icc_nmiar1_read()")
Signed-off-by: Alexandra Diupina <adiupina@astralinux.ru>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Generic RCC class for STM32 devices. It can be used for most of
the STM32 chips. Note that it only implements enable and reset
capabilities.
Signed-off-by: Roman Cardenas Rodriguez <rcardenas.rod@gmail.com>
[PMM: tweaked commit message, added MAINTAINERS lines]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The recently removed 'cheetah' machine was the single user
of the omap_uwire_attach() method. Remove it altogether with
the uWireSlave structure. Replace the send/receive callbacks
by Unimplemented logging.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Frontends can be attached and detached during run-time (although detach
is not implemented, but will follow). Counter variable of muxes is not
enough for proper attach/detach management, so this patch implements
bitset: if bit is set for the `mux_bitset` variable, then frontend
device can be found in the `backend` array (yes, huge confusion with
backend and frontends names).
Signed-off-by: Roman Penyaev <r.peniaev@gmail.com>
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>
Cc: qemu-devel@nongnu.org
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20241014152408.427700-7-r.peniaev@gmail.com>
If the defaults for --enable-rust ($rust in configure) and Meson's rust
option are out of sync, incremental builds will pick Meson's default.
This happens because, on an incremental build, configure does not run
Meson, Make does instead. Meson then gets the command line options
from either coredata.dat (which has everything cached in Python's pickle
format) or cmd_line.txt (slow path when Meson version is upgraded), but
neither knows about the rust option, and the meson_options.txt default
is used.
This will cause have_rust to be true if rustc is available; and the build
to fail because configure did not put a RUST_TARGET_TRIPLE in config-host.mak.
When in the Rust pull request I changed the $rust default from auto
to disabled, I should have made the same change to meson_options.txt;
do it now.
Cc: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Reported-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Tested-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20241014110113.173946-1-pbonzini@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
A working native Rust compiler is always needed in order to compile Rust
code, even when cross compiling, in order to build the procedural macros
that QEMU uses.
Right now, the check is done in rust/qemu-api-macros/meson.build, but this
has two disadvantages. First, it makes the build fail when the Meson "rust"
option is set to "auto" (instead, Rust support should be disabled). Second,
add_languages() is one of the few functions that are executed even by
"meson introspect", except that "meson introspect" executes both branches
of "if" statements! Therefore, "meson introspect" tries to look for a
Rust compiler even if the option is disabled---and then fails because
the compiler is required by rust/qemu-api-macros/meson.build. This is
visible for example if the compilation host has a stale
scripts/meson-buildoptions.sh and no rustc installed.
Both issues can be fixed by moving the check to the main meson.build,
together with the check for the cross compiler.
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
gio.pc variable is a bit bogus in context of cross-compilation, since it
contains an absolute path, relative to the sysroot directory. On Fedora, it ends
up as:
/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/usr/bin/gdbus-codegen
path which does not exist because it is not shipped by Fedora mingw
packages.
Instead, we can rely on meson find_program() behaviour to do a better
job based on its search order and capabilities.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241008125028.1177932-14-marcandre.lureau@redhat.com>
Use qemu_memfd_alloc() to allocate the display surface memory, which
will fallback on tmpfile/mmap() on systems without memfd, and allow to
share the display with other processes.
This is similar to how display memory is allocated on win32 since commit
09b4c198 ("console/win32: allocate shareable display surface").
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Message-ID: <20241008125028.1177932-13-marcandre.lureau@redhat.com>
