warpme_ has quit [Quit: Connection closed for inactivity]
apritzel has quit [Ping timeout: 260 seconds]
Mangy_Dog has quit [Ping timeout: 252 seconds]
elros1 has quit [Remote host closed the connection]
jstefanop has quit [Remote host closed the connection]
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 265 seconds]
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 246 seconds]
camus is now known as kaspter
kaspter has quit [Ping timeout: 260 seconds]
kaspter has joined #linux-sunxi
jstefanop has joined #linux-sunxi
victhor has quit [Ping timeout: 240 seconds]
jstefanop has quit [Ping timeout: 252 seconds]
<tuxd3v>
hello,
<tuxd3v>
the driver sun6i_csi can be used by allwiner H3 Soc?
buzzmarshall has quit [Remote host closed the connection]
tuxd3v has quit [Read error: Connection reset by peer]
tuxd3v_ has joined #linux-sunxi
ganbold has quit [Ping timeout: 252 seconds]
ganbold has joined #linux-sunxi
tuxd3v_ has quit [Quit: Leaving]
ganbold has quit [Ping timeout: 240 seconds]
tuxd3v has joined #linux-sunxi
gaston1980 has quit [Quit: Konversation terminated!]
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 260 seconds]
camus is now known as kaspter
ganbold has joined #linux-sunxi
pdp7 has quit [Excess Flood]
pdp7 has joined #linux-sunxi
<tuxd3v>
the driver sun6i_csi should be used by allwiner H3 Soc?
<smaeul>
apritzel: BROM adds some delays that may be important. starting at 0xa90c, you have 1/disable BGR, 2/enable BGR, 3/disable PHY, 4/enable PHY, 5/???, 6/wrapper w/USBPHY2 SIDDQ @ 0xaa54
<smaeul>
apritzel: from the SIDDQ setup, it looks like you probably need the whole PHY reference, not just the gates/resets
<smaeul>
oh, the fifth function (0xaa0c) is non-ISCR PHY setup. the ISCR bits start at 0x9bf4, but those may not be interesting
lucascastro has quit [Remote host closed the connection]
<plaes>
hash I posted earlier was commit from my own 5.11 branch
<gediz0x539>
I've even looked at gstreamer commits to find that :)
apritzel has quit [Ping timeout: 246 seconds]
<gediz0x539>
so it's better to use 5.11.6 at least, I assume
gediz539 has joined #linux-sunxi
gediz0x539 has quit [Ping timeout: 240 seconds]
uis_ has joined #linux-sunxi
uis has quit [Ping timeout: 240 seconds]
slapin has quit [Quit: Lost terminal]
montjoie has quit [Ping timeout: 240 seconds]
montjoie has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
prefixcactus has joined #linux-sunxi
kaspter has quit [Ping timeout: 268 seconds]
kaspter has joined #linux-sunxi
danqo has quit [Quit: Idle for 30+ days]
indy has quit [Ping timeout: 240 seconds]
indy has joined #linux-sunxi
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 268 seconds]
camus is now known as kaspter
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 260 seconds]
camus is now known as kaspter
jo0nas has quit [Read error: Connection reset by peer]
jo0nas has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
Mangy_Dog has quit [Changing host]
Mangy_Dog has joined #linux-sunxi
jstefanop has joined #linux-sunxi
victhor has joined #linux-sunxi
jstefanop has quit [Ping timeout: 240 seconds]
lkcl has quit [Quit: BNC by ##bnc4you]
lkcl has joined #linux-sunxi
indy has quit [Ping timeout: 260 seconds]
specing_ has joined #linux-sunxi
specing has quit [Ping timeout: 240 seconds]
specing_ is now known as specing
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 265 seconds]
apritzel has joined #linux-sunxi
lucascastro has quit [Ping timeout: 240 seconds]
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-sunxi
indy has joined #linux-sunxi
<ndufresne>
gediz539: atm the situation is that for 1.18 you need 5.9 or less, and for gstreamer master (upcoming 1.20) it will be 5.11 and more for H264 decode
<ndufresne>
for VP8, we'll see the timing, but 1.20 might be set to 5.13 (the final API is lending there)
<ndufresne>
mpeg2 made it final to 5.14, just few days late for 5.13
luke-jr has joined #linux-sunxi
<ndufresne>
HEVC and VP9 are pending, but upstream work is progressing well
<ndufresne>
gediz539: note that with 1.20 + 5.11+, you get much better performance, lower CPU utilisation, better throughput
indy has quit [Ping timeout: 252 seconds]
<gediz539>
ndufresne: actually i was thinking about 1.20 + 5.11+ scenario. it makes it even clear for me to hear this from you. thanks a lot.
gaston1980 has joined #linux-sunxi
tnovotny has quit [Read error: Connection reset by peer]
tnovotny has joined #linux-sunxi
indy has joined #linux-sunxi
elros1 has joined #linux-sunxi
Net147 has quit [Ping timeout: 252 seconds]
Net147 has joined #linux-sunxi
jstefanop has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
choozy has joined #linux-sunxi
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
cmeerw has joined #linux-sunxi
tnovotny has quit [Quit: Leaving]
vagrantc has joined #linux-sunxi
indy has quit [Ping timeout: 240 seconds]
specing has quit [Ping timeout: 260 seconds]
indy has joined #linux-sunxi
indy has quit [Ping timeout: 240 seconds]
indy has joined #linux-sunxi
indy has quit [Excess Flood]
indy has joined #linux-sunxi
lucascastro has joined #linux-sunxi
indy has quit [Excess Flood]
indy has joined #linux-sunxi
<vagrantc>
for crust-firmware, can the pine64-lts use the pine64_plus target, or is it different enough to warrant it's own config?
prefixcactus has quit [Ping timeout: 240 seconds]
<jernej>
I think it's safe
gsz has joined #linux-sunxi
<apritzel>
vagrantc: the pine64_plus_defconfig just says that it has an AXP, which is true for both
<vagrantc>
hah, didn't realize those configs were so short :)
<tuxd3v>
mripard, many thanks :)
specing has joined #linux-sunxi
Jin^eLD has joined #linux-sunxi
<Jin^eLD>
hi, does anyone happen to have a device tree for the old cubietruck to enable spi? I have pretty much zero experience with lower level/hardware stuff, so if anyone got his spi going with mainline and has the dts around I'd be super greatful :>
<vagrantc>
if you're not running a linux kernel with the patches for crust and you've got crust loaded ... will terrible things happen? or will crust just not work?
<Jin^eLD>
apritzel: ah... so I should be looking for some spi*_pb_pins?
<apritzel>
Jin^eLD: weird, that doesn't match up with the dtsi, let me double check
<apritzel>
try the spi2_pb_pins and friends
<apritzel>
and it seems to SPI2
<Jin^eLD>
so everything like in the sun7i-a20-pcduino3.dts from the wiki, but with spi2_pb_pins instead?
<apritzel>
Jin^eLD: seems like sun7i-a20-hummingbird.dts has exactly what you need
<Jin^eLD>
looking at it
<Jin^eLD>
it has less than I thought was needed
<Jin^eLD>
let me just try :)
<apritzel>
it seems like the Cubietruck exposes *both* SPI2 pin sets, the PC one at pins 5-8, and the PB one at pins 9-12
<apritzel>
Jin^eLD: the SPI0 naming on the connector is a bit confusing, maybe it means "the first SPI port on the Cubietruck"?
<Jin^eLD>
I honestly have no idea, I looked at the image in the first link and also in the wiki and then a friend of mine told me what pins on the adxl go to which spi pin since I honestly have not the slightest clue about hardware
<Jin^eLD>
once the adxl driver did not actually do anything I realized spi is not enabled by default :) that's how I got to the dts thing
<Jin^eLD>
but of course trying the patch from the wiki for another board was a bit too naive and optimstic
<vagrantc>
apritzel: does suspend happen to be one of those advanced features?
hlauer has joined #linux-sunxi
<apritzel>
vagrantc: haven't tried that, there is some suspend support in TF-A, smaeul should be able to answer that
<vagrantc>
working on integrating into debian's u-boot packages (although someone else already packaged crust) ... and also packaging crust for guix
<apritzel>
Jin^eLD: seems like you need to describe the adxl in the DT as well, compare the example in Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
<Jin^eLD>
oh
<apritzel>
Jin^eLD: spi0 is spi2 in your case, and you need to add this pinctrl property as well
<apritzel>
Jin^eLD: so like the SPI node from hummingbird, with an accelerometer subnode from the example
<Jin^eLD>
the pinctrl is just as in the hummingbird? that's what I have so far, will now try to add the accel thing https://paste.ee/p/3we0y
<apritzel>
yes, you need to marry the Allwinner SPI controller driver to your accelerator driver somehow
mnemoc has quit [Ping timeout: 245 seconds]
menomc has joined #linux-sunxi
jernej has quit [Ping timeout: 250 seconds]
<apritzel>
and you do exactly that by placing the adxl subnode inside the SPI node
elros1 has quit [Read error: Connection reset by peer]
<apritzel>
vagrantc: suspend is typically not the problem, btw, it's resuming that is tricky :-D
buzzmarshall has joined #linux-sunxi
<Jin^eLD>
apritzel: do I need the includes from the example as well?
<apritzel>
Jin^eLD: those should be already in
<vagrantc>
apritzel: yes, i suppose i do need *both* to work well. :)
<Jin^eLD>
does this make any sense? https://paste.ee/p/6IEeK I really have no idea what I am doing there
<apritzel>
Jin^eLD: somewhat, I'd remove the two interrupt properties for now
<apritzel>
Jin^eLD: do you have an extra interrupt line coming from the adxl to the connector?
<apritzel>
(in addition to the four SPI pins)
<Jin^eLD>
no, only the spi pins
<Jin^eLD>
ok so getting rid of the interrupts
<Jin^eLD>
compiling...
<apritzel>
yes, otherwise looks good, just hope that the adxl driver doesn't depend on interrupts
<smaeul>
vagrantc: boot/shutdown should work without any Linux patches. suspend to/resume from "deep" mem sleep will not. s2idle will still work, but "deep" the default option for /sys/power/mem_sleep if it is available
<smaeul>
this is assuming you have CONFIG_SUN6I_MSGBOX enabled/loaded. otherwise, shutdown/reboot will be broken
<smaeul>
vagrantc: defconfigs are pretty simple. if you send me a list of boards, I can add them (or you can open an issue/PR)
<vagrantc>
smaeul: many thanks!
<smaeul>
mripard: it seems that protected-clocks will not be accepted. do you have a suggestion on how to move forward? different binding? CLK_IS_CRITICAL in CCU driver? add hwspinlocks to CCU driver and have the CPUs fight over the clock gate?
<vagrantc>
it's a bit difficult to get patches into debian that haven't at least landed in linux-next, but if they're small enough i can try
<smaeul>
yeah, that makes sense. the clock changes have been sitting out there for a couple of years, and are the only remaining blocker, so hopefully we can figure out a solution
<smaeul>
for R_TWD, another option would be to remove it from the CCU driver entirely -- since it is secure-only, Linux can never use it anyway
kaspter has quit [Ping timeout: 252 seconds]
camus has joined #linux-sunxi
camus is now known as kaspter
ats_ is now known as ats
gaston1980 has quit [Quit: Konversation terminated!]