On-demand initialization prevents read-write operations on BARs of
invalid devices at construction time, which may result in surprising
behavior later on, for example, when resetting X260 notebooks via ACPI
information.
These utilities simplify the control of clocks, resets, and power
domains from within the platform driver.
This is needed when driving a low-level device directly from the
platform driver, for example for driving the mbox mechanism to access
the system-control processor of the PinePhone.
This patch reflects both the pci_decode results and the platform
driver's aggregated device information in Sculpt's /report/drivers/ in
the form of pci_devices and devices files respectively.
The configured 'st_blksize' influences the sizing of the FILE buffer,
see '__swhatbuf()'. Increasing the blksize hint can lead to larger
'fread()' requests and in return to fewer roundtrips.
This commit updates the driver from version 6.6 to 7.1. In contrast
to the old driver the new one will now probe all available HDA devices
and will drive the first usable one, e.g.:
```
[init -> audio_drv] azalia0 [8086:160c]
[init -> audio_drv] :
[init -> audio_drv] azalia0: no supported codecs
[init -> audio_drv] azalia1 [8086:9ca0]
[init -> audio_drv] :
[init -> audio_drv] azalia1: codecs: Realtek ALC292
[init -> audio_drv] audio0 at azalia1
```
Fixes#4629.
Implemented as depicted in the OpenBSD driver, register description
found in 'AMD SB700/710/750 Register Reference Guide'
(43009_sb7xx_rrg_pub_1.00.pdf).
Issue #4629.
Instead of using a global value to enumerate the MSIs, use a function argument
instead. Whenever the process of PCI device reporting gets started again,
due to an initially too small report buffer, the MSI enumeration value is reset
again. Formerly, we wasted MSI numbers.
Ref genodelabs/genode#4628
Don't skip IRQ reporting if legacy IRQ/GSIs are not supported as the
device may support MSI/MSI-X exclusively.
The commit also enables reserved_memory reporting of devices without
IRQs.
Ref genodelabs/genode#4578
Until now, the /config/system ROM was not handled by the sculpt manager
but solely managed by the user. Its main purpose was the ability to
reset or power-down the machine by manually modifying the 'state'
attribute. However, down the road, we'd like to enable the sculpt
manager to drive this state, e.g., to implement the multi-staged
loading of drivers, or to drive suspend-resume states.
The support such scenarios, the 'system' state has been moved from
/config/system to /config/managed/system.
* Add EHCI PCI quirk
* Add UHCI reset to UHCI quirk
* Apply all PCI quirks in order of the PCI bus numbering
otherwise the machine might stall
Ref genodelabs/genode#4578
Instead of allowing the client to set a caching attribute
in the io_mem() call of the device interface, which was
only used to decide in between of the memory being
write-combined or not, remove it from the API.
Instead use the information delivered by the devices ROM,
whether memory from a PCI BAR is prefetchable or not,
to decide whether it is mapped write-combined or not.
Ref genodelabs/genode#4578
Memory descriptors in PCI BARs have a prefetchable bit, which can
be used to optimize memory access when setting, e.g. write-combined
in page-table entries.
Ref genodelabs/genode#4578
The DHCP client used to always send packets with a size of 1024 regardless of
the size of the actual content, which was always significantly lower. 1024
bytes was simply a guess to provide enough space for all types of DHCP client
packets. As we know the exact size of each packet the DHCP client sends even
before packet creation, this commit makes use of the knowledge resulting in
much smaller packets sent by the DHCP client.
Fixes#4619
On some Cortex A9 platforms (Qemu 4.2.1 PBXA9), the IRQ status register is not
reliable. Sometimes, it indicates an IRQ too early, i.e., shortly before the
counter wraps. Therefore we have to accomplish wrap detection via counter
comparison only. We check whether the current counter value is higher than the
start counter value of the current timeout.
However, this implies that we have to take care to always read out the counter
before it hits the max timout value again. And, therefore, the max timeout
value has to be far away from the first value the counter has after wrapping.
Consequently, we propagate a max timeout value of half the max counter value.
Fixes#4209