<anarsoul>
to understand why 2 consecutive reads aren't good enough to tell whether sample is good
<suprothunderbolt>
anarsoul: isn't that what the previous patch was doing and this one isn't?
<anarsoul>
no, this patch just reads register two times and repeats that if values do not match
<suprothunderbolt>
so is there a working work around?
<anarsoul>
likely no
<suprothunderbolt>
ahh. Anything we can do apart from bin the hardware? :)
<anarsoul>
someone has to investigate this issue
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 268 seconds]
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 268 seconds]
ChriChri_ is now known as ChriChri
tl_lim has joined #linux-sunxi
tllim has quit [Ping timeout: 268 seconds]
tl_lim has quit [Read error: Connection reset by peer]
Mangy_Dog has quit [Ping timeout: 265 seconds]
megi has quit [Ping timeout: 246 seconds]
Gerwin_J has joined #linux-sunxi
<willmore>
ARM is getting more like Intel every day. :) (refering to recent HPET bug in Intel chips)
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
<anarsoul>
MoeIcenowy: any known touchscreen issues with pinephone?
cnxsoft has quit [Read error: Connection reset by peer]
lurchi_ is now known as lurchi__
cnxsoft has joined #linux-sunxi
djakov has quit [Ping timeout: 276 seconds]
djakov has joined #linux-sunxi
<tuxd3v>
hello
[7] has quit [Ping timeout: 250 seconds]
TheSeven has joined #linux-sunxi
<MoeIcenowy>
anarsoul: good here
<anarsoul>
apparently UBPorts doesn't have your fixes yet
B-52 has joined #linux-sunxi
aloo_shu has quit [Read error: Connection reset by peer]
B-52 is now known as aloo_shu
<anarsoul>
MoeIcenowy: btw where I can the patches for touchscreen?
tuxd3v has quit [Quit: Leaving]
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 240 seconds]
suprothunderbolt has quit [Ping timeout: 268 seconds]
suprothunderbolt has joined #linux-sunxi
dddddd has quit [Remote host closed the connection]
smaeul has quit [Quit: cya]
return0e_ has joined #linux-sunxi
jstefanop has joined #linux-sunxi
return0e has quit [Ping timeout: 265 seconds]
selfbg has joined #linux-sunxi
Putti has quit [Quit: Leaving]
jstefanop has quit [Ping timeout: 250 seconds]
reinforce has joined #linux-sunxi
airstorm has joined #linux-sunxi
smaeul has joined #linux-sunxi
smaeul has quit [Quit: cya]
smaeul has joined #linux-sunxi
selfbg1 has joined #linux-sunxi
selfbg has quit [Ping timeout: 265 seconds]
selfbg1 is now known as selfbg
ldevulder_ is now known as ldevulder
matthias_bgg has joined #linux-sunxi
rra has joined #linux-sunxi
suprothunderbolt has quit [Ping timeout: 265 seconds]
djakov has quit [Ping timeout: 252 seconds]
djakov has joined #linux-sunxi
msev- has joined #linux-sunxi
<mripard_>
anarsoul: can you report it on the ML with maz and smaeul in Cc?
<smaeul>
I'm not sure how much help I can be at this point
<smaeul>
even if someone ships me hardware that still experiences issues (all of mine has been fine for months), it's just bandages until we find a chip that is worse
tllim has joined #linux-sunxi
pmpp has joined #linux-sunxi
pmp-p has quit [Ping timeout: 268 seconds]
florian_kc has joined #linux-sunxi
vpeter has quit [*.net *.split]
jelly has quit [*.net *.split]
wigyori has quit [*.net *.split]
mripard_ has quit [*.net *.split]
yann has quit [Ping timeout: 250 seconds]
wigyori has joined #linux-sunxi
mripard_ has joined #linux-sunxi
vpeter has joined #linux-sunxi
rra has left #linux-sunxi [#linux-sunxi]
rra has joined #linux-sunxi
florian_kc has quit [Ping timeout: 240 seconds]
<wens>
wow, still finding bugs from the damn axp20x-regulator macro conversion :(
jelly-home has joined #linux-sunxi
rra has left #linux-sunxi [#linux-sunxi]
<dgp>
That reminds me I still have patches to support the axp192 to post and get ignored :D
<wens>
which board / soc is that used with?
<dgp>
I was going to use it on a board I'm putting together with a non-allwinner SoC
<dgp>
but the battery charger is a dead short in the ones I have so I'm not going to use it.. but the patches worked enough for the pmic part
<wens>
dead short ... wow
<dgp>
lots of lovely smelling smoke when plugging in the lipo :)
<KotCzarny>
that stuff is toxic, you should know
<dgp>
not as toxic as an exploding lipo house fire
<KotCzarny>
yeah
diego_r has joined #linux-sunxi
<maz>
mripard_: I'm missing some context. what is that about?
<wens>
maz: A64 arch timer jumps X years into the future
<maz>
wens: didn't we work around that crap already?
<mripard_>
maz: turns out it doesn't work around it well enough apparently
<KotCzarny>
why dont you just ignore changes bigger than X ?
rra has joined #linux-sunxi
<maz>
mripard_: I wonder if we should ignore more than the bottom 12 bits, but someone with the HW at hand should try and investigate.
rra has left #linux-sunxi [#linux-sunxi]
<maz>
mripard_: or get AW to send a drill to all users...
florian_kc has joined #linux-sunxi
rra has joined #linux-sunxi
rra has left #linux-sunxi [#linux-sunxi]
florian_kc has quit [Ping timeout: 265 seconds]
yann has joined #linux-sunxi
<wens>
jernej: how did you know what the mbus offset was for the h3 deinterlace unit?
AneoX has joined #linux-sunxi
NeuroScr has joined #linux-sunxi
florian_kc has joined #linux-sunxi
florian_kc is now known as florian
jelly-home is now known as jelly
NeuroScr has quit [Quit: NeuroScr]
msev- has quit [Quit: Leaving]
NeuroScr has joined #linux-sunxi
megi has joined #linux-sunxi
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 245 seconds]
kaspter has quit [Ping timeout: 250 seconds]
kaspter has joined #linux-sunxi
NeuroScr has quit [Quit: NeuroScr]
Mangy_Dog has joined #linux-sunxi
<megi>
anarsoul: re PP ts, I have similar issue on my PocketBook touchscreen on a replacement display, and it's probably solvable by touchscreen calibration
selfbg has quit [Quit: selfbg]
<megi>
tough calibration procedure is touchscreen specific, so that will be tough ;)
selfbg has joined #linux-sunxi
<megi>
on my chip it's a bunch of commands that do some magic to calibrate sensitivity using self-capacity or something like that
florian_kc has joined #linux-sunxi
fl_0 has quit [Ping timeout: 250 seconds]
<wens>
megi: are you still seeing incorrect h/v sync polarities?
fl_0 has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
<megi>
wens: I'm not sure what you're asking
<megi>
I've inverted the meaning of bits in the camera driver - the code now looks weird, but at least both my gc2145 driver and sun6i-csi driver aggrees on the mbus configuration
matthias_bgg has quit [Read error: Connection reset by peer]
<wens>
megi: I'm not sure what I'm asking either ...
<megi>
it's possible that there's a slight offset at the beginning of each row, because HSYNC signal != negated HREF exactly
matthias_bgg has joined #linux-sunxi
<wens>
megi: for the sensor, does it use HREF or HSYNC semantics?
<megi>
but that's solvable by a bit of math
<megi>
it looks like HREF (that is HSYNC line is active for the duration of row transfer exactly)
<megi>
but there's no option to change the semantics
<megi>
in the cam registers
<wens>
I spent a bit of time fixing the polarity in sun4i-csi, but now I'm not sure if the sensor drivers are sane
<megi>
only invert
<megi>
hmm
<wens>
for example, I found ov7670 driver trying to emulate HSYNC by tweaking HREF start and stop to make it like HSYNC :(
<megi>
yeah
<megi>
I think it will be similar with my driver
<wens>
ov5640 driver seems to be sane, using HREF semantics
<wens>
at least I got ov5640, sun4i-csi, sun6i-csi to all agree on the polarity
<megi>
without some timing tweaks I get a few black pixels at the start of the row
<megi>
but that may also be something else
<wens>
but since I don't have a scope, I don't actually have a definite reference for which way is active high
<megi>
I don't have fast enough logical probe either, I'm just relying on A83T's gpio which I can read at ~6MHz which is not enough to see pixel clock acuracy
<megi>
it's for a83t, but should work with other SoCs with some tweaks
<megi>
I just run some capture program, and use this to switch some PD pins to gpio input mode and read them to a file
<wens>
so you still needed to invert the flags in sun6i-csi
<megi>
then view the result in pulseview
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
<megi>
no
<megi>
both cam driver and csi inver the meaning so it cancels out
<megi>
what cam driver describes as active hsync high in datasheet, means that while row is transmitted HSYNC line is held high
<megi>
that's what I see in the probe
<megi>
which is inverse of supposed meaning of HSYNC to the kernel interfaces, but it matches the Allwinner CSI datasheet diagram
<megi>
it's all confusing
<wens>
great, the datasheet has a frame timing diagram, but no row timing diagram :(
<wens>
based on the timing formulas found on page 18, I would guess that the sensor uses SYNC semantics, but inverted
<megi>
application note for gc2035 says "assume hsync is high active" and shows timing diagram that looks like HSYNC is high during row transfer, and low active means VSYNC is low during transfer
<megi>
so I think you're right
<wens>
Sh_delay + 4 would be the back porch, so even if you set it to zero, you'd still get 4 blank pixels per row
<wens>
for vertical, back porch is St + 8, meaning at least 8 blank rows, but HSYNC isn't sent during those
<megi>
there are also some regs that are only docummented in the version of datasheet for "internal use", that also affect this
<wens>
I suppose the problem then becomes, how does the sensor driver tell the capture device about the back porch
<libv>
so the powervr name is now so burned that img has moved away from it
tllim has quit [Read error: Connection reset by peer]
florian_kc has quit [Ping timeout: 276 seconds]
<megi>
wens: I see, CSI receiver can be configured with HOR/VER_START to ignore some rows/pixels at the beginning
ldevulder has quit [Ping timeout: 240 seconds]
ldevulder has joined #linux-sunxi
<wens>
correct
ldevulder has quit [Quit: Leaving]
gaston1980 has quit [Ping timeout: 265 seconds]
gaston1980 has joined #linux-sunxi
<tnovotny>
wens: if you want the A83t tablet for testing (the same as megi has), I can ask and try to send it to you. It is "TBS A711" tablet in the linux-sunxi wiki.
ldevulder has joined #linux-sunxi
tllim has joined #linux-sunxi
tl_lim has joined #linux-sunxi
tllim has quit [Ping timeout: 240 seconds]
lurchi_ is now known as lurchi__
nexgen has joined #linux-sunxi
nexgen has quit [Remote host closed the connection]
nexgen has joined #linux-sunxi
airstorm has quit [Quit: airstorm]
azend|vps has quit [*.net *.split]
samueldr has quit [*.net *.split]
ScrumpyJack has quit [*.net *.split]
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 268 seconds]
samueldr has joined #linux-sunxi
azend|vps has joined #linux-sunxi
ScrumpyJack has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
azend|vps has quit [*.net *.split]
samueldr has quit [*.net *.split]
ScrumpyJack has quit [*.net *.split]
samueldr has joined #linux-sunxi
azend|vps has joined #linux-sunxi
ScrumpyJack has joined #linux-sunxi
rra has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 240 seconds]
AneoX has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
selfbg has quit [Remote host closed the connection]
<MoeIcenowy>
megi: after hacking sun6i-csi, did you test 5640?
tl_lim has quit [Ping timeout: 268 seconds]
tl_lim has joined #linux-sunxi
tl_lim has quit [Remote host closed the connection]
tl_lim has joined #linux-sunxi
tl_lim has quit [Remote host closed the connection]
tl_lim has joined #linux-sunxi
<mripard_>
last time I checked, the ov5640 driver was working with sun6i-csi
Gerwin_J has quit [Quit: Gerwin_J]
<uKibab>
Hi everyone, is it possible to contact ayufan who hacked on MMC performance for Pinebook in the past?
<megi>
MoeIcenowy: I'm pretty sure it would not work :)
<uKibab>
It seems that eMMC on AllWinner is limited to 150 MHz
<DuClare>
uKibab: I'm sure it's possible to contact them...
<Dyraton01>
I am booting from emmc, idk if that's "_working_"
<uKibab>
Thanks. That seems to be uSD card, not eMMC.
rra has left #linux-sunxi [#linux-sunxi]
<uKibab>
maybe pinebook has different slot number for eMMC...
<uKibab>
what is in /sys/kernel/debug/mmc0/ios and /sys/kernel/debug/mmc1/ios if you don't mind sharing?
<Dyraton01>
Kibab: I am definitely booting from emmc
tuxd3v has joined #linux-sunxi
<uKibab>
mripard_: 200000000 MHz for MMC2 is indeed maximum of what the controller can accept, but the question is if it can reliably run on this freq. I have seen some reports on the forums that people decreased frequency to 150 MHz to make eMMC work reliably. I'm tring to understand if this is really a thing.
<uKibab>
Dyraton01: good, then please defiinitely share the ios from mmc0 and mmc1
<buZz>
200000000 Hz , i assume you ment
<uKibab>
mripard_: the issue is, I'm running a netbooted Pine64 with Foresee 16GB eMMC inserted, and I cannot do anything with it, any read just hangs.
<uKibab>
buZz: yes, which is 200 MHz
<mripard_>
uKibab: I could run an eMMC in HS200 at 200MHz last time I checked
<buZz>
:)
<mripard_>
HS400 wasn't working though
<uKibab>
mripard_: was it on Pine64 or Pinebook? that could make a difference as well....
<uKibab>
Dyraton01: oh, so yours is running in 52MHz mode
<uKibab>
interesting. Thank you
reinforce has joined #linux-sunxi
<uKibab>
I have decompiled the DTB and changed max-frequency there and compiled it back to DTB, booting the board with the changed DTB now, let's see what I have
matthias_bgg has quit [Read error: Connection reset by peer]
matthias_bgg has joined #linux-sunxi
jstefanop has joined #linux-sunxi
tl_lim has quit [Remote host closed the connection]
yann has quit [Ping timeout: 268 seconds]
<uKibab>
Yeah with 150 MHz the eMMC works just fine -- I can access the card for r/w ops
tl_lim has joined #linux-sunxi
<uKibab>
also there are no weird messages in journalctl -b about operations on mmcblk2p* taking too long