<KBme>
oliv3r, iirc yesterday you said you didn't use an initramfs right?
<oliv3r>
KBme: initramfs is built into the uImage ther e:)
<oliv3r>
that's a fully featured system :p
<KBme>
oliv3r, and that boots for you?
<oliv3r>
KBme: of course, no rootfs needed
<KBme>
I mean it manages to switch_root & all?
<KBme>
oh, yeah, well …
<oliv3r>
but it's for what i'm doing right now, i bet it's not usefull for what rellla is oding :)
<KBme>
might the problem be with the kernel not supporting the switch_root?
<KBme>
it's weird, i don't understand
<oliv3r>
KBme: that's the problem your having?
<KBme>
me also, it boots into initramfs fine, I boot to init=/bin/sh in initramfs
<rellla>
KBme: no. standard u-boot/script.bin/kernel - so the only source for issues could be uEnv.txt, rootfs or hardware. no powering issue. i tested 2 PCUs and the usb cable.
<KBme>
then I try to do what /init would do
<KBme>
oh weird
<oliv3r>
KBme: i think switch_root does require kernel support; but i'd be supprised if it's not copmiled in
<KBme>
so I mount the filesystems everything goes fine
<KBme>
then I do the switch_root, and it's weird, busybox gives me the standard switch_root usage help
<KBme>
but it does switch the root
<KBme>
then the kernel panics, I think the kernel panics almost instantly
<rellla>
oliv3r, KBme: on my cubieboard2 the system hangs randomly when modprobing sw_ahci_platform and/or accessing my sata after a while :(
<KBme>
oh, I haven't even gotten to plugging the sata in
<oliv3r>
rellla: sw_ahci_platform is in the process of being depreciated
<KBme>
mine doesn't boot correctly all the way
<oliv3r>
it will run off of ahci_platform once i have some time to fix it
<KBme>
it panics, I think it panics as soon as it switch_roots
<rellla>
oliv3r: yeah, but i should work on A20. on A10 it's fine, too.
<oliv3r>
it should work yes
<oliv3r>
mripard: any reason spear uses 0x4 for irq tuples where we use just 4? I'd expect it to be all decimal as the rest is decimal aswell
<oliv3r>
designware makes an i2s controller aswell
<oliv3r>
i wonder if aw used theirs
<torbenh3>
oliv3r: the flags are flags. and its 4 bits at least. i prefer reading c over 12 ... but maybe thats just me.
<oliv3r>
torbenh3: it depends, I do like things to be concistent however :p
<oliv3r>
torbenh3: little ocd inside I suppose ;)
<torbenh3>
one value is the irq number. and one value is a flag.
<oliv3r>
having dec dec hex; when everybody is doing dec dec dec makes me shiver :p
<torbenh3>
dec dec dec is just lazy people...
<torbenh3>
:)
<oliv3r>
hehehe
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<oliv3r>
mripard: getting back to the clocks; i don't understand why the ahci_platform driver has that clk thing there, the spear and exynos dt's don't even set them ...
<oliv3r>
Turl: clk_get(dev); gets the clock by name from the DT right?
<torbenh3>
oliv3r: imx for example is pretty consistently using 0x for flag values
<oliv3r>
torbenh3: i noticed
<torbenh3>
some are using IRQ_TYPE_LEVEL_HIGH ...
<oliv3r>
i like defines beest
<oliv3r>
best*
<libv>
mnemoc: nope, there isn't
<libv>
mnemoc: especially not for the kernel, as up until a few years ago any 2d accel in the kernel was a no-go
<libv>
today, everything goes
<oliv3r>
sluts.
<mnemoc>
:|
<oliv3r>
atleast there's stil the no floats in kernel thing
<oliv3r>
i wonder till when that'll last
<oliv3r>
next we'll see the kernel being converted to C++
_whitelogger has joined #linux-sunxi
printallthething has joined #linux-sunxi
<libv>
oliv3r: i just got up close and personal to the drm gem interface
<libv>
i think the people who did it would use the word "bonghits" for it.
<libv>
it's one big locking and kref inconsistency
<oliv3r>
:(
<oliv3r>
wasn't GEM an intel thing?
<libv>
oliv3r: yes, and of course the original ideas the pair of them had never could work out
<libv>
oliv3r: and they of course claimed that it was the sole solution to memory management
<libv>
oliv3r: even though some bits are very intel specific and get worked around by all other drivers in the same awkward way
<libv>
gem objects come with a driver private and some halfway useful callbacks which should promote the use of this generic member...
<libv>
but the standard calls all assume that you are intel style hw, and the callback that would invite you to use the driver_private is only called after you've initialized things intel style
<libv>
result, noone uses this member
<oliv3r>
:S
<oliv3r>
i'm happy i haven't dablled into all this
<libv>
the really bad thing is, this is all allowed to pass
<oliv3r>
though in 6 months from now, who knows. doing some 3D work on lima sounds a little fun still :)
<libv>
next time round the same people come with bs ideas, like "hey, why are we doing this shared library stuff, we can save 1% of performance on certain workloads if we all mash it into one huge binary. We could make that the absolute standard, and then we never have to clean up our public symbols!"
<libv>
then that idea is hailed as the best thing since boiled water
<oliv3r>
is it the same group that wants to make xorg one big thing again, like it used to be
<oliv3r>
i rather liked the modularity of the drivers etc
<libv>
oh yeah
<libv>
oliv3r: but really, why are xorg and wayland separate?
<libv>
oliv3r: why are they not mashed into mesa?
<libv>
oliv3r: this would get rid of libdrm as well
<oliv3r>
no clue lol
<libv>
and if everything then gets mashed into systemd, then you finally get somewhere useful
<libv>
as then people only need to care about kernel interfaces being stable
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
Black_Horseman has quit [Changing host]
ganbold_ has joined #linux-sunxi
<libv>
which of course is what the interfaces for graphics hw in drm is
<libv>
that's stable, oh yeah
<oliv3r>
pff, i want my system to be one single static binary
<oliv3r>
loaded as a initramfs
<libv>
one ginormous binary
<libv>
and you never have to worry about shoring up an interface ever
<libv>
and it will be fast, as the linker never has to resolve symbols and all calls are direct
<oliv3r>
this system, we can then call 'one-true-firmware'
<libv>
now if only anyone had some idea on how to fix that one crasher that always happens
<oliv3r>
and firmware doesn't have to be gpl either!
<libv>
then it would work out
<oliv3r>
call the supplier; i'm sure they'll sort it out
<libv>
if only one could go and logically figure out where that issue would be happening
<libv>
the way they sneaked in a very tiny window of opportunity for the kernel is amazing
<libv>
i think they tried to work around things a bit more in the hw specific libdrm parts since my post then
<libv>
but that's just one big crutch
<libv>
and hah, the drivers i was looking at in 3.4 have the same gem locking and referencing issues in mainline. great.
rz2k has quit []
<libv>
but then, the worst offender is samsung, which is just what they deserve :)
<libv>
unexplained race conditions and gem object leaking...
<libv>
tizen will be great!
<mripard>
oliv3r: to be generic?
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
ZetaNeta has quit [Read error: Operation timed out]
paulk-collins has joined #linux-sunxi
<oliv3r>
mripard: well you speculated yesterday that that clock is the generic ahci clock; which makes sense I suppose; but neither spear nor samsung define any clk in their dts that I understand to be related to ahci
<oliv3r>
mripard: the code looks like it would error out if it can't get the clock? I don't follow is all
<mripard>
oliv3r: you're sure that they use the common clock framework?
<mripard>
or they use the DT to represent their clock tree?
<oliv3r>
torbenh3: ah exynos52550 shouldn't be compatible though, only exynos5440
<oliv3r>
mripard: they use clk_get which invokes the dt doesn'tit?
<Turl>
oliv3r: yesterday was 10th :P
<oliv3r>
yeah my VM sometimes displays a weird date/time
<oliv3r>
like right now it says 13:03
<oliv3r>
oh wait, i lost connection then :p
<mripard>
oliv3r: yes, and ?
<torbenh3>
oliv3r: mmm... exynos5440-ahci only has one clk
<mripard>
clk_get has been there way before DT or the CCF ever existed
<Turl>
oliv3r: it takes a name argument too doesn't it?
<mripard>
only it was up to the platform to implement it
<Turl>
oliv3r: there's neon in kernel now :)
<torbenh3>
anyways. the clk is not mandatory.
<oliv3r>
Turl: oh nice!
<oliv3r>
mripard: my interwebs is really really slow atm as i'm loading up clk_get, i have to double check what i saw with relation to of_clk_get in there
wingrime has joined #linux-sunxi
<torbenh3>
clk_get(dev, <name> ) will get the clk thats specified in DT.
<oliv3r>
mripard: in any case, if the clock for the ahci for spear/exynos 5440 isn't in the dt, where else would it be? (exynos5440 has all other clocks under their nodes)
<oliv3r>
torbenh3: what if name is NULL?
<torbenh3>
then it takes the first clk, iirc
<oliv3r>
ok
<oliv3r>
i did find the samsiung clock, i overlooked it the first time
<mripard>
torbenh3: not necessarily
<oliv3r>
clocks = <&clock 23>
<mripard>
it might come from the code of the kernel itself
<oliv3r>
spear doesn't seem to have a clock
<mripard>
or, clk_get itself might get provided by the platform, and in that case, you don't use the CCF at all
<oliv3r>
in any case, spear has 0 clocks defined, exynoss has 1 clock defined, sunxi needs 2 clocks so that won't fit in the current framwork then
<mripard>
damn.
<mripard>
spear *has* clock defined.
<oliv3r>
where?
<mripard>
just not in the DT
<oliv3r>
oh
<oliv3r>
bah
<oliv3r>
how confusing!
<oliv3r>
so those clocks are defined in some plat or mach dir
<n01>
mripard: I hate the gray color font of your lxr :(((
<oliv3r>
mripard: so spear does clock init 'oldskool'?
<oliv3r>
e.g. ugly? or it only registers them that way and that's 'ok' to do it that way
<wens>
minimal effort converting to DT?
<mripard>
oliv3r: it doesn' construct the clock tree from the DT
<oliv3r>
so if they register a clk with the name "b1000000.ahci" that'll be the node name later?
<mripard>
some architectures still do that
<oliv3r>
or clkname rather
<mripard>
yeah
<mripard>
and clk_get will look up for that
<oliv3r>
so if i get it right, they register 2 clocks for ahci, dw_pcie0 (what we'd call ahb) and b100000.ahci (what we call sata)
<oliv3r>
so we have clk_register_gate("pcie_sata_0_clk", "ahb_clk) which enables the gate, then they add to that clk two clocks, dw_pcie.0 and b1000.ahci; so we have 3 'things' a gate and two clocks, or something along those lines
<oliv3r>
all 'bound' to 1 clk (struct clock clk i think)
<torbenh3>
oliv3r: just look at imx6
<y0g1>
hello
<oliv3r>
torbenh3: imx doesn't use ahci_platform properly though
<y0g1>
oliv3r: what kernel version do You use on A20 cubietruck ?
<oliv3r>
y0g1: erm right now? 3.13
<wens>
oliv3r: sounds like non-standard composite clock
<oliv3r>
y0g1: but otherwise there's 3.4
<mripard>
oliv3r: clk_register_clkdev is just to set an alias iirc
<y0g1>
oliv3r: I would like to test it. Now I use 3.4 from ubuntu. What do I need to change to test 3.13 ?
<y0g1>
oliv3r: do I need to update u-boot ?
<oliv3r>
y0g1: if you test 3.13 you need a serial console for one :)
<torbenh3>
oliv3r: errm... what do you mean, it doesnt use it properly ?
<y0g1>
oliv3r: ok, it is ttl (5v) serial console?
<oliv3r>
y0g1: if your u-boot is recent, nope; but mind you, 3.13 only supports serial ports and some other basics; no mmc, display etc
<y0g1>
oliv3r: how about gmac and sata?
<oliv3r>
torbenh3: first of all, it chains ahci_platform, e.g. you have ahci_imx that in turn registers and loads ahci_platform, kinda ugly
<oliv3r>
y0g1: nope
<y0g1>
oliv3r: so must stick with 3.4 :|
<oliv3r>
y0g1: sata i'm working on, gmac is being upstreamed by wens atm
<oliv3r>
torbenh3: the only two compatibles for ahci_platform are spear and exynos5440
<y0g1>
oliv3r: ok, thanx for the info, I will wait for it
<oliv3r>
y0g1: nop :)
hehopmajieh_ has quit [Ping timeout: 252 seconds]
<y0g1>
oliv3r: one more question, what does dtd mean? How to use it with 3.13 kernel?
<oliv3r>
torbenh3: but imx does the same thing what i try to fix, they also need 2 clks :) so they have their own probe setting up both clocks, and then ignore the ahci_platform clk
<oliv3r>
y0g1: dtb? device tree binary/blob; it's compiled from the dts which is supplied with the kernel; you let u-boot load it into memory and pass the memory address as argument, we have precompiled dtb's :)
<y0g1>
oliv3r: ic, howto setup u-boot for it?
<oliv3r>
y0g1: if your u-boot is fairly recent (< 1 year old) it can handle it just fine
<y0g1>
oliv3r: ok
<torbenh3>
oliv3r: they are not ignoring the ahci_platform clk
<oliv3r>
torbenh3: of course they are, ahci_probe is being skipped
<oliv3r>
it should have been dev_warn in that case though
<oliv3r>
but i get it now i think how it all fits together
<oliv3r>
not 100% sure on the seperation that you mentioned though; the IP needs several clocks, having 1 for the ACHI internals and 1 for the PHY, bus etc
<oliv3r>
having 1 clock controlled from 1 area of the driver, and the rest elsewhere is just a little odd, if they are all needed for the IP to function
<oliv3r>
I guess it's more of a 'what's the point'
<torbenh3>
1 area of the driver is a completely generic ahci driver, that also supports ahci controllers bound via pci-e
<torbenh3>
then another "area" wraps that thingy in a platform device.
<oliv3r>
true, so you'd want a callback for the driver to do additional clocks if required
<oliv3r>
well i was doing that anyway, but was going to put all 3 clocks in there
<torbenh3>
yeah. and thats what ahci_platform provides.
<torbenh3>
but you might ask, if people prefer to just extend the number of clks supported.
<oliv3r>
should :p
<oliv3r>
torbenh3: I do ask!
<torbenh3>
on the libata ML ?
<oliv3r>
no i ask you now here :p
<torbenh3>
its not my call :)
<oliv3r>
But it's a good question to ask
<oliv3r>
i thoguth you where going to answer that :)
<torbenh3>
well... you could send an RFC with a copy of the imx driver. changed so that it does what a20 needs.
<oliv3r>
torbenh3: oh we did that allready a week or so ago
<torbenh3>
and what was the reply ?
<oliv3r>
well a driver that looks like the imx driver
<oliv3r>
'i don't like where this is going, we should fix ahci_platform' which is what i'm working on now :p
<oliv3r>
but i dind't understand why there was just the 1 clock
naobsd has joined #linux-sunxi
wolfy has quit [Quit: Dragostea e oarba? Nu. E doar putin presbita: nu vede nici un defect pana nu se indeparteaza putin. (Drew Barrymore)]
<oliv3r>
torbenh3: (looking up the gmane post now, don't have access to my mail atm)
<oliv3r>
wens: do you speak or atleast read chinese? we just crossed my mind that we have the axp209 datasheet, but only in chinese, the axp202 we do have in english
<n01>
i think that axp202 in very similar to axp209
<oliv3r>
n01: i fully agree, i bet there's only very very minor differences
<libv>
mnemoc: really, you arrive on saturday morning?
<libv>
mnemoc: ouch :(
<libv>
mnemoc: i will be there friday ~18:00 or so, until monday early afternoon
<libv>
mnemoc: as i do not want to miss the "events" at friday or sunday evening :)
<oliv3r>
i will try to be there friday early ish, around that time aswell
<oliv3r>
i odn't like arriving very early :p
<oliv3r>
but I do have to work monday morning :(
<n01>
I'll be there also on friday ~17
<libv>
i usually try to organize a table at le mirabelle during sunday, and we usually get about 20-30 people together still
<libv>
and after we've finished there, we take a bus to the city center and then close down the delirium again
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
<libv>
and then that virus that someone brought along will find a perfectly broken immune system, and you just about make it home on monday, and you will be in bed the rest of the week
<oliv3r>
hahah
<wens>
oliv3r: what do you need?
wingrime has quit [Ping timeout: 250 seconds]
<oliv3r>
wens: nothing yet; but n01 was starting the the axp driver, so i just got reminded of this
<wens>
:)
<n01>
I'm using the axp202 datasheet for the 209 :)
<oliv3r>
see, i'm bringing people together here
* libv
says "it's oliv3r's sunxi lovefest!" in a spoof dutch english accent
<oliv3r>
LOL
<oliv3r>
yeah baby yeah!
<oliv3r>
i actually do a better austrian-english accent
<libv>
i am quite good at a dutch german accent these days, but admittedly, a large part of that is natural :)
wingrime has joined #linux-sunxi
<oliv3r>
wingrime: hey!
<wingrime>
oliv3r:
Sonic1_ has joined #linux-sunxi
<ssvb>
hi aseigo
<n01>
hum, the interrupt controller is the same for sun4i and sun7i?
<oliv3r>
n01: nope
<n01>
I see
<oliv3r>
sun4i is allwinner's own thing (or some IP), sun7i is ARM's generic IC
<ssvb>
mnemoc: about a decent standard for 2D acceleration, I believe it is assumed to be OpenGL ES nowadays (with all the work Qt5 folks are doing)
hehopmajieh_ has quit [Ping timeout: 260 seconds]
<oliv3r>
isn't glamor supposed to be the 2D framework? 2d ontop of 3d? :p
<ssvb>
mnemoc: a problem is that we have a bunch of 'legacy' applications which are not there yet
<WarheadsSE>
^
<ssvb>
oliv3r: yes, glamor is a compatibility layer for legacy applications, providing xrender on top of opengl
<aseigo>
ssvb: yo...
<aseigo>
ssvb: i hope my emails on the list helped clear up some misunderstandings. if you have remaining concerns / questions, i'm happy to discuss here
<oliv3r>
ssvb: i thought that the whole '3D engine for 2D' wasn't as awesome as everybody thought it was to be
<ssvb>
aseigo: yes, partially
<aseigo>
oliv3r: it works well enough that GPU designers just have 3D support on their silicon; in theory a GPU with "real" 2D would offer better performance, but as it is a subset of 3D for many applications and allows the GPUs to be simpler (which is a funny thing to say about modern GPUs :) .. openGL wins the day
<oliv3r>
aseigo: performance probably; but the problem is power consumption :p
<aseigo>
and yeah, Qt5 assumes a working openGL implementation is around; even when rendered in software it measures comparable (or even faster) than what was in Qt4 (which ended up mostly on the CPU :/)
<aseigo>
oliv3r: for modern applications i don't think it matters much
<oliv3r>
aseigo: you'd be supprised
<aseigo>
all the platforms are using openGL to render their primary user interface
<aseigo>
so having a 2D app in that world .. meh
<aseigo>
i agree that if you are designing something from the ground up and eschew all opengl, it could make a difference
<aseigo>
but there is no market for that, so there is no silicon
<aseigo>
(and then software higher in the stack has adapted ...)
<oliv3r>
i don't think we have any SoC that ommits the 2D engine
<oliv3r>
a few years ago, we saw some videocards trying to do the 2D bits emulated on the GPU
<aseigo>
you mean openVG?
<oliv3r>
it failed as they fell back to implementing full 2D engines again
<oliv3r>
as running the GPU in 3D mode constantly sucked up quite some power
<oliv3r>
might even do both; overlays and 2D blittersa re not done using opengl
<libv>
ssvb: this thing about doing everything with opengl(es)...
<libv>
ssvb: that's just laziness
<ssvb>
oliv3r: now you are talking about the performance and power optimizations, when these are brought into the picture, everything becomes naturally a bit more complicated
<libv>
ssvb: as it is harder to do synchronization by hand instead of just letting the hw take care of it
<libv>
ssvb: and because people cannot be bothered to do the little work that the bringup of a blitter usually is
<libv>
the same reason why people didn't want to care about overlays
<ssvb>
libv: devil is in the details
<libv>
ssvb: it is not impossible to solve.
<libv>
ssvb: and on SoCs like our sunxi, we have to solve it
<libv>
as we do have completely disjoint blocks, not gouverned by a single hw task controller or command processor
<ssvb>
many mutually incompatible revisions of SoCs and operating systems and lack of agreement on a 'common' standard
<libv>
ssvb: dma_buf should go some way
<libv>
ssvb: look at how drm is designed...
<libv>
in as far as that verb applies
<libv>
it's been written for intel
<libv>
one driver, for the lot, everything is mashed together
<libv>
that will never work for us
<libv>
we need some synchronization to do proper fire-and-forget rendering and blitting
<libv>
and with intel, they just cannot be bothered
<libv>
heck, at least intel does overlays again, already (and jesse produced the unfinished thought that is drm planes)
<libv>
radeon will never do it, even though at least r5xx and r6xx had one big RGB overlay (next to the main buffer and the hwc) per crtc
<libv>
intel needs it, to not eat too much power in android
<libv>
wayland needs to work with it, to not loose to android hwc too badly
<torbenh3>
a meta driver, glueing the sunxi subdrivers together, and providing the drm ioctl thingies... pretty similar, to alsa-soc drivers today... blabla
<libv>
but all of this requires a bit of structured thinking and some synchronization between 2d, 3d, media (perhaps the camera/csi) and the display engine
<libv>
it really is not that many components
<ssvb>
Intel does not give rats about this stuff working well for their competitors, I would say that they might be even motivated to sabotage their competitors but just do not show it on public :)
<libv>
ssvb: there are a few good guys in intel
<libv>
ssvb: some of our former colleagues
<libv>
and ville knows how the ti display engine was built up
<ssvb>
libv: yes
<libv>
he does think further than most
<libv>
but sadly he currently does not seem able to push his atomic modesetting stuff through
<libv>
because drm very quickly does fall apart when you pull a single thread
<libv>
it needs an insane amount of restructuring to get to a place where it would be universally useful
<libv>
and where it would finally do software synchronization between disjoint engines
Quarx has quit [Read error: Connection reset by peer]
<libv>
i actually believe that in 1-2 years time, as is the case with open source software, someone new will step in, and reinvent the lot, and everyone will cheer him on
<libv>
and he will make a total hash of it, like always happens
<aseigo>
heh. that never happens!
<libv>
and we will lose whatever things we should've kept from drm
<libv>
but if i talk structure, i always get shown the middle finger.
<libv>
if anything was proven time and time again the last decade...
<libv>
people just love going off and implementing things from scratch.
<libv>
as for intel...
<libv>
they completely dropped support for using a blitter or 2d engine
<libv>
and they have two solutions to make up for it
<libv>
glamor and sna (sandybridge "new" architecture"
<libv>
both from intel
<libv>
and they are not too friendly competing projects