news
Kernel: GPIO, /proc, AMD
-
Larry Bank ☛ Really really fast GPIO on Linux
The "digital pins" of most MCUs/SoCs are usually controlled from a few memory mapped ports. These exist in a similar form on simple Microcontrollers like the AVR 8-bit series (e.g. Arduino UNO) and on more complex SoCs like the Allwinner A733 (e.g. OrangePi Zero 3W). There are groups of bits to control each pin's function (e.g. simple input/output or special functions like I2C, SPI, etc) and additional bits to enable features such as pull-up resistors or interrupts. For anyone who is familiar with the digitalWrite() and digitalRead() functions of Arduino, it might surprise you to know that you can read and write all the pins of a GPIO port in parallel with a single instruction. The old Arduino UNO LCD shields depended on this feature - they're connected via an 8-bit parallel bus and make use of the fact that you can write 8-bits at once to the AVR's GPIO ports. If not for this ability to bit-bang 8-bits at a time in software, updating the contents of the LCD would be incredibly slow if done with individual calls to digitalWrite().
-
University of Toronto ☛ Why people have moved away from using /proc for everything
One of the great ideas in Unix is the /proc pseudo-filesystem (which comes from Research Unix). Initially used to expose processes (cf) as an alternative to ptrace(), it grew to encompass an increasing amount of general system information in some Unixes, such as Linux. In Linux, this has resulted in frequent use of general /proc files, but in Linux and in other Unixes, people are increasingly moving away from accessing information through /proc in favour of direct system calls. This isn't because /proc is a bad idea in theory. Instead, it's because there turn out to be some issues with /proc in practice, both about performance and about reliability.
-
AMD is trading DMA containment for lower latency on its APUs, and it is on by default
AMD's integrated graphics will give up the IOMMU's containment of direct memory access by default in the next Linux kernel, and AMD wrote the trade down in its own commit message. "Arming PerfOpt trades IOMMU DMA containment for lower DMA latency," the amdgpu patch says. "This is enabled by default for GPUs in the identity domain as a deliberate, documented policy and can be disabled with iommu_perfopt=0."