ftg has quit [Read error: Connection reset by peer]
montjoie_ has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
flyback has quit []
<ity>
OH
<ity>
Which drivers is it handled by? Which devices does devfreq scale
flyback has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
evgeny_boger has quit [Ping timeout: 480 seconds]
evgeny_boger has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
KREYREN_oftc has quit [Remote host closed the connection]
evgeny_boger has quit [Quit: evgeny_boger]
ungeskriptet has joined #linux-sunxi
junari has joined #linux-sunxi
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #linux-sunxi
ungeskriptet is now known as Guest621
ungeskriptet has joined #linux-sunxi
Guest621 has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest623
ungeskriptet has joined #linux-sunxi
Guest623 has quit [Ping timeout: 480 seconds]
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #linux-sunxi
montjoie has joined #linux-sunxi
ungeskriptet is now known as Guest626
ungeskriptet has joined #linux-sunxi
Guest626 has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest628
ungeskriptet has joined #linux-sunxi
Guest628 has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest629
ungeskriptet has joined #linux-sunxi
Guest629 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
ungeskriptet is now known as Guest631
ungeskriptet has joined #linux-sunxi
Guest631 has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest633
ungeskriptet has joined #linux-sunxi
Guest633 has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest635
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit []
Guest635 has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
junari_ has quit [Remote host closed the connection]
bauen1 has quit [Ping timeout: 480 seconds]
junari has quit [Ping timeout: 480 seconds]
warpme has quit []
apritzel has joined #linux-sunxi
<apritzel>
ity: CPUFREQ_DT and the generic cpufreq governors
warpme has joined #linux-sunxi
dsimic is now known as Guest656
dsimic has joined #linux-sunxi
Guest656 has quit [Ping timeout: 480 seconds]
warpme has quit []
bauen1 has joined #linux-sunxi
warpme has joined #linux-sunxi
colinsane has quit []
colinsane has joined #linux-sunxi
<jernej>
apritzel: regarding your wiki edit, H616 video engine is simple to support, but it needs new SRAM handling, otherwise it will break thermal driver
<apritzel>
jernej: ah, thanks, funny enough I was just looking at this SRAM part in your github ;-)
<apritzel>
jernej: so this SRAM C1 is for VE or DE?
<jernej>
I didn't bother to properly implement it yet
<apritzel>
and are you sure it's really all those bits in register 0? because in my experiments reg 0 didn't do anything, but bit 24 in reg 0x4 changed access
<apritzel>
so like sun50i_a64_sram_c
<jernej>
as I said, my code is not correct
<jernej>
because I assumed it's same as on H6
<jernej>
let me check
<apritzel>
OK, but those patches were successfully used by people already, weren't they?
<jernej>
yeah, Cedrus works with them
<apritzel>
I think I saw somewhere else that just bit 0 in reg 0x0 was used
<apritzel>
which would solve the clash with the thermal driver, I guess?
<apritzel>
jernej: btw: I wrote some GPU PPU driver: 125 lines of mostly boilerplate to flip a single bit ;-)
<jernej>
oh, great
<jernej>
please send it
<apritzel>
but then realised that we already somewhat claim that PRCM region via the CCU-R driver
<apritzel>
atm we limit its size to 0x210, which is just the last register used there
<apritzel>
so I was wondering if the PPU driver should be put into ccu-sun50i-h6-r.c
<jernej>
BSP code has two bits for Cedrus - bit 0 in reg 0 and bit 24 in reg 4
<apritzel>
does anyone have any pointer to some H616 PRCM documentation? I mean we know about the clock bits there, where did this info come from? smaeul, any hints?
<apritzel>
jernej: so both for VE?
<jernej>
I guess. There are following comments: "remapping SRAM to MACC for codec test" and "clear bootmode bit for give sram to ve" for bit 0 and bit 24, respectively
<jernej>
although I switched only first and it worked as far as I tested
<jernej>
definitvely some testing is needed
<apritzel>
so is it two independent bits? One to connect the VE to the SRAM, and the other to connect the CPU to the SRAM?
<apritzel>
so if you leave bit 24 on, you *could* disturb the VE memory from the CPU? But it doesn't hurt if you leave the access on, but just don't touch it?
<jernej>
I'm confused by the comments,
<jernej>
I've seen glitches when using AFBC compression, so maybe that's a reason?
<jernej>
*the reason
<apritzel>
so anyway we could just have two allwinner,sram elements in the VE DT node, and let them point to reg0x0/bit0 and reg0x4/bit24 in the SRAM (driver)?
<apritzel>
that should not disturb the thermal driver usage, I made sure they share the same lock, and thermal just asks for exactly only bit reg0x0/bit16
colinsane has quit []
<jernej>
ok, so bit 24 in reg 4 is usually associated with display engine
<jernej>
that's an easy test
<jernej>
and my confusion with clearing proper bits is understandable
<jernej>
there is different code between 4.9 and 5.4 based BSP
colinsane has joined #linux-sunxi
<jernej>
5.4 clears only bit 0, while 4.9 clears much more
<apritzel>
IIRC, clearing reg0x4/bit24 made all of SRAM C read-as-zero/write-ignore from the CPU. When setting the bit back, all the old content reappeared
<apritzel>
jernej: do you want any last minute change in there?
<apritzel>
but I guess we can fix any potential conflicts when the VE/DE patches appear?
<jernej>
no, it wasn't clear to me if I should also apply DT patch
<jernej>
I will, before I send PRs later today
<apritzel>
IIUC, that was Daniel's idea: he takes the code & bindings, you take the .dts patch
<jernej>
sure, but I can't see patches in linux-next
<apritzel>
I can poke him ...
macromorgan_ has joined #linux-sunxi
macromorgan_ has quit [Remote host closed the connection]
<apritzel>
done
macromorgan has quit [Ping timeout: 480 seconds]
macromorgan has joined #linux-sunxi
hitechshell has joined #linux-sunxi
hitechshell has quit []
nitechshell has joined #linux-sunxi
colinsane has quit []
nitechshell has quit []
bauen1 has quit [Ping timeout: 480 seconds]
colinsane has joined #linux-sunxi
hitechshell has joined #linux-sunxi
wingrime has joined #linux-sunxi
wingrime has quit []
wingrime-ww has joined #linux-sunxi
<wingrime-ww>
hi! anyone got Teclast P85T in fel mode?
<wingrime-ww>
dd
<wingrime-ww>
dd'ing toc0 to sdcard does not works, wonder why
hitechshell has quit []
hitechshell has joined #linux-sunxi
hitechshell has quit []
hitechshell has joined #linux-sunxi
hitechshell has quit [Quit: Page closed]
hitechshell has joined #linux-sunxi
<apritzel>
wingrime-ww: which toc0, exactly? fel-sdboot? or something nicked from some vendor image?
<hitechshell>
Hello. I successfully launched uboot, but usb does not work. After some searching I managed to find out that if I manually set the value 1 for the usb_det_vbus_gpio pin, then the usb starts working. device: pocketbook 614 plus
<hitechshell>
Can anyone tell me what I'm doing wrong?
hitechshell has quit []
hitechshell has joined #linux-sunxi
<apritzel>
wingrime-ww: I had it going into FEL mode with some fel-sdboot version a few weeks ago, but couldn't reproduce it last week. Will debug it this weekend.
<apritzel>
wingrime-ww: but I got my own code running from a TOC0 on SD card, and I managed to boot a boot0.toc0 isolated from a vendor image
<wingrime-ww>
apeitzel: I tried converted image from
<apritzel>
something internally connected, maybe? Like Wifi? We have seen this on some devices before
<hitechshell>
maybe. there is space on the board for a wifi module
<wingrime-ww>
apritzel: sd-card boot ignored, tablet goes to android boot, mkimage -A arm -T sunxi_toc0 -a 0x20060 -d sunxi-tools/bin/fel-sdboot.sunxi output.toc0
<wingrime-ww>
maybe I need fel-sdboot from vendor image&
<hitechshell>
apritzel: As far as I understand, the board understands that the wire is connected according to the state of the pin specified in CONFIG_USB0_VBUS_DET
<hitechshell>
but according to "gpio state -a" in uboot nothing changes when connecting/unplugging the cable
junari has joined #linux-sunxi
junari has quit [Remote host closed the connection]
warpme has quit []
<apritzel>
hitechshell: please note that this pin is not the ID det pin, but the VBUS detect pin. That's something internal that senses whether VBUS is supplied via the cable
<apritzel>
hitechshell: but the U-Boot code around this is particularly confusing, if not buggy. I need to have a closer look ...
<apritzel>
wingrime-ww: you need to write fel-sdboot.bin, otherwise it's double wrapped
<hitechshell>
apritzel: I looked at the code. checking the presence of a cable is to check the status of this pin
ity has quit [Remote host closed the connection]
ity has joined #linux-sunxi
<apritzel>
hitechshell: actually, do you want to use it in gadget mode, or in host mode?
<hitechshell>
at least in gadget mode (if I understand correctly, this is when the wire is connected from the computer to the device)
<hitechshell>
I managed to achieve this, but only by manually setting the state of this pin
<apritzel>
this pin is optional, I think, have you tried without it?
<hitechshell>
optional? no, I haven't tried it
bauen1 has joined #linux-sunxi
<hitechshell>
apritzel: Do you mean remove it from the config or even from devicetree?
<apritzel>
yeah, you can try both. You said "nothing changes when connecting/unplugging a cable": is there some host connected on the other end, supplying a VBUS voltage that the board could detect?
<hitechshell>
the other end of the wire is connected to the laptop
<apritzel>
and that GPIO is used as VBUS detect in the FEX file?
<apritzel>
wingrime-ww: ah, great, curious why this didn't work for me last week ...
<apritzel>
wingrime-ww: do you have any ambitions, plans or even patches for upstreaming?
<apritzel>
I am at offset 0xa74 for the clock driver
ungeskriptet is now known as Guest688
ungeskriptet has joined #linux-sunxi
Guest688 has quit [Ping timeout: 480 seconds]
vagrantc has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest689
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit []
ungeskriptet has joined #linux-sunxi
Guest689 has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit []
ungeskriptet has joined #linux-sunxi
hitechshell has quit [Remote host closed the connection]
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #linux-sunxi
ungeskriptet is now known as Guest696
ungeskriptet has joined #linux-sunxi
ungeskriptet has quit []
ungeskriptet has joined #linux-sunxi
Guest696 has quit [Ping timeout: 480 seconds]
ungeskriptet has quit []
ungeskriptet has joined #linux-sunxi
<apritzel>
wingrime-ww: are you sure the SID dump is correct? I think at least lcjs should have the secure boot bit set ...
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #linux-sunxi
<apritzel>
in previous experiments the FEL mode (entered this way) was non-secure, so the SID reads might be heavily filtered: all the later fuses read as zero