rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi - *only registered users can talk*
pmpp has joined #linux-sunxi
jstein has quit [Quit: quit]
pmp-p has quit [Ping timeout: 252 seconds]
Mangy_Dog has quit [Ping timeout: 276 seconds]
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #linux-sunxi
florian_kc has quit [Ping timeout: 250 seconds]
vagrantc has quit [Quit: leaving]
lurchi_ is now known as lurchi__
gaston1980 has quit [Quit: Konversation terminated!]
lurchi__ is now known as lurchi_
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 245 seconds]
ChriChri_ is now known as ChriChri
Da_Coynul has quit [Quit: Textual IRC Client: www.textualapp.com]
<megi> looks like vsync/hsync polarity is reversed in CSI driver
<megi> wrote a driver for gc2145 and configured/measured hsync/vsync polarity, and it only shows video on screen if I reverse the polarity on camera side compare to what would look proper
<megi> if rising then set to falling, heh
<megi> not sure how nobody noticed this yet
<megi> or maybe I'm missing something? :)
<megi> I guess not, since just a few lines below, the same code is reversed again
<megi> it's just bugged
<anarsoul> :)
<megi> now, let's break all those out-of-tree users by making this right :)
<anarsoul> beware pinephone devs?
<megi> I guess I'll be nice and let them know ;)
kaspter has quit [Quit: kaspter]
lurchi_ is now known as lurchi__
kaspter has joined #linux-sunxi
juri_ has quit [Ping timeout: 265 seconds]
juri_ has joined #linux-sunxi
DonkeyHotei has quit [Read error: Connection timed out]
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 250 seconds]
ChriChri_ is now known as ChriChri
kaspter has quit [Ping timeout: 265 seconds]
kaspter has joined #linux-sunxi
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 276 seconds]
camus is now known as kaspter
skiboy has joined #linux-sunxi
sunshavi has quit [Ping timeout: 265 seconds]
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 276 seconds]
camus is now known as kaspter
tllim has joined #linux-sunxi
<tllim> @megi, thanks on bring up GC2145 driver. Thumbs Up !
<megi> :)
<megi> it's starting to show signs of life
<wens> where is this used? pinephone?
<wens> I have a gc2035 which I never got around to working on
<megi> testing image works, and I already saw myself in the cam, now I'm poking around in the registers trying to figure out undocummented bits
<megi> wens: it's pretty much the same, aside from some minor differences
TheSeven has quit [Ping timeout: 252 seconds]
<wens> google produced a datasheet with register defs
TheSeven has joined #linux-sunxi
<megi> yeah, if you can understand what things do just from the register names, you can call that documentation
<wens> megi: I wonder what they tweak in between these revisions
<megi> for example some values are multiplied by 8 and some by 16
<megi> between revisions
<megi> that's what I noticed so far
<megi> I also have a gc2035 cam around for my orange pi pc
<wens> annoying differences :/
<wens> makes driver sharing all the more harder
<megi> so I'll test that too
<megi> not that much, in this case
<megi> wens: gc2145 is used in tbs tablet, that also has dts mainline, gc2035 is in PP and also sold as a cheap cam for orange pis
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 265 seconds]
camus is now known as kaspter
DonkeyHotei has joined #linux-sunxi
<wens> yeah, I have the orange pi cam
skiboy_ has joined #linux-sunxi
<tllim> Both PineTab and PinePhone are using GC2145 as front camera, OV5640 as rear camera.
skiboy has quit [Ping timeout: 265 seconds]
sunshavi has joined #linux-sunxi
dddddd has quit [Remote host closed the connection]
<megi> tllim: interesting, I got my info from here https://www.pine64.org/pinephone/ this says gc2035
<tllim> original plan is GC2035 but already switch to GC2145
<tllim> advise from vendor due to GC2035 already EoL
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 265 seconds]
camus is now known as kaspter
tuxd3v has quit [Quit: Leaving]
jonasbits has quit [Ping timeout: 252 seconds]
jonasbits has joined #linux-sunxi
megi has quit [Ping timeout: 246 seconds]
chewitt has quit [Quit: Adios!]
ScrumpyJack has quit [*.net *.split]
azend|vps has quit [*.net *.split]
samueldr has quit [*.net *.split]
samueldr has joined #linux-sunxi
azend|vps has joined #linux-sunxi
ScrumpyJack has joined #linux-sunxi
reinforce has joined #linux-sunxi
selfbg has joined #linux-sunxi
pmpp is now known as pmp-p
BenG83 has quit [Remote host closed the connection]
BenG83 has joined #linux-sunxi
airstorm has joined #linux-sunxi
ldevulder__ is now known as ldevulder
florian_kc has joined #linux-sunxi
florian_kc has quit [Ping timeout: 246 seconds]
skiboy_ has quit [Ping timeout: 265 seconds]
skiboy_ has joined #linux-sunxi
vagrantc has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
tnovotny has joined #linux-sunxi
suprothunderbolt has quit [Ping timeout: 265 seconds]
BenG83 has quit [Quit: Leaving]
nexgen has joined #linux-sunxi
ganbold has quit [Remote host closed the connection]
gaston1980 has joined #linux-sunxi
nexgen has quit [Ping timeout: 250 seconds]
nashpa has quit [Ping timeout: 250 seconds]
x5eb has joined #linux-sunxi
_0x5eb_ has quit [Ping timeout: 245 seconds]
x5eb is now known as _0x5eb_
tllim has quit [Read error: Connection reset by peer]
AneoX has joined #linux-sunxi
nashpa has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
florian has joined #linux-sunxi
diego_r has joined #linux-sunxi
alexxy[home] is now known as alexxy
Alexis3D has joined #linux-sunxi
Alexis3D has left #linux-sunxi [#linux-sunxi]
ldevulder_ has joined #linux-sunxi
ldevulder has quit [Ping timeout: 276 seconds]
Alexis3D1 has joined #linux-sunxi
Alexis3D1 is now known as Alexis3D
Alexis3D1 has joined #linux-sunxi
Alexis3D has quit [Ping timeout: 245 seconds]
Alexis3D1 is now known as Alexis3D
pmpp has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
pmp-p has quit [Ping timeout: 240 seconds]
pmpp has quit [Ping timeout: 240 seconds]
Alexis3D has quit [Quit: BRB]
lurchi__ is now known as lurchi_
megi has joined #linux-sunxi
florian_kc has joined #linux-sunxi
swiftgeek has joined #linux-sunxi
<swiftgeek> Is there Anything for linux to check uart error rate ?
skiboy_ has quit [Ping timeout: 246 seconds]
<mru> using a parity bit or what?
<KotCzarny> write your own?
<KotCzarny> transfer 10MB, check how many bytes are wrong
<KotCzarny> :)
<swiftgeek> mru: loopback/using several adapters
<mru> send a bunch of data, compare received to sent
<megi> KotCzarny: may not be as simple as that, as different data patterns may result in different error rates
<swiftgeek> sure but nobody till now wrote a tool that would handle that? :D
<KotCzarny> transfer few 10MB files with different patterns
<mru> so send "typical" data
<swiftgeek> lol
<mru> "cat" and "cmp" not good enough for you?
<swiftgeek> same could be applied to memtest (if it didn't exist already)
<megi> so what's typical data for uart, I guess not porn like on the internet
<megi> ?
<megi> ;)
<mru> ascii cats?
skiboy_ has joined #linux-sunxi
<megi> haha
<DuClare> ascii porn?
<KotCzarny> ascii pr0n cats
<swiftgeek> i don't porn is one of the tests in memtest86+
<swiftgeek> *don't think
<mru> are you sure?
skiboy_ is now known as skiboy
<kilobyte> "apt install chafa" if you want porn over uart :)
<kilobyte> or cats
<swiftgeek> ok finally found one https://github.com/cbrake/linux-serial-test
<mru> and here are some cats: https://www.asciiart.eu/animals/cats
<karlp> swiftgeek: that linux-serial-tests looks awesome
<karlp> I've been looking for something like that for ages, and have three half started attempts at it myself
<karlp> was always bothered by the apparent lack of proper test tools
<swiftgeek> yup ^^
<karlp> I'd always fallen back on sz/rz inside picocom to verify that things could perform properly with flow control and backpressure without corruption, but was't easy to script it.
<karlp> so many of them assumed loopback, which is just garbage for testing IMO
Danct12 has quit [Write error: Connection reset by peer]
oliv3r[m] has quit [Remote host closed the connection]
hpagseddy[m] has quit [Write error: Connection reset by peer]
freddor has quit [Read error: Connection reset by peer]
fevv8[m] has quit [Remote host closed the connection]
Jeremy_Rand_Talo has quit [Read error: Connection reset by peer]
z3ntu_ has quit [Read error: Connection reset by peer]
romainmahoux[m] has quit [Read error: Connection reset by peer]
thefloweringash has quit [Read error: Connection reset by peer]
MartijnBraam has quit [Read error: Connection reset by peer]
JuniorJPDJ has quit [Read error: Connection reset by peer]
solderfumes has quit [Read error: Connection reset by peer]
agates[m] has quit [Read error: Connection reset by peer]
mic-e[m] has quit [Write error: Connection reset by peer]
k40s[m] has quit [Read error: Connection reset by peer]
davidebeatrici has quit [Read error: Connection reset by peer]
EmilKarlson has quit [Remote host closed the connection]
atopuzov[m] has quit [Read error: Connection reset by peer]
t4h4[m] has quit [Write error: Connection reset by peer]
insep[m]1 has quit [Write error: Connection reset by peer]
clementp[m] has quit [Remote host closed the connection]
<swiftgeek> karlp: now if that would be extend to work with two ports, i could even test different voltage levels or other stranger contraptions :D
<karlp> swiftgeek: it aleady supports two ports....
<karlp> otherwise I wouldn't have been so enthusiastic about it...
<swiftgeek> oh but that involves RTS/CTS and i have only TX/RX :D
<karlp> doesnt have to.
<karlp> just don't put in the delay that would trigger it
<swiftgeek> tried and it errors out at first, but then it somehow synchronizes i guess
<swiftgeek> nope i added fault and it wasn't detected lol
<karlp> well, I'll try it out some nex ttime I'm doing this crap again
<swiftgeek> looks like it's fine if TX port starts sending frames before first "count for this session" appears
<swiftgeek> or maybe i just found an issue with a chipie lol
<swiftgeek> other chipie doesn't do that
<swiftgeek> i lowered baud rate to 115200 and there is no such issue
<swiftgeek> so fake CP2102 works fine even at 921600, but ch340g fails with 500000
<swiftgeek> the highest stable baud rate for me is 230400 on ch340g ;D
airstorm has quit [Quit: airstorm]
<karlp> how do you know it's fake anyway?
<karlp> is ch340g even specced higher than 230k?
tnovotny has quit [Quit: Leaving]
<swiftgeek> karlp: it's blank on the top + it doesn't quite match the spec i think
dddddd has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
skiboy has quit [Quit: Leaving]
vagrantc has joined #linux-sunxi
<zoobab> @karlp I have seen some python serial tests a while a go
<karlp> that looks like garbage already honestly.
<karlp> if I hve to read 20 level indented python and all of the source anyway I can customize whatever I want
<zoobab> it is a cli tool
<karlp> doesn't do any comparisons and checking either
<swiftgeek> just found fake ch340g lmfao
<karlp> all that does is some randomly jittery transmitting and storing rx in a file.
<swiftgeek> i know it's fake because it lacks markings and performs better xD
<swiftgeek> package is different as well (still sop16)
selfbg has quit [Remote host closed the connection]
reinforce has quit [Quit: Leaving.]
ldevulder_ is now known as ldevulder
k40s[m] has joined #linux-sunxi
hpagseddy[m] has joined #linux-sunxi
freddor has joined #linux-sunxi
insep[m]1 has joined #linux-sunxi
romainmahoux[m] has joined #linux-sunxi
Danct12 has joined #linux-sunxi
MartijnBraam has joined #linux-sunxi
EmilKarlson has joined #linux-sunxi
t4h4[m] has joined #linux-sunxi
thefloweringash has joined #linux-sunxi
mic-e[m] has joined #linux-sunxi
z3ntu_ has joined #linux-sunxi
atopuzov[m] has joined #linux-sunxi
Jeremy_Rand_Talo has joined #linux-sunxi
oliv3r[m] has joined #linux-sunxi
fevv8[m] has joined #linux-sunxi
davidebeatrici has joined #linux-sunxi
JuniorJPDJ has joined #linux-sunxi
agates[m] has joined #linux-sunxi
solderfumes has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
vagrantc has quit [Quit: leaving]
reinforce has joined #linux-sunxi
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
ganbold has joined #linux-sunxi
lurchi_ is now known as lurchi__
yann|work has quit [Ping timeout: 268 seconds]
hanni76 has joined #linux-sunxi
ganbold has quit [Remote host closed the connection]
ganbold has joined #linux-sunxi
ganbold has quit [Ping timeout: 252 seconds]
hanni76 has quit [Quit: Leaving]
diego_r has quit [Ping timeout: 276 seconds]
aloo_shu has joined #linux-sunxi
yann|work has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
florian has quit [Quit: Leaving]
florian_kc has quit [Ping timeout: 246 seconds]
hanni76 has joined #linux-sunxi
uKibab has joined #linux-sunxi
<uKibab> Hi everyone! FreeBSD developer here, trying to add MMC HS200 support for the eMMC slot on Pine64. I can reliably communicate with the card at 150 Mhz, but at 200 MHz I get CRC errors sooner or later. I'd like to understand if sunxi-mmc driver really sets 200 MHz frequency when requested to do so
<uKibab> Who can help me to debug this?
<anarsoul> uKibab: likely you're not doing calibration
<uKibab> Ideally either building Linux kernel with DYNAMIC_DEBUG enabled or by adding a "normal" printf at https://elixir.bootlin.com/linux/latest/source/drivers/mmc/host/sunxi-mmc.c#L804
<mru> the easiest way to find out what frequency it's using is to check with a scope
<uKibab> anarsoul: there is the call to set a constant value in calibration register that both Linux and FreeBSD do. Is that what you mean or there is something more?
<mru> or ask kenneth
<uKibab> mru: yeah, if only I had a scope :-)
<anarsoul> uKibab: that's what I meant
hanni76 has quit [Quit: Leaving]
<anarsoul> also make sure you don't configure any delays since it messes up calibration
<uKibab> that code never gets called for A64 since it is new timings- only
<anarsoul> are you referring to sunxi_mmc_calibrate()?
<uKibab> no, sunxi_mmc_clk_set_phase() which is a func at line 732
AneoX has quit [Quit: Textual IRC Client: www.textualapp.com]
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
netlynx has quit [Quit: Ex-Chat]
sunilmohan has quit [Read error: Connection reset by peer]
sunilmohan has joined #linux-sunxi
niceplace has quit [Quit: ZNC 1.7.4 - https://znc.in]
DonkeyHotei has quit [Ping timeout: 276 seconds]
niceplace has joined #linux-sunxi
lurchi__ is now known as lurchi_
florian_kc has joined #linux-sunxi
diego_r has joined #linux-sunxi
lurchi_ is now known as lurchi__
florian_kc has quit [Ping timeout: 240 seconds]
lurchi__ is now known as lurchi_
Net147 has quit [Ping timeout: 265 seconds]
pcbBob has joined #linux-sunxi
Net147 has joined #linux-sunxi
<pcbBob> No information regarding V316 & V536 floating around?
tllim has joined #linux-sunxi
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
lurchi_ is now known as lurchi__
aloo_shu has quit [Quit: nice to be back, but need more real life & sleep]
lurchi__ is now known as lurchi_
diego_r has quit [Ping timeout: 246 seconds]
matthias_bgg has quit [Quit: Leaving]
dlan has quit [Read error: Connection reset by peer]
ldevulder_ has joined #linux-sunxi
dlan has joined #linux-sunxi
ldevulder has quit [Ping timeout: 246 seconds]
tuxd3v has joined #linux-sunxi
warpme_ has quit [Quit: Connection closed for inactivity]