- Dec 18, 2023
-
-
Robert Nelson authored
6.1.46-ti-rt-r15 bb.org_defconfig TI SDK: 09.01.00.005 6.1 TI Delta: https://github.com/RobertCNelson/ti-linux-kernel/compare/85cb03befa7e7bf2b0e8a4279c52bf26f8138d28...3db9a45004a01caba21d64b397814abadcc841b0 BBDTBS: https://git.beagleboard.org/beagleboard/BeagleBoard-DeviceTrees/-/commit/868efe3cc170b171cca40ea28389104f468fc1b6 RT: patch-6.1.46-rt14.patch.xz WIRELESS_REGDB: https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/commit/?id=37dcea0e6e5effb4228fe385e906edba3cbee389 KSMBD: https://github.com/cifsd-team/ksmbd/commit/7dec4e9aa879132a92d730aedaebfff130e2963f TI_AMX3_CM3: http://git.ti.com/gitweb/?p=processor-firmware/ti-amx3-cm3-pm-firmware.git;a=commit;h=fb484c5e54f2e31cf0a338d2927a06a2870bcc2c WPANUSB: https://git.beagleboard.org/beagleconnect/linux/wpanusb/-/commit/6aa9bf65b9d88a2c9a111e7b4aed03de2be9413d Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
-
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Jason Kridner authored -
Robert Nelson authored
Signed-off-by: -
Jason Kridner authored
Original Commit : https://github.com/beagleboard/linux/commit/8884f22a6b3a5217177c2f843e5c83d613bc6676 Signed-off-by:
Jason Kridner <jkridner@beagleboard.org>
-
Robert Nelson authored
This reverts commit 2b038e78 . Signed-off-by:
-
Robert Nelson authored
#<Daulity> is there a kernel option to not reset gpio state at linux boot ? #<zmatt> Daulity: the kernel does not reset any gpio unless explicitly requested to by a driver #<zmatt> though by default if cape-universal is enabled then a gpio-of-helper device gets set up which configures all gpios as input... though that is normally the state they are in anyway after reset #<zmatt> Daulity: why? are you setting gpios in u-boot? #<Daulity> yes u-boot sets a few gpio's before it boots the kernel they get reset to a certain state not certain if u-boot or linux kernel #<Daulity> was just wondering #<zmatt> the annoying bit is that this isn't really fixable by applying an overlay on top of cape-universal due the the limitations of overlays and the fact that status="disabled"; doesn't work on individual gpios of a gpio-of-helper device node #<zmatt> so your options are to modify the cape-universal overlay or disable cape-universal entirely and use an overlay to declare/export gpios (with initialization of your choice) #<Daulity> i see #<zmatt> (or fix the gpio-of-helper drivers to respect the status property of individual gpios... which is probably a 2-line patch) #<zmatt> *driver #<zmatt> interesting, if CONFIG_OF_KOBJ=n then nodes with non-okay status property don't even get deserialized, however in practice CONFIG_OF_KOBJ is always y (specifically, it is only n in kernels that lack sysfs support) #<zmatt> yeah it's definitely a 2-line fix #<zmatt> https://pastebin.com/f8V8pz1V #<Daulity> thanks :) #<zmatt> rcn-ee: can you include that patch? that way overlays can disable cape-universal's gpio export for individual gpios used by the overlay #<zmatt> e.g. &ocp { cape-universal { P9_14 { status = "disabled"; }; }; }; #<zmatt> Daulity: you can use that in an overlay and then if you still want the gpio exported you can just declare your own gpio-of-helper ... unfortunately it doesn't support exporting a gpio without initializing it, but at least you can choose *how* to initialize it (input, output-low, output-high) and whether or not linux userspace is allowed to change the direction of the gpio Signed-off-by:
-
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
hack: gpiolib: yes we have drivers stomping on each other, we need to find a better way to share gpio... Signed-off-by: -
Robert Nelson authored
Authors: Pantelis Antoniou <panto@antoniou-consulting.com> Charles Steinkuehler <charles@steinkuehler.net> Jason Kridner <jdk@ti.com> Robert Nelson <robertcnelson@gmail.com> Tobias Müller <Tobias_Mueller@twam.info> Matthijs van Duin <matthijsvanduin@gmail.com> This patch was derived from 19 commits: https://github.com/RobertCNelson/linux-dev/tree/35e301ae8436e9f56f65bf1a7440021eda42f948/patches/drivers/ti/gpio Signed-off-by:
-
Robert Nelson authored
Authors: Pantelis Antoniou <panto@antoniou-consulting.com> Charles Steinkuehler <charles@steinkuehler.net> Jason Kridner <jdk@ti.com> Robert Nelson <robertcnelson@gmail.com> Tobias Müller <Tobias_Mueller@twam.info> Matthijs van Duin <matthijsvanduin@gmail.com> This patch was derived from 19 commits: https://github.com/RobertCNelson/linux-dev/tree/35e301ae8436e9f56f65bf1a7440021eda42f948/patches/drivers/ti/gpio Signed-off-by:
-
frost authored
-
bigguiness@gmail.com authored
------=_Part_422_1349561576.1515022447432 Content-Type: text/plain; charset="UTF-8" Hello all, The TI touch screen driver does not work _right_ with the libts-bin package in the jessie image. $ cat /etc/dogtag BeagleBoard.org Debian Image 2018-01-01 $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 8.10 (jessie) Release: 8.10 Codename: jessie $ dpkg -l | grep libts-bin ii libts-bin 1.14-1rcnee0~jessie+20171122 armhf touch screen library utilities $ sudo ts_calibrate ts_setup: No such file or directory It is possible to make it work by setting the TSLIB_TSDEVICE environment variable: $ sudo su # export TSLIB_TSDEVICE=/dev/input/event2 # ts_calibrate But, that's a bit of a pain since the environment variable always needs to be set in order to use the touchscreen. It appears that this version of the utilities uses the INPUT_PROP_DIRECT propbit to automatically detect which /dev/input/event device is the touchscreen. It looks like the following is the only change needed to make it work. Unfortunately, I don't have currently have a way to build a custom kernel for the BeagleBone in order to test it. If there is anyone that could I would appreciate it. Regards, Hartley -
Robert Nelson authored
This reverts commit 3c9dc275 . Signed-off-by:
-
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Reference: rpi-6.1.y Signed-off-by: -
Robert Nelson authored
Reference: v6.1.68 Signed-off-by: -
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
-
Robert Nelson authored
Reference: v5.10.204 Signed-off-by: -
-
-
-
Robert Nelson authored
patch-6.1.46-rt14.patch.xz Signed-off-by: -
-
Jason Kridner authored
From https://github.com/statropy/wpanusb
-
-
- Nov 16, 2023
-
-
Bryan Brattlof authored
All PREEMPT_RT kernel configurations for a given device and workload will take some level of tuning beyond selecting CONFIG_PREEMPT_RT. Most of these configurations will act more like tuning knobs, each with their advantages and disadvantages, rather than concrete selections to make the system perform 'better' These config changes are meant to be a generic PREEMPT_RT configuration that works for most of TI's SoCs for fairly typical real-time workloads and could required more tuning as necessary for a specific application. Because of this I've commented the reasoning behind each setting decision to help others tune their system further Signed-off-by:Bryan Brattlof <bb@ti.com>
-
Sinthu Raja authored
Add support to enable HDMI audio to work with OMAPDSS HDMI for AM57x SoC family Signed-off-by:Sinthu Raja <sinthu.raja@ti.com>
-
Sinthu Raja authored
The sysfs entries for power management on AM57x platforms are disabled by default. Add configs to enable the power and suspend options at sysfs level Signed-off-by: -
Sinthu Raja authored
Add support to enable OSD LCD display panel and touchscreen driver for AM57x SoC family Signed-off-by: -
Siddharth Vadapalli authored
The CPSW Proxy Client driver communicates with the Ethernet Switch Firmware (EthFw) running on a remote MAIN R5 core via RPMsg. EthFw configures the CPSWnG instance of the CPSW Ethernet Switch on TI's SoCs and provides services to the clients running on different cores of which the CPSW Proxy Client is the client on the core running Linux. Enable the CPSW Proxy Client driver as a module for availing the services provided by EthFw. Signed-off-by:
Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by:
Jai Luthra <j-luthra@ti.com> Tested-by:
MD Danish Anwar <danishanwar@ti.com>
-
Siddharth Vadapalli authored
The CPSW Proxy Client driver in Linux communicates with the Ethernet Switch Firmware (EthFw) running on a remote MAIN R5 core via RPMsg. EthFw announces its endpoint over the RPMsg-Bus, triggering the probe of the CPSW Proxy Client driver. Following this, the communication between CPSW Proxy Client driver and EthFw can proceed over RPMsg and the Client driver can request various services provided by EthFw which facilitate the transmission and reception of Network Data by the Client. EthFw is in complete control of the CPSWnG peripheral and any configuration pertaining to the CPSWnG peripheral can only be performed by EthFw at the request of the Client. This model allows the shared use of the CPSWnG peripheral between the clients running on different cores. The data is transmitted/received over the DMA Channels which EthFw allocates to the Client. The Client configures the DMA Channels allocated to it using the DMA APIs provided by the DMA driver. Signed-off-by:
-
Siddharth Vadapalli authored
The Ethernet Switch Firmware (EthFw) running on the remote MAIN R5 core is capable of configuring the CPSWnG instance of TI's CPSW Ethernet Switch on various TI SoCs such as J721E, J7200 and J784S4. EthFw is in complete control of CPSWnG and acts as a server which allocates and provides the resources to clients on different cores. All communication between EthFw and the clients occurs via RPMsg. Define the message structures used to communicate with EthFw. This shall enable the Linux Client to avail the services provided by EthFw. Signed-off-by:
-
Siddharth Vadapalli authored
The existing function k3_udma_glue_request_remote_rx_chn() supports requesting an RX DMA channel and flow by the name of the RX DMA channel. Add support to request RX channel by ID in the form of a new function k3_udma_glue_request_remote_rx_chn_by_id() and export it. Since the implementation of k3_udma_glue_request_remote_rx_chn_by_id() reuses most of the code in k3_udma_glue_request_remote_rx_chn(), create a new function k3_udma_glue_request_remote_rx_chn_common() for the common code. Signed-off-by:
-
Siddharth Vadapalli authored
The existing function k3_udma_glue_request_tx_chn() supports requesting a TX DMA channel by its name. Add support to request TX channel by ID in the form of a new function k3_udma_glue_request_tx_chn_by_id() and export it. Since the implementation of k3_udma_glue_request_tx_chn_by_id() reuses most of the code in k3_udma_glue_request_tx_chn(), create a new function for the common code named as k3_udma_glue_request_tx_chn_common(). Signed-off-by:
-
