<RaYmAn>
they added a lot of 2d info to the trm like, months ago
<RaYmAn>
before they were hacked
<hno>
RaYmAn, available without NDA?
<hno>
was NVidia hacked?
<RaYmAn>
I'm not entirely sure whether their online agreement to get an account to download it counts as an NDA or not
<RaYmAn>
they developer site was - it's been mostly down since
eFfeM has left #arm-netbook [#arm-netbook]
mSquare has left #arm-netbook [#arm-netbook]
<hno>
SATA connected via Graphics Memory Interface? Feels kind of like they misnamed that memory bus.
MMlosh has quit [Ping timeout: 260 seconds]
ceo16 has quit [Read error: Connection reset by peer]
ZaEarl has joined #arm-netbook
MMlosh has joined #arm-netbook
cat_x301 has quit [Remote host closed the connection]
cat1 has joined #arm-netbook
rellla has quit [Quit: rellla]
<techn_>
eflatun: hi.. sure I can help :)
<mnemoc>
wb techn_
<techn_>
mnemoc: thanks.. I'll try to push initial edid support today
<mnemoc>
\o/
<techn_>
It's a bit hacky.. Whole disp needs refactoring to get it better
<cat1>
techn_: any chance to send patch(es) to linux-sunxi@googlegroups.com ? at least it will be visible and somebody might want to give some comments if any. Also, one can test patch instantly by applying from mail. Sorry if I ask too much :)
* cat1
thinks that it generally would be good to send all upcoming patches to ml. really.
<mnemoc>
+1
<techn_>
cat1: you can comment on github.com/techn? I'm not much for doing extra work ;)
<techn_>
or to github.com/amery if I'll do pull request? ;)*
<cat1>
techn_: yeah, this will do too.. but..
<techn_>
but sure I can if it's decided and proofed better :)
<cat1>
techn_: to me it is more trackable. e.g. one will know what patches are flying around and can pick them into own tree if needed. i am not sure if one e.g. can apply a single patch from github directly.
<techn_>
cat1: so can you tell what's better on mailing list code review? (newer done that.. expect stypid excel/beyond compare reviews)
<techn_>
cat1: you can take patches out from github
<cat1>
techn_: hmm.. it is difficult to explain, but you can do inline comments and keep discussion in i would say more "natural" way :)
<mnemoc>
git even knows to send commits by email specially for that
<mnemoc>
techn_: it's not that. from git a hash can be deleted and lost
<cat1>
techn_: check git send-email
<mnemoc>
techn_: or rebased and new hash assigned
<mnemoc>
on email the real history of the commit is preserved
<mnemoc>
including the whole discussion
gimli has quit [Ping timeout: 248 seconds]
<cat1>
mnemoc: right, and then again, it is easy to check patch w/o getting it commited into mailline (amery/..)
<mnemoc>
cat1: fully agree. I'm all in favour of the ML
<cat1>
s/mailline/mainline
eflatun has quit [Ping timeout: 246 seconds]
eflatun has joined #arm-netbook
<cat1>
techn_: btw, it is also good practise to get patch through ./scripts/checkpatch.pl before sending for review.
<techn_>
cat1: ok I'll use ML now on :)
<cat1>
techn_: thanks!
<mnemoc>
cat1: it's complicated consider all old lines don't honor the code style
<mnemoc>
considering*
* cat1
thinks that we are not yet in the stage to give proper review, but at least it would serve a good stimulus to have one in the future.
<cat1>
mnemoc: yeah, but for simple patches it might help
<cat1>
s/simple/small
<cat1>
..or at least it will give submitter the idea on how much work is ahead ;)
<hno>
so someone needs to do the same for X11 EXA.
<mnemoc>
techn wanted to turn g2d into v4l2
<mnemoc>
libv teased with getting someone from his company to do it in a couple of days
<mnemoc>
the exa driver I mean
<hno>
should be pretty straight forward.
<hno>
and also XVideo support should be easy.
<hno>
and hardware mouse pointer.
<hno>
hardware mouse pointer is done by disp however, not g2d.
eflatun__ has joined #arm-netbook
eflatun_ has quit [Ping timeout: 246 seconds]
<hno>
XVideo is also disp, but can also be done by g2d. A bit of overlap there in the silicon.
<mnemoc>
I supose the disp driver should use the g2d driver
<techn_>
yep.. it could be done
zewelor_ has quit [Ping timeout: 246 seconds]
<techn_>
during probe, check if g2d module available.. if it is use own blit, etc.. if not use kernels
<techn_>
and own is just wrapper for g2d implementation
zewelor has joined #arm-netbook
<techn_>
but then again.. how memory is mapped?
ibrah has quit [Ping timeout: 240 seconds]
eflatun__ has quit [Remote host closed the connection]
<mnemoc>
it's reserved in core.c
eflatun__ has joined #arm-netbook
<mnemoc>
before the MMU gets initialized
* mnemoc
hates those reserves
<RaYmAn>
reserve only prevents linux from using it, nothing more (afaik)
<RaYmAn>
"using" - rather, allocating it for stuff
<RaYmAn>
what's wrong with the reserves though?
<RaYmAn>
It's a good thing to reserve stuff :P
<mnemoc>
happens before I change check if the stuff is enabled in script.bin :<
zewelor has quit [Ping timeout: 244 seconds]
<RaYmAn>
ah, right
<mnemoc>
also before we can check the cpu-id
<mnemoc>
the ugliest reserving is for mali, which happens at fixup time. taking the chunk out of meminfo
zewelor has joined #arm-netbook
eflatun__ has quit [Read error: Connection reset by peer]
eflatun__ has joined #arm-netbook
<hno>
yes the mali reservation is ugly as hell. If MALI driver need to continue hiding it's memory like this then support needs to be added to u-boot.
eflatun__ has quit [Ping timeout: 256 seconds]
<cat1>
hno: DT?
<mnemoc>
*cough*
* cat1
hides away
<mnemoc>
cat1: beside the greediness in suggesting DT as a fix at this point, mali currently needs the 64M between 448 and 512 to be totally unknown to the kernel
<mnemoc>
reserving it doesn't work
<cat1>
holly crap.
eflatun__ has joined #arm-netbook
<hno>
would love DT support.
<hno>
fact: it's not the kernels job to hide memory from the kernel.
<mnemoc>
+1
<mnemoc>
BUT, how do we do to not-hide it when mail is not enabled?
<mnemoc>
it's not nice to cut 64M out for headless A10s
eflatun__ has quit [Remote host closed the connection]
<mnemoc>
f* mali :<
eflatun__ has joined #arm-netbook
<cat1>
i think is should be configurable
<mnemoc>
cat1: got homework for the weekend :)
<cat1>
mnemoc: list of homeworks is growing exp..ly
<cat1>
;)
<mnemoc>
:)
<cat1>
btw, does SPARSE memory option have anything to do with mem reservation? remember playing with that on octeon boards some years ago..
<hno>
mnemoc, any idea how the memory reservation is handled on other mali implementatios?
<hno>
cat1, not really, unless the sparse memory I know if is something else than you think of.
eflatun__ has quit [Remote host closed the connection]
<mnemoc>
hno: in drivers/gpu/mali/mali/arch/config.h they use OS_MEMORY instead of MEMORY
eflatun__ has joined #arm-netbook
<hno>
mnemoc, they are?
<mnemoc>
hno: but in our case the libs don't work with that :<
<hno>
reserved memory is more reliable when it comes to blob allocations. There is no guarantee you can allocate a contigous blob after the kernel have been running for a while.
<hno>
and 3D is a lot of blob allocations.
<hno>
OS memory ie easier to conifgue however.
<techn_>
hmm.. could kernel even put mali's memory to swap? (dummy question?)
<techn_>
or is it reserved directly from physical memory?
eflatun__ has quit [Remote host closed the connection]
eflatun__ has joined #arm-netbook
<techn_>
i suppose so.. so why there is possibility to get non linear allocation from physical memory?
<hno>
techn_, no.
gimli_ has joined #arm-netbook
<hno>
it's a physical memory reservation.
<hno>
and MALI wan's blobs for to be allocated linearly.
<mnemoc>
a normal reserve should do the job
<mnemoc>
but when doing that the kernel driver fails to allocate it (obviusly)
<mnemoc>
couldn't find how to tell mali it was already reserved
<techn_>
could it be done so that if mali is reserving memory.. kernel reduces/reorders it's own phy memory and gives mali memory it wants
gimli has quit [Ping timeout: 256 seconds]
<techn_>
ah.. so mali reservers memory before kernel get's a change to reserve it's own
<hno>
techn_, kernel can not arbitrarily move it's memory around. The virtual<->physical mapping is linear for the kernel.
<hno>
not like processes where the address space is purely virtual with no relation to physical memory.
<hno>
and yes, mali memory reservation is even before the kernel actually starts for real.
<hno>
done in the early platform fixup code which prepares the system environment for running the kernel.
<hno>
early startup code in kernel image.
RITRedbeard_ has quit [Remote host closed the connection]
<mnemoc>
i think we "only" need to find how to tell drivers/gpu/mali/mali/arch/config.h the memory is already reserved
<mnemoc>
and reserve it in the same way we do for fb/ve/g2d
<mnemoc>
I suppose people from that arm forum can give us a hand on that
<mnemoc>
iirc there others we use "resources" for that
<cat1>
mnemoc: what do you how to tell the memory is reserved? would some exported function from some mali driver, something like mali_reserve_memory() do the magick?
<cat1>
s/what do you/what do you mean
<mnemoc>
cat1: look at drivers/gpu/mali/mali/arch/config.h
<mnemoc>
cat1: the driver uses that to decide how to get the memory and how to use it
<cat1>
mnemoc: i see some static declarations htere
<mnemoc>
that is what I mean by "tell"
<cat1>
so it simply needs to pick up proper config, right?
<mnemoc>
what to write the so the mali driver uses a pre-reserved chunk without failing to try to allocate it
<mnemoc>
cat1: yes, that simple
eflatun has joined #arm-netbook
eflatun__ has quit [Ping timeout: 256 seconds]
<mnemoc>
but "proper" implies the need of understanding how the driver works
<mnemoc>
neat. the arm-soc base for 3.7 is ready
RITRedbeard has quit [Quit: Leaving]
RITRedbeard has joined #arm-netbook
<cat1>
mnemoc: i know this is totally stupid to ask, but what is the current problem with mali we are trying to resolve?
<mnemoc>
cat1: the current discussion. to make it work reserving it's 64MB in a civilized way
<cat1>
mnemoc: i mean, i haven't seen mali in action myself at all, so for me it all is still hypothetical :)
<mnemoc>
the other big issue with mali is proper drm/ump integration so mali/x11 actually gets hw acceleration
<mnemoc>
cat1: those are two completely separated problems
<cat1>
mnemoc: and mali_drm is somewhat fully implemented?
<mnemoc>
no
<mnemoc>
that works in the the next_mali branch, still incomplete. x11/mali runs... but no acceleration
<mnemoc>
s/in the/is in/
<ibot>
mnemoc meant: that works is in the next_mali branch, still incomplete. x11/mali runs... but no acceleration
eflatun has quit [Remote host closed the connection]
eflatun has joined #arm-netbook
<cat1>
dammit, i am not yet that far with mer adaptation. need to speed it up a little bit :)
<mnemoc>
meh. I thought you wanted to help fixing the mali kernel driver :<
Quarx has quit []
<cat1>
mnemoc: i want and will do what i can, no worries.
<mnemoc>
:)
* cat1
hates to make promises though ;)
<mnemoc>
^^
<ManoftheSea>
mer?
<ManoftheSea>
On the Mali?
<ManoftheSea>
Cool. I don't even have mer on my n900
Almamuetya has quit [Ping timeout: 256 seconds]
eflatun has quit [Remote host closed the connection]
eflatun has joined #arm-netbook
<cat1>
ManoftheSea: actually up to console it works out of the box, the only problem was/is graphics.. err.. and connman ;)
<cat1>
well, maybe usb and other things too, but i haven't even looked at this yet.
<techn_>
cat1: what rendering engine it uses?
<cat1>
xorg
<techn_>
ah
<cat1>
wayland in theory
<cat1>
the work is going on wayland atm.
<techn_>
wayland, directfb should work if gles2 is used directly
<techn_>
or without gles2 ofcourse
<cat1>
techn_: actually i saw xorg started and cursor was on display but that was it, no funcy stuff at all.
<mnemoc>
you usually need to start some apps (at least a wm) after running X :p
* cat1
pushed into Linus's tree by mistake, luckily got err 22
<cat1>
mnemoc: :))
<cat1>
mnemoc: it supposed to be done automgically!
<cat1>
mnemoc: besides there is no wm in there, some composite-manager.
<techn_>
hmm.. So I can read edid and pass it to kernel (a bit hackish).. but applying wanted timings is really painfull :(
<RaYmAn>
at least that proves it works in theory :)
<mnemoc>
:D
n6pfk has quit [Remote host closed the connection]
mikey_w has quit [Read error: Connection reset by peer]
eflatun has quit [Remote host closed the connection]
eflatun has joined #arm-netbook
<techn_>
current resolution change sequence is that msg comes to disp-disp, which passes enum to de_bsp, which passes another enum to disp-hdmi, which reads timings from hardcoded table and passes to controller
<mnemoc>
i told you to try to flatten the driver before trying to add new features :p
<rz2k>
we_need_to_go_deeper.jpg
<techn_>
mnemoc: that's a bit brave if allwinner gives us newer codes :/
mysteryname has joined #arm-netbook
<mnemoc>
techn_: very true
<mnemoc>
but somehow i lost my hope on that
<techn_>
but true.. best solution before new feature(our own feature) would be full refactoring
<techn_>
but should we still merge wip/disp branch before that.. :/
eflatun has quit [Ping timeout: 245 seconds]
eflatun has joined #arm-netbook
<techn_>
even if there is only features that we don't even need
<mnemoc>
+1
<mnemoc>
+1
<mnemoc>
maybe an soft refactoring first to be able to unift sun3i too?
<mnemoc>
unify*
<mnemoc>
damn... coffee or nap? that is the question
<cat1>
nap is healthier..
<mnemoc>
indeed
<cat1>
techn_: will you start from scripts/Lindent ? ;)
<ZaEarl>
coffee then nap
<cat1>
might not be compatible..
<mnemoc>
cat1: that ruins history :<
zowtar has joined #arm-netbook
<ZaEarl>
in the 15 min it takes the caffeine to hit your brain, you get a nice nap, and then pop up awake
<mnemoc>
style fixes need to be done only where there is code changes
eflatun has quit [Remote host closed the connection]
<cat1>
ZaEarl: scientists, scientists -- they will change mind next time ;)
<techn_>
sun3i merge is also pretty hard with current design.. also without device with test cant do large refactorings, i'm only human :(
<cat1>
techn_: but only the code you touch
<rz2k>
who needs sun3i now, really..
<techn_>
cat1: yeah.. but it isn't good to add every second line ifdef
<cat1>
techn_: fully agree
<techn_>
rz2k: i'm wondering same :)
<techn_>
has anyone even tested that current codes work with that device? :p
<cat1>
some philanthropists.
eflatun has quit [Ping timeout: 264 seconds]
ceo16 has quit [Remote host closed the connection]
eflatun has joined #arm-netbook
<techn_>
hmm.. propably best would be flatten disp/lcd/hdmi more.. leave de_bsp as is since there is all the stuff what can't be understood without datasheet + most of the allwinner patches will be there
<techn_>
so should we combine those 3 binaries as one, or even combine modules
<techn_>
and how should be dependecies go.. disp depends on lcd/hdmi(fb).. or lcd/hdmi depends disp(fb)
<techn_>
äh.. disp(fb)
<mnemoc>
hdmi -> lcd -> disp
<mnemoc>
i wouldn't combine them yet
<mnemoc>
we probably need to turn them into drm drivers anyway
<techn_>
ok.. so should we then just jump to drm? could you give me a link of drm fb? or was it that kms link?
<mnemoc>
techn_: do you feel you know enough about the drm to make that jump directly?
<mnemoc>
s/drm/disp/
<ibot>
mnemoc meant: techn_: do you feel you know enough about the disp to make that jump directly?
tuliom has joined #arm-netbook
eflatun has quit [Remote host closed the connection]
eflatun has joined #arm-netbook
<techn_>
mnemoc: implementing new features with current design is seems to be waste of time
<techn_>
but not sure if I have time to get things running with drm.. (dunno yet what it needs)
<mnemoc>
techn_: well... i wouldn't call it a waste of time. but it's probably MUCH harder than it might be after cleaning the driver
<mnemoc>
first flatten/refactor what you can in the fbdev based driver
<mnemoc>
(baby steps)
<mnemoc>
deeper the changes, harder to find what broke :<
eflatun has quit [Remote host closed the connection]
eflatun has joined #arm-netbook
L84Supper has quit [Quit: puff of smoke]
<techn_>
mnemoc: that's true.. maybe it's good to start by making module dependecies clean..
<mnemoc>
yes, that too
<techn_>
but I'm not sure about hdmi -> lcd -> disp dependecy
<mnemoc>
that dep already exists
<mnemoc>
hdmi init needs lcd to have init'ed first
<mnemoc>
or it dies painfully
<mnemoc>
{hdmi,lcd} -> disp will require heavy refactoring
<techn_>
yep that kind dependency needs to removed.. I was thinkin that disp -> {hdmi,lcd} could be better
<mnemoc>
baby steps :)
<techn_>
since atleast fex config allows to wrap output modes under one framebuffer
<mnemoc>
once you understand the interactions better, sure, turn it upside down
L84Supper has joined #arm-netbook
<techn_>
so basicly framebuffer is dependand of outputs.. not otherway around
<mnemoc>
they didn't really care about the real driver is de_bsp anyway
<mnemoc>
s/the /that as /
<ibot>
mnemoc meant: they didn't really care about that as real driver is de_bsp anyway
eflatun has quit [Remote host closed the connection]
<techn_>
i think thas good.. since there is a lot of usefull stuff under enum ( we don't need to understand registers)
eflatun has joined #arm-netbook
<techn_>
but still.. every wrapper layer causes bugs
eflatun has quit [Client Quit]
<mnemoc>
techn_: fyi #ifdef CONFIG_ARCH_SUN?I became illegal now. machs now (since 3.7) shall be bool instead of choice, so code needs to use if (machine_is_sun4i()) instead
<mnemoc>
but well... not a problem for 3.0 :)
<techn_>
but that's good for getting same binary for both :)
<mnemoc>
yup
<techn_>
btw. I was wondering was that PPL fix good.. should DT or fex give correct clocks?
<bsdfox>
anyone got hints on booting mele a2000 from sata?
<techn_>
sata PLL..
<bsdfox>
phase lock loop?
<mnemoc>
techn_: there is a new common clock framework too, so I guess they can be configures using DT
gimli_ has quit [Quit: Verlassend]
<mnemoc>
bsdfox: boot a linux/kexec from nand/mmc and then jump to sata
<hno>
bsdfox, the boot rom do not know SATA. You need to boot something from nand/sd which then boots from sata.
<hno>
and he only something we have who knows he sata controller is Linux.
<bsdfox>
hmm looking at my sd build /etc/fstab has nothing and /boot is empty.. any advice?
<bsdfox>
I guess it might be booting something from the fat32 partition on the sd?
<mnemoc>
you can add the first partition of your sd card as /boot in your fstab
<mnemoc>
but it's not required
<mnemoc>
good night
<bsdfox>
thanks
<bsdfox>
if I want to backup all my nand would you guys do dd if=/dev/nand of=nand.img or would you do it per partition ie if=/dev/nanda of=nanda.img etc?
akaizen has joined #arm-netbook
<akaizen>
So whats the current state of A10 / MALI400 ? Where is help needed the most?
<akaizen>
Looks like empat_zero did some nice work on the A10 VPU.
piezo has quit [Remote host closed the connection]
DEAT_ has joined #arm-netbook
msb_ has joined #arm-netbook
msb has quit [Read error: Connection reset by peer]