Asara has quit [Read error: Connection reset by peer]
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
junari has joined #linux-sunxi
<junari>
tokyovigilante: I haven't tested this. But it most likely works
junari 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
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel_ has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel_ has left #linux-sunxi [#linux-sunxi]
apritzel has joined #linux-sunxi
<tokyovigilante>
junari: thanks, I have put what should be the correct registers and so on for the H616 into the existing mainline sun4i driver, and get audio via lineout, but it's running 50% too slow, so wondered if you'd seen that on the H618
<tokyovigilante>
Jookia: I'm testing your SPI and NV3052C patches, and have integrated my panel info/regs on top, do I also need your DE/HDMI patch series?
<tokyovigilante>
Jookia: have pulled them in (didn't quite apply cleanly but not too bad) but seeing this in u-boot:
<tokyovigilante>
stdio_add_devices: Failed to probe video device 'sunxi_de2' (ret=-19)
<tokyovigilante>
seems my panel is not being detected
<tokyovigilante>
video panel not found: -19
<tokyovigilante>
sunxi_de2_probe: lcd display not found (ret=-19)
<tokyovigilante>
seems my UCLASS_PANEL list is empty :/
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
<macromorgan>
INFO: mentor_i2c_address_set: ERROR - status 20 addr in Write mode.
gsz has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
<apritzel>
macromorgan: what does the DT say in this case? Do you use r_i2c for the PMIC? And does that happen on a cold boot or a reboot?
<macromorgan>
r_i2c, and cold or warm I get the error
<macromorgan>
plus in U-Boot (I'm still testing just U-Boot) I can't see the PMIC via the i2c tool
<macromorgan>
I'm using all the i2c patches that have been recently posted too
<macromorgan>
the "replace SPL driver" and whatnot
<apritzel>
so you mean the U-Boot AXP patches?
warpme has joined #linux-sunxi
testaccount has joined #linux-sunxi
<macromorgan>
yes
testaccount has quit []
<macromorgan>
the very first error (prior to A-TF) is "Failed to set core voltage! Can't set CPU frequency". I remember getting this before, but always forget the fix
<macromorgan>
okay think I have something, let me keep debugging the first error
<macromorgan>
so board_init() calls axp_init(), which calls pmic_bus_init(), which seems to struggle. If I enable the necessary GPIO and i2c stuff, I run out of sram it seems.
<macromorgan>
because in order to satisfy pmic_bus_init() I need to enable dm mode in SPL, which means I also need to bring OF_REAL_SPL and the DM_I2C drivers before everything stops complaining about missing stuff.
<apritzel>
so one possible problem resulting in "Failed to set core voltage" is that the PMIC is still in RSB state, so talking to it via I2C doesn't work
<apritzel>
that happens when Linux is running and you reboot, which resets the SoC, but not the PMIC
<apritzel>
but if you run with I2C consistently: in the DT, so in U-Boot proper, Linux, and now TF-A, and in the SPL anyway, then this shouldn't happen
<apritzel>
macromorgan: and I am still puzzled why you seem to require DM_SPL? For what, exactly, more debug info?
<macromorgan>
I'm trying to get the PMIC to run in i2c mode in SPL
<macromorgan>
using the new drivers you released
<apritzel>
but that should work just fine, definitely it does on the AXP313a boards, like the OPi Zero3
<apritzel>
I mean the SPL supports I2C only anyways, IIRC
<apritzel>
macromorgan: compare orangepi_zero3_defconfig for the weird config options you need for that
<macromorgan>
okay
<macromorgan>
let me check that and try again
apritzel has quit [Ping timeout: 480 seconds]
ftg has joined #linux-sunxi
linkmauve has left #linux-sunxi [Error from remote client]
<tokyovigilante>
this is detected now, maybe my compatible is wrong
<Jookia>
possibly
<tokyovigilante>
no, but that wasn't appearing before so thats good
<Jookia>
i THINK my boot code is somehow causing a display tint. im not sure
<Jookia>
if it tints for you please tell me
<tokyovigilante>
ah nice
<tokyovigilante>
uclass_find_device: 0
<tokyovigilante>
nv3052c_panel panel@0: Failed to get power supply: -19
<tokyovigilante>
well, bad, but detected
<tokyovigilante>
I presume I need regulators enabled in some fashion?
<Jookia>
yay! regulators!
<Jookia>
yeah
<Jookia>
gpio regulator
<tokyovigilante>
Cool, gotta get to work but feels like imminent success, thanks for the tips! Will review/test on list once I've got it working here, plus I can test HDMI
<Jookia>
awesome :)
gsz has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<apritzel>
so does anyone know if there is some kind of path to follow in the display engine DT graph, with one top node that leads to all other needed devices?
<apritzel>
for instance is that the hdmi-connector, and the panel driver, that links to the mixer and from there to the other devices likes the clocks and any PHYs needed?
<apritzel>
I am thinking about how to teach U-Boot manners in terms of properly following the DT for the graphics pipeline
<apritzel>
problem seems to be that U-Boot does not probe devices automatically, it needs something to trigger that
<apritzel>
Jookia: for the background: I have an answer to your U-Boot gfx series in my draft folder for a while, but didn't dare to send this without having some kind of plan
<Jookia>
apritzel: oh?
<apritzel>
I don't feel like we should proliferate the hack that the U-Boot DE2 driver is atm, and make it a full DT/DM citizen: so no more SUNXI_DE2_BASE and friends ....
<Jookia>
ah
<Jookia>
at the moment i don't have any plans to do further u-boot devel :\
<smaeul>
apritzel: you start at the (synthetic) display-engine node, follow allwinner,pipelines to find mixers, then traverse the OF graph outputs to get to the other components
<Jookia>
smaeul: i think apritzel said no to traversing the graph
<apritzel>
Jookia: no, that's fine, the drivers should be connected to each other via properties, but U-Boot apparently needs one entry point to trigger the whole chain
<smaeul>
hmm, OF graph is the only connection between the pipeline components (e.g. you don't otherwise know if there's a TCON TOP)
<apritzel>
smaeul: OK, thanks, though this doesn't really tell me which of the pipelines I will need, right? I was wondering if I could start at /hdmi-connector, if that exists?
<Jookia>
that's a lot of work
<apritzel>
Jookia: tell me about it...
<Jookia>
and this blocks merging the code now?
<smaeul>
what about boards without an HDMI connector?
<apritzel>
Jookia: well, yes, that's the news I didn't want to break to you :-(
<Jookia>
apritzel: ok. just tell me when that work is done and i'll rebase
<smaeul>
apritzel: you could have the probe routine for each component device_probe() its downstream, and have that return -ENODEV if there is no panel/connector
<apritzel>
smaeul: so the other alternative would be to check for any panels that bound
<apritzel>
smaeul: neat idea, will think about it
<smaeul>
that is, any component could -ENODEV if there is no downstream in the OF graph (or child node for MIPI-DSI)
<apritzel>
so do I get from each allwinner,pipelines to either a connector or a panel, eventually?
<smaeul>
yeah, either you get to a connector or panel, or that pipeline is not usable*
<apritzel>
ah, cool, that might work then, many thanks!
<smaeul>
*assuming you don't cross pipelines (hook up mixer 0 to tcon 1), which Linux doesn't do
<Jookia>
i don't know if linux is the best model to reference here, it seems to set up both mixers/pipelines regardless of whether its used
<Jookia>
i think having a static DE setup is a better idea but i don't know
<Jookia>
walking a graph seems like overkill for u-boot
tokyovigilante has quit [Ping timeout: 480 seconds]
<apritzel>
Jookia: what would describe this static setup? Kconfig variables?
<Jookia>
maybe per-chip settings and looking at the dt for specific things
<Jookia>
when using the graph you'd have to deal with clocking and calculations which we've decided not to do
<apritzel>
well, I was hoping to cut the clocking short, in the display clock driver
<apritzel>
but yeah, I am happy to take shortcuts, for the sake of simplicity
<apritzel>
for instance I hacked^Wadded the SRAM part into the probe routine of some simple allwinner,sun50i-a64-de2 bus driver
<Jookia>
is there a point to mainlining u-boot patches?
<apritzel>
always, but you know that ;-)
<Jookia>
the list of reasons to mainline is empty in my head at the moment
<Jookia>
especially after discussions we've had earlier
ryan_ has joined #linux-sunxi
<apritzel>
I am sorry that you are frustrated about it, but there isn't exactly many people doing serious review on the U-Boot side :-(
<Jookia>
i'm not that frustrated about it, just genuinely curious at this point
ryan_ has left #linux-sunxi [#linux-sunxi]
<Jookia>
you've explained that bootloaders and firmware should be shipped by vendors
<Jookia>
so it really seems like there's no value in mainlining?
<apritzel>
so here is the deal: you *can* indeed ship your own firmware build
<apritzel>
that's in contrast to shipping your own kernel!
<apritzel>
as long as you keep the DT's strictly adhering to the Linux bindings, so don't invent any hacks, that's probably a quick and easy way
<apritzel>
but in the same way the true power of Open Source lies in peer review
<smaeul>
there's also "so I don't have to keep resolving merge conflicts when I rebase my patches"
<Jookia>
smaeul: git merge works well for that
<apritzel>
well, until someone pulls the plug on a subsystem
<apritzel>
if you are mainline, it's *their* job to solve that problem
<smaeul>
s/when I rebase my patches/when I merge from upstream/ has the same impact
tokyovigilante has joined #linux-sunxi
<Jookia>
right now i just git merge with the RCs of u-boot and it seems to work fine without trouble
<apritzel>
Jookia: speak to you in a year then ;-)
<apritzel>
either you stopped doing that by then, or something fundamentally changed
<Jookia>
i would be really surprised to see the code i've touched change
<apritzel>
which one?
<Jookia>
mostly the DE code
<apritzel>
U-Boot has changed quite drastically over the last years, and it continues to do so
<Jookia>
yes, but it doesn't change that fast
<apritzel>
take a look at the DE code before smaeul and jernej reworked that to bring it into the 20th century ;-)
<Jookia>
I did
<apritzel>
and as a matter of fact I am about to turn that upside down, to make the A64 fully DT driven (w/ shortcuts)
<apritzel>
though this would actually make it easier to put H6 and H616 support on top, just in a quite different way
<Jookia>
I mean, this all ignores the cost of patches rotting right?
<Jookia>
There's the assumption that people will rebase their patches on your changes
<apritzel>
my plan was to look at your patches and adapt the bits to the new structure
<tokyovigilante>
I'll try and chip in if there is to be some display refactoring, as I can. The other downside of not mainlining, is that you end up with vendors shipping awful hacks from 2018 ;) but I appreciate it is a bit of a burden. Certainly the mainlining process has been hard for me and a steep learning curve, but made me a much better programmer
<Jookia>
there is a long term cost to hacks yes, but there's a very real short term cost to not onboarding developers
<tokyovigilante>
also fair to note that I wouldn't have been able to build my display code on top if Jookia hadn't submitted his, so much appreciated
<apritzel>
Jookia: tokyovigilante: if you need something that works for now, and makes the lives of other (Linux) developer's easier, then by all means ship some hacked up U-Boot image
<Jookia>
there's no other choice than to ship hacked up images
<apritzel>
but please don't give up upstreaming, because that's the only thing that has a future
<Jookia>
open source maintainers don't seem to understand this a lot of the time because they can self-review their own code
<Jookia>
you always have to carry patches
<apritzel>
Jookia: that is a problem because the sunxi community is half dead by now, or at least was a year ago
<apritzel>
I mean the mainline based community, the one that reviews patches
<Jookia>
it's not an antisocial thing, it's just reality that things don't get mainlined
<Jookia>
so you end up shipping a patched kernel and u-boot
<apritzel>
I somewhat agree that Allwinner U-Boot is in pity shape, and I am somewhat responsible for that
<apritzel>
but I strongly disagree on the kernel side
<apritzel>
proper review is essential, and that takes time
<apritzel>
the main problem is that it starts far too late
<apritzel>
for proper devices you start *a year before* the device is released
<apritzel>
that and a professional setting (being able to work on that 9 to 5) make a timely release much easier
<apritzel>
Allwinner should do that
<Jookia>
there is no SLA for reviews
<Jookia>
you can send patches to projects and they can just never respond
<apritzel>
that's because it's Open Source
<apritzel>
but if there are people pushing on that, and if people really want it, things move
<Jookia>
that's very wishful
<apritzel>
they do, on the Linux side, just more slowly, because we don't have professional contributors
BroderTuck has joined #linux-sunxi
<apritzel>
professional as in: working on this full time
<apritzel>
but what's actually the most important in this upstreaming process is the quality
<Jookia>
i'm not a fan of the framing that mainlining is something developers can control
<apritzel>
they cannot, but they can shape it
<apritzel>
and it takes *multiple* people to do so
<apritzel>
look at macromorgan's and tokyovigilante's progress in the last month
<Jookia>
i would really appreciate some more understanding towards people not mainlining things given how horrid the process is :)
<apritzel>
I see your point, but from my point of view there is really no alternative
<apritzel>
for quality reasons
<BroderTuck>
H3 (and friends) HDMI Audio has been in development hell for ... how many years now?
<Jookia>
this 'quality' is theoretical
<Jookia>
there's no guarantee it will pan out or exist
<Jookia>
it's at the expense of existing, good enough solutions
<apritzel>
Jookia: the quality of many downstream patches is just shocking
<Jookia>
it's at the expense of building a community of contributors
<Jookia>
maintainers can sit around enjoying their cross-subsystem changes and code quality improvements, but it's at the cost of getting people involved in the project
<Jookia>
like it is fantastic when the cross-subsystem changes happen and when things become more elegant. when things move to the device tree and no longer .h config files
<apritzel>
BroderTuck: how many patches have been sent to the relevant mailing lists? How many people have engaged with maintainers and contributors to push for this?
<Jookia>
:\ why is it immediately assumed this is the developer's lack of activity/effort for pushing the patches
<apritzel>
didn't say developer, it's more about multiple people asking for this
<Jookia>
doesn't that kind of conflict with the whole 'get things mainlined before your product is released'
<Jookia>
i don't know. maybe there's some subtext i'm missing here
<apritzel>
in an ideal world Allwinner would employ a team of say at least three people that do mainlining
<apritzel>
they get early access to the documentation and prototypes or FPGAs
<apritzel>
they develop patches and send them
<apritzel>
and then the respective maintainers and reviewers start to do their job
<apritzel>
if it gets stuck, the team asks why
<Jookia>
which companies mainline like that
<apritzel>
AMD, Intel, Arm, ..
<Jookia>
do they have kernel maintainers of their own?
<apritzel>
yes, absolutely
<Jookia>
it seems to me that the problem is lack of maintainers more than anything
<apritzel>
grep $company.com MAINTAINERS
<apritzel>
maintainers are notoriously overloaded, that's a known problem, typically a topic on every Linux conference
<apritzel>
but since it's a community, people help each other out, for instance by doing proper reviews
<Jookia>
i don't think that really works?
<apritzel>
I am employed for doing mainline work for about 18 years now: it absolutely works very well
<Jookia>
like for example, the USB sunxi DM patches in u-boot that are required for USB gadget to work are over a year old, and I've given a reviewed-by, and someone else has independently done their own patch of it and submitted it
<apritzel>
and if you look at the progress of Allwinner mainlining a few years back: it was working very well too
macromorgan has joined #linux-sunxi
<Jookia>
it's just very, very, very exhausting to the point i'm probably not going to bother mainlining code any more :\ it can live in my kernel/u-boot fork
<apritzel>
Jookia: as I said, the situation is a bit different on the U-Boot
<Jookia>
u-boot is neglected
<Jookia>
in favor of the kernel, at least
<Jookia>
it would be nice to use linuxboot or something similar instead
<apritzel>
diverging efforts will only make things worse
<Jookia>
i don't know. there's some logic my brain can't follow here where i'm being told to mainline things in promise of ... something. but in reality it's basically throwing time and code in to /dev/null and seeing other people do the same
<Jookia>
i can't mentally allocate in time and energy for code review then have it not happen
<apritzel>
Jookia: you seem to be completely frustrated. So can you please make a list of patches that you care about the most?
<apritzel>
and maybe recruit reviewers in here as well?
<Jookia>
apritzel: maybe some time when i'm less frustrated. next year maybe?
<Jookia>
my patches are on the mailing list
<Jookia>
i don't have the resources to review them/respond to feedback at the moment as i have kernel code to write :\
<apritzel>
welcome to my world ;-)
<Jookia>
and this isn't some indirect rant about you as a maintainer btw
<Jookia>
you're a very nice person and i'm thankful for your advice and keeping me in the loop
<BroderTuck>
How was that line again. "Perfect is the enemy of good"?
<Jookia>
but i have also sent patches to other maintainers that just seem to go to /dev/null
<apritzel>
did you ping them again? Often it helps to involve other people as well
<Jookia>
yeah someone else voiced that they could use one of the patches
<Jookia>
and the other was just a cleanup
<Jookia>
one got lost but got merged, so i officially have one patch in u-boot mainline
<apritzel>
look for instance at the H616 cpufreq patches: Martin decided to upstream them, around summer last year. Then I jumped on it, and *together* we pushed them upstream
<apritzel>
and in the process we fixed quite some issues and improved them significantly
<Jookia>
gah. that makes me wonder if i'll send the fractional clocking patches
<Jookia>
maybe next year
macromorgan has joined #linux-sunxi
<Jookia>
untangling my changes in to something that can be reviewed and preparing for the interrogations is not great
<apritzel>
that's because many contributors and maintainers in this Chinese Soc/SBC fringe are actually hobbyists, and only have so much time, and also so much motivation (as you figured)
<Jookia>
maybe i'll only go for the approach of mainlining if other developers are interestedd
<Jookia>
rather than trying to get everything mainline
<apritzel>
it's partly a problem of interest, yes
<apritzel>
if something is quite a bit fringe, so to speak, there are not many people out there interested
<apritzel>
and Allwinner's performance both hardware wise and software wise is surely contributing to this
<Jookia>
right now it's looking like i'll just have my own u-boot/kernel and eat the merge conflicts :\
macromorgan has quit []
macromorgan has joined #linux-sunxi
<Jookia>
i'm not actually sure why i'm salty about this, i'm sending patches upstream and people are using them and it's solving real problems
<apritzel>
I can understand your frustration on the U-Boot side, but please don't give up on the kernel
macromorgan has quit []
<apritzel>
it's essential to get kernel patches reviewed
<Jookia>
eh
macromorgan has joined #linux-sunxi
<Jookia>
it sure would be nice if these projects used a good patch tracking system
BroderTuck has quit [Quit: sleeeeeep]
<Jookia>
i would really like to be able to say 'yes i will mainline my patches' but it's such an unpleasant and draining experience that i could just not do, you know? maybe embedded devel is the wrong career for me
<apritzel>
as mentioned, I understand your frustration, but if that would have been the attitude of all the other developers in the sunxi community before, you would have nothing to build on
<Jookia>
i wonder how many it has been the attitude for, and whether that's a reason the community is so small
bauen1_ has joined #linux-sunxi
macromorgan has quit []
<apritzel>
and the fix for this is?
<apritzel>
keep trying, maybe?
<Jookia>
for me or for u-boot? because i feel like it's a good amount u-boot issue
macromorgan has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
<Jookia>
i would probably focus a little less on quality and more on getting people contributing
<tokyovigilante>
I do sympathise with some of the feedback I've recieved being a bit pedantic, particularly around the DT-bindings, but then I do really appreciate being able to go and rely on what has been committed. What has been really helpful to me is supporting others to test etc, then getting the Tested-by: tags, which seems to help the maintainers prioritise.
<tokyovigilante>
Certainly the hobbyist theme rings true, I'm not a programmer by trade, nor even had any embedded knowledge, just wanted a bit more from these cheap and cheerful devices.
<tokyovigilante>
Anyway Jookia I really appreciate your help with the display patches, will generate a bit of noise on the list once I get them working, and happy to help with the refactoring as noted.
<tokyovigilante>
The DE33 patches for the kernel took a *long* time to break down, but helped my understanding enormously and I even found a couple of ways to improve them
<apritzel>
tokyovigilante: btw: with professional I don't mean "by trade or degree", it's purely the luxury of getting paid for doing that, so being able to work on this 9-to-5, and not in the hours around midnight only
<tokyovigilante>
yup understood, and apritzel I really appreciate your help too, would have achieved absolutely nothing without this community so I wouldn't say it is doing too badly. even if others don't have a huge amount of time their work has been extremely valuable to refer to
<tokyovigilante>
That is probably the greatest shame for me about Linux in general, that so much of it is carried by hobbyists, despite the enormous value to corporate users who don't contribute back, financially or code-wise
<apritzel>
tokyovigilante: the community actually gained traction again when you, macromorgan and loki666 stepped on here, and also because the Anbernic device seemed a bit more sexy than the previous AW based boards
<apritzel>
(plus acmeplus and the others I forgot to mention)
<apritzel>
that's actually the reason I diverted resources away from U-Boot :-(
<Jookia>
that's pretty cool
<Jookia>
i appreciate all of you. i'm not annoyed at anyone in particular, just a bit salty that this is the situation we're in
<Jookia>
taking a bit of a break from u-boot will help
<Jookia>
as long as someone wants my patches i'll work on mainlining them
<Jookia>
and i will make nice patchsets for the kernel and u-boot
<Jookia>
since at the very least it means others can mainline it for me :)
<tokyovigilante>
then compared to the likes of ARM, Valve, AMD etc who make a massive effort. Even Lenovo for example, had direct support from them for my laptop for example
<buZz>
what, there's a lenovo with allwinner cpu? :O
<tokyovigilante>
apritzel: thanks, I literally just bunged code together from other people, but the H700 devices do seem to be quite successful, and there is quite a big community around some of the custom firmware, admittedly mostly users but that was where kikuchan first reached out, and he did some great work with the display panel
<tokyovigilante>
buZz: heh no, there is a linux developer who works on their firmware, and did quite a lot of work for a thermal issue on one of the X1 devices via their forums
<buZz>
ah aww :)
<apritzel>
tokyovigilante: you did and are doing a great job, and I see quite some development there, so keep up the good work!
<Jookia>
yes, you're doing good :)
<Jookia>
apritzel: tokyovigilante: please keep me involved in the DE/panel/etc stuff. i hope to be of help even if i'm not up to providing full patches atm
ndufresne has joined #linux-sunxi
ftg has quit [Read error: Connection reset by peer]
<tokyovigilante>
of course :)
<tokyovigilante>
you think the LKML is tough, try getting funding out of a government department ;)
<Jookia>
oof
<apritzel>
hey, easy review opportunity: there is patch 4/4 of the H616 crypto series: that just requires comparing the H616 manual against the numbers put into the DT, and maybe against the binding