ftg has quit [Read error: Connection reset by peer]
sh1 has quit [Quit: I'm just going offline and may be some time.]
sh1 has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
radxanaoki has joined #linux-sunxi
junari_ has quit [Remote host closed the connection]
junari_ has joined #linux-sunxi
junari_ has quit []
<apritzel>
macromorgan: is there any update on that "dual AXP20x regulator" issue? The patch causing the issue you reported is now reverted, but that means any A523/A527/T527 board won't boot now :-(
cnxsoft has joined #linux-sunxi
<macromorgan>
no, no updates. I'm sorry but I've been super slammed. Let me see if I can write a patch to it later. I might need to add some new helpers for the ADC subsystem unless you have any ideas...
<jernej>
warpme: that's not really acceptable workaround for mainline, since 17 is perfectly valid value
<jernej>
warpme: which line is 84? I'm sure I don't have same sources as you
<apritzel>
that's odd anyway, isn't it? If the device uses 16 rows (as reported below, for the successful boot), why does anything beyond 16 matter anyway? If the test is successful, it "break;"s out, right?
<apritzel>
jernej: and I think warpme refers to line 84 of the log: "detecting row address bits"
<jernej>
so mctl_write_pattern() breaks? which make sense, since it's first usage of DRAM memory with new configuration
<apritzel>
but doesn't it run with rows = 17 before?
<jernej>
where?
<apritzel>
line 39 sets the rows to 17
<apritzel>
then does one test, and then starts looping over rows
<jernej>
line 39 and 41 are just configuration of DRAM, neither actually use such configured DRAM
<jernej>
line 45 just reads data from known existing locations (beginning of DRAM), so no issue there
<jernej>
and line 48 is first one which depends on writing on possibly non-existing locations
<apritzel>
yes, but with 17 rows configured, right?
<jernej>
but I have an idea. Since there can't be more of 4 GB of DRAM, we can actually calculate max. supported row, since all other parameters are known
<jernej>
so we can start at that one
<jernej>
apritzel: this is with board with 4 GB RAM, full width and single rank. using 17 rows give you 8 GB of RAM, which, I think, isn't be handled with SoC address decoder.
<apritzel>
yes, 4GB is the maximum at the moment (for H616 and A523), but the A733 supports also 8GB, IIUC
<jernej>
apritzel: what I mean to say, configuration is reasonable, but SoC has only 4 GB window for memory. With such configuration, you fall out of it and it's entirely possible that access to undefined address freezes SoCs.
warpme has joined #linux-sunxi
<apritzel>
yes, for DRAM that's what typically happens: I think the interconnect locks up, and the whole SoC freezes
<jernej>
so that's why I think row shouldn't be staticly defined to 17 as it is now but we should calculate max. row which is supported based on other parameters, which are already know at that time.
<apritzel>
right, so never try to configure anything beyond 4GB?
<apritzel>
still I wonder why it didn't bail out at 16 already, which is the right number?
<jernej>
although BSP DRAM driver has statically configuration to 17 when testing is performed
<jernej>
apritzel: it fails at writing test pattern already, before any kind of testing is done
<jernej>
so before for loop
<jernej>
oh, I think what is the issue
<jernej>
apritzel: we leave columns at detected number, which is 11, but BSP forces to 8, which compress working space to lower number and allows to operate inside DRAM memory region, so no read or write happens outside of it
<jernej>
it would be nice to test for regressions on others too
<warpme>
yeah i know :-))))))
colinsane has joined #linux-sunxi
warpme has quit []
bauen1_ has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
colinsane has quit []
bauen1_ has quit [Ping timeout: 480 seconds]
colinsane has joined #linux-sunxi
<macromorgan>
apritzel: apparently past Chris already fixed this, I'll test the fix again and see if it still works, then ask again for upstream to consider it?
<macromorgan>
I like it when Past Chris does things for me, he's so helpful (when not making my life a living hell).
<apritzel>
macromorgan: sorry, slightly confused. I dimly remember this series, but also that it wasn't applied, since there were things to discuss and improve.
<apritzel>
Hence I pushed for the revert of my patch, which didn't get there in time for the v6.13 release, but slightly later
<apritzel>
macromorgan: so are you saying your series was dismissed because the revert removed the immediate need for it?
<macromorgan>
I'll check on the comment, the only criticism I see is asking if getting dev->parent works
<macromorgan>
yes, correct
<macromorgan>
as for the dev->parent thing, I think if the device wasn't probed yet I got a null pointer so it wouldn't work
<macromorgan>
I've slept about 90 times since then, so I'll have to re-remember
<apritzel>
that's s shame, because I just pushed for the revert to avoid the regression. But we still need my patch, for devices with more than one PMIC (which is all A523 based devices so far)
<macromorgan>
yeah, let me check again and if dev->parent doesn't work then I'll resubmit with that note
colinsane has quit [Read error: Connection reset by peer]
<apritzel>
I am somewhat hopeful to get the basic A523 support into v6.15, but that little revert seems to spoil that ...
<macromorgan>
sorry, if my wife says I'm good at one thing, it's being a party pooper
<macromorgan>
:-p
colinsane has joined #linux-sunxi
<apritzel>
if your solution makes it into v6.15, or at least into v6.15.x, you are my reveler ;-)
colinsane has quit []
<macromorgan>
trying to confirm if there are any other drivers that do it this way... looks like I'm looking for devices that call an ADC MFD cell with DEVID_AUTO...
theslowcoder has joined #linux-sunxi
bauen1_ has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
theslowc1der has quit [Ping timeout: 480 seconds]
<macromorgan>
so passing the parent dev (the main MFD) doesn't really work as near as I can tell... I responded to that pending message and we'll see if they have any other recommendations or are fine with the new symbol I requested.
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
theslowcoder has quit [Ping timeout: 480 seconds]
<apritzel>
macromorgan: thanks!
<macromorgan>
the only other solution I can think of is getting the parent and checking every child, then returning the first channel that matches the name