Hypfer has quit [Quit: Ping timeout (120 seconds)]
Hypfer has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
s1b1_ has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
dsimic has quit [Ping timeout: 260 seconds]
dsimic has joined #linux-rockchip
s1b1 has joined #linux-rockchip
godvino has quit [Ping timeout: 260 seconds]
Net147_ has joined #linux-rockchip
clarity has quit [Ping timeout: 244 seconds]
Net147 has quit [Ping timeout: 244 seconds]
clarity has joined #linux-rockchip
walter has joined #linux-rockchip
naoki has joined #linux-rockchip
smaeul_ has quit [Remote host closed the connection]
smaeul has joined #linux-rockchip
walter has quit [Remote host closed the connection]
hexdump01 has quit [Ping timeout: 256 seconds]
hexdump01 has joined #linux-rockchip
Daanct12 has joined #linux-rockchip
cbeznea_ has joined #linux-rockchip
System_Error has quit [Remote host closed the connection]
<wens>
blah, nvme failed again in the early morning :(
<wens>
do I really need to get one of those Raspberry Pi non-standard 5V 4~5A PSUs?
System_Error has joined #linux-rockchip
walter has joined #linux-rockchip
<naoki>
Radxa (and other) boards have pin headers that provide various functions other than GPIO. I believe that almost all .dts do not enable functions other than GPIO, but would it be possible to provide an overlay under the Linux dts that enables specific functions?
<naoki>
For example, rk3566-radxa-zero-3-uart4.dtso.
<naoki>
(I think there are too many to write about.)
<diederik>
chewitt: One of the things I noticed vs 'downstream' is clocks and assigned-clocks and assigned-clock-rates
<chewitt>
there were differences to the Armbian patch too
<chewitt>
s/there/those
<diederik>
yeah, I changed the unit address as I think that should be the lowest value, but the 2nd item actually has the lowest item. 'downstream' has that wrong too; detlev did not (but I haven't compared that to downstream)
<diederik>
and I made the reg-names more similar to what's there for rk3588, which is different from what minimyth has.
<diederik>
So I felt I needed to verify ... and *understand* ... what each item is and be able the explain why things are different (with f.e. references to the TRM)
jelly-home is now known as jelly
<diederik>
So the 'feeling' I have now is that it's too much of something which seems to work, but may not be very good. It could explain why my test on rk3588 were impressive, while those on rk356x were decent-ish
<diederik>
can ofc also come that the HW in rk3588 is just better
<diederik>
what is present in the armbian dts is 'cache' which was removed from the minimyth which I took as a starting point ... but I _think_ the SRAM thingie is the cache ... so I'm inclined to think that armbian one is better in that regard
<diederik>
at a quick glance, what armbian has seems to match much closer to what downstream has
<diederik>
interestingly, the armbian dts has the unit addresses sorted (alpha)numerically, while detlev's patch does not (the 2nd item is 'lower') and I aligned with that. That (would) explain why the sequence of armbian's reg-names is different from 'mine'. But reg-addr -> reg-name mapping is consistent
<diederik>
Another thing that bothers me is that I set the unit address to fdf80100 which I think is better then fdf80200, but the TRM says fdf80000. So where is the other '100'? I think I should be able to explain that before submitting a RFC patch. And 'hopefully' be able to track down where the reg values come from ...
urja has quit [Ping timeout: 256 seconds]
urja has joined #linux-rockchip
<walter>
Is there a visual tool to diff device tree sources in tree form? I'm in the process of going to mainline and I have some very old DTS files for an RK3399 board.
<diederik>
kdiff3?
raster has joined #linux-rockchip
<chewitt>
I often find something like "diff -y old.dts new.dts | more" is useful
<walter>
The files are structured differently with different inlcudes. Maybe I could join them somehow and diff the joined version.
<dsimic>
wens: let's see how will it work out, but you'll probably need a Raspberry-Pi-5-like PSU capable of delivering 5 A at 5 V... BTW, the USB specs actually allow such PSUs to exist, but at the very edge of the specs
sultan has quit [Quit: Connection closed for inactivity]
<diederik>
yeah, that's the one I have and I haven't had a single issue with it :)
<qschulz>
naoki: what i personally like to do with our modules is setting the pinctrl-0 for controllers that I know can only be accessed through one set of pins. Then the user technically only needs to enable the controller (and possibly PHYs) to hopefully get most of it working
<chewitt>
warpme: I have the planes ordered ESmart/Cluster/Smart .. but I think it only matters that ESmart is first so it gets selected as the OSD plane
<chewitt>
the vdec2 node patch looks the same (or very close) as the one in my tree
<diederik>
that's because I took that as my starting point?
<warpme>
chewitt : it was sometime ago when i was playing with this (so maybe we can have less intrusive code changes?) but i recall patch i pointed gives me: full oob working mythv & kodi in: egl dma buf & drm planes modes
<chewitt>
yup, I believe that I have everything working now
<warpme>
qschulz: ??
<qschulz>
warpme: sorry, didn't check the nick the autocomplete took
<qschulz>
walter: decompile the final dtb and compare with diff/meld?
raster- has quit [Remote host closed the connection]
ungeskriptet has quit [Remote host closed the connection]
raster has quit [*.net *.split]
ungeskriptet has joined #linux-rockchip
<dsimic>
walter: regarding the level shifter, I still think it only eliminates some leakage current
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<walter>
qschulz: good point, I'll probably do that, cause there are many includes and it's a mess.
<walter>
dsimic: you might be right, the thing is, I didn't see any issue since adding the level shifter in the mix, so that good. but it's strange how before I didn't have to do anything and UART worked.
<diederik>
chewitt: I may do a RFC patch after all ;-D ... but it'll probably take me a while
<qschulz>
walter: I would recommend some search and replace to rename the phandle hex when decompiling to something that is human readable and easier to diff against
* Ermine
thinks of making phandle resolver
<qschulz>
Ermine: I think the issue is how to differentiate between an actual phandle in its hex value and simply a hex value
<qschulz>
I don't know if it is any different in DTB actually
<Ermine>
I'm dealing with converting fdts extracted from boards into something usable
<qschulz>
if not you would need to add a new property to store which index in which array is a phandle or not
<Ermine>
and I have to look at dtsi's and other devices to figure out meaning of each hex value
<qschulz>
Ermine: the decompiled DTS stores this information in the phandle property
<Ermine>
yes
<qschulz>
so if you **know** a value is a phandle hex, you can simply traverse the decompiled DTB to find the node that has that phandle
<Ermine>
that's what i'm doing right now: i've marked places requiring phandle with &todo, and look for a node with phandle I need
<qschulz>
and then replace it with &{/path/to/node} in the decompiled DTB to make it make sense
<qschulz>
if you compile the DTB with -@ you should have access to labels too, then you can simply use &label instead with some additional logic
<Ermine>
does kernel compile them this way?
<walter>
`-@`? good to know.
<qschulz>
it can
<qschulz>
walter: -@ is required for overlays to work
<CounterPillow>
Ermine: depends on the specific dts file
<CounterPillow>
some have it added in the flags in the makefile, some don't
<qschulz>
Ermine: look at arch/arm64/boot/dts/rockchip/Makefile, specifically the comment in Overlay application tests at the end of the file
<CounterPillow>
Ideally we'd enable it in all SBCs but the problem is that it increases DTB size and some u-boot/TF-A builds have trouble with large DTBs, so it's risky
<qschulz>
it's transparently added for the first entry in each *-dtbs := line
<qschulz>
Ermine: you can see in arch/arm64/boot/dts/ti/Makefile that they are applying the -@ flag to DTC unconditionally, c.f. DTC_FLAGS
<qschulz>
and in arch/arm64/boot/dts/nvidia/Makefile you can see it's applied only to select DTSes
<Ermine>
hm, i see
warpme has joined #linux-rockchip
<Ermine>
btw that rk3288 dts I was annoying you with is a "converted one" :]
System_Error has quit [Remote host closed the connection]
System_Error has joined #linux-rockchip
<dsimic>
walter: perhaps the leakage current has been there for a while and it somehow managed to damege the SoC a bit, to the point that it now requires no leakage current to work
<dsimic>
s/damege/damage/
<Ermine>
Also, if decompiled fdt contains __symbol__ node, does it mean that original dts was built with -@ ?
<naoki>
chewitt: As far as I know, there are currently no solid plans for mainlining the AIC8800.
<qschulz>
Ermine: as far as I know, yes
<naoki>
Well, I don't know all the plans.
dsimic has quit [Ping timeout: 260 seconds]
dsimic has joined #linux-rockchip
eballetbo has joined #linux-rockchip
Dex_2x has quit [Changing host]
Dex_2x has joined #linux-rockchip
<chewitt>
naoki that's a shame, means I can't add the driver to LE images
<chewitt>
we won't add out of tree drivers unless there's visibility on being able to drop the driver for a mainlined one
<naoki>
chewitt: I don't maintain it myself, so maybe someone else can do it.
<chewitt>
the source looks rather fugly
<chewitt>
in fact, so far I can't even find the source, there are so many nested folders in the repo
<chewitt>
ahh, git submodules
<chewitt>
so the source is packaged by morons with no experience of buildsystems
<chewitt>
I am raising my middle-finger to aic8800 support :)
<chewitt>
"The code quality in this driver is absolutely horrendous, even by vendor standards. It's no uwe5622, but it's damn close. I would very much prefer to not ship this in nixpkgs."