<hanetzer>
yes, I've eyballed the latter, but a link I'm interested in is dead or sommat
<plaes>
yeah.. but if you follow the "Progress history" section, you can see how things moved...
<plaes>
an effort of lot of people over span of multiple years
<hanetzer>
and I'm literally the only person messing with this :/
<plaes>
well, there needs to be one :)
BenG83 has quit [Quit: Leaving]
f0xx has quit [Ping timeout: 256 seconds]
Hao__ has quit [Ping timeout: 240 seconds]
Hao__ has joined #linux-sunxi
solarnetone has joined #linux-sunxi
<wens>
plaes: likely
<wens>
the point being the interrupt line *is* documented
<wens>
just not the interrupt status bits
<plaes>
oh..
<plaes>
missed that *bit* ;)
paulk-collins has joined #linux-sunxi
dave0x6d has quit [Quit: Connection closed for inactivity]
<Hao__>
e... :<
<Hao__>
Dose someone use the rtl8188cus or rtl8187 on kernel 3.10.y?
<Hao__>
it seem something unstable on it
<plaes>
why do you need 3.10?
<Hao__>
when i ping to router it always loss packet...
Andy-D has quit [Ping timeout: 240 seconds]
<Ke>
I would be hoping for standard hostapd compilant ap mode on same family chips
<Ke>
if anyone knows some 5GHz capable chip that can do off the shelf AP mode on linux
massi has joined #linux-sunxi
jstein_ has joined #linux-sunxi
<IgorPec>
Ke: atheros ath9k, mostly avaliable on mpci
<Hao__>
plaes cause the sdk is 3.10......
<Hao__>
plaes it is not allwinner soc ....
<Ke>
IgorPec: oh right, I wanted USB
<Ke>
IgorPec: I have already ath pci chip
<Hao__>
plaes the soc of hisilicon
jstein_ is now known as jstein
<IgorPec>
Ke: that is extremly hard to find
<Ke>
realtek can do, but with patched hostapd
<IgorPec>
which realtek?
<plaes>
Hao__: out Wifi page in wiki is somewhat outdated
<plaes>
s/out/our
<plaes>
it would be nice if you could look up Hans de Goede'semail to mailinglist about various wifi chips and update it with the info he had in his email
<Ke>
IgorPec: almost all of them seem to come with hostapd code, I haven't investigated whether it actually works, if that is your point?
<plaes>
Hao__, hanetzer - and create #linux-hisilicon channel...
<IgorPec>
yes, i mean if you find any good working one by? 8812au was promising but it has been some time when I play with those wifi chips
Worf has joined #linux-sunxi
<Ke>
IgorPec: I am not that keen on playing with their custom hostapd that would not get security updates or anything
<hanetzer>
Hao__: oh hey! which hisilicon soc?
Mr__Anderson has joined #linux-sunxi
<Hao__>
plaes : if someting has fixed , would it be merge into longterm 3.10 ?
<plaes>
Hao__: Hans's email was mostly about out-of-tree repositories :(
<Hao__>
hanetzer : hi3520dv300
<hanetzer>
Hao__: oh, that's the same as mine basically. hi3521av100
matthias_bgg has joined #linux-sunxi
<Ke>
IgorPec: yeah 5GHz can also be a problem, but you can see that on the specs
<IgorPec>
Ke: specs usually doesn't meet reality :) Well, so far I only have solid 5Ghz AP on atheros ... client also on Intel and one Broadcomm
<Ke>
I was actually tempted to buy the 60€ USB wifi from ipTIME...
<IgorPec>
and the other problem is / can be also my router. none of my conclusions have much scientific value
<IgorPec>
what is chipset at that ipTime?
<Ke>
one of the brcmfmac ones
<IgorPec>
you need to do close study. some chips, intel for example, disabled 5ghz AP mode in firmware ... and you can't do shit
BenG83 has joined #linux-sunxi
<hanetzer>
Hao__: do you have any reverse engineering skills?
<tkaiser>
hanetzer: (not only) nove asked himselve whether most recent Allwinner SoCs are only on SBC now. And it seems not. Some low-end TV boxes for Chinese market seem to exist using H5. And maybe R40 can be found in stupid^Wsmart things like 'smart speakers' and stuff like that.
<hanetzer>
Hao__: I've been working on getting hi3521a mainlined, which means no need to stick to old kernels
<Hao__>
hanetzer: oh, good jobs, sometime i also want to getting hi3520 to mainline :)
<hanetzer>
Hao__: our two chips are the same, just a different package. yours is lqfp256, no?
<Hao__>
hanetzer : i has hi3520dv300/ hi3520dv300 /hi3518
<BenG83>
moin moin
<hanetzer>
moin
<hanetzer>
Hao__: I have 4.1x.x booting on hi3521av100, but drivers.
<Ke>
tkaiser: well anyway tell me the results, I am not sure the direction of data tranfer was correct in that expression...
<tkaiser>
Ke: Check Armbian free forum in a week, there's a huge rant of mine regarding the onboard Wi-Fi crap on SBC and I'll add then results with dual-band, dual-antenna sticks using Ralink RT5572 and the RTL above
chlorine has joined #linux-sunxi
<Hao__>
hanetzer : those soc support Image&video processing , it seem a troublesome job to getting driver support on mainline kernel ... :(
<hanetzer>
Hao__: yep, for exactly that reason. 29 blob kernel modules to deal with.
<Hao__>
hanetzer : yep, my hi3520dv300 is lqfp256 :)
<IgorPec>
tkaiser: mine is noname and it looks like at least 2x2 mimo
<tkaiser>
IgorPec: Hmm, then performance is pretty bad since with 2x2 mimo and HT20 even el cheapo RTL8192CU sticks perform better (see the TP-Link results: https://forum.armbian.com/index.php?/topic/3739-wi-fi-performance-and-known-issues-on-sbc/ )
<tkaiser>
IgorPec: I will focus with next round of tests on distance with 2.4GHz (HT20 only) and performance/distance with 5GHz (trying wider channel settings too). Only 802.11n and skipping 802.11ac since useless with SBC anyway
<KotCzarny>
'even el cheapo RTL8192CU sticks perform better' aahhahaha
<IgorPec>
well, I would say the same.
silviop has joined #linux-sunxi
<IgorPec>
and this 8812au you can get for 10 USD so they are considered el cheapo too :)
<KotCzarny>
i think i was getting pretty decent speeds from 8192cu. when it was working though
<IgorPec>
the one tkaiser choose, has better areal which should help in certain cases
<tkaiser>
IgorPec: always 'use case' first. 50cm away from AP might be interesting to test maximum throughput but things get interesting over larger distances. And then antennas start to matter and also MIMO if available. And the ability to leave 2.4Ghz band and enter 5GHz of course.
<IgorPec>
i am unable to test 5Ghz at the moment :(
<KotCzarny>
test them in the basement? ;)(
<tkaiser>
IgorPec: And just 50cm might be not far enough, better test with 1-2m also ;)
mfratello has joined #linux-sunxi
<mfratello>
hi all
<mfratello>
i managed to build uboot for the licheepi from this repository
techping has quit [Remote host closed the connection]
wzyy2 has quit [Ping timeout: 260 seconds]
alsy has quit [Ping timeout: 268 seconds]
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
chlorine has quit [Ping timeout: 260 seconds]
swiftgeek has quit [Ping timeout: 240 seconds]
Hao__ has quit [Remote host closed the connection]
Mr__Anderson has quit [Ping timeout: 258 seconds]
swiftgeek has joined #linux-sunxi
Hao_ has joined #linux-sunxi
JohnDoe71rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
yann-kaelig has joined #linux-sunxi
akaWolf1 has joined #linux-sunxi
swiftgeek has quit [Ping timeout: 260 seconds]
<MoeIcenowy>
qschulz: I suggest you add a clock property to sun4i-gpadc iio device tree binding
<qschulz>
MoeIcenowy: can I have a bit of context?
<MoeIcenowy>
your A33 THS patchset
<MoeIcenowy>
for A33 osc24M and audio pll should be feed
<MoeIcenowy>
(but I didn't find how to switch clock source for A33...
<qschulz>
why?
swiftgeek has joined #linux-sunxi
<MoeIcenowy>
qschulz: I'm trying to add H3 support to it
<MoeIcenowy>
and for H3 a real mod clock is used as clock in
<MoeIcenowy>
for A33 there's also a clock input for ADC, but not a dedicated mod clock
<MoeIcenowy>
according to your code you assumed it's osc24M
komunista has joined #linux-sunxi
<MoeIcenowy>
oh for H3+ the clock divider is moved from ths to ccu
<silviop>
what is the A33 DSI-MPI support situation ?
<silviop>
there is someone working ?
<MoeIcenowy>
silviop: nothing working...
<silviop>
i read bsp source code , medium-low level complex for a coder
perr has joined #linux-sunxi
perr has quit [Changing host]
perr has joined #linux-sunxi
<wens>
someone might be working on it
[7] has quit [Remote host closed the connection]
<mripard>
I am
<mripard>
but it's kind of low priority
<silviop>
do you have code to test ? i have a A33 tablet with lcd_if=4
<silviop>
u-boot and kernel are ok but not video (obviously)
<qschulz>
MoeIcenowy: ACK, ping me if I haven't sent anything til Friday
<mripard>
I have some code, but it's not functional
<MoeIcenowy>
qschulz: seems to be not needed
<MoeIcenowy>
as the clock divider is configured in CCU on H3+ (or maybe A83T+)
<MoeIcenowy>
but in A33 it's in THS
<MoeIcenowy>
mripard: have you seen my AR100 measurement?
<mripard>
no
<mripard>
I'm away most of today, please send an email
<MoeIcenowy>
sent yesterday
<qschulz>
MoeIcenowy: yes, a default divider is set in the driver, but there is no clock selection in the datasheet
<MoeIcenowy>
(yesterday in your timezone)
<MoeIcenowy>
qschulz: yes so we can assume it can only use osc24M
<qschulz>
MoeIcenowy: I'll have to check in allwinner source code
raknaz[m] has joined #linux-sunxi
<silviop>
mripard: Clock init or tcon registry init ?
chlorine has joined #linux-sunxi
<MoeIcenowy>
qschulz: I will do some development for H3 based on your current code.
<qschulz>
MoeIcenowy: on the code I sent for A33 or the one that has been merged?
<MoeIcenowy>
you sent for A33
<MoeIcenowy>
it's a framework for thermal-only ADCs
<MoeIcenowy>
but if you send anything new I will rebase it
<MoeIcenowy>
P.S. for this binding it seems to be not so suitable to be placed under bindings/mfd/
<MoeIcenowy>
bindings/iio/adc/ is better for the thermal part
<MoeIcenowy>
maybe you should place (move?) A10/13/20/31 binding in bindings/mfd/
<MoeIcenowy>
then place A33 in bindings/iio/adc/
<qschulz>
for me, same driver, same IP, makes no sense to split it in two different places
techping has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
<MoeIcenowy>
but the A33 part also makes no sense to be placed in bindings/mfd/
<mripard>
silviop: I don't know
<MoeIcenowy>
as it have even no MFD part
<qschulz>
we discussed this at the office and found this was the best compromise
<qschulz>
if you have a different opinion, feel free to start a discussion on the mailing list :)
<MoeIcenowy>
ok it's also acceptable
<MoeIcenowy>
although it seems a bit confusing to users
<qschulz>
we didn't want to split the doc
<qschulz>
so either you have everything in mfd or in iio
<qschulz>
in both cases, something's wrong and we decided it makes more sense yet to put everything in mfd as there is support for three SoCs via MFD and one via IIO directly
TheSeven has joined #linux-sunxi
<MoeIcenowy>
qschulz: furtherly we will have support for 3 SoCs via MFD but more and more SoCs via IIO directly
<MoeIcenowy>
after A33 we have H3, after H3 we have A83T/A64
<MoeIcenowy>
and H5
wzyy2 has joined #linux-sunxi
chomwitt has quit [Ping timeout: 258 seconds]
<qschulz>
MoeIcenowy: feel free to send a mail to the mailing list, really. I'll not change this if there is no "opposition" on this. Maybe your argument will make more sense for the maintainer
kloczek has joined #linux-sunxi
kloczek has left #linux-sunxi [#linux-sunxi]
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
FergusL has quit [Remote host closed the connection]
FergusL has joined #linux-sunxi
victhor has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
FergusL has quit [Remote host closed the connection]
<tkaiser>
KotCzarny: ever searched for 'TBD' in another Allwinner manual ;) But at least last XR819 miracle solved. We're not talking about 130Mbps but just the half and 20-22 Mbits/sec will be the maximum achievable at TCP/IP layer.
<KotCzarny>
yeah, and that's in favorable conditions
<tkaiser>
KotCzarny: And in TX direction half of the packets got lost with older driver variant. Maybe that will change with the more recent code drop but I doubt it :)
<tkaiser>
jelle: Icenowy did something back and dgp and here you find discussion about re-using cw1200 mainline driver: https://forum.armbian.com/index.php?/topic/3243-orange-pi-zero-wireless-module-status-xradio-st-cw1200/&
<MoeIcenowy>
for single antenna of course we cannot have 130Mbps ;-)
<MoeIcenowy>
I remember 130Mbps is the maximum MIMO speed of 802.11n
<tkaiser>
MoeIcenowy: Yep, you're right. So XR819 should be able to reach 40-45 Mbits/sec but no one measured anything above 20 Mbits/sec so far. But hey, why think about performance at all with these designs :)
Worf has quit [Quit: Konversation terminated!]
<MoeIcenowy>
maybe we need an external USB 2.0 802.11ac card? ;-)
<BenG83>
lol
alsy has quit [Read error: Connection reset by peer]
JohnDoe71rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
chlorine has quit [Remote host closed the connection]
<tkaiser>
MoeIcenowy: If I'm after performance I always choose USB3 stuff even if SuperSpeed data lines aren't used. Since 'made for performance' and better chances to avoid crappy hardware ;)
<BenG83>
does anyone know where to source ampak wifi modules in single quantities?
<willmore>
I don't care if the XR819 can only manage 802.11b speeds. The thing about it that killed its usefullness to me was the huge packet loss which caused all kinds of pauses and latency issues when trying to ssh to it over wireless.
alsy has quit [Read error: Connection reset by peer]
alsy2 has joined #linux-sunxi
<willmore>
Others may, of course, feel differently.
<willmore>
Then again, I didn't need the wireless on the Orange Pi Zero anyway. I prefer wired network connections.
<willmore>
BenG83, I can't find that in small quantity. I did see that there may be some USB WiFi adapters that use them. Maybe find one of those and harvest the chip out of it?
<jernej>
I understand it differently, because manual never mentions DE2 as multiple units
<jernej>
but I concur with your view
<MoeIcenowy>
as manual does not want to tell you the details about DE2
<BenG83>
there is a manual for DE2?
<MoeIcenowy>
BenG83: nope
<MoeIcenowy>
at least nothing publicly available
<BenG83>
ok
<MoeIcenowy>
everything we did is based on the analyze to public codes
<BenG83>
btw how did the follow-up from your visit to AW with Tl work out?
<BenG83>
did anything get answered?
<MoeIcenowy>
nothing about DE2
<jernej>
lets hope Allwinner releases DE2 under GPL as promised
<BenG83>
the BSP stuff?
<jernej>
yes
<BenG83>
I think on that part Tl can push some buttons if it's only missing headers
<BenG83>
I don't think he had any luck about the binary blobs
<MoeIcenowy>
P.S. and for A64 we have a more severe problem than DE2 -- PRCM CCU
<MoeIcenowy>
without PRCM CCU we can use no peripherals in 0x01fxxxxx except RTC
<MoeIcenowy>
that includes RSB, which is the most critical
<BenG83>
that is Power and Reset Control Clock Control Unit?
<MoeIcenowy>
BenG83: yes
<MoeIcenowy>
oh RSB is not the most critical now -- the most critical is R_PIO
<BenG83>
peripherals controlled by the ARISC?
<MoeIcenowy>
BenG83: ARISC and ARM can controll all non-PRCM and PRCM peripherals
<jernej>
MoeIcenowy: Now that U-Boot video code is mostly acked, I will focus on kernel driver
<MoeIcenowy>
and it seems that without proper R_PIO we cannot use r8732bs stably
<BenG83>
are those the same peripherals that are mentioned in the UM as S_ ?
<MoeIcenowy>
BenG83: yes
<BenG83>
ah ok
<MoeIcenowy>
and the "Port Controller (CPUs-Port)"
<BenG83>
CPUs is the ARISC?
<MoeIcenowy>
yes
<BenG83>
ok I just had some things fall into place for me
<MoeIcenowy>
oh seems not the same
<MoeIcenowy>
CPUs is a power unit on the SoC
<MoeIcenowy>
which contains several peripherals and the ARISC core
<BenG83>
I saw that there is this CPUs UART on some test pads on the SOPine modules
<MoeIcenowy>
CPUs UART is in fact wired onto the Wi-Fi module slot on Pine64
<MoeIcenowy>
and used as GPIOs
<jernej>
MoeIcenowy: But as you already suggested, I will first try to enable TV out driver on H3
<BenG83>
and the CCU info is important to gate/configure clocks to those modules?
<MoeIcenowy>
BenG83: yes
<MoeIcenowy>
and the R_PIO has also a clock gate
<BenG83>
how does this happen in BSP?
<MoeIcenowy>
BenG83: in BSP these clocks are in clk-sun50iw1.c
<BenG83>
ok
<BenG83>
sorry for the all the questions I just want to understand where the problem exactly is :)
<MoeIcenowy>
no need for sorry ;-)
<BenG83>
so there is info missing that can not be learned from the BSP sources?
|Jeroen| has joined #linux-sunxi
komunista has quit [Quit: Leaving.]
<MoeIcenowy>
jernej: I will try renew the DE2 driver after a sleep.
<MoeIcenowy>
but it's now nearly 3 am here
<jernej>
MoeIcenowy: Great! Next week I will have a lot of time so I hope I will make some progress
<jernej>
uh, better go to sleep :)
<MoeIcenowy>
P.S. jernej: do you have Pine64, FEL cable for Pine64, UART access to Pine64, a set of OpenRISC cross-compiler and a set of ARM 32-bit cross-compiler?
Ntemis has joined #linux-sunxi
<jernej>
everything except OpenRISC compiler
<MoeIcenowy>
ok can you get it? ;-)
<MoeIcenowy>
(I want to find someone to help me to ensure that the MUX 3 of AR100 clock on A64 is 11MHz or 12MHz ;-)
<BenG83>
how do you measure that?
<BenG83>
I guess toggling a pin is out of the question because no GPIO access?
<MoeIcenowy>
BenG83: by running a program on ARISC
<MoeIcenowy>
ARISC have of course GPIO access ;-)
<BenG83>
ok
<MoeIcenowy>
BenG83: I remember your distro is Gentoo? I think it's easy to build a cross tool on gentoo ;-)
<MoeIcenowy>
oh root permission is needed for FEL ;-)
<MoeIcenowy>
it will generate a long output on UART0, but the frequency number after "Set clock source to Internal OSC ...done" is the most important one
<vinimac>
ssvb, hi
<ssvb>
hi vinimac
<vinimac>
ssvb, Mark is ignoring completely the latest emails. What do you think?
<ssvb>
vinimac: ah, sorry, I'm also "ignoring" you, I should have replied sooner
<ssvb>
will do something today
<vinimac>
well, i will not submit a new patch until he gives some feedback
<vinimac>
about we discuss
apritzel has joined #linux-sunxi
<ssvb>
and we will have to wait like 2 years or so, while the mainline kernel is shipping crap to its users
Nacho_ has joined #linux-sunxi
<ssvb>
a fix for the SPI message size bug was submitted in 2014, but only applied in 2016 for sun4i/sun5i and in 2017 for sun6i+
<ssvb>
they are slowpokes and we can't do much about this
Nacho has quit [Ping timeout: 264 seconds]
<vinimac>
wow, it is long time to wait
<ssvb>
yes, unless we gently poke them
alsy2 has quit [Ping timeout: 268 seconds]
<vinimac>
well, you probably noticed that I don't much experience submitting patches. Maybe if you submit the patch, so you could do a more acceptable patch, given your experience
alsy has joined #linux-sunxi
<vinimac>
of course, of course, a single patch as Mark said, for sun7i and sun6i
<ssvb>
well, the linux kernel is one of the most unpleasant open source projects to work with, there are way too many freaks with huge ego
<jernej>
apritzel: If DM_I2C dependency is removed in drivers/video/Kconfig, line 358, it compiles successfully without a warning, but I'm not sure if that breaks something
<apritzel>
jernej: yeah, technically it needs to be sorted which boards actually needs I2C and which not
<apritzel>
jernej: is that a per video device decision?
<apritzel>
like Tegra needs it, Rockchip not?
<jernej>
dependencies are as following: CONFIG_DISPLAY -> I2C_EDID -> DM_I2C
<jernej>
trouble is, that DISPLAY option is used basically with all boards which implements DM video driver
mzki has quit [Ping timeout: 240 seconds]
<jernej>
because it is part of video framework
<apritzel>
I see that, but this doesn't seem to be true, entirely
<apritzel>
as sunxi doesn't need it, for instance
<apritzel>
if it's only for sunxi, I guess it doesn't make too much sense to fix it
<jernej>
I2C_EDID simbol is uses by edid parsing code and i2c command
<jernej>
but edid doesn't use I2C calls at all and i2c command knows to use old style i2c interface
<apritzel>
so the dependency is wrong then ...
Hao__ has quit [Ping timeout: 256 seconds]
<apritzel>
is EDID based on I2C (on the pins, I mean)?
<apritzel>
like SMBus?
<jernej>
something like that
<apritzel>
I see
<apritzel>
but it's actually the DE2 which is handling that, not some I2C IP on the SoC, right?
lurchi__ is now known as lurchi_
<jernej>
actually, edid are timing informations, which are read over DDC channel, which has (limited) I2C capabilities
<jernej>
this is domain of HDMI controller, so technically not DE2
<apritzel>
ah, right
<apritzel>
but anyway not the Allwinner I2C blocks?
<apritzel>
this video stuff is really mind-boggling ...
lkcl has quit [Ping timeout: 246 seconds]
<jernej>
no, dw hdmi controller has it's own DDC core inside, so no need for separate I2C bus
mzki has joined #linux-sunxi
<jernej>
at first, yes, but over time things become more clear :) as with anything
<apritzel>
that's true!
<jernej>
I found some other issues with edid parsing. apritzel, should I include patch which remove DM_I2C dependency?
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
<apritzel>
jernej: if you like and have the time, that would be great