dddddd has quit [Remote host closed the connection]
jstefanop has joined #linux-sunxi
dev1990 has quit [Ping timeout: 264 seconds]
jstefanop has quit [Ping timeout: 252 seconds]
dev1990 has joined #linux-sunxi
dwalt has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-sunxi
suprothunderbolt has joined #linux-sunxi
Rafael1980 has quit [Quit: Konversation terminated!]
return0e has quit [Ping timeout: 264 seconds]
chomwitt has quit [Ping timeout: 252 seconds]
return0e has joined #linux-sunxi
vagrantc_ has joined #linux-sunxi
dev1990 has quit [Quit: Konversation terminated!]
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 264 seconds]
\\Mr_C\\ has joined #linux-sunxi
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
\\Mr_C\\ has joined #linux-sunxi
\\Mr_C\\ has quit [Excess Flood]
\\Mr_C\\ has joined #linux-sunxi
ganbold has quit [Quit: Leaving]
ganbold has joined #linux-sunxi
victhor has quit [Ping timeout: 252 seconds]
chewitt has quit [Ping timeout: 250 seconds]
<suprothunderbolt>
still attempting to get my DSI panel working. I've got some more debugging now and all the start up stuff appears to be sent but nothing after start up. Does anyone know when it would be waiting for any response from the panel? I.e. would any of the setup messages fail to send or is their not any acknowledgment system?
<suprothunderbolt>
oh and tear mode vblank... how should I specify what the TE pin is connected to?
megi has quit [Ping timeout: 252 seconds]
lurchi_ is now known as lurchi__
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
TheSeven has quit [Ping timeout: 240 seconds]
TheSeven has joined #linux-sunxi
camus has joined #linux-sunxi
chewitt has joined #linux-sunxi
kaspter has quit [Ping timeout: 264 seconds]
camus is now known as kaspter
agraf_ has joined #linux-sunxi
agraf has quit [Ping timeout: 250 seconds]
agraf_ is now known as agraf
DonkeyHotei has joined #linux-sunxi
<suprothunderbolt>
I think specifying the connection of the TE pin is what I'm confused by. I'm not sure which GPIO that should be connected up to and where that's specified
<suprothunderbolt>
can I force the DSI clock to be active on the pins so I can look at it easily?
<anarsoul>
no idea
<anarsoul>
I think only allwinner knows the answer
<suprothunderbolt>
:(
<suprothunderbolt>
not sure how else I should be working this out. I'm not sure how to write a panel driver for the BSP.
<suprothunderbolt>
I haven't connected up the TE pin to anything assuming that was an optional features as there isn't anyway to specify it in the DT
return0e has quit [Read error: Connection reset by peer]
return0e has joined #linux-sunxi
<suprothunderbolt>
something I don't understand is what is responsible for the signalling the vblank
<suprothunderbolt>
should the panel respond?
vagrantc_ has quit [Quit: leaving]
lykt has quit [Quit: leaving]
<anarsoul>
suprothunderbolt: tcon is signalling vblank, but if you don't configure dsi and panel correctly it won't signal it
tllim has quit [Quit: Leaving]
<suprothunderbolt>
ahh okay. I'm just keen to know how it knows dsi & panel is configured correctly. I.e. how can I check if the panel is responding to the commands
<suprothunderbolt>
they check return codes and don't fail but I'm not sure where the bus returns anything
<anarsoul>
suprothunderbolt: it just works if configured correctly :)
<suprothunderbolt>
i.e. is there a place earlier I can see if the panel isn't working than when the vblank fails.
<suprothunderbolt>
anarsoul: hah :) Not what's i'm getting right now then.
<suprothunderbolt>
So just trying to work out if it's my panel driver or the DSI driver
<suprothunderbolt>
the calculated clock looks correct
<anarsoul>
suprothunderbolt: I'm not aware of any way to debug it other than compare registers with BSP with working DSI and panel drivers.
<suprothunderbolt>
mmm, so I should write a panel driver for the the BSP version...
<anarsoul>
suprothunderbolt: it's roughly the same work as writing panel driver for mainline
<suprothunderbolt>
where do they go? It seems like the panels are SOC specific in the BSP code
<anarsoul>
suprothunderbolt: what you need is correct timings that satisfy both DSI controller and panel
<anarsoul>
I assume you don't have them
<anarsoul>
and, of course, set of commands to enable panel
<anarsoul>
panel driver goes into drivers/drm/panel/ in mainline
<suprothunderbolt>
I've got commands and timings the manufacturer gave me, and I've written a driver using them, modifying the existing ili9881C driver
<suprothunderbolt>
the only messages I see sent are the start up ones.
<anarsoul>
well, good luck with that :)
<suprothunderbolt>
hah thanks
shfil has joined #linux-sunxi
<suprothunderbolt>
do you know where the panel drivers go in BSP?
<anarsoul>
somewhere in drivers/video, I don't have BSP sources on my laptop
<suprothunderbolt>
I'm running with the RT patches / Armbian sources + amarula's DSI patches
<suprothunderbolt>
maybe I should get it working with just Amarula patch
t3st3rV2 is now known as t3st3r
lykt has joined #linux-sunxi
nuuuciano has quit [Ping timeout: 252 seconds]
vagrantc has quit [Quit: leaving]
return0e has quit [Ping timeout: 255 seconds]
return0e has joined #linux-sunxi
suprothunderbolt has quit [Ping timeout: 255 seconds]
<MoeIcenowy>
suprothunderbolt: which BSP kernel version?
<MoeIcenowy>
3.10 or 4.9?
<MoeIcenowy>
for 4.9 it's drivers/video/fbdev/sunxi/disp2/disp/lcd/
<MoeIcenowy>
for 3.10 there's no "fbdev" level
f0xx has joined #linux-sunxi
<bbrezillon>
lavamind: sponsor it? you mean pay you to port my patches?
dwalt has quit [Ping timeout: 252 seconds]
ccaione has quit [Ping timeout: 252 seconds]
ric96 has quit [Ping timeout: 252 seconds]
ric96 has joined #linux-sunxi
return0e has quit [Read error: Connection reset by peer]
return0e has joined #linux-sunxi
Nyuutwo has quit [Read error: No route to host]
Nyuutwo has joined #linux-sunxi
dwalt has joined #linux-sunxi
IgorPec1 has joined #linux-sunxi
ccaione has joined #linux-sunxi
IgorPec has quit [Ping timeout: 250 seconds]
clemens3 has joined #linux-sunxi
IgorPec1 has quit [Ping timeout: 252 seconds]
<plaes>
:D
t3st3r has quit [Ping timeout: 256 seconds]
t3st3r has joined #linux-sunxi
IgorPec has joined #linux-sunxi
rah_ is now known as rah
Mangy_Dog has joined #linux-sunxi
cmeerw has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
Andy-D has quit [Ping timeout: 250 seconds]
shfil has quit [Quit: Connection closed for inactivity]
dev1990 has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
f0xx has quit [Ping timeout: 255 seconds]
victhor has joined #linux-sunxi
afaerber has joined #linux-sunxi
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 252 seconds]
camus is now known as kaspter
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 264 seconds]
Andy-D has joined #linux-sunxi
IgorPec has quit [Quit: Leaving]
<libv>
MoeIcenowy: no device page for the d978
<libv>
i'm putting the fex files in right now
<libv>
i should actually give you access to this repo
megi has joined #linux-sunxi
madez has joined #linux-sunxi
nuuuciano has joined #linux-sunxi
<MoeIcenowy>
libv: in fact I now doubt whether my iNet D978 rev2 tablet will run or not
<MoeIcenowy>
it has not been powered on for 2 yrs
<MoeIcenowy>
and as it has its touchscreen broken (because I wrongly flashed the firmware of its GT9271 touch screen controller)
<MoeIcenowy>
I won't use it any more
<libv>
i have 2 billy shelves full of devices that have not been touched for close to two years :)
<libv>
err, 4
<MoeIcenowy>
in fact I will prefer to just drop it
<libv>
ok
<libv>
hrm
<libv>
imho it is still worth documenting some things, and putting at least half a device page up
<libv>
disassembly pictures, uart, link to fex
<MoeIcenowy>
libv: for A33 tablets the on-board UART pins are usually the ones muxed with SD
<MoeIcenowy>
oops I even lost FEX for this tablet... sorry
<libv>
i just pushed that fex :)
<libv>
it was in a pull request
<libv>
and you should be able to commit to -tools and -boards now
<MoeIcenowy>
libv: should we upload the FEX if we even have the schematics?
<MoeIcenowy>
e.g. I have the Pine Tab FEX and schematics on hand
<libv>
yeah, extra data, and if someone does write up soc specific bsp build howtos, the fex will be needed
<libv>
such howtos should be pretty boilerplate and simple, but someone needs to go through the motions and make it happen
<MoeIcenowy>
btw for building PineTab a LCD panel initialization driver is needed
<MoeIcenowy>
libv: do we have any other active repositories other than sunxi-tools and sunxi-boards? ;-)
<libv>
MoeIcenowy: i have no idea :)
<libv>
but you and several others here should have access to whatever is useful
<libv>
after i am done with the fex files, i will alter the device page boiler plate to better reflect reality, and then i will hopefully get back to the fosdem project :)
<libv>
heh, and now my 2y old is waking up
ninolein has joined #linux-sunxi
<MoeIcenowy>
at Guangzhou every spring is a trial for stored electronics devices
<MoeIcenowy>
in this spring I get the keyboards of one x86 laptop and one Pinebook broken
<MoeIcenowy>
(because of overwet
Rafael1980 has joined #linux-sunxi
Net147 has quit [Quit: Quit]
victhor has quit [Ping timeout: 240 seconds]
reinforce has joined #linux-sunxi
clementp has joined #linux-sunxi
<clementp>
Matrix IRC is still down :(.
<clementp>
MoeIcenowy: did AW reply about the wdog issue for H6 ?
<clementp>
libv: thanks for the clean and push of my board on sunxi-boards :)
<clementp>
I was wondering why linux-sunxi doesn't have a kernel ML and patchworks ? Instead of using the Google groups ?
<clementp>
Like amlogic, allwinner and rockchip
<clementp>
s/allwinner/mediatek
<MoeIcenowy>
not yet
<MoeIcenowy>
clementp: btw how did you get GS1 fex?
<MoeIcenowy>
bbtw what memory does GS1 use?
<lavamind>
bbrezillon: by sponsor I meant submit the patches
<lavamind>
heh, I'd be curious to know how much you think it would cost though
<lavamind>
(obviously I'm not a Co and I don't have funds to pay to kernel development...)
<libv>
clementp: this community was started in july 2012
clementp has quit [Ping timeout: 256 seconds]
<libv>
the first to have gpled kernel source for chinese android devices
<libv>
some of these things are such for historic reasons.
clementp has joined #linux-sunxi
<clementp>
MoeIcenowy: extracted from the SD / USB provide by the manufacturer
<clementp>
It has an eMMC memory but I only use Sdcard for now
<MoeIcenowy>
oh I mean RAM
<MoeIcenowy>
according to the wiki, it's LPDDR3, right?
<clementp>
libv: Ok but tis could be a good move
<clementp>
How can I check if it's Lpddr3 or 4 ?
<MoeIcenowy>
it won't be lpddr4 ;-)
<MoeIcenowy>
H6 has no LPDDR4 support
<MoeIcenowy>
but it could be DDR3/4
Rafael1980 has quit [Ping timeout: 252 seconds]
Rafael1980 has joined #linux-sunxi
<clementp>
The website says DDR4 but I don't trust market guys :)
<clementp>
I would check the ref when I come back home
<clementp>
Will*
clementp has quit [Ping timeout: 256 seconds]
jstefanop has joined #linux-sunxi
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 246 seconds]
<hanetzer>
unrelated to sunxi in particular, but related in the arm embedded space. anyone have a good trick for reducing your kernel Image by a couple megs? (aarch64, rk3399)
<hanetzer>
I'm half convinced I've cut everything I can afford to cut
jstefanop has quit [Remote host closed the connection]
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 252 seconds]
<bbrezillon>
lavamind: actually, submitting/rebasing the patches shouldn't take long (already rebased them on top of nand/next)
<bbrezillon>
what takes long is getting them merged
<bbrezillon>
and I fear MTD maintainers (which I'm no longer part of) don't have time to review it
Andy-D has quit [Ping timeout: 255 seconds]
t3st3r has quit [Ping timeout: 256 seconds]
t3st3r has joined #linux-sunxi
chewitt has joined #linux-sunxi
jstefanop has joined #linux-sunxi
f0xx has joined #linux-sunxi
jstefanop has quit [Remote host closed the connection]
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 252 seconds]
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 252 seconds]
chewitt has quit [Ping timeout: 252 seconds]
madez has quit [Read error: Connection reset by peer]
madez has joined #linux-sunxi
<martinayotte>
clementp: MoeIcenowy: In case you need to provide more H6 serialNo to AW, here are mine : OPi3 = HA047BA 69W2 / OPiOnePlus = H7310BA 6842 / OPiLite2 = H6448BA 6662 / and the only one that didn't face the WDOG issue PineH64 = H8069BA 6892
agraf has quit [*.net *.split]
jrg has quit [*.net *.split]
indy has quit [*.net *.split]
DuClare has quit [*.net *.split]
masterdonx has quit [*.net *.split]
sunshavi has quit [*.net *.split]
freemangordon has quit [*.net *.split]
ijc_ has quit [*.net *.split]
angelo_ts has quit [*.net *.split]
fest has quit [*.net *.split]
Andy-D has joined #linux-sunxi
JohnDoe8 has joined #linux-sunxi
DuClare has joined #linux-sunxi
fest has joined #linux-sunxi
masterdonx has joined #linux-sunxi
freemangordon has joined #linux-sunxi
ijc has joined #linux-sunxi
angelo_ts has joined #linux-sunxi
sunshavi has joined #linux-sunxi
jrg has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 252 seconds]
indy has joined #linux-sunxi
nashpa has quit [Ping timeout: 250 seconds]
dddddd has quit [Read error: Connection reset by peer]
shfil has joined #linux-sunxi
nashpa has joined #linux-sunxi
tllim has joined #linux-sunxi
victhor has joined #linux-sunxi
jo0nas has joined #linux-sunxi
<jo0nas>
MoeIcenowym anarsoul: I got a teres-i and can help test patches for u-boot - I have been sifting through some draft works of yours but am eager to have it land in mainline so it can go into Debian
<anarsoul>
jo0nas: I think getting teres dts into u-boot and appending u-boot specific dst akin to pinebook should work
<jo0nas>
yes, I have my teres-i running now - i.e. with backlight properly activated - by using only two of your patches from https://github.com/Icenowy/u-boot (very slightly adapted) - commits e319f59 (AXP803 support) and 960ae7 (DTS and config)
<jo0nas>
anarsoul: my question is how can I help get this further?
<jo0nas>
I have found that the config does not follow newest style of mainline u-boot
<anarsoul>
use mainline u-boot, you don't need AXP803 support
<anarsoul>
everything for pinebook is already mainlined
<anarsoul>
so just add your dts (take it from linux), u-boot.dts (to enable display) and defconfig
<jo0nas>
...but I am in deep waters messing directly with the code - my skills are in system administration, patching, and compiling - but not in understanding the hardware pieces nor in writing C code
<jo0nas>
well, I have not succeeded in getting backlight enabled without that AXP803 driver
<jo0nas>
I noticed somewhere (in the ATF codebase, as I recall) what looked like code doing the backlight enabling if fed the correct magic spells in device tree
<jo0nas>
...but I have been unable to cast such spell
<anarsoul>
use mainline ATF :)
<jo0nas>
yes
<jo0nas>
I tried with mainline ATF and mainline u-boot and messing only with piecing a device-tree file together
<jo0nas>
...but failed
<jo0nas>
what works for me so far is using mainline ATF and mainline u-boot with those 2 patches applied
<jo0nas>
my point above was that I tried express in a device-tree file the hints about voltage needed to wake up backlight - which I tried to grasp from _reading_ the sourcecode for mainline ATF - I did not patch ATF
<anarsoul>
jo0nas: I'm not sure if dts in mainline linux for teres is up to date
jstefanop has joined #linux-sunxi
<jo0nas>
anarsoul: how do ou mean "just take [...] u-boot.dts" - do you mean the dts from your ancient commit 960ae7 or something else?
<anarsoul>
if it is, take dts from linux
<anarsoul>
drop it into u-boot (into arch/arm/dts/)
<jo0nas>
hmm - that simple?
<anarsoul>
and create u-boot/arch/arm/dts/sun50i-a64-teres-i-u-boot.dtsi similar to arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi
<anarsoul>
then create new defconfig for teres
<anarsoul>
jo0nas: yes.
<jo0nas>
pinebook uses r_i2c which you mentioned to someone else is done differently for teres-i
<jo0nas>
the arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi talks about r_i2c
<anarsoul>
bridge is described in sun50i-a64-teres-i-u-boot.dtsi
<anarsoul>
jo0nas: yes, you need to modify it
<jo0nas>
if you mean s/r_i2c/i2c/ then sure I can do that, but deeper than that and I need hand-holding
<anarsoul>
s/r_i2c/i2c0
<anarsoul>
well, looks like mainline dts from linux lacks backlight
<anarsoul>
you'll have to add it as well
<anarsoul>
into u-boot.dtsi
<jo0nas>
ok, if you think only hacking needed is dts files + config (and I cannot persuade you to do more of the work for me) then I will try another round of fumbling in the dark - thanks!
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 240 seconds]
<jo0nas>
...and thanks a lot for your previous code - which provided me a working laptop (even if not adoptable into Debian formally) :-)
<anarsoul>
but I have no idea if it'll work or not. I don't have teres to test it
pmpp has quit [Ping timeout: 246 seconds]
<jo0nas>
thanks - having the hardware is _exactly_ how I can be of help here :-)
<anarsoul>
jo0nas: you'll have to fix it if it doesn't work :) I hope you have serial adapter for your teres
<jo0nas>
I do
<jo0nas>
...and I have plenty backup microSD cards :-)
<jo0nas>
...and several working u-boot blobs
<jo0nas>
boot failed - "DRAM: 0 MiB"
<jo0nas>
could that be the config option CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y added compared to the older patch?
* jo0nas
goes flash a working u-boot...
<MoeIcenowy>
martinayotte: now I think it might be board problem instead of chip problem
<megi>
MoeIcenowy: how so? differnt power domain for r_wdg?
<anarsoul>
jo0nas: sorry, I have no idea what memory teres uses
<martinayotte>
MeoIcenowy: No, as clementp said, we suspect chip batches that would explain why my PineH64 didn't fail reboot/reset while all my other H6 failed.
<jo0nas>
np - helped remove that line - it then hangs loading USB so I will try remove the OHCI line as well...
<jo0nas>
it is really really helpful having a known-working patchset to compare against!
<jo0nas>
anarsoul: ok, now it boots, but screen is black - any suggestions how to debug?
<anarsoul>
jo0nas: so sunxi_lcd isn't probed for some reason
<anarsoul>
add "#define DEBUG 1" at the beginning of drivers/video/sunxi/sunxi_de2.c, drivers/video/sunxi/sunxi_lcd.c and drivers/video/bridge/anx6345.c and recompile u-boot
<anarsoul>
and then check output again
<anarsoul>
oh
<anarsoul>
and you're missing reg_dc1sw regulator
<anarsoul>
check your schematics if dc1sw powers the panel
<anarsoul>
if it does, copy dc1sw node from pinebook dts to yours