- Dec 16, 2023
-
-
Robert Nelson authored
6.1.46-ti-rt-r14 bb.org_defconfig TI SDK: 09.01.00.004 6.1 TI Delta: https://github.com/RobertCNelson/ti-linux-kernel/compare/7d494fe58c8e5d41a6bd886c9a628a7fff5763f9...85cb03befa7e7bf2b0e8a4279c52bf26f8138d28 BBDTBS: https://git.beagleboard.org/beagleboard/BeagleBoard-DeviceTrees/-/commit/a4c67953cbfdc5110b48dc9ffa1b8895109e157b 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 <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Jason Kridner authored
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
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 <robertcnelson@gmail.com>
-
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 <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
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 <robertcnelson@gmail.com>
-
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 <robertcnelson@gmail.com>
-
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 <robertcnelson@gmail.com>
-
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 <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
Reference: rpi-6.1.y Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Reference: v6.1.68 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
-
Robert Nelson authored
Reference: v5.10.204 Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
patch-6.1.46-rt14.patch.xz Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Jason Kridner authored
From https://github.com/statropy/wpanusb
-
- Nov 09, 2023
-
-
Bryan Brattlof authored
Add in the input and output delay values for the available speed modes for the MMC controller for eMMC for the am62p5 allowing it to operate that the highest speed modes available. I've labeled this as a HACK because the HS200 and HS400 values have not been finalized as of yet and we will need to revisit this before these numbers are sent upstream. Signed-off-by:
Bryan Brattlof <bb@ti.com>
-
Hari Nagalla authored
As such each mailbox cluster in AM62A have 16 fifos. For Linux rpmsg IPC only 2 fifos are used. The rest of the fifos could be used for RTOS-RTOS communications. On a suspend, mailbox driver checks for any pending outstanding messages in the fifos and if any present returns with an error. Currently C7x DSP is not under system suspend and it seems some mailbox messages between DM-R5 and C7 could be present in the fifos when Linux suspend is exercised. This is resulting in mailbox driver suspend failure. As a HACK for now restrict the mailbox fifos to 2, which are used for Linux IPC with remote core. Signed-off-by:
Hari Nagalla <hnagalla@ti.com>
-
Hari Nagalla authored
Enable MCU R5F as a wakeup source. Signed-off-by:
Hari Nagalla <hnagalla@ti.com>
-
Hari Nagalla authored
Introduce MCU wakeup handler support in the remote proc driver. When MCU wakeup is enabled on a SUSPEND request, the driver sends a SUSPEND mailbox message to the remote core and waits for the ACK from the remote core. The remote device is not stopped in this scenario. On the other hand for a graceful shutdown the remote core is stopped and a ti-sci request is to sent to the DM to turn off the LPSC. Signed-off-by:
Hari Nagalla <hnagalla@ti.com>
-
Judith Mendez authored
EQEP overlay for AM62 platforms was renamed to k3-am62x-sk-eqep.dts. Remove the original k3-am625-sk-eqep.dts overlay. Signed-off-by:
Judith Mendez <jm@ti.com>
-
Roger Quadros authored
Exposing the entire CTRL_MMR space to syscon is not a good idea. Add sub-nodes for USB0_PHY_CTRL and USB1_PHY_CTRL and use them in the USB0/USB1 nodes. Cc: Andrew F. Davis <afd@ti.com> Signed-off-by:
Roger Quadros <rogerq@kernel.org> Reviewed-by:
Andrew Davis <afd@ti.com>
-
Roger Quadros authored
vddcore-supply is required property so the driver knows the correct bit to program in the USB_PHY_CTRL register based on the vddcore voltage. Signed-off-by:
Roger Quadros <rogerq@kernel.org>
-
Roger Quadros authored
Add VDD_CORE as a fixed voltage regultor at 0.85V. Signed-off-by:
Roger Quadros <rogerq@kernel.org>
-
Roger Quadros authored
The USB driver needs to configure a bit in the USB PHY control register depending on the PHY core voltage used in the system. The PHY core supply is the same as the vdd_core supply on the SoC. Use 'vddcore-supply' property to get the regulator the provides the vdd_core supply to the SoC. Signed-off-by:
Roger Quadros <rogerq@kernel.org>
-