ftg has quit [Read error: Connection reset by peer]
parthi has joined #linux-sunxi
parthiban has quit [Ping timeout: 480 seconds]
Hypfer has quit [Ping timeout: 480 seconds]
Hypfer has joined #linux-sunxi
vagrantc has joined #linux-sunxi
vagrantc has quit []
apritzel has quit [Ping timeout: 480 seconds]
hipboi has joined #linux-sunxi
hipboi has quit []
hipboi has joined #linux-sunxi
hipboi has quit [Quit: hipboi]
<MasterR3C0RD>
parthiban: Should've asked before, but by LVDS working, did you mean that LVDS *and* DE are up and running for you, or just that the LVDS core is working?
<MasterR3C0RD>
Because if TCON and DE are up and running, I'd like to take a look at bringing up the DE/SYNC RGB screen on my device
<parthiban>
Poor quality recording in my Pinephone ;-)
<MasterR3C0RD>
Also, I just pushed up my WIP patches for SPI and crypto, as well as an attempt at adding thermal trips to bring up the thermal sensors on my device, to `linux-a100/allwinner-a100-stage3`
<parthiban>
Great thanks.
<MasterR3C0RD>
parthiban: Awesome! I'm assuming from the frame rate that's completely software rendered at the moment
<parthiban>
Yes, fully software rendering in single core CPU.
<MasterR3C0RD>
I haven't tested out SPI much yet, but it seems like it's initializing the module at least. Crypto on the other hand appears to work as expected, without any self-test failures
<parthiban>
I tried that independent DE thing yesterday sometime, but not fully success. I see the whole screen is blue. Something is happening, but still am missing pieces it seems.
<parthiban>
Also I don't know if INDEPENDENT DE means, it can't do DE0 <-> LCD1 and DE1 <-> LCD0 crossing. Also this support is lagging in the upstream as there is no control to change DE2TCON_MUX yet.
<parthiban>
My plan is build mesa from imagination tree to see if I can run things from GPU today. Then will resume the DE1 experiments.
<MasterR3C0RD>
But are there actually two working DEs on the A100? The user manual seems to imply there's only one
<parthiban>
I have 2 other custom PCB with RGB and DSI in it. Also my helper board comes with DSI and 2 x LVDS on the same 2.5mm header. So I have plenty to figure out regarding the display. I will spend rest of this week in this topics and then we can sync about testing your RBG?
<MasterR3C0RD>
I suppose I've asked that question before, but it seems like there's only one LCD controller/TCON/DE if the user manual is to be believed
<parthiban>
Yes there are 2 DE's for sure. I can see the DE2 is functional partially now. Let me make it full. See if I can run dual screen, LVDS1 and DSI together.
<parthiban>
User manual mentioned those bits are reserved. Not sure why. But there is IP underneath hidden. O
<MasterR3C0RD>
parthiban: Sounds good! I probably won't be able to do any late night stuff in my time zone until the weekend; luckily I think our time zones are an hour closer until DST returns in March 2025, so hopefully we get this figured out and in-progress to upstream before then :-)
<parthiban>
All the display pins are exposed only in PD group. So only dual combination is LVDS1 and DSI
<MasterR3C0RD>
Or rather an hour further; it's midnight here, while I believe before you would be online at 1AM my time
<MasterR3C0RD>
before DST ended
<parthiban>
I remember we discussed about TF-A for A133 sometime before. Anything real which I can have a look?
<MasterR3C0RD>
apritzel mentioned that someone with free cycles would need to take a look, as there's a reviewer problem with TF-A at the moment and thus he can't submit any patches as he'd also need to be the one approving
<parthiban>
Ok got it.
<MasterR3C0RD>
And I won't have free cycles for a bit from the looks of it, as once I get a little more progress here I'll be jumping onto getting DRAM init upstreamed for the A100 and A523
<MasterR3C0RD>
Speaking of DRAM, did you get a chance to try the new U-Boot address mapping code?
<parthiban>
A523 is next in my basket. Once again display first (head first jumping) ;-)
<parthiban>
Oh I forget in the flow. Let me pull and try it today.
colinsane has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
The new code is a lot less messy for me to work with, so hopefully it just works
colinsane has joined #linux-sunxi
<parthiban>
Boots fine in 1GB version. Let me check 4GB
<MasterR3C0RD>
It means somehow there's an issue setting up the rank bit
JohnDoe_71Rus has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
parthiban: Just pushed up a version with extra debug prints; if you could undo the rank change and test it, that'd be great
<MasterR3C0RD>
This version won't boot into U-Boot; for whatever reason the debug prints cause the boot to not succeed even if everything checks out (times out after SPL finishes)
<MasterR3C0RD>
But in return I get a lot more info to work with as it'll dump the address mappings selected for your board
<MasterR3C0RD>
Weird... the address mapping is correct. The config suggests an HIF layout of rRRRRRRRRRRRRRRRRBBBCCCCCCCCCC, which seems correct to me
hipboi has joined #linux-sunxi
<MasterR3C0RD>
They must be working around something with the special col_bits = 10, row_bits = 16, rank_bitss = 1 case
sh1 has joined #linux-sunxi
<MasterR3C0RD>
I suppose I should figure out exactly what that's doing...
<MasterR3C0RD>
Hmm, so in this case boot0 changes the mapping so that CS[0] (rank bit) = HIF[bankgrps+banks+columns+14], and then shifts ROW[14] and ROW[15] by 1
<MasterR3C0RD>
In other words, in pathiban's case the HIF layout is RRrRRRRRRRRRRRRRRBBBCCCCCCCCCC ("R" = rows, "r" = rank)
<MasterR3C0RD>
parthiban: Pushed up new code that should handle the C=10,R=16,r=1 case similarly to boot0; when you have a free moment please give it a quick test
<MasterR3C0RD>
Still has the debugging that'll prevent it from completing, but I'll remove it once things look right
apritzel has joined #linux-sunxi
<MasterR3C0RD>
Rediscovering hardware quirks is loads of fun for the whole family :))
<MasterR3C0RD>
The dependency cycles seem suspicious; probably a good idea to figure out where that's coming from
Schimsalabim has quit [Read error: Connection reset by peer]
<machinehum>
Seems reasonable
Schimsalabim has joined #linux-sunxi
<MasterR3C0RD>
parthiban: U-Boot debugging removed and missing header added; should be the last DRAM update for a bit until I start on the "combo" driver, or a 1.5GB/3GB A133 device pops up :)
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
colinsane has quit []
aggi has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
warpme has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<parthiban>
machinehum: Share `dmesg | grep -i -e display -e mipi -e drm` this might give some idea. Otherwise the dependency cycles should be ok
<parthiban>
MasterR3C0RD: U-boot still fails to boot fully. Do I need to patch something?
colinsane has joined #linux-sunxi
colinsane has quit []
colinsane has joined #linux-sunxi
<theslowcoder>
Anyone know of any quirks when it comes to I2C/TWI on the T113?
<theslowcoder>
Getting "mv64xxx_i2c 2502000.i2c: can't get pinctrl, bus recovery not supported". Typical cause would be that something else is using the pins, but there's nothing..
<Jookia>
theslowcoder: i don't think i've seen that error on the T113. i'll check tomorrow
<theslowcoder>
Jookia: Appreciated. I'm muxing on PB2/PB3 and PB4/PB5 (i2c0,i2c1) and getting the same error on both
<Jookia>
theslowcoder: i wouldn't say that's an error as much as a warning. it shouldn't prevent you from using i2c
<theslowcoder>
Jookia: I'm not seeing any activity on the bus either when probing with an oscilloscope. Might need to re-check that though, as it was a little while since I checked
<Jookia>
Did you try running i2cdetect?
<theslowcoder>
Jookia: Just checked for activity when loading a driver that should poke the bus. Can do the i2cdetect thing as well when I re-check
anarsoul|2 has quit [Remote host closed the connection]
anarsoul has joined #linux-sunxi
<theslowcoder>
Jookia: Re-checked with o-scope. No activity on either bus. Constant high signal
<Jookia>
hmm, sounds like your i2c bus isn't working?
<theslowcoder>
Jookia: The bus is literally empty right now. Only thing on those pins are pull-up resistors
<theslowcoder>
Should still see it clock out the address to the non-existing device..
<Jookia>
yeah
colinsane has quit []
hipboi has quit [Quit: hipboi]
hipboi has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
colinsane has joined #linux-sunxi
colinsane has quit [Remote host closed the connection]
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
dsimic is now known as Guest9315
dsimic has joined #linux-sunxi
Guest9315 has quit [Ping timeout: 480 seconds]
<parthiban>
MasterR3C0RD: not sure if we can run something meaningful with GE8300 GPU. frank in powervr irc said it still needs lots of work in the runtime shaders.
<parthiban>
am pretty much new to mesa. tried compiling with https://pastebin.com/raw/SRKMxAKJ . not sure If I missed things. Ideas? Thanks.
<MasterR3C0RD>
parthiban: Not too surprised, I expected that it'd likely be a while until it gets supported since the GE8300 isn't one of the prioritized GPUs
<machinehum>
I think sun6i_dsi_attach is getting called before drm_dev_register
<parthiban>
MasterR3C0RD: I was expecting some basic functions. But :-(
<parthiban>
machinehum: how does your display pipeline look like in dts?
<MasterR3C0RD>
I was hopefully that there'd be a chance of some bits working, but if too much is missing ATM then that's that. At least we know that we can initialize the GPU
<parthiban>
Looks like DSI depends on another block which isn't loaded yet. Probably TCON, TCON_TOP?
<parthiban>
machinehum: what do you see in /sys/class/drm ?
<machinehum>
parthiban: I'll take a look
<parthiban>
dsi is waiting for tcon and which needs the drc.
<parthiban>
Cross check Kconfig for those are enabled and also check if those nodes are set with status okay.
<machinehum>
Thanks, yeah none of that stuff is on.
<machinehum>
For future reference, how would I have figured that out?
<machinehum>
This I gues "[ 0.031388] platform 1e60000.display-backend: Fixed dependency cycle(s) with /soc/drc@1e70000"
<parthiban>
No, that's only the dependency in terms of ordering AFAIK.
<parthiban>
Pipeline components needs to be enabled in Kconfig and dts. sunxi DRM probe only does the component addition. bind is called only after full pipeline is parsed.