<DarkNeutrino>
jernej: so yea. It must have been the code cause i switched to the h616-hdmi branch and hdmi works. So either something then broke it. Or i screwed up in the driver rebase
apritzel has quit [Ping timeout: 480 seconds]
pabs has quit [Quit: Don't rest until all the world is paved in moss and greenery.]
pabs has joined #linux-sunxi
vagrantc has joined #linux-sunxi
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
cnxsoft has quit []
vagrantc has quit [Quit: leaving]
junari has joined #linux-sunxi
<jernej>
DarkNeutrino: I'm glad that you have working reference. Now it's only a matter of finding out the difference.
<apritzel>
it booted to the U-Boot prompt, but I didn't test further
<apritzel>
IIRC MMC was not working the last time
DarkNeutrino has quit [Read error: No route to host]
DarkNeutrino has joined #linux-sunxi
DarkNeutrino has quit [Read error: Connection reset by peer]
DarkNeutrino has joined #linux-sunxi
DarkNeutrino has quit [Ping timeout: 480 seconds]
cnxsoft1 has quit [Read error: Connection reset by peer]
DarkNeutrino has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
bauen1_ has quit [Ping timeout: 480 seconds]
mkazantsev has joined #linux-sunxi
DarkNeutrino_ has joined #linux-sunxi
DarkNeutrino is now known as Guest3004
DarkNeutrino_ is now known as DarkNeutrino
<DarkNeutrino>
ok so it looks like some changes were done to the mixer. I will try to adjust for the changes and also update the code a bit so we could potentially upstream it soon.
bauen1 has joined #linux-sunxi
junari_ has joined #linux-sunxi
junari__ has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
bauen1 has quit [Ping timeout: 480 seconds]
junari has joined #linux-sunxi
junari__ has joined #linux-sunxi
junari_ has quit [Read error: Connection reset by peer]
junari has quit [Ping timeout: 480 seconds]
<DarkNeutrino>
jernej: ok so i did the update and etc. I can upload it to github and could you look over as preliminary review ?
<DarkNeutrino>
oh and yea it works
szemzoa has quit [Remote host closed the connection]
diego71_ has quit [Remote host closed the connection]
vagrantc has joined #linux-sunxi
<jernej>
DarkNeutrino: preliminary review - it needs a lot of work to be mainline worthy :)
<jernej>
first of all, all magic values must go away, some to nicely named macros, some maybe in bitmaps, etc.
<jernej>
second of all, I'm pretty sure YUV scaling and YUV formats don't work. That's why I never continued with the work.
<jernej>
de33 clock driver can be at least partially merged to existing one, nothing really new about clocks
<DarkNeutrino>
does de3 have a clock driver ? if so is it in the de2 one :
<DarkNeutrino>
?
<DarkNeutrino>
cause thats bit weird to have it named de2 and support de3 as well
<jernej>
last but not least, DE3.3 allows to assign planes between mixers. This is currently hacked into de33 clock driver, but should be make adjustable (DRM subsystem already supports that)
<jernej>
why? sun4i DRM driver supports not only A10, which is suggested by the name, but also all other SoCs
<jernej>
driver gets name by first supported HW
<DarkNeutrino>
ohhhh
<DarkNeutrino>
that i didnt know
<jernej>
in the end, name doesn't matter as much as code deduplication
<DarkNeutrino>
fair. so lets just say this is a very crude proof of concept to at least use while we improve it :)
<jernej>
yeah, it's usable for having console or simple desktop
<jernej>
but not for, say, LibreELEC and Kodi
<DarkNeutrino>
oh right those need YUV right ?
<jernej>
yes
<DarkNeutrino>
also you said CPU will lock up with GPU enabled ?
<DarkNeutrino>
cause mine runs just fine
<jernej>
only if you have power domain disabled
<jernej>
and you have it enabled with U-Boot hack
<DarkNeutrino>
power domain as in the regulator ?
<jernej>
no
<jernej>
I'm not sure how to properly explain this, but I guess you can imagine that part of silicon is just powered down
<DarkNeutrino>
oh i know what you mean
<jernej>
I guess smaeul can explain it better
<DarkNeutrino>
but i would surely love to hear an explanation if i got anything wrong from the quick look at docs
<jernej>
which part?
ftg has joined #linux-sunxi
<DarkNeutrino>
well from what i understand its basically like defining that this and this and etc need to be shutdown together and thus save on power ? i could be totally off here :)
<DarkNeutrino>
so the chip is basically split into chunks that can be powered off independently
<jernej>
ah, yes, I understand it that way
<apritzel>
I'd say: a "power domain" powers a set of peripherals, and is typically supplied by a regulator
<apritzel>
in DT (especially our ones) the differentiation between the two is sometimes somewhat fuzzy, and we often skip the "power domain" concept and instead just specify the regulator
<DarkNeutrino>
but 1 power domain doesnt need to have only 1 regulator correct ? it can have multiple to power sets of the things that need their own regulators no ?
<apritzel>
a power domain could be as simple as some kind of switch, and I think this is what it actually here is this case?
<apritzel>
I am not quite sure how multiple regulators would supply one power domain
<apritzel>
you can have peripherals with multiple regulators, for instance MMC with a supply voltage and an I/O voltage
<DarkNeutrino>
ah right yea thats where i got confused with multiple regs
<apritzel>
I think in the MMC case the power domain is still separate, I guess it's everything that's powered by VDD_SYS
<DarkNeutrino>
ohhh interesting. devices can have multiple power domains.
<apritzel>
mmh, not really, they can use multiple voltages (with regulators providing them), for different things. In the MMC examples it's the SD card supply voltage, the I/O lines voltage
<DarkNeutrino>
yea but you define it in dt as 2 power domains no ?
<apritzel>
and then the MMC controller itself is on a power domain, which we actually don't describe in the DT, since it's the "common" power domain that powers most peripherals
<apritzel>
but minus the RTC, for instance, since that is on a separate power domain
<apritzel>
I guess the same can be said about the actual CPU cores, and the GPU
<DarkNeutrino>
ah and the operating points are split per power domain as well it seems.
<DarkNeutrino>
well folks thanks so much for this. i learned something new today :)
<DarkNeutrino>
apritzel: do you by any chance have time tomorrow to help me with some things on the axp313a ?
<apritzel>
yeah, I should be around
junari has joined #linux-sunxi
<DarkNeutrino>
also i may have to look into opp tables and temp control on h616 cause the chip runs hot when you hit it (i know who would have thought...) and even with heatsink on its hot
junari_ has quit [Ping timeout: 480 seconds]
DarkNeutrino has quit [Quit: Page closed]
apritzel has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
diego71 has joined #linux-sunxi
apritzel has joined #linux-sunxi
sepf has joined #linux-sunxi
grming has joined #linux-sunxi
DarkNeutrino has joined #linux-sunxi
Guest3004 has quit [Read error: Connection reset by peer]
junari_ has joined #linux-sunxi
<jernej>
MoeIcenowy: Do you know why you decided to drop vbus regulator support while working on H6 USB3 PHY driver?
<jernej>
I'm looking for upstreaming "trivial" patches, and enabling USB3 on PineH64 is one of them
junari has quit [Ping timeout: 480 seconds]
<jernej>
btw, I think devm_regulator_get_optional() will also search child nodes, so code can be pretty simple
<apritzel>
jernej: +1 for USB3 on the PineH64 ;-)
<apritzel>
jernej: oh, btw: is there any problem with the F1C100s USB series? Seems like that missed the merge window (again)?
<jernej>
apritzel
<jernej>
no, not really, but usb patches should be merged through usb tree first
<jernej>
i think gkh does that
<apritzel>
yet another tree?
<apritzel>
I already forked off the PHY patches, which basically cost one merge window
<apritzel>
and was a PITA, because of the stupid dependency
<jernej>
sunxi tree takes only clk, dt, config and soc (drivers/soc) patches. Everything else goes through respective subsystem tree
<jernej>
oh, and platform patches (arch/arm/mach-sunxi)
<jernej>
but hopefully we ended with that one, except some rare maintenance things
<jernej>
maybe the issue was missing ack, which I missed. sorry about that.
<jernej>
just checked, gkh applies musb patches
<apritzel>
yeah, just writing an email to him and Bin Liu
<apritzel>
jernej: who is handling this usb-a-connector compatible string? Is that a job for each PHY driver?
<apritzel>
because I don't see this string in drivers/ at all ...
mkazantsev has quit []
<jernej>
believe it or not, I and Neil (amlogic maintainer) were on same wild goose chase this evening
<jernej>
there is no driver for it
<jernej>
what happens is that you're supposed to add connector as child node of usb node
<jernej>
and usb driver will aquire vbus regulator from usb node. Funny thing is that regulator functions are recursive. If regulator is not found in current node, all child nodes are checked and so on until every node is checked.
<apritzel>
really? I thought DT children traversal requires a known compatible string, so opt-in from the device?
<apritzel>
I mean generally speaking DT children could mean anything ...