Enable regulator support #1756
Closed
Enable regulator support #1756
Conversation
This file contains hidden or 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
|
This is re-visiting #1479? |
|
@clivem yes, basically |
HiassofT
force-pushed
the
rpi-4.8.y-regulator
branch
from
e92a604 to
9fec570
Compare
|
Regarding to this discussion simple regulators do not belong to a simple bus. |
|
@lategoodbye thanks for your feedback. I'm a little confused now: I followed the DT structure of the Tegra210 which had regulators added in a simple-bus a few months ago 1b4c842 Is there some definitive guide where off-soc / on-board nodes should be added? |
|
I assume the patch for Tegra210 has never been forwarded to the DT folks. There are a lot of bad examples. Unfortunately i don't know about a guide about this topic. The devicetree mailing list should be more reliable in such cases. |
HiassofT
force-pushed
the
rpi-4.8.y-regulator
branch
from
9fec570 to
67e80fe
Compare
|
Digging through quite some mails on the DT list the consensus seems to be that non-addressable on-board devices are best added as root nodes to the DT. That also makes sense topology-wise, having a bus with pseudo addresses for the regulators looked odd to me. I've moved the regulator nodes to the DT root and changed the names to end in _reg instead of _sys - that seemed more logical to me. |
|
Looks good to me. Thanks |
This reverts commit 15001e5.
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: Sam Nazarko <email@samnazarko.co.uk>
Signed-off-by: popcornmix <popcornmix@gmail.com>
tty_port_hangup sets a port's tty field to NULL (holding the port lock), but uart_tx_stopped, called from __uart_start (with the port lock), uses the tty field without checking for NULL. Change uart_tx_stopped to treat a NULL tty field as another stopped indication. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Without this patch, removing a device tree overlay can crash here. Signed-off-by: Phil Elwell <phil@raspberrypi.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>
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.
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>
Signed-off-by: Noralf Tronnes <notro@tronnes.org>
Contrary to the documentation, the BCM2835 GPIO controller actually has four interrupt lines - one each for the three IRQ groups and one common. Rather confusingly, the GPIO interrupt groups don't correspond directly with the GPIO control banks. Instead, GPIOs 0-27 generate IRQ GPIO0, 28-45 GPIO1 and 46-53 GPIO2. Awkwardly, the GPIOS for IRQ GPIO1 straddle two 32-entry GPIO banks, so it is cleaner to split out a function to process the interrupts for a single GPIO bank. This bug has only just been observed because GPIOs above 27 can only be accessed on an old Raspberry Pi with the optional P5 header fitted, where the pins are often used for I2S instead.
Although the GPIO controller can generate three interrupts (four counting the common one), the device tree files currently only specify two. In the absence of the third, simply don't register that interrupt (as opposed to registering 0), which has the effect of making it impossible to generate interrupts for GPIOs 46-53 which, since they share pins with the SD card interface, is unlikely to be a problem.
When dynamically unloading overlays, it is important that freed pins are restored to being inputs to prevent functions from being enabled in multiple places at once. Signed-off-by: Phil Elwell <phil@raspberrypi.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>
The combo of list_empty() check and return list_first_entry() can be replaced with list_first_entry_or_null(). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Eric Anholt <eric@anholt.net>
Fixes broken grayscale ramps on many HDMI monitors, where large areas at the ends of the ramp would all appear as black or white. Signed-off-by: Eric Anholt <eric@anholt.net>
On Pi0/1/2, we use an external GPIO line for hotplug detection, since the HDMI_HOTPLUG register isn't connected to anything. However, with the Pi3 the HPD GPIO line has moved off to a GPIO expander that will be tricky to get to (the firmware is constantly polling the expander using i2c0, so we'll need to coordinate with it). As a stop-gap, if we don't have a GPIO line, use an EDID probe to detect connection. Fixes HDMI display on the pi3. Signed-off-by: Eric Anholt <eric@anholt.net>
Fixes occasional debug spew at boot when connected directly through HDMI, and probably confusing the HDMI state machine when we go trying to poke registers for the enable sequence too soon. Signed-off-by: Eric Anholt <eric@anholt.net>
We really do need to be using the halved V fields. I had been confused by the code I was using as a reference because it stored halved vsync fields but not halved vdisplay, so it looked like I only needed to divide vdisplay by 2. This reverts part of Mario's timestamping fixes that prevented CRTC_HALVE_V from applying, and instead adjusts the timestamping code to not use the crtc field in that case. Fixes locking of 1920x1080x60i on my Dell 2408WFP. There are black bars on the top and bottom, but I suspect that might be an under/overscan flags problem as opposed to video timings. Signed-off-by: Eric Anholt <eric@anholt.net>
Fixes a purple bar on the left side of the screen with my Dell 2408WFP. It will also be required for supporting the double-clocked video modes. Signed-off-by: Eric Anholt <eric@anholt.net>
Now that we have infoframes to report the pixel repeat flag, we can start using it. Fixes locking the 720x480i and 720x576i modes on my Dell 2408WFP. Like the 1920x1080i case, they don't fit properly on the screen, though. Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
Lots of drivers don't properly compile without this when CONFIG_FB=n. It's kinda a hack, but since CONFIG_FB doesn't stub any fucntions when it's disabled I think it makes sense to add it to drm_fb_helper.h. Long term we probably need to rethink all the logic to unload firmware framebuffer drivers, at least if we want to be able to move away from CONFIG_FB and fbcon. v2: Unfortunately just stubbing out remove_conflicting_framebuffers in drm_fb_helper.h upset gcc about static vs. non-static declarations, so a new wrapper it needs to be. Means more churn :( Cc: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: tomi.valkeinen@ti.com Cc: dh.herrmann@gmail.com Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470847958-28465-2-git-send-email-daniel.vetter@ffwll.ch
…ode. This gets us normal 3D support on top of the existing firmware display stack. There's no real modesetting support, no async pageflips (hurting performance), etc., but it means that the desktop can at least run until we get full native modesetting. Signed-off-by: Eric Anholt <eric@anholt.net>
If the allocation fails the current code returns success. If copy_from_user() fails it returns the number of bytes remaining instead of -EFAULT. Fixes: d5b1a78 ("drm/vc4: Add support for drawing 3D frames.") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Eric Anholt <eric@anholt.net> (cherry picked from commit b2cdeb1)
The loop is scanning until the original max_ip (size of the BO), but we want to not examine any code after the PROG_END's delay slots. There was a block trying to do that, except that we had some early continue statements if the signal wasn't a PROG_END or a BRANCH. The failure mode would be that a valid shader is rejected because some undefined memory after the PROG_END slots is parsed as a branch and the rest of its setup is illegal. I haven't seen this in the wild, but valgrind was complaining when about this up in the userland simulator mode. Signed-off-by: Eric Anholt <eric@anholt.net> (cherry picked from commit 457e67a)
The validation for it ends up being quite simple, but I hadn't got around to it before merging the driver. For backwards compatibility, we also need to add a flag so that the userspace GL driver can easily tell if the kernel will allow ETC1 textures (on an old kernel, it will continue to convert to RGBA8) Signed-off-by: Eric Anholt <eric@anholt.net> (cherry picked from commit 7154d76)
The pm_runtime_put() we were using immediately released power on the device, which meant that we were generally turning the device off and on once per frame. In many profiles I've looked at, that added up to about 1% of CPU time, but this could get worse in the case of frequent rendering and readback (as may happen in X rendering). By keeping the device on until we've been idle for a couple of frames, we drop the overhead of runtime PM down to sub-.1%. Signed-off-by: Eric Anholt <eric@anholt.net> (cherry picked from commit 3a62234)
FS threading brings performance improvements of 0-20% in glmark2. The validation code checks for thread switch signals and ensures that the registers of the other thread are not touched, and that our clamps are not live across thread switches. It also checks that the threading and branching instructions do not interfere. (Original patch by Jonas, changes by anholt for style cleanup, removing validation the kernel doesn't need to do, and adding the flag for userspace). v2: Minor style fixes from checkpatch. Signed-off-by: Jonas Pfeil <pfeiljonas@gmx.de> Signed-off-by: Eric Anholt <eric@anholt.net> (cherry picked from commit c778cc5)
The i2c-sensor overlay is a container for various pressure and temperature sensors, currently bmp085 and bmp280. The standalone bmp085_i2c-sensor overlay is now deprecated. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
We now create overlays as .dtbo files.
[ Upstream commit 1bcaa05 ] This reverts commit 18339f5 ("HID: dragonrise: fix HID...") because it breaks certain dragonrise 0079:0006 gamepads. While it may fix a breakage caused by commit 79346d6 ("HID: input: force generic axis to be mapped to their user space axis"), it is probable that the manufacturer released different hardware with the same PID so this fix works for only a subset and breaks the other gamepads sharing the PID. What is needed is another more generic solution which fixes 79346d6 ("HID: input: force generic axis ...") breakage for this controller: we need to add an exception for this driver to make it keep the old behaviour previous to the initial breakage (this is done in patch 2 of this series). Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Avoids the 0x40000 cycles of warmup again if firmware has already used it
popcornmix
force-pushed
the
rpi-4.8.y
branch
from
430587d to
49020f7
Compare
Signed-off-by: Matthias Reichl <hias@horus.com>
Signed-off-by: Matthias Reichl <hias@horus.com>
Reference 3.3V / 5V system rails instead of instantiating local regulators. Add missing power supply properties for codecs where these are required according to the DT bindings docs. Signed-off-by: Matthias Reichl <hias@horus.com>
HiassofT
force-pushed
the
rpi-4.8.y-regulator
branch
from
67e80fe to
f5a5a6e
Compare
popcornmix
force-pushed
the
rpi-4.8.y
branch
from
49020f7 to
c8af0c2
Compare
|
superseded by #1810 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
39 participants
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.
Several audio codecs and (headphone-) amplifiers, especially those with builtin regulators, require voltage/current regulator support in the kernel.
This feature hadn't been enabled before because it had the potential to break drivers that didn't list the (often required) supply properties in their DT overlays.
Fortunately things have changed and the kernel attaches a dummy regulator in those cases for quite a while now. This is especially important for HATs where the DT overlay is loaded from EEPROM.
Using a HiFiBerry Digi Pro (HAT, with overlay in EEPROM) on a kernel with regulator support only gives 2 harmless warnings but otherwise the device works fine:
I've mainly tested with 4.8 and 4.9 kernels, but a quick test shows that it would be safe to add this to 4.4 as well - the hifiberry card works fine on this kernel, too.