Rpi 4.19.y RFC Enable Raspberry Pi voltage monitor #2706
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Re-expose some dmi APIs for use in VCSM
smsc95xx is adjusting truesize when it shouldn't, and following a recent patch from Eric this is now triggering warnings. This patch stops smsc95xx from changing truesize. Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
Signed-off-by: popcornmix <popcornmix@gmail.com>
Without this patch, removing a device tree overlay can crash here. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
The old arch-specific IRQ macros included a dsb to ensure the write to clear the mailbox interrupt completed before returning from the interrupt. The BCM2836 irqchip driver needs the same precaution to avoid spurious interrupts. Spurious interrupts are still possible for other reasons, though, so trap them early.
Initialise the level for each IRQ to avoid a warning from the arm arch timer code. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Add a duplicate irq range with an offset on the hwirq's so the driver can detect that enable_fiq() is used. Tested with downstream dwc_otg USB controller driver. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Eric Anholt <eric@anholt.net> Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
The spi-bcm2835 driver automatically uses GPIO chip-selects due to some unreliability of the native ones. In doing so it chooses the same pins as the native chip-selects would use, but the existing code always uses pins 7 and 8, wherever the SPI function is mapped. Search the pinctrl group assigned to the driver for pins that correspond to native chip-selects, and use those for GPIO chip- selects. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Select software CS in bcm2708_common.dtsi, and disable the automatic conversion in the driver to allow hardware CS to be re-enabled with an overlay. See: raspberrypi#1547 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Load driver early since at least bcm2708_fb doesn't support deferred probing and even if it did, we don't want the video driver deferred. Support the legacy DMA API which is needed by bcm2708_fb. Don't mask out channel 2. Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Without this alias, Device Tree won't cause the driver to be loaded. See: raspberrypi#1510
The Raspberry Pi firmware looks at the RSTS register to know which partition to boot from. The reboot syscall command LINUX_REBOOT_CMD_RESTART2 supports passing in a string argument. Add support for passing in a partition number 0..63 to boot from. Partition 63 is a special partiton indicating halt. If the partition doesn't exist, the firmware falls back to partition 0. Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
…itical clocks can get enabled early on in the boot process avoiding the risk of disabling a clock, pll_divider or pll when a claiming driver fails to install propperly - maybe it needs to defer. Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Avoids the 0x40000 cycles of warmup again if firmware has already used it
The VPU configures and relies on several PLLs and dividers. Mark all enabled dividers and their PLLs as CRITICAL to prevent the kernel from switching them off. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
The claim-clocks property can be used to prevent PLLs and dividers from being marked as critical. It contains a vector of clock IDs, as defined by dt-bindings/clock/bcm2835.h. Use this mechanism to claim PLLD_DSI0, PLLD_DSI1, PLLH_AUX and PLLH_PIX for the vc4_kms_v3d driver. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
The VPU is responsible for managing the core clock, usually under direction from the bcm2835-cpufreq driver but not via the clk-bcm2835 driver. Since the core frequency can change without warning, it is safer to report the maximum clock rate to users of the core clock - I2C, SPI and the mini UART - to err on the safe side when calculating clock divisors. If the DT node for the clock driver includes a reference to the firmware node, use the firmware API to query the maximum core clock instead of reading the divider registers. Prior to this patch, a "100KHz" I2C bus was sometimes clocked at about 160KHz. In particular, switching to the 4.9 kernel was likely to break SenseHAT usage on a Pi3. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
These divide off of PLLD_PER and are used for the ethernet and wifi PHYs source PLLs. Neither of them is currently represented by a phy device that would grab the clock for us. This keeps other drivers from killing the networking PHYs when they disable their own clocks and trigger PLLD_PER's refcount going to 0. v2: Skip marking as critical if they aren't on at boot. Signed-off-by: Eric Anholt <eric@anholt.net>
At present there is no mechanism to specify driver load order, which can lead to deferrals and repeated retries until successful. Since this situation is expected, reduce the dmesg level to INFO and mention that the operation will be retried. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Christopher Alexander Tobias Schulze - May 2, 2015, 11:57 a.m. This patch fixes a problem with VFP state save and restore related to exception handling (panic with message "BUG: unsupported FP instruction in kernel mode") present on VFP11 floating point units (as used with ARM1176JZF-S CPUs, e.g. on first generation Raspberry Pi boards). This patch was developed and discussed on raspberrypi#859 A precondition to see the crashes is that floating point exception traps are enabled. In this case, the VFP11 might determine that a FPU operation needs to trap at a point in time when it is not possible to signal this to the ARM11 core any more. The VFP11 will then set the FPEXC.EX bit and store the trapped opcode in FPINST. (In some cases, a second opcode might have been accepted by the VFP11 before the exception was detected and could be reported to the ARM11 - in this case, the VFP11 also sets FPEXC.FP2V and stores the second opcode in FPINST2.) If FPEXC.EX is set, the VFP11 will "bounce" the next FPU opcode issued by the ARM11 CPU, which will be seen by the ARM11 as an undefined opcode trap. The VFP support code examines the FPEXC.EX and FPEXC.FP2V bits to decide what actions to take, i.e., whether to emulate the opcodes found in FPINST and FPINST2, and whether to retry the bounced instruction. If a user space application has left the VFP11 in this "pending trap" state, the next FPU opcode issued to the VFP11 might actually be the VSTMIA operation vfp_save_state() uses to store the FPU registers to memory (in our test cases, when building the signal stack frame). In this case, the kernel crashes as described above. This patch fixes the problem by making sure that vfp_save_state() is always entered with FPEXC.EX cleared. (The current value of FPEXC has already been saved, so this does not corrupt the context. Clearing FPEXC.EX has no effects on FPINST or FPINST2. Also note that many callers already modify FPEXC by setting FPEXC.EN before invoking vfp_save_state().) This patch also addresses a second problem related to FPEXC.EX: After returning from signal handling, the kernel reloads the VFP context from the user mode stack. However, the current code explicitly clears both FPEXC.EX and FPEXC.FP2V during reload. As VFP11 requires these bits to be preserved, this patch disables clearing them for VFP implementations belonging to architecture 1. There should be no negative side effects: the user can set both bits by executing FPU opcodes anyway, and while user code may now place arbitrary values into FPINST and FPINST2 (e.g., non-VFP ARM opcodes) the VFP support code knows which instructions can be emulated, and rejects other opcodes with "unhandled bounce" messages, so there should be no security impact from allowing reloading FPEXC.EX and FPEXC.FP2V. Signed-off-by: Christopher Alexander Tobias Schulze <cat.schulze@alice-dsl.net>
This adds a debug module parameter to aid in debugging transfer issues by printing info to the kernel log. When enabled, status values are collected in the interrupt routine and msg info in bcm2835_i2c_start_transfer(). This is done in a way that tries to avoid affecting timing. Having printk in the isr can mask issues. debug values (additive): 1: Print info on error 2: Print info on all transfers 3: Print messages before transfer is started The value can be changed at runtime: /sys/module/i2c_bcm2835/parameters/debug Example output, debug=3: [ 747.114448] bcm2835_i2c_xfer: msg(1/2) write addr=0x54, len=2 flags= [i2c1] [ 747.114463] bcm2835_i2c_xfer: msg(2/2) read addr=0x54, len=32 flags= [i2c1] [ 747.117809] start_transfer: msg(1/2) write addr=0x54, len=2 flags= [i2c1] [ 747.117825] isr: remain=2, status=0x30000055 : TA TXW TXD TXE [i2c1] [ 747.117839] start_transfer: msg(2/2) read addr=0x54, len=32 flags= [i2c1] [ 747.117849] isr: remain=32, status=0xd0000039 : TA RXR TXD RXD [i2c1] [ 747.117861] isr: remain=20, status=0xd0000039 : TA RXR TXD RXD [i2c1] [ 747.117870] isr: remain=8, status=0x32 : DONE TXD RXD [i2c1] Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
See commit dae803e -- the warning is expected sometimes when using CMA. However, that commit still spams my kernel log with these warnings. Signed-off-by: Eric Anholt <eric@anholt.net>
Enable EEE mode as soon as possible after connecting to the PHY, and before phy_start. This avoids a second link negotiation, which speeds up booting and stops the interface failing to become ready. See: raspberrypi#2437 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
The ARM coprocessor registers include dcache line size, but there is no function to expose this value. Rather than create a new one, use the read_cpuid_id function to derive the correct value, which is 32 for BCM2835 and 64 for BCM2836/7. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Rename the driver from "RPI simple soundcard" to "RPi-simple" so that the driver name won't be mangled allowing to be used unaltered as the card conf filename.
Signed-off-by: Serge Schneider <serge@raspberrypi.org> PoE HAT driver cleanup * Fix undeclared variable in rpi_poe_fan_suspend * Add SPDX-License-Identifier * Expand PoE acronym in Kconfig help * Give clearer error message on of_property_count_u32_elems fail * Add documentation * Add vendor to of_device_id compatible string. * Rename m_data_s struct to fw_data_s * Fix typos Fixes: raspberrypi#2665 Signed-off-by: Serge Schneider <serge@raspberrypi.org>
Rationalise the offset and update all call sites. Fixes raspberrypi#2408
It appears the GPU only sends us a message all 10ms to update the playback progress. Other than this, the playback position (what SNDRV_PCM_IOCTL_DELAY will return) is not updated at all. Userspace will see jitter up to 10ms in the audio position. Make this a bit nicer for userspace by interpolating the position using the CPU clock. I'm not sure if setting snd_pcm_runtime.delay is the right approach for this. Or if there is maybe an already existing mechanism for position interpolation in the ALSA core. I only set SNDRV_PCM_INFO_BATCH because this appears to remove at least one situation snd_pcm_runtime.delay is used, so I have to worry less in which place I have to update this field, or how it interacts with the rest of ALSA. In the future, it might be nice to use VC_AUDIO_MSG_TYPE_LATENCY. One problem is that it requires sending a videocore message, and waiting for a reply, which could make the implementation much harder due to locking and synchronization requirements.
…rrypi#2699) During a bulk transfer we request a DMA allocation to hold the scatter-gather list. Most of the time, this allocation is small (<< PAGE_SIZE), however it can be requested at a high enough frequency to cause fragmentation and/or stress the CMA allocator (think time spent in compaction here, or during allocations elsewhere). Implement a pool to serve up small DMA allocations, falling back to a coherent allocation if the request is greater than VCHIQ_DMA_POOL_SIZE. Signed-off-by: Oliver Gjoneski <ogjoneski@gmail.com>
added 2 commits
October 8, 2018 16:15
The upstreamed driver for the GPIO expander has a different compatible string. Change the relevant Device Tree files to match. See: raspberrypi#2704 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
|
@lategoodbye thanks for taking this upstream. This PR needs rebasing, so in the meanwhile here's the link to the commits: |
|
@notro The reason for this pull request is to discuss if the userspace ABI break (different path and different value) is acceptable for Raspbian. I would rebase after final 4.19 is out. |
|
Is it feasible to switch to the upstream driver and provide a downstream patch that additionally creates |
|
From my understanding the hwmon driver cannot simply create such a file, because the sysfs entries are always relative. Edit: Okay, i think of a hacky solution with a global variable or to extract the response for the get_throttled within the firmware driver. |
|
I see now that there's a difference between downstream and mainline in that downstream returns the whole throttled value, wereas mainline only returns the undervoltage bit. Another difference is that ->last_throttled is set during probe. AFAIU this means that the undervoltage warning won't be reported if undervoltage happened before hwmon probe. The voltage normalise message will show though. |
Per hwmon sysfs
Nice catch. I could add a warning into the probe function. |
This reverts commit e460b56, because there is already the Raspberry Pi hwmon driver for this. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
This enables the Raspberry Pi voltage monitor as a replacement for the get_trottled sysfs approach in the firmware driver. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Although the correct fix for low voltage warnings is to improve the power supply, the current implementation of the detection can fill the log if the warning happens freqently. This replaces the logging with slightly custom ratelimited logging. Signed-off-by: James Hughes <james.hughes@raspberrypi.org> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Avoid a hard userspace ABI change by adding a compatible get_throttled sysfs entry. Its value is now feed by the GET_THROTTLED requests of the new hwmon driver. The first access to get_throttled will generate a warning. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
lategoodbye
force-pushed
the
rpi-4.19.y-hwmon
branch
from
74959ba to
7401d7d
Compare
|
Okay, i added a patch which "restore" the old get_throttled. |
popcornmix
force-pushed
the
rpi-4.19.y
branch
from
2599cc2 to
a5d3335
Compare
popcornmix
force-pushed
the
rpi-4.19.y
branch
from
c2f4561 to
83bf476
Compare
|
@lategoodbye thanks for this. The backward compatible node seems to work well (the WARN backtrace will probably generate some worried reports, but should identify any significant users of the old node). I've picked it to rpi-4.19 (dues to conflict after the bump to v4.19) for further exposure (should be an rpi-update kernel with this in very soon). |
popcornmix
added a commit
to raspberrypi/firmware
that referenced
this pull request
Oct 22, 2018
kernel: Enable Raspberry Pi voltage monitor See: raspberrypi/linux#2706
popcornmix
added a commit
to Hexxeh/rpi-firmware
that referenced
this pull request
Oct 22, 2018
kernel: Enable Raspberry Pi voltage monitor See: raspberrypi/linux#2706
27 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@notro pull request has been upstreamed as the Raspberry Pi voltage monitor within the hwmon subsystem and is available since 4.19.
In order avoid having two driver doing the same thing, this pull requests tries to push the Raspberry Kernel more into upstream direction.
"Old" get_trottled sysfs entry:
/sys/devices/platform/soc/soc:firmware/get_trottled"New" hwmon entry:
/sys/class/hwmon/hwmon0/in0_lcrit_alarmDocumentation:
https://github.com/raspberrypi/linux/blob/rpi-4.19.y/Documentation/hwmon/raspberrypi-hwmon