- Dec 13, 2022
-
-
Robert Nelson authored
5.10.153-ti-arm64-r81 bb.org_defconfig 5.10 TI Delta: https://github.com/RobertCNelson/ti-linux-kernel/compare/8b51d20b6e6e1b9277b59b7aaed8a97eff43097f...3eee621d164a02048ba26ca1342cba9c8d913d46 AUFS: https://github.com/sfjro/aufs-standalone/commit/2c2dfeb062b323e07fd1e3a0d1c3eb816da25a8b BBDTBS: https://git.beagleboard.org/beagleboard/BeagleBoard-DeviceTrees/-/commit/96c2eeb3f529435e79b845525e00dee5216a7d0c RT: patch-5.10.153-rt76.patch.xz WPANUSB: https://github.com/statropy/wpanusb/commit/251f0167545bf2dcaa3cad991a59dbf5ab05490a BCFSERIAL: https://github.com/statropy/bcfserial/commit/aded88429a8a00143596b41f4c1f50d9ae3d4069 WIRELESS_REGDB: https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/commit/?id=fe05cc94e070c71486047002fc2edf68f5f2a07a KSMBD: https://github.com/cifsd-team/ksmbd/commit/133175a68d5aa674b79707b31b5b2f87aac22291 Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Reference: v6.0.11 Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Nishanth Menon authored
Hardcode LED configuration for LED2 signal to be link status and LED0 signal to be rx/tx Signed-off-by: Nishanth Menon <nm@ti.com>
-
Nikita Yushchenko authored
Hotplug events reported by bridge drivers over drm_bridge_hpd_notify() get ignored unless somebody calls drm_bridge_hpd_enable(). When the connector for the bridge is bridge_connector, such a call is done from drm_bridge_connector_enable_hpd(). However drm_bridge_connector_enable_hpd() is never called on init paths, documentation suggests that it is intended for suspend/resume paths. In result, once encoders are switched to bridge_connector, bridge-detected HPD stops working. This patch adds a call to that API on init path. This fixes HDMI HPD with rcar-du + adv7513 case when adv7513 reports HPD events via interrupts. Fixes: c24110a8 ("drm: rcar-du: Use drm_bridge_connector_init() helper") Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com> Signed-off-by: Paul Cercueil <paul@crapouillou.net> Tested-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211225063151.2110878-1-nikita.yoush@cogentembedded.com
-
Nishanth Menon authored
This takes a leaf from drivers/gpu/drm/rockchip/rockchip_rgb.c This is a bit of a chicken or hen issue at this point. when the call chain looks like this: tidss_atomic_check drm_atomic_check_only drm_atomic_commit drm_client_modeset_commit_atomic drm_client_modeset_commit_locked drm_client_modeset_commit drm_fb_helper_set_par fbcon_init visual_init The bridge_attach is invoked, but bridge_enable is NOT invoked yet, at this stage, we cannot really confirm the display format. So, it begs the question - what do others do? why do they work? Signed-off-by: Nishanth Menon <nm@ti.com>
-
Nishanth Menon authored
This takes a leaf from drivers/gpu/drm/rockchip/rockchip_rgb.c Most of the bridge drivers seem to invoke connector_init and attach_encoder in the modeset_init function. this seems to let the DRM framework call the necessary hooks to get the bridges to probe successfully. This might imply our DSS drivers are'nt compatible with quite a many bridges out there.. this needs to be dug in deeper. The current hack is introduced solely for AM625 - unfortunately, that also means that drivers like SK Sii9022 wont work. Signed-off-by: Nishanth Menon <nm@ti.com>
-
Aradhya Bhatia authored
Add a function to lookup the subrevision of the tidss component. this can be used to introduce a hack later in the series. Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Vaishnav Achath authored
Commit 165cd04f upstream and related patches to phy layer. This is not a clean backport, needs work to properly pick the necessary patches. Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
-
Darren Etheridge authored
On some boards the HDMI bridge takes a 24bit DPI input, but only 16 data pins are actually enabled from the SoC. This new property forces the output to be RGB565 on a specific video port if the bridge requests a 24bit RGB color space. This assumes that the video port is connected like so: SoC : Bridge R0 -> R3 R1 -> R4 R2 -> R5 R3 -> R6 R4 -> R7 G0 -> G2 G1 -> G3 G2 -> G4 G3 -> G5 G4 -> G6 G5 -> G7 B0 -> B3 B1 -> B4 B2 -> B5 B3 -> B6 B4 -> B7 On the bridge side R0->R2, G0->G1, B0->B2 would be tied to ground. The bridge sees 24bits of data, but the lsb's are always zero. Signed-off-by: Darren Etheridge <detheridge@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com>
-
Dave Stevenson authored
TC358762 wants the DSI host to be prepared before it is powered up, so set the flag to request that the upstream bridges have their pre_enable called first. Link: https://github.com/raspberrypi/linux/commit/f57b6e4732ddbedc785c8d1d52c4f1c7101dbfa1 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Rahul T R <r-ravikumar@ti.com>
-
Dave Stevenson authored
DSI sink devices typically want the DSI host powered up and configured before they are powered up. pre_enable is the place this would normally happen, but they are called in reverse order from panel/connector towards the encoder, which is the "wrong" order. Add a new flag pre_enable_upstream_first that any bridge can set to swap the order of pre_enable (and post_disable) for that and the immediately upstream bridge. Should the immediately upstream bridge also set the pre_enable_upstream_first flag, the bridge upstream of that will be called before either of those which requested pre_enable_upstream_first. eg: - Panel - Bridge 1 - Bridge 2 pre_enable_upstream_first - Bridge 3 - Bridge 4 pre_enable_upstream_first - Bridge 5 pre_enable_upstream_first - Bridge 6 - Encoder Would result in pre_enable's being called as Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5, Bridge 4, Encoder. Link: https://lore.kernel.org/all/ec19836b0fbbc1bb53a6ba6ce93eec2184676aae.1646406653.git.dave.stevenson@raspberrypi.com/ Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Rahul T R <r-ravikumar@ti.com>
-
Dave Stevenson authored
Mapping to the drm_bridge flag pre_enable_upstream_first, add a new flag prepare_upstream_first to drm_panel to allow the panel driver to request that the upstream bridge should be pre_enabled before the panel prepare. Link: https://lore.kernel.org/all/a593a187fe3e6fc1ca5bf3db001ed87457e3d4ee.1646406653.git.dave.stevenson@raspberrypi.com/ Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Rahul T R <r-ravikumar@ti.com>
-
Rahul T R authored
Update VESA standard timings for RPi panel Signed-off-by: Rahul T R <r-ravikumar@ti.com>
-
Dave Stevenson authored
The Raspberry Pi 7" 800x480 panel uses a Toshiba TC358762 DSI to DPI bridge chip, so there is a requirement for the timings to be specified for the end panel. Add such a definition. upstream link: https://lore.kernel.org/lkml/20220131191517.30249-1-detlev.casanova@collabora.com/T/ Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Rahul T R <r-ravikumar@ti.com>
-
Dave Stevenson authored
If no interrupt is defined then a timer and workqueue are used to poll the controller. On remove these were not being cleaned up correctly. Fixes: ca61fdaba79f "Input: edt-ft5x06: Poll the device if no interrupt is configured." Link: https://github.com/raspberrypi/linux/commit/ba209048b9ee073bc25a71297759cbafd00c68eb Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Rahul T R <r-ravikumar@ti.com>
-
Dave Stevenson authored
Not all systems have the interrupt line wired up, so switch to polling the touchscreen off a timer if no interrupt line is configured. Link: https://github.com/raspberrypi/linux/commit/ca61fdaba79fa29fc950b3b731c99557d6781ff5 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Rahul T R <r-ravikumar@ti.com>
-
Dave Stevenson authored
commit 1d746d44 upstream. The driver was implementing a get_brightness function that tried to read back the PWM setting of the display to report as the current brightness. The controller on the display does not support that, therefore we end up reporting a brightness of 0, and that confuses systemd's backlight service. Remove the hook so that the framework returns the current brightness automatically. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Link: https://lore.kernel.org/r/20220124220129.158891-8-detlev.casanova@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Rahul T R <r-ravikumar@ti.com>
-
Dave Stevenson authored
commit 8c518eb4 upstream. We need independent control of the resets for the panel&bridge, vs the touch controller. Expose the reset lines that are on the Atmel's port C via the GPIO API so that they can be controlled appropriately. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Link: https://lore.kernel.org/r/20220124220129.158891-7-detlev.casanova@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Rahul T R <r-ravikumar@ti.com>
-
Dave Stevenson authored
commit 4866e35e upstream. The Atmel was doing a load of automatic sequencing of control lines, however it was combining the touch controller's reset with the bridge/panel control. Change to control the control signals directly rather than through the automatic POWERON control. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Link: https://lore.kernel.org/r/20220124220129.158891-6-detlev.casanova@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Rahul T R <r-ravikumar@ti.com>
-
Dave Stevenson authored
commit 89339a2a upstream. The initial state of the Atmel is not defined, so ensure the backlight PWM is set to 0 by default. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Link: https://lore.kernel.org/r/20220124220129.158891-5-detlev.casanova@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Rahul T R <r-ravikumar@ti.com>
-
Dave Stevenson authored
commit 00440bcd upstream. The driver was using the regmap lock to serialise the individual accesses, but we really need to protect the timings of enabling the regulators, including any communication with the Atmel. Use a mutex within the driver to control overall accesses to the Atmel, instead of the regmap lock. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Link: https://lore.kernel.org/r/20220124220129.158891-4-detlev.casanova@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Rahul T R <r-ravikumar@ti.com>
-
Dave Stevenson authored
commit 7291e7d6 upstream. There's no reason why 2 Raspberry Pi DSI displays can't be attached to a Pi Compute Module, so the backlight names need to be unique. Use the parent dev_name. It's not as readable, but is unique. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Link: https://lore.kernel.org/r/20220124220129.158891-2-detlev.casanova@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Rahul T R <r-ravikumar@ti.com>
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Matthijs van Duin authored
"uio" for generic use "ti,pruss-shmem" for backwards compatibility the of_id module parameter is still supported to add another id
-
Matthijs van Duin authored
-
Jason Kridner authored
-
Ming zq authored
-
Robert Nelson authored
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
-
Kishon Vijay Abraham I authored
Lets drive Sierra clock output and workaround a TIFS/DM bug for now. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
-
Jason Kridner authored
Signed-off-by: Jason Kridner <jkridner@beagleboard.org>
-
Vaishnav Achath authored
split the rename changes across two separate patches to work around the buildroot apply-patch issue. Signed-off-by: Vaishnav M A <vaishnav@beagleboard.org>
-
Vaishnav Achath authored
Tested on PocketBeagle + ATUSB + CC1352R SensorTag: debian@beaglebone:~$ uname -a Linux beaglebone 5.8.18-bone23 #1xross PREEMPT Tue Dec 15 15:41:20 IST 2020 armv7l GNU/Linux All drivers probed correctly as per manifest, but a kernel panic occurs after sometime: debian@beaglebone:~$ dmesg [ 218.793223] greybus 1-svc: no primary interface detected on module 2 [ 218.876678] greybus 1-2.2: Interface added (greybus) [ 218.876707] greybus 1-2.2: GMP VID=0x00000126, PID=0x00000126 [ 218.876739] greybus 1-2.2: DDBL1 Manufacturer=0x00000126, Product=0x00000126 [ 219.296368] greybus 1-2.2: excess descriptors in interface manifest [ 220.922786] mikrobus:mikrobus_port_gb_register: mikrobus gb_probe , num cports= 3 [ 220.922793] mikrobus:mikrobus_port_gb_register: protocol added 11 [ 220.922824] mikrobus:mikrobus_port_gb_register: protocol added 3 [ 220.922829] mikrobus:mikrobus_port_gb_register: protocol added 2 [ 220.922896] mikrobus:mikrobus_port_register: registering port mikrobus-1 [ 220.931490] mikrobus_manifest:mikrobus_manifest_attach_device: parsed device 1, driver=bme280, protocol=3, reg=76 [ 220.931526] mikrobus_manifest:mikrobus_manifest_attach_device: parsed device 2, driver=opt3001, protocol=3, reg=44 [ 220.931557] mikrobus_manifest:mikrobus_manifest_parse: Greybus Service Sample Application manifest parsed with 2 devices [ 220.931602] mikrobus mikrobus-1: registering device : bme280 [ 220.937043] mikrobus mikrobus-1: registering device : opt3001 [ 221.628678] bmp280 3-0076: supply vddd not found, using dummy regulator [ 221.628976] bmp280 3-0076: supply vdda not found, using dummy regulator [ 221.630669] opt3001 3-0044: Found TI OPT3001 debian@beaglebone:~$ ls /sys/bus/iio/devices/iio\:device iio:device0/ iio:device1/ iio:device2/ debian@beaglebone:~$ ls /sys/bus/iio/devices/iio\:device1 current_timestamp_clock dev events in_illuminance_input in_illuminance_integration_time integration_time_available name power subsystem uevent debian@beaglebone:~$ ls /sys/bus/iio/devices/iio\:device2 dev in_humidityrelative_input in_humidityrelative_oversampling_ratio in_pressure_input in_pressure_oversampling_ratio in_temp_input in_temp_oversampling_ratio name power subsystem uevent . . . [ 235.947231] 8<--- cut here --- [ 235.951059] Unable to handle kernel NULL pointer dereference at virtual address 00000004 [ 235.964814] pgd = 1f321289 [ 235.970754] [00000004] *pgd=00000000 [ 235.977393] Internal error: Oops: 5 [#1] PREEMPT THUMB2 [ 235.983348] Modules linked in: bmp280_i2c bmp280 opt3001 gb_netlink gb_loopback(C) gb_gpio(C) gb_i2c(C) gb_spi(C) gb_gbphy(C) gb_spilib(C) greybus nhc_udp nhc_routing nhc_ipv6 nhc_mobility nhc_hop nhc_fragment nhc_dest ieee802154_6lowpan 6lowpan evdev usb_f_acm u_serial usb_f_ncm usb_f_mass_storage usb_f_rndis u_ether libcomposite iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables x_tables atusb mac802154 ieee802154 spidev [last unloaded: gb_netlink] [ 236.028629] CPU: 0 PID: 5 Comm: kworker/0:0 Tainted: G C O 5.8.18-bone23 #1xross [ 236.037887] Hardware name: Generic AM33XX (Flattened Device Tree) [ 236.044761] Workqueue: events do_work [greybus] [ 236.050022] PC is at skb_release_data+0x52/0xe4 [ 236.055268] LR is at kfree_skb+0x23/0xa8 [ 236.059903] pc : [<c0857e6a>] lr : [<c0857583>] psr: 400f0033 [ 236.066892] sp : dc139e60 ip : a00f0013 fp : c0f1369c [ 236.072833] r10: da5b5200 r9 : da5b5214 r8 : 00000001 [ 236.078775] r7 : da5b5300 r6 : db633c00 r5 : da5b5300 r4 : 00000000 [ 236.086026] r3 : 00000008 r2 : 00000000 r1 : 00000000 r0 : 00000000 [ 236.093279] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment none [ 236.101316] Control: 50c5387d Table: 9b5a4019 DAC: 00000051 [ 236.107785] Process kworker/0:0 (pid: 5, stack limit = 0x39163ebd) [ 236.114689] Stack: (0xdc139e60 to 0xdc13a000) [ 236.119766] 9e60: da5b5200 db633c00 ffffff91 bf9391cd db51c000 c0857583 db633c00 ffffff91 [ 236.128678] 9e80: dae21168 bf9391cd 00000000 00000001 00000000 c0f05288 d64e7ea0 00000000 [ 236.137590] 9ea0: 000007d0 00000cc0 da6b0e00 00000000 00000000 bf90f84d 00000cc0 d64e7ea0 [ 236.146502] 9ec0: 00000000 00000000 00000013 bf90f8b9 d64e7ea0 bf90f94d 00000000 00000cc0 [ 236.155415] 9ee0: d6543d40 db51c400 00000000 dfa07300 00000000 00000000 d6543d44 bf90e973 [ 236.164328] 9f00: 00000000 00000000 000007d0 c0153c45 c0f05288 bf90eb39 00000000 c0f05288 [ 236.173240] 9f20: dfa07305 d6543d40 dc0e5b00 00000000 dfa07300 c01377c7 dc139f50 c0137a53 [ 236.182153] 9f40: dc0e5b00 c0f1365c dc0e5b14 c0f1d060 c0f13670 dc138000 c0f1365c c0137af9 [ 236.191065] 9f60: 00000000 dc0fd080 dc0fd380 dc138000 00000000 c0137a2d dc0e5b00 dc117eb8 [ 236.199979] 9f80: dc0fd0a0 c013ba45 00000000 dc0fd380 c013b955 00000000 00000000 00000000 [ 236.208891] 9fa0: 00000000 00000000 00000000 c0100159 00000000 00000000 00000000 00000000 [ 236.217804] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 236.226716] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 236.235638] [<c0857e6a>] (skb_release_data) from [<c0857583>] (kfree_skb+0x23/0xa8) [ 236.244032] [<c0857583>] (kfree_skb) from [<bf9391cd>] (message_send+0x91/0x12c [gb_netlink]) [ 236.253333] [<bf9391cd>] (message_send [gb_netlink]) from [<bf90f84d>] (gb_operation_request_send+0xad/0xfc [greybus]) [ 236.264799] [<bf90f84d>] (gb_operation_request_send [greybus]) from [<bf90f8b9>] (gb_operation_request_send_sync_timeout+0x1d/0x4c [greybus]) [ 236.278268] [<bf90f8b9>] (gb_operation_request_send_sync_timeout [greybus]) from [<bf90f94d>] (gb_operation_sync_timeout+0x65/0xb0 [greybus]) [ 236.291736] [<bf90f94d>] (gb_operation_sync_timeout [greybus]) from [<bf90e973>] (gb_svc_ping+0x23/0x28 [greybus]) [ 236.302849] [<bf90e973>] (gb_svc_ping [greybus]) from [<bf90eb39>] (do_work+0x19/0xe8 [greybus]) [ 236.312387] [<bf90eb39>] (do_work [greybus]) from [<c01377c7>] (process_one_work+0x127/0x38c) [ 236.321651] [<c01377c7>] (process_one_work) from [<c0137af9>] (worker_thread+0xcd/0x3d0) [ 236.330482] [<c0137af9>] (worker_thread) from [<c013ba45>] (kthread+0xf1/0x124) [ 236.338526] [<c013ba45>] (kthread) from [<c0100159>] (ret_from_fork+0x11/0x38) [ 236.346474] Exception stack(0xdc139fb0 to 0xdc139ff8) [ 236.352244] 9fa0: 00000000 00000000 00000000 00000000 [ 236.361156] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 236.370067] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 236.377413] Code: 78bb 42a3 dd1b 6aa8 (6843) 07da [ 236.394147] ---[ end trace dc655e652b764722 ]--- Signed-off-by: Vaishnav M A <vaishnav@beagleboard.org>
-