- Jul 19, 2019
-
-
Giedrius authored
-
Phil Elwell authored
The new i2c overlays for pi4 (i2c3, i2c4, i2c5, i2c6) have a standardised interface that allows pin groups to be chosen atomically rather than as individual pins. Add i2c0 and i2c1 overlays to fit the naming scheme and parameter usage, deprecating i2c0-bcm2708 and i2c1-bcm2708. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
The dpi overlays use the fb device tree node as a place to hang the necessary pinctrl changes. With one of the VC4 overlays loaded, the fb node is disabled so the changes have no effect. Modify the overlays to also use the vc4 node, to cover both use cases. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Allen Wild authored
The Raspberry Pi 4 uses the brcmstb thermal driver rather than brcm2835, based on the device tree compatible string 'brcm,avs-tmon-bcm2838'. With CONFIG_BRCMSTB_THERMAL enabled, reading temperature from /sys/class/thermal/thermal_zone0/temp works as expected instead of returning EINVAL. Fixes: https://github.com/raspberrypi/linux/issues/3071 Signed-off-by: Allen Wild <allenwild93@gmail.com>
-
Phil Elwell authored
Add support for the PCF2129 RTC to i2c-rtc and i2c-rtc-gpio overlays. Also add rv3028 to i2c-rtc-gpio (it was missed previously), and don't attempt to set an alternate address for the PCF2127. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Eric Anholt authored
commit 7a9b6be9 upstream. When adding the MFD dependency for power domains and WDT in bcm2835, I added it only on the arm32 side and missed it for arm64. Fixes: 5e6acc3e ("bcm2835-pm: Move bcm2835-watchdog's DT probe to an MFD.") Signed-off-by: Eric Anholt <eric@anholt.net> Reported-by: Stefan Wahren <stefan.wahren@i2se.com> Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
-
Phil Elwell authored
The BCM2835 I2C blocks have a register to set the clock-stretch timeout - how long the device is allowed to hold SCL low - in bus cycles. The current driver doesn't write to the register, therefore the default value of 64 cycles is being used for all devices. Set the timeout to the value recommended for SMBus - 35ms. See: https://github.com/raspberrypi/linux/issues/3064 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Jonathan Bell authored
Seen on a VLI VL805 PCIe to USB controller. For non-stream endpoints at least, if the xHC halts on a particular TRB due to an error then the DCS field in the Out Endpoint Context maintained by the hardware is not updated with the current cycle state. Using the quirk XHCI_EP_CTX_BROKEN_DCS and instead fetch the DCS bit from the TRB that the xHC stopped on. See: https://github.com/raspberrypi/linux/issues/3060 Signed-off-by: Jonathan Bell <jonathan@raspberrypi.org>
-
Phil Elwell authored
pl011_tx_chars takes a "from_irq" parameter to reduce the number of register accesses. When from_irq is true the function assumes that the FIFO is half empty and writes up to half a FIFO's worth of bytes without polling the FIFO status register, the reasoning being that the function is being called as a result of the TX interrupt being raised. This logic would work were it not for the fact that pl011_rx_chars, called from pl011_int before pl011_tx_chars, releases the spinlock before calling tty_flip_buffer_push. A user thread writing to the UART claims the spinlock and ultimately calls pl011_tx_chars with from_irq set to false. This reverts to the older logic that polls the FIFO status register before sending every byte. If this happen on an SMP system during the section of the IRQ handler where the spinlock has been released, then by the time the TX interrupt handler is called, the FIFO may already be full, and any further writes are likely to be lost. The fix involves adding a per-port flag that is true iff running from within the interrupt handler and the spinlock has not yet been released. This flag is then used as the value for the from_irq parameter of pl011_tx_chars, causing polling to be used in the unsafe case. Fixes: 1e84d223 ("serial/amba-pl011: Refactor and simplify TX FIFO handling") Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
The "bus" parameter has two functions - providing unique names for multiple instances of the overlay, and allowing the number of the bus (i.e. "i2c-<bus>") to be specified. The second function hasn't worked as intended because the overlay doesn't include a "reg" property and the firmware intentionally won't create a "reg" property if one doesn't already exist. Allow the bus numbering scheme to work as intended by providing a "reg" with a default value that means "the next available one". See: https://github.com/raspberrypi/linux/issues/3062 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Annaliese McDermond authored
Commit 9de93b04 upstream. Probe function fails to recognize that upstream clock actually doesn't yet exist because clock driver has not been initialized. Actually try to go get the clock and test for its existence before trying to set up a downstream clock based upon it. This fixes a bug that causes the i2c driver not to work with monolithic kernels. Fixes: bebff81f ("i2c: bcm2835: Model Divider in CCF") Signed-off-by: Annaliese McDermond <nh6z@nh6z.net> Acked-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Annaliese McDermond authored
Commit 4a5cfa39 upstream. If any of the clock code in the probe fails and returns, the IRQ will not be freed. Moving the IRQ request to last allows it to be freed on any errors further up in the probe function. devm_ calls can apparently not be used because there are some potential race conditions that will arise. Fixes: bebff81f ("i2c: bcm2835: Model Divider in CCF") Signed-off-by: Annaliese McDermond <nh6z@nh6z.net> Acked-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
-
Phil Elwell authored
Rename the various pi3- overlays to be more generic, listing the devices they apply to in the README. The original names are retained for backwards compatibility as files that just include the new versions - the README marks them as being deprecated. See: https://github.com/raspberrypi/firmware/issues/1174 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
As a result of being loaded by the POE HAT EEPROM, the rpi-poe overlay doesn't expose parameters in the usual way; instead it adds them to the base Device Tree, and the user is expected to use "dtparam=..." to access them. To make the documentation correct and to protect users who load the overlay explicitly, expecting to be able to use the parameters, add real parameters to the overlay as well. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Dave Stevenson authored
This reverts commit a2c73e18. An alternative version was accepted upstream. Revert this patch to apply that one. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
-
Dave Stevenson authored
Apparently this is a vestigial setting and should be removed. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
-
Dave Stevenson authored
Fix a few minor checkpatch complaints to make the driver clean Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
-
Dave Stevenson authored
Due to a misunderstanding of the DMA mapping APIs, I made the wrong decision on how to implement this. Rework to use dma_alloc_coherent instead of the CMA API. This also allows it to be built as a module easily. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
-
Dave Stevenson authored
The cache flushing ioctls are used by the Pi3 HEVC hw-assisted decoder as it needs finer grained flushing control than dma_ops allow. These cache calls are not present for ARM64, therefore disable them. We are not actively supporting 64bit kernels at present, and the use case of the HEVC decoder is fairly limited. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
-
Phil Elwell authored
The gpio-fan overlay was submitted for the 4.14 kernel where the second value in the Device Tree gpios declaration was ignored (thanks to an old-style driver), allowing the fan-control output to be active-high even though the declaration appears to request it be active-low. The gpio-fan driver in 4.19 uses GPIO descriptors and honours the active-low flag that the overlay (accidentally?) supplies. Change/correct the flags field to mark the GPIO as active-high. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Andrei Gherzan authored
This driver is used in the device tree for the emmc2 node. See #3032 Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
-
Phil Elwell authored
And all Rabbit's friends-and-relations. See: https://github.com/raspberrypi/linux/issues/3042 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
See: https://github.com/raspberrypi/linux/issues/3042 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
Downstream Raspberry Pi dts files add "coherent_pool=1M" to the kernel command line to aid the dwc_otg driver, but this excluded Pi 4 which uses a new XCHI interface instead. UAS also benefits from a larger coherent_pool value, so replicate the addition in bcm2711-rpi-4-b.dts. See: https://github.com/raspberrypi/linux/pull/3040 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Dave Stevenson authored
Adds signalling for BT601/709/2020, and limited/full range (on BT601). Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
-
Dave Stevenson authored
"4600e91b Pulled in the multi frame buffer support from the Pi3 repo" pulled back in the code for allocating the framebuffer from the CMA heap. Revert it again. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
-
Chris Miller authored
Signed-off-by: Chris G Miller <chris@creative-electronics.net>
-
- Jun 26, 2019
-
-
Mariusz Bialonczyk authored
commit aacd152e upstream. This commit is fixing a smatch warning: drivers/w1/slaves/w1_ds2413.c:61 state_read() warn: impossible condition '(*buf == 255) => ((-128)-127 == 255)' by creating additional u8 variable for the bus reading and comparision Reported-by: kbuild test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Fixes: 3856032a ("w1: ds2413: when the slave is not responding during read, select it again") Signed-off-by: Mariusz Bialonczyk <manio@skyboo.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mariusz Bialonczyk authored
commit 3856032a upstream. The protocol is not allowing to obtain a byte of 0xff for PIO_ACCESS_READ call. It is very likely that the slave was not addressed properly and it is just not respoding (leaving the bus in logic high state) during the read of sampled PIO value. We cannot just call w1_reset_resume_command() because the problem will persist, instead try selecting (addressing) the slave again. Signed-off-by: Mariusz Bialonczyk <manio@skyboo.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mariusz Bialonczyk authored
commit c50d09a8 upstream. The state_read() was calling PIO_ACCESS_READ once and bail out if it failed for this first time. This commit is improving this to trying more times before it give up, similarly as the write call is currently doing. Signed-off-by: Mariusz Bialonczyk <manio@skyboo.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mariusz Bialonczyk authored
commit ae2ee27a upstream. Make the output_write simpler. Based on Jean-Francois Dagenais code from: 49695ac4 ("w1: ds2408: reset on output_write retry with readback") Signed-off-by: Mariusz Bialonczyk <manio@skyboo.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mariusz Bialonczyk authored
commit 0e3743d8 upstream. The ds2805 has a structure named: w1_family_2d, which surely comes from a w1_ds2431 module. This commit fixes this name to prevent confusion and mark a correct family name. Signed-off-by: Mariusz Bialonczyk <manio@skyboo.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Phil Elwell authored
The dwc2 overlay no longer uses the dwc2_usb label, and the latest ovmerge (which generates the upstream overlay) removes unused labels. Update the checked-in version to match. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
See: https://github.com/raspberrypi/linux/issues/3013 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
Kernels since 4.19 have required the correct manufacture name in the compatible string for I2C devices, and unfortunately the one for the Dallas/Maxim DS1307 should have been "dallas,ds1307" and not "maxim,ds1307". See: https://github.com/raspberrypi/linux/issues/3013 Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
I've attempted to follow the upstream conventions in the DT commits, but this is just presented here initially as a talking point. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
1) The top-level .dts files now include parallel chains of bcm27xx.dtsi and bcm27xx-rpi.dtsi files, with no cross-inclusion between the two chains. 2) Move definitions and deletions to the point of maximum commonality to reduce redundancy. Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
-
Dave Stevenson authored
Selecting 1080p100 and 120 has very limited gain, but don't want to block VGA85 and similar. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
-
dp111 authored
It appears to me the addresses for the gic400 are slightly wrong . See section 3.2 https://static.docs.arm.com/ddi0471/a/DDI0471A_gic400_r0p0_trm.pdf
-