ganbold has quit [Remote host closed the connection]
ganbold has joined #linux-sunxi
<Net147>
wens: I was using assigned-clock-parents and wondering for a long while why the parent was still wrong. perhaps there should be an option for assigned-clock-parents to add the CLK_SET_RATE_NO_REPARENT flag?
<wens>
nope
<wens>
AFAIK you shouldn't have assigned-clock-* in the device tree unless it is a hardware constraint
<wens>
in this case there isn't
<wens>
the drivers just have to do a better job at negotiating a sharable clock rate, or not step on each other
pfeerick has joined #linux-sunxi
juri_ has joined #linux-sunxi
<Net147>
so that means whenever clock rate changes, it should traverse the clock tree and figure out the best mux + clock rate combination for both existing rates for other clocks and the new rate for the clock?
<wens>
something like that
<Net147>
that seems really complicated...
<wens>
it is
<wens>
wonder how the x86 drivers do it
<wens>
since they manage their plls/dotclocks themselves, instead of using the clk subsystem
<Net147>
does the clock system store the unrounded rates? otherwise you will get drift whenever the clock hierarchy configuration is recalculated.
<Net147>
ideally the clock system should know what the original target rate is too
<Net147>
then clk_summary can give a nice overview of how accurate the clocks are
<wens>
Net147: no it doesn't
<wens>
there is a constraint (min/max) system, but no one actually implements checks for them :p
<Net147>
having assigned-clock-* isn't really a constraint. it just specifies the default parent and rate. the kernel can stil change them later on.
<wens>
you could also set the default parent and rate in the clk driver
<Net147>
using clk_set_parent and clk_set_rate?
<wens>
yes
<wens>
that is basically what the clk core does when it sees assigned-clocks-*
<Net147>
clk_set_rate could change the parent though
<Net147>
wens: what is the resolution of the monitor?
chrisf_ has quit [Read error: No route to host]
chrisf_ has joined #linux-sunxi
<Net147>
wens: can you send me a dump of the monitor EDID so I can check if it works here?
<wens>
1366x768
<wens>
FYI I think some of the error checking logic is wrong
<Net147>
and what is the EDID length? 128 bytes or 256 bytes?
<wens>
I don't have a working system atm, so I don't know
<Net147>
ah ok but you can connect the monitor to your Linux desktop to get the EDID
<wens>
I don't have a Linux desktop :p
<Net147>
Windows...?
<wens>
yeah
chrisf_ has quit [Read error: No route to host]
<wens>
I work off a remote workstation, so what desktop I use is irrelevant
chrisf_ has joined #linux-sunxi
<wens>
at home I play games, so Windows is a must
<wens>
at work, some shitty tools require Windows
chrisf_ has quit [Client Quit]
<Net147>
okay. what part of the logic is wrong?
<wens>
I'm still trying to figure it out
<oliv3r>
plaes: sorry for accidentally sending you an empty mail. i hit send by accident :(
<wens>
it might just be the <= vs < part that needs to be worked around :/
<oliv3r>
wens: there's lots of linux games these days :p
<wens>
oliv3r: not the commercial online game I play
<Net147>
KVM GPU passthrough =)
<wens>
Net147: then it's still Windows
<Net147>
I use Windows at home too, but I have a Linux server sitting next to it
xes__ is now known as xes
techping has quit [Remote host closed the connection]
<wens>
Net147: my Linux server is a VM somewhere else :)
<Net147>
I use Windows for music not gaming
yann has joined #linux-sunxi
xes_ has joined #linux-sunxi
<oliv3r>
i've played an mmorpg via wine for years
<oliv3r>
was actually more stable then the under windows :D
<wens>
well I rarely have it crash, unless it's the machine overheating
xes has quit [Ping timeout: 255 seconds]
<wens>
Net147: purely playing music is ok on either platform I guess
<wens>
hmm, RX underflow fixed, now it's TX overflow :/
<Net147>
wens: music production
<oliv3r>
well this was years ago, when vista was the big thing and the early win7's; i suppose now it is more stable
<wens>
Net147: I'm think using the FIFO_LEVEL value as the read/write length is better?
<Net147>
wens: I was using that before... but it was in another register
<Net147>
wens: the idea of using the threshold is you know the fifo_level is at least a certain level and it is in same register as the error status
chlorine has joined #linux-sunxi
chlorine_ has joined #linux-sunxi
<Net147>
wens: the logic goes like this. rx_threshold is 15, so fifo request bit will be set when fifo is full (16 bytes). so it will read in 16 byte chunks, resetting the fifo request bit after each read. if the read length is not a multiple of 16, the last read will not be 16 bytes so instead of the fifo request bit being set, the transfer complete bit will be set.
<Net147>
wens: as a sanity check - before readsb, check that fifo_level == len, before writesb, check that 16 - fifo_level == len
chlorine has quit [Ping timeout: 248 seconds]
Leepty has joined #linux-sunxi
<Net147>
wens: actually before writesb, check that 32 - fifo_level == len. as fifo size is 32 bytes.
LargePrime has quit [Ping timeout: 276 seconds]
tom_nov_cz has quit [Quit: Leaving]
<wens>
Net147: it only has 16 bytes of space IIRC
tom_nov has joined #linux-sunxi
<Net147>
wens: oh yes you are right. was confused there for a moment.
<Net147>
wens: SUN4I_HDMI_DDC_FIFO_SIZE is 16
<Net147>
wens: the logic for writing is similar in that it writes in 16 byte chunks. the tx_threshold is 1 so it will be set when fifo_level < 1 (when fifo is empty). it waits for this bit before writing.
BenG83 has quit [Quit: Leaving]
<wens>
argh, FIFO_LEVEL doesn't really work on A31 :(
LargePrime has joined #linux-sunxi
<Net147>
they broke it?
<wens>
don't know
msimpson has joined #linux-sunxi
<Net147>
what do you expect the fifo level to be and what does it tell you?
<Net147>
A31 has separate fifo levels for RX and TX. A20 has combined fifo level.
<wens>
it's all 0
<wens>
I'm now resorting to printing the raw value
lemonzest has joined #linux-sunxi
afaerber has quit [Quit: Leaving]
diego_r has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 258 seconds]
Gerwin_J has joined #linux-sunxi
<wens>
Net147: seems like the bit offsets in the manual for RX part is wrong
<wens>
also it seems on the A31, FIFO size > 16
<Net147>
wens: what is the actual FIFO size?
<wens>
probably 32? I get a FIFO level of 20 when I read
<Net147>
wens: you can set the read length to something like 128 bytes, start the command, wait a bit and then read the FIFO level
<Net147>
wens: 0x20 is 32
<wens>
I meant decimal 20, 0x14 in heximal
popolon has joined #linux-sunxi
<Net147>
hmm... I get 32 as well
<wens>
well it kind of makes sense
<wens>
if you set the threshold to >= 32, by the time you get around to read from it, it would've already overflowed
<Net147>
wens: fifo status register reads 0x00000020
<Net147>
mripard: wens: SUN4I_HDMI_DDC_FIFO_SIZE was incorrectly set at 16 in the original code then...
<wens>
Net147: I think that was originally from Allwinner's kernel
<wens>
but they used the explicit E-DDC read command
<wens>
IMHO it is much easier to program
<Net147>
explicit read just does the write to set the address to read from automatically for you
<Net147>
Linux already has E-DDC handling on top of the I2C adapter
<wens>
what is supposed to happen if a read falls short
BenG83 has joined #linux-sunxi
<wens>
seems like the read falls short for the second segment
<Net147>
if the read falls short of the threshold, transfer complete bit is set
<wens>
but you still try to read 16 bytes, and then it underflows, and returns an error
<Net147>
no, it is limited by len
<wens>
what I meant was the request is for len amount of bytes, but the request only returns < len of bytes
<Net147>
in the for loop, the number of bytes remaining to transfer is passed to fifo_transfer
<wens>
what then?
<Net147>
that would indicate the thresholds are incorrect
<Net147>
do the thresholds, request bit and fifo levels match up?
<wens>
even getting bus arbitration errors... wha?
afaerber has joined #linux-sunxi
<Net147>
wens: I wonder if the incorrect SUN4I_HDMI_DDC_FIFO_SIZE really causes any problems though
<Net147>
wens: it would just mean it would write at most 16 bytes at a time instead of 32
<wens>
right, it's not a big deal
tlwoerner has quit [Quit: Leaving]
<Net147>
then even if it was at 32, the thresholds would limit it such that max read size is 16 and max write size is 32
<Net147>
instead of max read size of 16 and max write size of 16
<wens>
ok
<wens>
works with 256 byte EDID
<wens>
seems that the DDC controller isn't very stable
<wens>
(or maybe it's because of the tons of printk calls)
<Net147>
the printk calls shouldn't affect it
<wens>
maybe it's the monitor :(
tlwoerner has joined #linux-sunxi
tlwoerner has joined #linux-sunxi
tlwoerner has quit [Changing host]
<Net147>
would using interrupts be any better...?
<wens>
I don't know
<Net147>
you would get less delay between the chunks
<wens>
there's also DMA (wink)
<Net147>
if the monitor is sensitive to delays when reading
<Net147>
wens: the monitor has previously worked fine?
<Net147>
it's usually just an EEPROM chip hanging off the DDC pins near the HDMI port on the monitor
<wens>
worked fine with the old E-DDC explicit read code
<wens>
but that was doing 16 byte explicit reads per cycle
<Net147>
so that would have done transactions consisting of 1 byte read + 16 byte read
<Net147>
instead of 1 byte write + delay + 128 byte read (with delay after each 16 bytes)
<Net147>
what is the error you are getting?
<wens>
Net147: bus arbitration error or ack error
<Net147>
:L
<Net147>
wens: I never got errors unless I am writing to a read-only EEPROM or there is no device at the requested address
<Net147>
wens: do you have an A20 device to test with as well?
<Net147>
wens: just to verify if this issue is A31 specific
<Net147>
wens: or an A10s
<Net147>
wens: by the way, clearing the fifo request bit causes it to refresh by updating it from the fifo level and thresholds
<Net147>
wens: it doesn't necessarily clear it to 0, unless the fifo level has changed to make it that way
<wens>
huh?
<Net147>
wens: where it says "Clear FIFO request bit", that causes the FIFO request bit to refresh
<wens>
makes sense
<Net147>
wens: didn't make sense to me when I first looked at it. because I had never worked with interrupt status registers before this.
<wens>
great... very interesting... adding a printk call and printing out a status line right after fifo_transfer makes it work
<Net147>
that happened sometimes to me during development
<Net147>
it means the printk gives it enough time to transfer a byte
<wens>
but fifo_transfer is supposed to wait for FIFO request bit to be set again
<Net147>
unless there is an error or the transfer complete (if remaining bytes less then threshold)
Gerwin_J has quit [Quit: Gerwin_J]
<Net147>
if transfer complete the fifo should be empty after readsb/writesb
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Client Quit]
<wens>
it's reporting underflow _before_ readsb
<Net147>
maybe A31 has different behavior for underflow/overflow?
<Net147>
try ignoring the underflow/overflow bits
<wens>
then I get an invalid EDID block :/
<Net147>
okay, how about if you set both thresholds to 8?
<Net147>
to reduce the chance of the FIFO becoming empty/full
nvz has joined #linux-sunxi
<wens>
funny thing is that fifo level reports 0x20
Gerwin_J has joined #linux-sunxi
<wens>
reducing it to 8 now gives me bus arbitration / ack errors
<wens>
but the first error is still RX underflow
<wens>
maybe the logic is just slow to update the status :/
<Net147>
I would do a read of 8 bytes with RX threshold 4. then read a byte at a time, after each byte check the fifo level and request bit, then clear the request bit.
<Net147>
you should be able to verify if the request bit is being updated correctly depending on the fifo level and RX threshold
leviathan_ has quit [Read error: Connection reset by peer]
<oliv3r>
Net147: not yet, i'll apply it once i get things working again :)
<oliv3r>
Net147: i'm a little supprise that this needs to be solved at the drv level. I would have expected that the generic drm_lastclose would do this anyway
leviathan_ has joined #linux-sunxi
<oliv3r>
bah, i hoped to have found the big in my dt why i wasn't getting the driver up
BenG83 has joined #linux-sunxi
<oliv3r>
alas, no such luck
<oliv3r>
to diff i go
<Net147>
oliv3r: drm_lastclose doesn't have access to drm_fb_helper
JohnDoe_71Rus has joined #linux-sunxi
marble_visions has joined #linux-sunxi
<Net147>
any particular reason why the ICs on the Orange Pi PC 2 are rotated so strangely...?
<oliv3r>
Net147: i forgot the sun7i-a20-backend compatible in the drv!
<oliv3r>
it seems to work now
<MoeIcenowy>
Net147: I think it's because of the compatiblity of the peripherals to original PC
<oliv3r>
diego_r: and i overlooked your ping a while ago
<oliv3r>
i'll ping them i guess :)
<oliv3r>
might need a rebase :(
<diego_r>
oliv3r: don't worry, life's so busy for us all!
<oliv3r>
diego_r: tell me about it :(
<oliv3r>
and the OPi PC2 looks horrendous
<Net147>
oliv3r: only if you are OCD about PCB layouts =D
<oliv3r>
I am :p
<oliv3r>
well it just looks fugly :p
marble_visions has left #linux-sunxi [#linux-sunxi]
marble_visions has joined #linux-sunxi
<oliv3r>
steve jobs did many things wrong, but this was one of those things he was not wrong on :)
chlorin__ has quit [Read error: Connection reset by peer]
chlorine has joined #linux-sunxi
<Net147>
I do like the Realtek logo on their ICs though. it is quite distinctive.
Andy-D_ has joined #linux-sunxi
<Net147>
wens: any luck with the thresholds?
<wens>
well they look correct
<wens>
I still don't understand why it doesn't work reliably
<Net147>
does the request bit behave as expected with regard to the fifo level and thresholds?
<wens>
yes
Andy-D has quit [Ping timeout: 268 seconds]
<Net147>
I guess should work out whether it is specific to the A31 implementation or whether it affects A20 as well? then we know if it is the SoC or the monitor.
cnxsoft has quit [Quit: cnxsoft]
<Net147>
so you are still getting bus arbitration error or ack error?
BenG83_ has joined #linux-sunxi
BenG83 has quit [Ping timeout: 240 seconds]
<oliv3r>
Net147: the 'crab'?
<Net147>
oliv3r: yep
<oliv3r>
Net147: what's the latest version of your ddc -> i2c patches? as i want to test those too
<oliv3r>
Net147: i appreciate it that they are still using the same logo after all these years :)
<Net147>
oliv3r: from their about page - "Through strength, persistence, and adaptability, Realtek follows in the spirit of the crab"
<Net147>
oliv3r: it works fine for me if I do that on Intel desktop using qmlscene
<oliv3r>
it works great, just slow :p
<Net147>
oliv3r: switches back without leaving any trace of the app graphics. I am just rendering a 100x100 red rectangle though
<oliv3r>
hmm my logs are being spammeed with: [drm:drm_update_vblank_count [drm]] updating vblank count on crtc 0: current=10658, diff=1, hw=0 hw_last=0
<oliv3r>
where the current is increasing fast
<oliv3r>
but first, i'll checkout your ddc bus code :)
<Net147>
oliv3r: well it increments for every frame so...
dave0x6d has quit [Quit: Connection closed for inactivity]
<oliv3r>
ah ok
<Net147>
oliv3r: maybe your drm debug level is too high?
<Net147>
oliv3r: I have it set to 0xdf. /sys/module/drm/parameters/debug is 223.
<oliv3r>
Net147: ah, true, i have set it to 0xff
<oliv3r>
there, 0 is som uch more quiet :)
<oliv3r>
so it went to to 27 fp snow
reinforce has quit [Quit: Leaving.]
<oliv3r>
climbing to 28
chlorine_ has joined #linux-sunxi
willmore has quit [Ping timeout: 255 seconds]
<oliv3r>
it's going to hit 30 fps in a min
chlorine has quit [Ping timeout: 240 seconds]
jernej has joined #linux-sunxi
chlorine_ has quit [Ping timeout: 240 seconds]
<oliv3r>
Net147: by turning hdmi into a proper i2c device, do I also get userspace access?
<wens>
yes
<oliv3r>
so how does this fit into the devicetree?
<oliv3r>
normally, I set the status=okay to an i2c node, and put devices underneath it
<wens>
there won't be any devices under it
<oliv3r>
well I need it to have devices :p
<wens>
since it's only used for DDC
<oliv3r>
i want to use it for the backlight i2c driver
<oliv3r>
and for an i2c touchscreen driver
<wens>
why are you abusing the DDC pins from HDMI?!
<wens>
just use the normal I2C controller
<oliv3r>
which costs an extra cable
<oliv3r>
and will have interference issues
<oliv3r>
the HDMI cable is nice and shielded, and will allow for low-speed data
<oliv3r>
the electronics are in the back, the controls are in the front
yann has quit [Ping timeout: 260 seconds]
<oliv3r>
running an i2c wire just for the backlight is silly :p
chlorine has joined #linux-sunxi
chlorine_ has joined #linux-sunxi
<wens>
not really
<oliv3r>
wens well, monitor manufactures equally abuse this :p
<oliv3r>
as they also put controls there
<Net147>
do Intel, ATI, NVIDIA let you do this through device tree?
<oliv3r>
no idea
<oliv3r>
they probably never thought of it :p
<oliv3r>
in a tablet it's less of an issue
<oliv3r>
but it's technically possible, so why not
<oliv3r>
the only argument against it would be from an electronical engineerings standpoint (weak drivers etc)
<oliv3r>
Net147: how is the patch related only to the A10s and not other sunxi chips btw?
<wens>
because the other chips are not supported yet
<oliv3r>
ahh ok
<wens>
you don't see compatibles for a10/a20/a31, do you?
chlorine has quit [Ping timeout: 240 seconds]
<oliv3r>
i was just looking for that
willmore has joined #linux-sunxi
<oliv3r>
well i know Net147 has added hdmi support in his branch for the a20
<wens>
that still depends on plaes' ccu patches getting merged first
<Net147>
It is a work in progress
<oliv3r>
wens: i have those locally :)
<wens>
otherwise, a20 hdmi is basically the same as a10s
<wens>
the display pipelines is a different story
<oliv3r>
right now, i just need to do a feasability study, see if we can get drm on the a20 working
<wens>
AFAIK it shouldn't be hard
<oliv3r>
well i have drm on the a20 on the LCD interface
<oliv3r>
so now doing the hdmi patches
<oliv3r>
and after that the i2c patches
<Net147>
what kind of monitor you will be using?
<oliv3r>
no monitor
<oliv3r>
it will be a custom pcb
<wens>
if you're not doing multiple pipelines at the same time, existing code would just work
<oliv3r>
with a 800x300 res touchscreen
<wens>
if you are, there's still some work to do
<oliv3r>
wens: just single pipe atm
<Net147>
so you're not sending any image over HDMI?
<oliv3r>
Net147: well yeah, HDMI -> i2c + rgb
<oliv3r>
so the LCD will connect to the RGB, the eeprom + leddriver for the BL and the touschreen will go over i2c
<Net147>
oliv3r: single display should work fine with LCD
<oliv3r>
if it will turn out to be impossible; we'll likley add a USB hub and an usb -> i2c chip or something
<oliv3r>
Net147: yeah, except for performance atm, it works great
<oliv3r>
both fb and dri that is
<oliv3r>
going to hdmi now
<Net147>
oliv3r: you could use Mali for that
<oliv3r>
not going to do a binary blob :p
<oliv3r>
so unless yuq finishes his work :p
<oliv3r>
i'm just pondering why drm is 110 FPS slower then fb
<Net147>
oliv3r: it is locked to vsync
kelvan has quit [Remote host closed the connection]
yann has joined #linux-sunxi
<oliv3r>
Net147: yeah but a) cpu usage is the same; b) i would then expect it to be stable at 60 (or 30) but not start at 20 and then slowly move up to 29
<oliv3r>
i'll see if it passes 30fps overnight though :)
<oliv3r>
(the reason we started the drm excersize is because we want pageflipping/tearfree/vsync)
f0xx has quit [Ping timeout: 240 seconds]
<Net147>
is the tearing significant at the moment?
<oliv3r>
very
<oliv3r>
it looks very very bad with just fb0
marble_visions has left #linux-sunxi [#linux-sunxi]
<Net147>
Also keep in mind HDMI cables are not the best at staying securely plugged in
<oliv3r>
yeah i know
<oliv3r>
but our mechanical engineers will address that hopefully :p
fkluknav has quit [Ping timeout: 260 seconds]
<MoeIcenowy>
mripard: I found something interesting -- Nano Pi NEO2 has no external osc32k!
<MoeIcenowy>
X32KOUT and X32KIN pins are NC
<oliv3r>
ouch
<MoeIcenowy>
So doesn't Nano Pi NEO
lkcl has quit [Ping timeout: 248 seconds]
<oliv3r>
so no no way to do rtc timekeeping with an RTC battery
<oliv3r>
Net147: are there 3 fixed endpoints for the tcon? e.g. endpoint@0 is always the tve, endpoint@1 is always the RGB and endpoint@2 is always HDMI?
<Net147>
oliv3r: I forget, maybe check the binding documentation? I think wens may have changed the endpoint numbering scheme.
jernej has quit [Ping timeout: 260 seconds]
<Net147>
oliv3r: also check my tcon1 branch as I have both LCD and HDMI enabled there
<oliv3r>
ohh nice
<oliv3r>
Net147: will do
<oliv3r>
Net147: i don't see a tcon1 branch on github
<Net147>
oliv3r: it ends in tcon1
<oliv3r>
yeah not there
<oliv3r>
until i refresh :p
<oliv3r>
ok see it now
<oliv3r>
Net147: what is your branch missing with regards to mripard's for-drm-next branch?
<Net147>
oliv3r: there is still problem of HDMI and LCD both using pll-video0 so the HDMI clock and cause the LCD timing to be somewhat off
<Net147>
oliv3r: mine is based on sunxi-next. I guess you can diff to check
<oliv3r>
rgr, i'll check out your tcon1 branch see if all works
fkluknav has joined #linux-sunxi
<wens>
@0 is always the LCD panel
rocketpenguin has joined #linux-sunxi
<oliv3r>
ok so fixed outputs
<oliv3r>
is it like this in hardware? or is there some configurable mux there?
<oliv3r>
though I don't think it matters anything if they are at fixed poisitions in the dt
<oliv3r>
with LCD panel you mean RGB output
<oliv3r>
Net147: why is tcon0 allwiner,tcon-channel = <1>? why are both (tcon0 and tcon1) the same?
<oliv3r>
i'll double check the datasheet in the tcon section
<oliv3r>
i think i saw some diagrams there
<wens>
because both tcons have 2 channels
<wens>
tcon[01]-ch[01]
<wens>
panel outputs are fixed, everything else is muxable
jernej has joined #linux-sunxi
chlorine has joined #linux-sunxi
chlorine_ has quit [Ping timeout: 255 seconds]
fkluknav has quit [Ping timeout: 260 seconds]
chlorine has quit [Ping timeout: 276 seconds]
pmpp_ has quit [Ping timeout: 240 seconds]
pmpp has joined #linux-sunxi
msimpson has quit [Quit: Leaving]
Dweebs has joined #linux-sunxi
Dweebs has quit [Client Quit]
reinforce has joined #linux-sunxi
jstein has joined #linux-sunxi
jernej has quit [Ping timeout: 268 seconds]
jernej has joined #linux-sunxi
chlorine has joined #linux-sunxi
chlorine has quit [Read error: Connection reset by peer]
chlorine_ has joined #linux-sunxi
willmore has quit [Quit: Leaving]
lemonzest has quit [Quit: Quitting]
<adfad666>
On Linux master the SPI Nor for Orange Pi Zero patch was merged but with status = "disabled";
<adfad666>
does this mean I need to edit the dts file to enable the SPI or is there another way to enable it without editing the file?
engideavr has quit [Quit: Konversation terminated!]
Striktarn has joined #linux-sunxi
jernej has quit [Ping timeout: 240 seconds]
tom_nov has quit [Quit: Leaving]
vagrantc has joined #linux-sunxi
chlorine_ has quit [Ping timeout: 255 seconds]
lkcl has joined #linux-sunxi
chlorine has joined #linux-sunxi
kivutar has quit [Ping timeout: 255 seconds]
yann has quit [Ping timeout: 268 seconds]
kivutar has joined #linux-sunxi
kelvan has joined #linux-sunxi
netlynx has joined #linux-sunxi
chlorine has quit [Ping timeout: 240 seconds]
jernej has joined #linux-sunxi
jernej has quit [Ping timeout: 240 seconds]
chlorine has joined #linux-sunxi
chlorine has quit [Ping timeout: 240 seconds]
Striktarn has quit [Quit: Leaving]
rocketpenguin has quit [Quit: WeeChat 1.7.1]
dev1990 has quit [Remote host closed the connection]
dev1990 has joined #linux-sunxi
marble_visions has joined #linux-sunxi
yann has joined #linux-sunxi
f0xx has joined #linux-sunxi
f0xx has quit [Ping timeout: 246 seconds]
marble_visions has left #linux-sunxi [#linux-sunxi]