<gediz0x539>
do you use it to read out internal temperature?
<swiftgeek>
yep
<swiftgeek>
after it breaks it will display those message for some time but it will lock up pretty quickly
<swiftgeek>
that's like good 30s :D
lkcl has joined #linux-sunxi
<wens>
hmm, must be my config then :/
<wens>
not seeing anything abnormal on kernelci either
<MoeIcenowy>
wens: you enabled LPAE?
<wens>
MoeIcenowy: nope. I checked
<gediz0x539>
swiftgeek: is it enough to enable sun4i-ts or should i also adjust dts to read temperature?
<swiftgeek>
i don't think i was loading -ts
<swiftgeek>
sun4i_gpadc / sun4i_gpadc_iio should be enough i think
<gediz0x539>
thanks
faruk__ has joined #linux-sunxi
<swiftgeek>
and monitored with /sys/class/thermal/thermal_zone0/temp
faruk_ has quit [Ping timeout: 264 seconds]
faruk_ has joined #linux-sunxi
faruk__ has quit [Ping timeout: 240 seconds]
reinforce has quit [Remote host closed the connection]
reinforce has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
camus has joined #linux-sunxi
camus is now known as kaspter
iamfrankenstein has joined #linux-sunxi
hlauer has joined #linux-sunxi
<hlauer>
is a20 i2c hardware capable of generating an additional clock cycle if SDA is stuck low?
pCactus has joined #linux-sunxi
pCactus_ has quit [Read error: Connection reset by peer]
pCactus_ has joined #linux-sunxi
pCactus has quit [Ping timeout: 265 seconds]
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
apritzel has joined #linux-sunxi
<gediz0x539>
swiftgeek: "find / -name temp" returns only "/sys/devices/virtual/thermal/thermal_zone0/temp"
<gediz0x539>
and i cannot read anything from the said "temp"
ldevulder has joined #linux-sunxi
\\Mr_C\\ has joined #linux-sunxi
<gediz0x539>
apparently i've enabled mfd but not the actual sun4i_gpadc
apritzel has quit [Ping timeout: 256 seconds]
<gediz0x539>
temperature is readable right now but got some warning about irqs at startup https://bpa.st/4X4Q
pCactus_ has quit [Read error: Connection reset by peer]
pCactus has joined #linux-sunxi
prefixcactus has joined #linux-sunxi
lkcl has quit [Ping timeout: 256 seconds]
mmarc__ has joined #linux-sunxi
mmarc___ has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 272 seconds]
lkcl has joined #linux-sunxi
cmeerw has joined #linux-sunxi
dlan_ has quit [Quit: leaving]
dlan has joined #linux-sunxi
asdf28 has joined #linux-sunxi
mmarc___ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
atsampson has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 264 seconds]
mmarc___ has joined #linux-sunxi
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
mmarc___ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
\\Mr_C\\ has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 258 seconds]
_rze has quit [Ping timeout: 240 seconds]
gediz0x539 has quit [Remote host closed the connection]
victhor has joined #linux-sunxi
gediz0x539 has joined #linux-sunxi
lkcl has quit [Ping timeout: 265 seconds]
mmarc__ has joined #linux-sunxi
lkcl has joined #linux-sunxi
<mmarc__>
thanks, Peetz0r! It still does not work, and I'm wondering if it's even possible to send the key, if "Hit ctrl+u to stop autoboot:" is given 0 seconds to do so?
pCactus has quit [Read error: Connection reset by peer]
pCactus_ has joined #linux-sunxi
<Peetz0r>
I don't actually know. Never seen that prompt with 0 seconds
<mmarc__>
I guess it should be quite common for devices, which are not supposed to be debugged.
* psydruid
briefly tried 5.11 on a64 but dropped back to 5.10.17 due to instabilities
* Peetz0r
is running 5.11 on a64 (specifically the pinephone) just fine
apritzel has quit [Ping timeout: 265 seconds]
sunshavi has quit [Read error: Connection reset by peer]
sunshavi has joined #linux-sunxi
pCactus has joined #linux-sunxi
pCactus_ has quit [Read error: Connection reset by peer]
pCactus_ has joined #linux-sunxi
faruk_ has quit [Quit: Leaving]
pCactus has quit [Ping timeout: 240 seconds]
gediz0x539 has quit [Quit: Leaving]
fuzzybritches has quit [Quit: WeeChat 3.0]
<Peetz0r>
smaeul: sorry, I went missing yesterday. But I'm back. Can you help me with configuring crust so we can have serial during sleep without using too much power?
<Peetz0r>
you mentioned 2048 baud yesterday. Not 2400?
<MoeIcenowy>
Peetz0r: yes
<MoeIcenowy>
the clock remaining open is osc32k
<MoeIcenowy>
which is 32768Hz
<MoeIcenowy>
8250-compatible UART controllers do /16 internally
<Peetz0r>
So that means the original clock runs at 1843200 Hz, or 1.8 GHz?
<Peetz0r>
hmm, it's called OSC24M so I assume it should be close to 24 MHz :p
<Peetz0r>
eh, where I said GHz before I meant MHz. My brain is toast :p
<Peetz0r>
ANyway, I think I understand what needs to be done now :)
pCactus has joined #linux-sunxi
pCactus_ has quit [Ping timeout: 264 seconds]
pCactus_ has joined #linux-sunxi
<Peetz0r>
huh, it's actually running at 157 baud now. So I am having one /16 too many
<Peetz0r>
but, power usage is now ~20 mW
pCactus has quit [Ping timeout: 240 seconds]
<Peetz0r>
(before wowlan patches, so this is my baseline figure)
<Peetz0r>
eh forget what I said, I forgot that I had the charger still plugged in
<Peetz0r>
lemme try again without :p
JohnDoe_71Rus has joined #linux-sunxi
kaspter has quit [Quit: kaspter]
victhor has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
<apritzel>
Peetz0r: there is a programmable baud rate divider in the UART, which divides down the input clock, *on top* of the mandatory "by 16" (used for oversampling the RX line)
<apritzel>
Peetz0r: when the input clock is the 24MHz oscillator, you set this divider to 13, to get 115200
<Peetz0r>
so it needs to be unset, or set to 0
<Peetz0r>
I assume that is CLK_RAT_M?
<apritzel>
dividing by 0 is less popular, so I'd say 1 ;-)
<Peetz0r>
(I was just reading about it, and now it makes sense)
<Peetz0r>
Eh yeah, divide by 1, set register bits to 0
<Peetz0r>
"The pre-divided clock is divided by (m+1). The divider is from 1 to 32." as the manual states it
<Peetz0r>
But, I already did set that to 0, I copypasted existing code that did that. Wait, do I need to change the existing code to use 13?
<apritzel>
Peetz0r: drivers/serial/uart.c does the divison, based on CONFIG_SERIAL_BAUD *and the input clock rate*
<apritzel>
Peetz0r: you would need to change the input clock to the 32KHz OSC
netlynx has joined #linux-sunxi
<apritzel>
Peetz0r: the UART baud clock is hardwired to APB2, so would need to hack the APB2 mux settings in the clock driver, to select the 32KHz OSC
<apritzel>
Peetz0r: not sure if crust then figures out itself that it then can turn off the other clocks
prefixcactus has quit [Ping timeout: 246 seconds]
pCactus has joined #linux-sunxi
pCactus_ has quit [Ping timeout: 240 seconds]
pCactus_ has joined #linux-sunxi
pCactus has quit [Ping timeout: 256 seconds]
tuxd3v has quit [Remote host closed the connection]
pCactus has joined #linux-sunxi
pCactus_ has quit [Ping timeout: 240 seconds]
<smaeul>
the UART divisor is only calculated at boot, so it's easiest to leave it as-is (13) and use 32768/16/13 ~ 150 baud
<Peetz0r>
yeah, the 157 I stumbled upon earlier :p
<Peetz0r>
I guess I'll just do my measurements at 157 baud and enjoy the retro text scrolling effect :p
<smaeul>
that will get you 300 baud (which I need because my UART cannot do custom baud)
<Peetz0r>
The one available in the pine store for the headset jack does it just fine :)
<smaeul>
note that the UART connection itself will impact power consumption, so this won't give you absolute numbers, but it should be fine for relative measurements
<smaeul>
specifically: the DCDC1 rail will be powered by the UART cable
<Peetz0r>
meanwhile, I was grepping trough that wifi driver and I found this thing which are... printer configs?
<smaeul>
Peetz0r: there's probably some provider of prebuilt toolchains that work, but it looks like I need to be more careful about which ones I recommend
<jernej>
it allows you to specify function for mode validating, very much like in Linux
<jernej>
and you don't need to check width and height, as long as mode clock is equal or below 165 MHz, it should work
<apritzel>
jernej: thanks, this driver can use some serious rework, and I have some patches already
<jernej>
I concur, DE2 version too
<apritzel>
so this was just a small proof of concept to see if it fixes uis' problem
<apritzel>
jernej: yeah, indeed, DE2 as well
<jernej>
currently it's a bit messy due to sharing code with non-DM driver
<apritzel>
and the resolution check is just to avoid the 1024 fallback, when the problem is that the monitor is actually too *good* for us
<jernej>
and at the time, H3 DT didn't even containt HDMI DT nodes
<apritzel>
so I try FullHD if the monitor can display that
<apritzel>
jernej: also there is already a fallback in place, actually: we start with a 1024x768 modeline
<jernej>
not sure I understand, if resolution is too big, then pixel clock will be above limit
<apritzel>
yes, and then we try a smaller resolution
<apritzel>
but I figured the canonical 1024x768 fallback a bit too small these days
<apritzel>
so at the moment we don't check anything, so the modeline passes, and we program garbage -> no picture
<jernej>
I don't see a reason why this is driver specific, you should change framework instead
<apritzel>
jernej: sure, can of worms
<jernej>
?
<apritzel>
jernej: there is so much more that could be changed, just not sure it's really worth it
<jernej>
so leave default as-is?
<apritzel>
for instance the simplefb is pretty generic, apart from the pipeline name, yet we now have two functions
<apritzel>
(one in -de2, one in sunxi-display)
<jernej>
ok, but you know that these two pipelines are a bit different?
<apritzel>
what I am trying to say is that this patch is just the smallest possible solution to uis' problem: to get a picture on his 4K monitor
<jernej>
so simplefb functions are different
<jernej>
ok, as a quick hack, but it not something I would send upstream
<jernej>
better to gradually update
<jernej>
I can take a look at DE2 code
<apritzel>
jernej: from what I gather all this sunxi_simplefb_setup() function does is to *find* the right pipeline node, and alter that
<apritzel>
what's different is just the pipeline names, no?
<jernej>
ah, yes, seems so
<apritzel>
and uclass_find_device_by_name() is actually an internal function, so it's dodgy to use in a driver
<apritzel>
so we could generate the pipeline DT name already in probe(), store this somewhere, maybe even as a generic uclass member, and then have one generic simplefb setup function
<apritzel>
there is much more in sunxi_display.c to fix, Simon pointed out some issues already
<apritzel>
jernej: and yeah, this patch is not for mainline as is, but I wanted to see first if that fixes uis' problem
<jernej>
apritzel: sunxi_display.c is the last user of video_edid_dtd_to_ctfb_res_modes(), if you switch to edid helpers, it can go away
<apritzel>
oh, you are right
<jernej>
and calls to video_ctfb_mode_to_display_timing() can then be removed too, I added those so same tcon function could be used for DM and pre-DM driver
<uis>
Will try patch tomorrow
<Peetz0r>
smaeul, megi: it seems to hover around 190 mW when sleeping with wowlan enabled (vs 120 mW without it). There was no difference between the kernel with the feature disabled at runtime vs the stock kernel, so shipping this kernel and letting the user decide would be fine.
<Peetz0r>
ok I don't know what's happening but it just went down to 120 mW with wowlan enabled
giomba has quit [Quit: Leaving]
<smaeul>
it probably depends on the amount of WLAN traffic on that channel
<Peetz0r>
I'll tell that to the neighboors :p
<apritzel>
jernej: are those ctfb_* structures and functions (non-DM) legacy, and should be replaced in general by struct display_timing and friends?
<jernej>
good question
<apritzel>
de2 doesn't seem to use that at all
<jernej>
true
<jernej>
but if you completely remove them, then you'll lose mode configurability through env vars
<jernej>
and many people rely on that
<jernej>
apritzel: now I remember reason for usage of uclass_find_device_by_name - at the time, there were no display related nodes in DT, so I have to come up with something else
<jernej>
these drivers predate Linux ones
asdf28 has quit [Ping timeout: 256 seconds]
hlauer has quit [Ping timeout: 272 seconds]
ldevulder has quit [Ping timeout: 240 seconds]
netlynx has quit [Quit: Ex-Chat]
ldevulder has joined #linux-sunxi
BenG83 has quit [Quit: Leaving]
ldevulder_ has joined #linux-sunxi
ldevulder has quit [Ping timeout: 264 seconds]
ldevulder__ has joined #linux-sunxi
jo0nas has quit [Ping timeout: 246 seconds]
ldevulder_ has quit [Ping timeout: 240 seconds]
jstein has joined #linux-sunxi
warpme_ has quit [Quit: Connection closed for inactivity]
qschulz_ has quit [Remote host closed the connection]
qschulz has joined #linux-sunxi
mmarc__ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
tuxillo has quit [Remote host closed the connection]