ftg has quit [Read error: Connection reset by peer]
montjoie has joined #linux-sunxi
montjoie_ has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
hentai has quit [Ping timeout: 480 seconds]
<tokyovigilante>
heh ok, will consider myself told ;) I see your cpufreq patches have hit the mailing list, will rebase my kernel, pull those in and try it the Right Way(TM)
hentai has joined #linux-sunxi
hentai has quit [Ping timeout: 480 seconds]
vagrantc has quit [Quit: leaving]
asriel has quit [Quit: Don't drink the water. They put something in it to make you forget.]
<tokyovigilante>
jernej: where's the best place to pull your hdmi patches from? your github?
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<tokyovigilante>
[ 1.745386] cpu cpu0: _of_add_opp_table_v2: no supported OPPs
<tokyovigilante>
[ 1.759704] cpu cpu0: OPP table can't be empty
<tokyovigilante>
Just trying the cpufreq patches
<tokyovigilante>
Have this in my DTS - compatible = "anbernic,rg35xx-plus", "allwinner,sun50i-h700", "allwinner,sun50i-h616";
<tokyovigilante>
should I just have the H616
<tokyovigilante>
nope, just PEBKAC... [ 0.023308] cpuidle: using governor menu
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
mripard has joined #linux-sunxi
warpme has joined #linux-sunxi
<tokyovigilante>
hmm, still not loading the sun50i-cpufreq-nvmem module
<tokyovigilante>
whoops, seems the thermal sensor support isn't mainlined yet..
<tokyovigilante>
although good news jernej I haven't seen a single incorrect DRAM amount with your second patchset
DarkNeutrino has joined #linux-sunxi
chewitt has joined #linux-sunxi
DarkNeutrino has quit [Read error: Connection reset by peer]
DarkNeutrino has joined #linux-sunxi
warpme has quit []
DarkNeutrino has quit [Ping timeout: 480 seconds]
DarkNeutrino has joined #linux-sunxi
DarkNeutrino has quit [Ping timeout: 480 seconds]
DarkNeutrino has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
tokyovigilante: yeah, it's all a bit in flux at the moment. The THS patches should reach mainline this week, it will all become much easier after the merge window closes this Sunday
warpme has joined #linux-sunxi
<apritzel>
tokyovigilante: acmeplus: so with those cpufreq patches your devices will run at 1.416GHz at most, due to the speedbin index in your efuses.
<apritzel>
can you check whether the vendor firmware allows to run at 1.5GHz?
<apritzel>
the OPPs and efuses encoding we use are quite old, I wonder if that predates the H700, so its speedbin is just not listed there
<apritzel>
so if it can run stable at 1.5GHz (ignoring thermal throttling, which is expected in a passively cooled device), we could add 0x6c00 to the list for speedbin 3
warpme has quit []
<DarkNeutrino>
apritzel: thanks a lot man for sending out the patches.
<DarkNeutrino>
I have been stuck in rockchip hell for a little while xD
<apritzel>
is it really hotter in there than in the AW hell? ;-)
<DarkNeutrino>
Not hotter but it burns a lot more when you get stuck xD
<DarkNeutrino>
Tho i will try to be at least reachable here whenever im in work :)
<apritzel>
DarkNeutrino: oh, can you check at some point what speedbin your boards are? All the ones I tested only went up to 1.4GHz (bin 0 or 2)
<KREYREN_oftc>
> A64 Ethernet is shared with the LCD, so if you want to use the build in Ethernet you lose the LCD, quite annoying decision but Allwinner made A64 thinking for tablets where Ethernet is not mandatory
acmeplus has joined #linux-sunxi
<gamiee>
yes it is true
<gamiee>
but it is only for LCD interface, not MIPI-DSI
<KREYREN_oftc>
gamiee, for the MIPI-DSI are there any special things needed to get a display to work there? e.g. on teres it needs the ANX6345 for parallel LCD
<karlp>
there's probably somethign that prints it out somewhere...
<gamiee>
KREYREN_oftc : ABX3645 is DPI to eDP bridge... You need MIPI-DSI to eDP bridge, or find display which have MIPI-DSI input instead of eDP
<KREYREN_oftc>
gamiee, i see
<KREYREN_oftc>
gamiee, thanks for info
<gamiee>
np
<apritzel>
karlp: for the H616 it's the lowest 16 bits of the first SID word, this gets looked up in a switch/case
<apritzel>
and so far there is nothing that prints it, though you can deduce your speedbin by the choice of OPPs the kernel lists
<apritzel>
but we might want to add some printk to report that number, for reference
<apritzel>
acmeplus: thanks for those dumps, they look quite useful. I need to go over the pinctrl settings later, to see if there is anything to consider still
<apritzel>
acmeplus: for the cpufreq table: that was what I was looking for
<apritzel>
it looks different to any of the existing tables, the lower frequencies look better (require less voltage than the other bins), but it needs more juice at 1.5GHz
<apritzel>
I guess it's worth to add another entry
<acmeplus>
I'm going to apply your last opp patch set in a bit
<acmeplus>
Ok, I can see the frequencies as expected: 480000 720000 936000 1008000 1104000 1200000 1320000 1416000
<apritzel>
acmeplus: yes, that's expected: the value on the H700 (0x6c00) does not match any of the listed, so it takes the default branch, which results in speedbin 0
acmeplus has quit [Ping timeout: 480 seconds]
acmeplus has joined #linux-sunxi
<karlp>
apritzel: yeah, if people are being asked to provide it, either a printk, or added to sunxi-fel or .... something might be nice :)
<KREYREN_oftc>
apritzel, were you able to get design reference for that A527 btw? The manufacturer didn't bother to reply to me
<gamiee>
KREYREN_oftc one A527 design is available online
<KREYREN_oftc>
gamiee, where?
<gamiee>
+ PINE64 will sell A527 SBC hopefully soon
<gamiee>
oh, here we go again... I really don't get for what the gerbers would be useful, but whatever.
<gamiee>
and np
<KREYREN_oftc>
gamiee, bcs i want to make my own design :p those schematics seems sufficient though
<gamiee>
KREYREN_oftc : as you said, schematics are sufficient, so for what you need gerbers?
<KREYREN_oftc>
less work with gerbers available as i have to make them from the schematics
<gamiee>
you need to do that anyway
<KREYREN_oftc>
and they often have recommended ways to handle things e.g. how the inner layers should be used to cool down the chips passively etc..
<KREYREN_oftc>
without those i have to figure these out by trial and error
<gamiee>
for that you need hw design guide from Allwinner, for that gerbers are not that useful,.
<gamiee>
Unless you want 1:1 board
<KREYREN_oftc>
like ideally i don't want to bother with designing the chips for PCBs and would much rather have them as open-source SOM standard so that i can just wire 1~4 layers PCBS that the chip on a module board slots into
junari has quit [Ping timeout: 480 seconds]
<KREYREN_oftc>
bcs like try fitting a SBC into a phone, tablet or a drone form factor it might work but it won't be pretty.. the SOM kinda addresses the issue e.g. with how sipeed does licheepi 4a
<gamiee>
well, SoM will be helpful mostly only on tablet. SoMs are often too big for phone and (small) drones
<KREYREN_oftc>
i wanted to address the SOM issue for a phone by having a tiny board with a standard set of pins on the bottom that has the CPU, RAM, eMMC and is placed on e.g. MxM socket
<KREYREN_oftc>
so for phone you can just remove the board from the MxM board
<gamiee>
I don't know how big the phone would need to be.
<gamiee>
like, it's not impossible, but ...
<KREYREN_oftc>
gamiee, the size of the SoC,RAM and eMMC next to each other with pins at the bottom of it
<gamiee>
"thickness"/height of SoM is also something :)
<karlp>
sget doesn't even list osm as one of the filters for "member products" is it even being used?
<karlp>
ok, I can find some vendors when I skip sget themselves :)
junari has joined #linux-sunxi
<karlp>
even found some non-imx8 ones! cute
junari has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
<KREYREN_oftc>
karlp, no idea they seemed to be kinda nice and willing to adjust their terms for open-source
junari has joined #linux-sunxi
warpme has joined #linux-sunxi
smaeul has joined #linux-sunxi
DarkNeutrino has quit [Read error: Connection reset by peer]
DarkNeutrino has joined #linux-sunxi
warpme has quit []
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
DarkNeutrino has quit [Ping timeout: 480 seconds]
DarkNeutrino has joined #linux-sunxi
<jernej>
junari: that's true, but since we encourage blind copying of TPR values from BSP, it might be different with 0 in place. Besides, it doesn't generate any extra code due to constants optimizations.
<jernej>
tokyovigilante: yes, I have latest hdmi patches on gh. I'm glad that DRAM issues disappeared.
<acmeplus>
jernej: in your rkt507c branch?
junari has quit [Ping timeout: 480 seconds]
<jernej>
I haven't updated hdmi/de33 patches in a while
<jernej>
that branch has same patches as at least one other
<jernej>
acmeplus: do you mind testing dram patch?
<acmeplus>
Sure, send me the link because I'm not sure I have it now
<acmeplus>
jernej: just did a series of cycles, just power on, off, etc. I got 2048 MiB about 2/10. This is with tokyovigilante u-boot + DRAM patch
<jernej>
hm... this is still annoyingly high
<jernej>
thanks for testing!
chewitt has quit [Quit: Zzz..]
<acmeplus>
Sorry :) During normal cycles (power on, using the device for a while, etc.) the 2048 cases seem less frequent, but could be just perception
vagrantc has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]