hramrach_ has quit [Remote host closed the connection]
hramrach_ has joined #linux-sunxi
tinti has quit [Quit: Leaving]
rellla_ has joined #linux-sunxi
rellla has quit [Ping timeout: 248 seconds]
<WarheadsSE>
Turl: ping
<WarheadsSE>
Turl: sorry, was AFK for most of the weekend
<Turl>
WarheadsSE: pong
<Turl>
WarheadsSE: np
<Turl>
WarheadsSE: I wanted to know if firefox is available on ALARM
<WarheadsSE>
v7
<WarheadsSE>
let me check
<WarheadsSE>
It was having issues building a while back
<WarheadsSE>
currently in skipped
<WarheadsSE>
aka do not auto-build
<Turl>
ok, thanks WarheadsSE
<Turl>
good night :)
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
luoyi has quit [Ping timeout: 248 seconds]
drachensun has quit [Ping timeout: 256 seconds]
dwilkins has quit [Ping timeout: 245 seconds]
dwilkins has joined #linux-sunxi
drachensun has joined #linux-sunxi
Yaku has quit [Read error: Connection reset by peer]
theOzzieRat has quit [Ping timeout: 252 seconds]
theOzzieRat has joined #linux-sunxi
luoyi has joined #linux-sunxi
n01 has joined #linux-sunxi
n01 has quit [Client Quit]
n01 has joined #linux-sunxi
n01 has quit [Client Quit]
n01 has joined #linux-sunxi
sanka has joined #linux-sunxi
<hramrach_>
rellla_: found that mkvs it's mkvs with subtitles that play invisible unless X server is running
<hramrach_>
so there really is stacking problem with xbmc
<hramrach_>
also for some reason xbms suddenly insisted on running in a small 720x480 window at the lower left of the screen
<hramrach_>
had to manually edit the config to get it show back fulscreen
<hramrach_>
also seems that once the disp layers are initialized that way they stay broken. even vlc does not show anything then and starting the X server after the fact does not help
<hramrach_>
huh, maybe it is just a file CedarX cannot decode
<hramrach_>
there are so many bugs you never know what you are seeing :(
FunkyPenguin has quit [Remote host closed the connection]
forcev is now known as FunkyPenguin
FunkyPenguin has quit [Changing host]
FunkyPenguin has joined #linux-sunxi
BJfreeman has quit [Ping timeout: 248 seconds]
<hramrach_>
see video-samples repo for a short clip which fails to decode :s
_BJfreeman has joined #linux-sunxi
shineworld has joined #linux-sunxi
Yaku321 has joined #linux-sunxi
<rellla_>
hramrach_: godd morning. i cannot download the newest file: FORBIDDEN
<rellla_>
no problem in playing and replaying the others with libhybris. fyi i recently added some more codecs on stage/Frodo branch
rellla_ is now known as rellla
paulk-desktop has joined #linux-sunxi
_BJfreeman has quit [Ping timeout: 260 seconds]
_BJfreeman has joined #linux-sunxi
_BJfreeman is now known as BJfreeman
shineworld has quit [Remote host closed the connection]
wingrime-android has quit [Remote host closed the connection]
mab_ has joined #linux-sunxi
<hramrach_>
rellla: I have no idea why it would forbid it
<hramrach_>
any good place to upload?
<hramrach_>
should be downloadeble now
<hramrach_>
seems downloadeble blobs are limited to 10MB
<hramrach_>
hmm, can't build new xbmc right now
<hramrach_>
have the disk with the sources somewhere in a box
Yaku321 has quit [Ping timeout: 248 seconds]
tinti has joined #linux-sunxi
<oliv3r>
hno: ping
tinti has quit [Read error: Operation timed out]
<oliv3r>
is there any way, some setting, either in the PHY chip or in the A10; that can 'remember' certain things that do not reset during a full power cycle?
<oliv3r>
Anything other then nand/mmc flash
<n01>
oliv3r: fuse?
<oliv3r>
could it be that something has changed something with regards to the emac + phy? or are chances that the PHY or EMAC is simply broken
<oliv3r>
n01: yep, but afaik the fuses aren't influencing the emac/phy
tinti has joined #linux-sunxi
<n01>
sometimes fuses are used to store the mac AFAIK
<hramrach_>
but our driver does not seem to do that
<oliv3r>
far from
<oliv3r>
anyway, nand android used to work; but can't get lan to work at all
<hramrach_>
also check cables ;-)
<oliv3r>
lol
<oliv3r>
yeah but mac driver crashes constantly
<oliv3r>
crash, restart, crash; slowing down the board horribly
<oliv3r>
console is spammed
<oliv3r>
with or without cable
<hramrach_>
that should not be cables then
<hramrach_>
fex could cause that too but that's suff in flash
mab_ has quit [Remote host closed the connection]
<oliv3r>
yeah i didn't touch that
<hno>
oliv3r?
<hno>
There is nothing (except NAND/MMC/efuses) that surives a full power cycle, but as long as there is power there is persistent registers both in the AXP209 companion and in the RTC embedded in the A10.
<hno>
one of them have any effect on PHY or emac.
<hno>
none of them...
Yaku321 has joined #linux-sunxi
<oliv3r>
hno: you are the u-boot expert here, how do i use 'mii *' it wants an address and register, and while I can get registers from the phy datasheet; no clue what to use for address
<oliv3r>
hno: yeah i'm affraid that my phy/mac is somehow broken, or misconfigured, but that should have reset on power cycle
<hno>
oliv3r, address is the PHY address on the MII bus. You can use "mii info" without address to list the available PHYs. On cubieboard the PHY have address 1.
<oliv3r>
ah, so address is always 1
<hno>
It's the address of the PHY as a whole. There may be more than one PHY on the same MII bus
<oliv3r>
okay
<oliv3r>
makes sense
<oliv3r>
what does u-boot's mii command us by default? 1?
<oliv3r>
also why not 0? just curious
<hno>
The address is wired in the hardware.
<hno>
there is no default. mii scans the bus.
eebrah|away is now known as eebrah
<oliv3r>
mii info 1; no output
<oliv3r>
mii read 1 0; mii read 1 15; all output '0xffff
<oliv3r>
mii dump 1 0; also outputs 0.(ffff) and shows '1' for every option in the dump
<hno>
oliv3r, what does "mii info" without address show?
<oliv3r>
nothing
* mnemoc
wonders how the A20 does Gb ethernet over mii
<oliv3r>
gmii!
<hno>
do the leds light up when you connect the cable?
<oliv3r>
nope
<mnemoc>
oliv3r: is it magicaly backward compatible?
<mnemoc>
oliv3r: the cbii uses the same phy as the a10 variant
<oliv3r>
gmii is backwards compatible
<hno>
MII is only PHY control. There is no data traffic on the MII bus.
<mnemoc>
i see
<mnemoc>
but then... why two different drivers in the sun7i tree?
<oliv3r>
copy paste
<oliv3r>
rename
<oliv3r>
instead of git mv
<mnemoc>
so a20 and a31 have sunxi-gmac, period. no dual identity
<oliv3r>
i was reading the wiki on mii, gmii rmii rgmii etc, and it should be all nearly compatible
<hno>
Yes.
<oliv3r>
i think you can connect a mii, to a gmac
<hno>
And I meant MII management bus above.
<oliv3r>
hno: so i'll try a nother cable (though i'm certain this one works, on a different port on my switch) and that's that. if that doesn't work, i fried my phy/emac somehow?
<oliv3r>
i just can't imagine how :S
<hno>
oliv3r, It's not the cable. mii command reads data even without cable connected.
<oliv3r>
and lights come on/off too I assume
<oliv3r>
because the phy does that bit
<oliv3r>
it could not possibly be a powering issue of the mii?
<oliv3r>
er phy
<mnemoc>
btw, now that github supports redirects. should I rename the linux-sunxi orga to just sunxi ?
<hno>
oliv3r, could be, but you said it worked before.
<hno>
oliv3r, Mele do have GPIO power control of the PHY, and Cubieboard schematics is prepared for the same but at least the board I have have the PHY hardwired on.
<mnemoc>
i doubt they save much power turning off the phy...
<hno>
oliv3r, if it's cubieboard then try "gpio set ph19" in case your board have the PHY power control bit soldered.
<hno>
oliv3r, any thunder in the area recently?
hglm has joined #linux-sunxi
<oliv3r>
mnemoc: probably not bad
<oliv3r>
hno: not yet, but it has started to rain just now
<oliv3r>
cats came in
<oliv3r>
oh you mean cause of the phy
<oliv3r>
erm, nope, and it was disconnected meanwhile
<oliv3r>
the cubie is connected through a cheap adapter; the lan is connected to my HP switch which is on a UPS
<oliv3r>
gpio set, is that a u-boot command?
<hno>
oliv3r, yes
<mnemoc>
phy-frying-proof
<oliv3r>
gpio: pin ph19 (gpio 243) value is 1
<oliv3r>
well the cheap power might do nasty things :p
<oliv3r>
but there was no thunder, and I turn off the outlet to which it is connected
<oliv3r>
hno: no change with that
<hno>
oliv3r, :(
<oliv3r>
i just wonder if it's something I did (poking registers) or it just ... died
<hno>
Haven't heard of PHY chips dying by poking their registers
<oliv3r>
well poking a10 registers
<oliv3r>
ccm; is one
<mnemoc>
iirc there is a laptop of a big brand who was briked by gregkh by *reading* uefi registers
<mnemoc>
s/who/which/
<oliv3r>
samsung, yeah; but their uefi was broken
<oliv3r>
not enough memory :)
<mnemoc>
broken software or not. bricking by *reading* memory???
<mnemoc>
so it's a proposed name for the RE project
<ssvb>
ok :)
<ssvb>
hglm: hi
* mnemoc
wonders if libhybris has RE-friendly features
<ssvb>
mnemoc: what's wrong with initially using the native blob? other than thumb2 code which is causing some troubles for the current https://github.com/iainb/CedarXWrapper
<hglm>
ssvb: Hi. It's been fun experimenting with the X driver.
<mnemoc>
ssvb: i don't know. we've always assumed the android driver to have better quality than the armhf tom got
<ssvb>
mnemoc: the armhf blob has problems with some types of h.264 videos, but this is not critical for RE work
<mnemoc>
:)
<ssvb>
I guess one would start with simpler codecs anyway
<mnemoc>
+1
<ssvb>
hglm: yes, it is surely fun
<ssvb>
hglm: have you tried 50Hz refresh rate for 1920x1080?
<mnemoc>
wingrime started trying to decode jpeg
<oliv3r>
i belive we thought mpeg would be easier, as jpeg is a subset of mpeg
<oliv3r>
jpeg uses the mpeg engine
<oliv3r>
either/or
<hglm>
ssvb: Not yet, not sure my monitor supports it. I may have an aversion to low refresh rates due to dealing with CRTs in the past :)
<ssvb>
hglm: just try it, in the worst case the monitor will refuse it with something like "out of range" error message :)
<ssvb>
hglm: LCDs are a bit different, 60Hz also used to be bad on CRT
<hglm>
ssvb: It seems to work, I'll check the memory bandwidth.
<ssvb>
hglm: and you also need 432+ memory clock frequency to get the best results
<ssvb>
hglm: driving 1920x1080 monitor at 60Hz and 32bpp is degrading memory speed a lot even with 480MHz dram clock
<hglm>
ssvb: I'm running 1920x1080 at 16bpp now (50 Hz).
<ssvb>
hglm: ok, makes sense
<ssvb>
hglm: but many people would still use 32bpp by default or because of thinking that it is better for them
eebrah is now known as eebrah|away
<ssvb>
hglm: I'm currently looking at EDID parsing code to check if we can maybe automatically make it prefer 50Hz if this refresh rate is supported
Yaku-noob has joined #linux-sunxi
Yaku321 has quit [Disconnected by services]
<hglm>
ssvb: That makes sense I guess. BTW: tinymembench shows a big jump running at 50 Hz (1920x1080x16bpp) compared to 60 Hz, 20% faster copy.
<ssvb>
hglm: for 32bpp graphics, we could probably also use some sort of shadowfb alike hack with the real framebuffer configured as 24bpp (3 bytes per pixel)
<oliv3r>
as expected, cable works perfectly fine in my laptop
<oliv3r>
:(
<hglm>
ssvb: So sunxi really supports 24bpp natively? I wouldn't be easy/possible to integrate with other video components (console, VE, G2D, Mali) though.
<ssvb>
hglm: hmm, or maybe not, somehow I thought that the display controller supported 24bpp for scanout
<hglm>
ssvb: the pixel format flag for 24bpp exists, not sure it would work. The chip does support a lot of formats.
<slapin_nb>
hi, all!
* slapin_nb
needs to write hw-accelerated video encoder on top of cedarx by the weekend, any pointers?
<mnemoc>
the docu on github?
<ssvb>
hglm: yes, 3 bytes per pixel framebuffer seems to work, got a bit of doubt when trying to verify it because of a glitch
<hglm>
ssvb: 24bpp is never easy to test, the pixels are a little awkard :)
<ssvb>
hglm: I agree that it's a pita to work with, that's why a shadow framebuffer using 32bpp format could be used with real 24bpp framebuffer
<hglm>
ssvb: I see. Does xorg still support 24bpp?
<ssvb>
hglm: but this brights all the shadowfb drawbacks and disables G2D acceleration :)
<ssvb>
hglm: the xorg does not need to care, it will only see and work with the 32bpp shadow framebuffer
<ssvb>
hglm: we need to only override the part which does shadowfb->framebuffer copy and replace it with 32bpp->24bpp conversion
<hglm>
ssvb: I get it, that would be doable. And 32bpp->24bpp is fast when done efficiently (probably asm).
<ssvb>
hglm: yes, NEON optimized 32bpp->24bpp conversion is faster than 32bpp->32bpp copy
* hno
considers 24bpp trivial. Still remembers HAM mode from the Amiga.
<slapin_nb>
neon copy is fast, too
sanka has quit [Quit: Leaving]
<ssvb>
slapin_nb: it is limited by memory bandwidth, 32bpp->24bpp conversion needs less bandwidth
<ssvb>
the same applies to rgba8888 <-> rgb565 conversion
<hglm>
It seems the linux console supports 24bpp also.
<hramrach_>
PC cards are not so much bandwidth constrained so 32bit is usually faster
<hramrach_>
easier to work with
<hramrach_>
it's mostly supported still
<ssvb>
hramrach_: are you familiar with EDID code?
<hglm>
24bpp console mode is running fine here, I need to set the refresh rate to 50 Hz to get decent memory copy bandwidth, it seems at 60 Hz there's some kind of bottleneck (with memory clock 408).
<ssvb>
both my LCD monitors report 56Hz as the minimal supported refresh rate in EDID, but actually work with 50Hz :(
<hglm>
I guess monitors targeted at the PC market may not support HDMI TV modes. It may be a limitation of LCD circuitry or the system software inside the monitor. My monitor supports 50 Hz and 60 Hz (it has DVI and HDMI inputs).
wingrime-android has joined #linux-sunxi
<ssvb>
my monitors also have HDMI connectors
<ssvb>
the issue is that they prefer to lie and pretend that 56Hz is the minimum
<ssvb>
while the real minimum seems to be around 48Hz (tested some time ago with an OMAP3 based board)
<ssvb>
going below the real minimum, the monitor software complains and shows a floating box with something like "signal out of range" message
<hglm>
I also get that, with the actual frequencies specified. Useful for debugging display controllers.
<ssvb>
maybe we should try to construct 1920x1080@56Hz mode and check whether it provides any memory bandwidth improvements compared to 60Hz
<slapin_nb>
rgb565 is not that good mode, if packed, very little software supports it, neither Qt nor Xorg by default. X11 supports it, which is interesting, but RENDER bitmap manipulation library doesn't (forgot the name), so disabling render will make it work...
<ssvb>
slapin_nb: rgb565 is reasonably well supported by Xorg
<slapin_nb>
they don't care for embedded stuff and won't care for it in future, so embedded stuff should grow and suport at least 24-bit packing.
<slapin_nb>
ssvb: last tried it about a month ago, RENDER didn't work
* slapin_nb
tries to remember library name
<ssvb>
slapin_nb: I find it hard to believe
<ssvb>
maybe some applications may have problems (if they insist on making wrong assumptions), but this should not be very common
<slapin_nb>
ah, pixman, yes
<ssvb>
but 24-bit packing is a real PITA, because it is difficult to calculate addresses of the pixels and reading them with a single instruction
<slapin_nb>
no, X11 itself uses color offsets and bit masks, so it will work with any mode, like 333
<ssvb>
slapin_nb: pixman has good rgb565 support
<slapin_nb>
the pixman library wont work (requires patching, I don't remember if I submitted one, or someone lese submitted), and graphic apps who misuse X11 bitmap functions won't work too.
<ssvb>
slapin_nb: just try to find a link to this bug, and I will try to fix it
<slapin_nb>
ssvb: I made it work on PXA 16-bit 565 mode, and 18-bit 666 packed mode, and I know what I am talking about
<slapin_nb>
ssvb: no much need for fixing
<slapin_nb>
ssvb: as all who needed it already have the patch and noone else needs the code
<ssvb>
this reassures me that you are probably misunderstanding something
<slapin_nb>
ssvb: no
<ssvb>
if there is a patch, please let me take a look at it
<slapin_nb>
ssvb: confidential, as it was never released to production (the hardware was converted to be more compatible to stock software), but you can probably google it.
<ssvb>
I can believe that it might be adding an exotic 18-bit mode, but you should have no problems with rgb565 at all
<slapin_nb>
ssvb: I remember both didn't worked (while stock X11 stuff worked fine, only RENDER stuff and what depended on it didn't and various other code, which tried to be too clever).
<slapin_nb>
hmmmmm
<slapin_nb>
ssvb: you're probably right
<slapin_nb>
ssvb: first revision was 666, and a lot of patching was done
<slapin_nb>
ssvb: second was 565, with some pixman patches, but these were bugfixes (crashes), not mode implementation
<slapin_nb>
ssvb: third was 19bit mode, which worked with just pixman patch
<slapin_nb>
ssvb: yes, probably at some state 565 was working
<ssvb>
btw, sunxi disp driver insisted on treating 16bpp modes as rgb555 with unused alpha bit some time ago, which resulted in taking unoptimized code paths
<ssvb>
but this is already fixed
<slapin_nb>
ssvb: pixman is ugly beast, crashes in every non-trivial situation, beware of it, as X11 asusmes every mode wich can be set by offsets and masks is possible, and pixman doesn't check anything
<slapin_nb>
it is better not to step away from piman authors' line of thought
<slapin_nb>
it is where it all started, which ends with systemd and wayland
<slapin_nb>
the ugliness...
<ssvb>
I guess there must be a lot of bugs reported for these crashes, right?
<ssvb>
hopefully not in the secret internal bugtrackers used for developing unreleased hardware
<slapin_nb>
ssvb: dunno, mainstream doesn't use these modes, and embedded used Xfb these days which had it all working, Xorg was too big for these machines at these days...
<slapin_nb>
ssvb: the patches were circulating for Xorg, too, so I picked-up these, as I was on bleeding edge with my requirements
<mnemoc>
afaik xorg-server has a configure option to build it instead of the normal beast
<slapin_nb>
ssvb: that was several years ago don't remember when, as I have no reference, as everything is lost, only some mail remains
Yaku-noob has quit [Ping timeout: 264 seconds]
<ssvb>
several years is a lot of time
<mnemoc>
specially in free-software time
<slapin_nb>
mnemoc: it was considered deprecated long time ago
<slapin_nb>
mnemoc: these days were better
<slapin_nb>
mnemoc: much better
<mnemoc>
slapin_nb: deprecated because it was adopted by xorg-server
<slapin_nb>
mnemoc: normal technologies, etc.
<slapin_nb>
mnemoc: xorg version is considered unsupported IIRC
<slapin_nb>
mnemoc: I mean Xfb one
<slapin_nb>
mnemoc: as they have fbdec driver for normal Xorg, which is not that big actually
<mnemoc>
i don't mean a driver
<mnemoc>
check xorg-server's ./configure
<slapin_nb>
mnemoc: was running fine on PXA270 with 256MB RAM (or something)
<slapin_nb>
mnemoc: I was adviced against it a lot of times by devs
Yaku321 has joined #linux-sunxi
<mnemoc>
they obviusly advertise the usual X, with drivers
<mnemoc>
as it isn't that fat anymore
* slapin_nb
never touched anything from X since 2008
<slapin_nb>
mnemoc: Xorg server is not fat and quite easier to set up and much more featured
<slapin_nb>
mnemoc: Xfb now depends on pixman, too, so it is also taunted.
<slapin_nb>
the problem with X memory consumption is actually apps allocating large bitmaps, rendering all their stuff there, not X itself.
<hglm>
I just ran X in 24bpp mode, it worked, but there were a few rendering problems (lxterminal). I guess 24bpp has few quircks (especially when the default pixmap depth of 32 doesn't correspond to the root window depth of 24).
<slapin_nb>
if doing your system with your apps, you can be as tiny as with 64Mb of RAM and have plenty of funcionality
<slapin_nb>
hglm: there is 2 flavors of 24bpp packed and unpacked one; also the byte order might be different; sometimes for pixman it is different ordering than for X11 (as pixman doesn't care for X's color representation).
<mnemoc>
xorg has changed a lot these years
<slapin_nb>
mnemoc: yes, most devs want to engrave it. X deserves a new development team, definitely... :(
<slapin_nb>
I mean most xorg devs
<slapin_nb>
mnemoc: do you remember the funny bug, somebody broke software line drawing algorithm in X11 and nobody still fixed it, as fixes break nvidia?
<slapin_nb>
mnemoc: can be easily triggered with Kicad.
* slapin_nb
hopes he won't see X11's death
eebrah|away is now known as eebrah
<slapin_nb>
btw, did anybody work on using cedarx as encoder for something?
<Turl>
slapin_nb: android uses it to encode the camera video
wingrime-android has quit [Read error: Connection reset by peer]
wingrime-android has joined #linux-sunxi
<libv>
X is broken
<libv>
üe
<libv>
people have been hard at work for years to break it
<libv>
now those same people are inventing a whole new world...
<libv>
and we're all cheering them on.
<libv>
somehow we still believe them when they state that this time round, things will finally get better
vinifm has joined #linux-sunxi
<vinifm>
ssvb, ping
<ssvb>
hi vinifm
<vinifm>
hi :)
<vinifm>
is it possible to play video using only libvlc?
<ssvb>
just try it to find out
* ssvb
has not
mturquette has joined #linux-sunxi
<vinifm>
i did, but work only using libvlc + libsdl
<nove>
it looks simples, init device, write the bitstream, flip register, write the conficientes, flip registers, and the decoded frame appears
<nove>
yes cedar
<mnemoc>
people working on REing cedarx should really start to team up....
<mnemoc>
i think wingrime has a working jpeg decoder, but not sure
<mnemoc>
nove: can you send the link to your project and some introduction to it and what you have already achived to the sunxi ML?
<nove>
i am interested to contribute for the REing, but not enough time (to take the leader of the project)
<nove>
ok
<nove>
s/leader/leadership
shineworld has joined #linux-sunxi
<ssvb>
nove: thanks for the link, I'll check it a bit later, it's nice to see you here again :)
rellla has quit [Remote host closed the connection]
<mnemoc>
nove: please stay here. so you can talk with other devs also working on cedarx :)
<nove>
not much time to stay idle
mturquette has quit [Quit: leaving]
ZaEarl has joined #linux-sunxi
<mnemoc>
just leave an irssi running and periodically check for messages ;-)
<mnemoc>
no need to be staring at the window
mab_ has joined #linux-sunxi
booss has joined #linux-sunxi
<nove>
there is also the logs.
<hno>
valgrind works well on ARM?
<mnemoc>
true. but people won't tell you things if you aren't here
<nove>
it works
<hno>
Nice. Must play more with that. Use it a lot on x86. hadn't realized ARM support had matured to a usable state.
<hno>
Even an Android version it seems.
<nove>
but the part to inject the trace function, is black magic
<mnemoc>
wiki wiki :)
<nove>
worked well in i386, but in arm crash badly
<nove>
it has no documentation i have to grep the source code
<nove>
to know what can be done
<hno>
Even if it has quirks it's a really cool application of valgrind.
* mnemoc
never thought valgrind was usable for that
<hno>
valgrind is at the core an instrumented CPU emulator. Can do many things you never thought of.
<hno>
such as this.
<hno>
nove, any plans on submitting this tool to valgrind?
<nove>
i looked at qemu, it can also be used, but don't have instrumentation included
<nove>
no, valgrind has plenty of tools already
<nove>
in other words, there is no time to make the tool for generic use
mab_ has quit [Ping timeout: 248 seconds]
<hglm>
ssvb: I implemented 16bpp G2D Fillrect using 32bpp pixel format in up to three segments, it works pretty well for large triangles (double the throughput), for smaller triangles (100x100) I think the non-sequential memory access when drawing the edges makes the gain smaller
<nove>
the cedar hardware looks robust, till now never made the system crash
<nove>
and that includes bugged reads,writes to random registers
<hno>
nove, ok.
<hno>
nove, yes, the cedarx is probably quite robust. I think the issues seen is in DMA mapping rather than CedarX.
<ssvb>
hglm: 56Hz ("valid" according to EDID data of most monitors) might be useful for cubieboard, because it runs memory at 480MHz
<ssvb>
hglm: it would be also interesting to try reduced blanking modes, because with lower pixel clock they should be stressing the RAM a bit less intensively
<hglm>
ssvb: Reduced blanking has to do with mode timings?
<ssvb>
I'm a total noob at this stuff, but my understanding is that normally there is a significant delay between the end of the previous frame and the start of the next frame (CRT monitors legacy)
<ssvb>
which means that the pixels are processed faster while the refresh is being done and then the hardware is idle for a while between frames
<ssvb>
reduced blanking modes should make stressing the RAM a bit more uniform on average
<hglm>
I see, I'm sure whether most monitors like reduced blanking. It shouldn't matter much for an LCD I guess.
<mnemoc>
hno: I've never worked with registers before, does this mess count as "decent" at least? http://sprunge.us/UfCO
<ssvb>
some monitors or TV may be incompatible, but we never know until we try
<ssvb>
right now we have a major problem with the "user friendly" distros using EDID settings by default, which just ends up as 1920x1080-32@60Hz mode for many users
<ssvb>
and the 2D performance takes a nose dive
mab_ has joined #linux-sunxi
vinifm has quit [Remote host closed the connection]
<hno>
mnemoc, looks decent to me.
<mnemoc>
hno: awesome. thanks :)
<hglm>
ssvb: I guess there could be room for improvement for the easiness with which the boot-up mode is selected. I have written a program to change modes at run-time, but that's not ideal.
mab_ has quit [Ping timeout: 256 seconds]
<hno>
mnemoc, does it work?
<mnemoc>
hno: on my cubie and a13-olinuxino it does
<hno>
Good. Was a little worried a memory barrier or delay may be needed between the write & read.
<mnemoc>
i'm doing it after the iomap()
<mnemoc>
don't know if it's affecting something
<hno>
it's fine. readl() has an implicit memory barrier in the kernel to guarantee ordering.
JonnyH has quit [Quit: leaving]
tinti has quit [Quit: Leaving]
shineworld has quit [Remote host closed the connection]
booss has quit [Remote host closed the connection]
user_2 has joined #linux-sunxi
orsic has joined #linux-sunxi
<nove>
end of idle for today, weekdays around this time-4h, will check the logs
nove has quit [Quit: nove]
user_2 has quit [Remote host closed the connection]
_BJfreeman has joined #linux-sunxi
BJfreeman has quit [Ping timeout: 240 seconds]
user_2 has joined #linux-sunxi
<Turl>
hno: do you know if uboot configures mmc clocks using osc24/hosc?
CaCtus491 has joined #linux-sunxi
tinti has joined #linux-sunxi
<Turl>
anyone with any sunxi handy that can dump me the value of 0x01c20088?
hglm has quit [Quit: leaving]
orsic has quit [Read error: Connection reset by peer]