- Mar 18, 2021
-
-
Robert Nelson authored
4.14.108-ti-rt-r139 bb.org_defconfig AUFS: https://github.com/sfjro/aufs4-standalone/commit/df5c09adc49fd0d431c0f18d190130675c8bffb9 BBDTBS: https://github.com/beagleboard/BeagleBoard-DeviceTrees/commit/ecc6dae2df15f7e004a87dbc80d1b6e2b79c7d21 CAN-ISOTP: https://github.com/hartkopp/can-isotp/commit/748f8efe84ab7c27496d8c8165f28892ba0e8868 RT: patch-4.14.106-rt56.patch.xz TI_AMX3_CM3: http://git.ti.com/gitweb/?p=processor-firmware/ti-amx3-cm3-pm-firmware.git;a=commit;h=fb484c5e54f2e31cf0a338d2927a06a2870bcc2c Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
-
http://gfnd.rcn-ee.org:8080Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Reference: v5.2.21 Signed-off-by: -
Dirk Mueller authored
commit e33a814e upstream. gcc 10 will default to -fno-common, which causes this error at link time: (.text+0x0): multiple definition of `yylloc'; dtc-lexer.lex.o (symbol from plugin):(.text+0x0): first defined here This is because both dtc-lexer as well as dtc-parser define the same global symbol yyloc. Before with -fcommon those were merged into one defintion. The proper solution would be to to mark this as "extern", however that leads to: dtc-lexer.l:26:16: error: redundant redeclaration of 'yylloc' [-Werror=redundant-decls] 26 | extern YYLTYPE yylloc; | ^~~~~~ In file included from dtc-lexer.l:24: dtc-parser.tab.h:127:16: note: previous declaration of 'yylloc' was here 127 | extern YYLTYPE yylloc; | ^~~~~~ cc1: all warnings being treated as errors which means the declaration is completely redundant and can just be dropped. Signed-off-by:
Dirk Mueller <dmueller@suse.com> Signed-off-by:
David Gibson <david@gibson.dropbear.id.au> [robh: cherry-pick from upstream] Cc: stable@vger.kernel.org Signed-off-by:
Rob Herring <robh@kernel.org> [nc: Also apply to dtc-lexer.lex.c_shipped due to a lack of e039139b , where dtc-lexer.l started being used] Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Robert Nelson authored
already default on BBB/X15, just calcuated everybootup Signed-off-by: -
Tony Lindgren authored
We have errata i688 workaround produce warnings on SoCs other than omap4 and omap5: omap4_sram_init:Unable to allocate sram needed to handle errata I688 omap4_sram_init:Unable to get sram pool needed to handle errata I688 This is happening because there is no ti,omap4-mpu node, or no SRAM to configure for the other SoCs, so let's remove the warning based on the SoC revision checks. As nobody has complained it seems that the other SoC variants do not need this workaround. Signed-off-by:Tony Lindgren <tony@atomide.com>
-
Robert Nelson authored
Signed-off-by: -
Jeremy Stashluk authored
This crashes the kernel when an runtime overlay is applied.
-
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Matt Porter authored
Convert the driver over the the device model component framework, making use of the drm encoder/connector helpers. This allows adihdmi to be dynamically selected as an external encoder for drm drivers like tilcdc that support the DT graph binding which defines ports and remote-endpoints to attach external encoders. Also, this driver was modified by another developer to support audio and tweak some settings. Along the way it seems to have been reformatted to 4 space tabs which is hard to work with alongside the standard 8 space tabs in the kernel coding standard. As such, this is reformatted to standard 8 space tabs so it's a bit more readable. The component and audio support should be merged into the upstream driver so this adihdmi driver can be removed. Signed-off-by:Matt Porter <mporter@konsulko.com>
-
Jason Kridner authored
Hacked driver that has audio support. Use this temporarily until audio support can be added to the upstream adv7511 driver. Signed-off-by:
Jason Kridner <jdk@ti.com> [Remove slave hacks and use adv75xx compatible strings] Signed-off-by:
-
Jason Kridner authored
Signed-off-by: -
Robert Nelson authored
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:
-
Matthijs van Duin authored
Signed-off-by:Matthijs van Duin <matthijsvanduin@gmail.com>
-
Matthijs van Duin authored
Signed-off-by: -
Matthijs van Duin authored
Signed-off-by: -
Matthijs van Duin authored
-
Elias Bakken authored
-
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
Signed-off-by: -
Dimitar Dimitrov authored
The original patch has been mistakenly applied to DRAM addresses, whereas IRAM are the ones needing a fixup. This patch fixes the following error: [ 1672.917602] remoteproc remoteproc1: Booting fw image pru-core0.elf, size 7104 [ 1672.917632] remoteproc remoteproc1: bad phdr da 0x20000000 mem 0x8f4 [ 1672.929347] remoteproc remoteproc1: Failed to load program segments: -22 [ 1672.938733] remoteproc remoteproc1: Boot failed: -22 Signed-off-by:Dimitar Dimitrov <dimitar@dinux.eu>
-
Dimitar Dimitrov authored
PRU IRAM addresses need to be masked before being handled to remoteproc. This is due to PRU Binutils' lack of separate address spaces for IRAM and DRAM. Signed-off-by:Dimitar Dimitrov <dinuxbg@gmail.com>
-
Robert Nelson authored
Signed-off-by: -
Drew Fustini authored
Call pm_runtime_get_sync() at the beginning of any functions that will read or write to the memory mapped eQEP registers. This is to ensure that the eQEP peripheral is running and its clock is enabled. Before this patch, an attempt to read the position file via sysfs would results in a segmentation fault. The kernel log would be contain this error: [ 2591.653471] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa304180 [ 2591.915165] [<bf005310>] (eqep_get_position [tieqep]) from [<c08930d0>] (dev_attr_show+0x2c/0x58) More details: https://gist.github.com/pdp7/fe07082d23f2bfbc362c733a7b0aea72 BeagleBoard mailing list thread: https://groups.google.com/d/msg/beagleboard/_TdTH7oPEXE/MNvU-mY6DgAJ
-
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Jay at Control Module Industries authored
I have encountered the same issue(s) on A6A boards. I couldn't find a patch, so I wrote this patch to update the device tree in the davinci_mdio driver in the 3.15.1 tree, it seems to correct it. I would welcome any input on a different approach. https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/SRlnumt0LoMJ v4.1-rcX: added hack around CONFIG_OF_OVERLAY v4.2-rc3+: added if (of_machine_is_compatible("ti,am335x-bone")) so we do not break dual ethernet am335x devices Signed-off-by:
-
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Pantelis Antoniou authored
Insert overlay symbols to the base tree when applied. This makes it possible to apply an overlay that references a label that a previously inserted overlay had. Signed-off-by:Pantelis Antoniou <pantelis.antoniou@konsulko.com>
-
Pantelis Antoniou authored
Add a benchmarking hashed phandles unittest which report what kind of speed up we get switching to hashed phandle lookups. ### dt-test ### the hash method is 8.2 times faster than the original On the beaglebone we perform about 1877 phandle lookups until that point in the unittest. Each non-hashed lookup takes about 23us when the cash is hot, while the hash lookup takes about 3us. For those 1877 lookup we get a speedup in the boot sequence of 1877 * (23 - 3) = 37.5ms, which is not spectacular but there's no point in wasting cycles and energy. Signed-off-by: -
Pantelis Antoniou authored
When a device tree contains a lot of phandles, resolving one takes time because the original method uses a search against all nodes (not just the ones with phandles). Signed-off-by:
-
