hno changed the topic of #linux-sunxi to: /Allwinner/sunxi development discussion - Don't ask to ask. Just ask and wait! - See | | Logs at
leowt has joined #linux-sunxi
leowt has quit [Quit: leowt]
<hno> hmm.. large spl boots fine on a10s, but not on a20 it seems.
<hno> will look into it in more detail tomorrow. But looks like we need to cut down the SPL a bit to guarantee it's <=24K.
popolon has quit [Quit: Quitte]
robb83 has joined #linux-sunxi
robb83 has quit [Client Quit]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
akaizen_ has joined #linux-sunxi
akaizen has quit [Read error: Connection reset by peer]
<Turl> wooot, watchdog driver merged :)
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
hipboi has joined #linux-sunxi
rz2k has quit []
eagles0513875 has quit [Ping timeout: 276 seconds]
eagles0513875 has joined #linux-sunxi
ganbold_ has quit [Ping timeout: 256 seconds]
hipboi has quit [Ping timeout: 248 seconds]
ganbold_ has joined #linux-sunxi
hipboi has joined #linux-sunxi
hipboi has quit [Read error: Connection reset by peer]
robb83 has joined #linux-sunxi
\\Mr_C\\ has quit []
MadSpark- has joined #linux-sunxi
RaYmAn_ has joined #linux-sunxi
wigyori has quit [Ping timeout: 256 seconds]
wigyori has joined #linux-sunxi
jeremb_ has joined #linux-sunxi
_enrico_ has joined #linux-sunxi
RaYmAn has quit [*.net *.split]
Tartarus has quit [*.net *.split]
MadSpark has quit [*.net *.split]
awafaa has quit [*.net *.split]
jeremb has quit [*.net *.split]
HeHoPMaJIeH has quit [*.net *.split]
jeremb_ is now known as jeremb
awafaa has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
Tartarus has joined #linux-sunxi
Black_Horseman has quit [Ping timeout: 264 seconds]
NotTooGood has joined #linux-sunxi
<NotTooGood> hello
<NotTooGood> Hows linux working on the A20 ?
popolon has joined #linux-sunxi
wingrime has joined #linux-sunxi
\\Mr_C\\ has joined #linux-sunxi
sanka has joined #linux-sunxi
ZetaNeta has joined #linux-sunxi
rings_IIV has quit [Ping timeout: 256 seconds]
sud0x3 has joined #linux-sunxi
n01 has joined #linux-sunxi
<NotTooGood> hello?
<hno> NotTooGood, reasonably well, but some drivers still missing.
<wingrime> hno: how much difficult add to uboot fbcon suport
<NotTooGood> like what kind of drivers
i-rinat has joined #linux-sunxi
i-rinat has quit [Client Quit]
<hno> NotTooGood, not keeping track in detail on what is the current status.
<hno> wingrime, no idea. Why would one want fbcon in u-boot?
<hno> crap, it's only sun5i that accepts large SPL. sun4i and sun7i both rejects them.
atiti has quit [Ping timeout: 268 seconds]
<NotTooGood> Is there anything particular to look for on Allwinner based products that one intend to load linux onto?
deasy has joined #linux-sunxi
kaspter has joined #linux-sunxi
<NotTooGood> hi?
wingrime_ has joined #linux-sunxi
<NotTooGood> If i connect a Allwinner device with HDMI output to a monitor with dvi input.... would i be able to use debian or ubuntu with the proper resolution for the particular monitor?
<buZz> dno if _you_ would be able to
<buZz> but in general, yes
<hno> When DDI support have been more tested so we can have it enabled by default it will be a lot easier.
<buZz> EDID support?
<wingrime_> ssvb: if cedar MMIO region will be exported using DRM interface , this request vdpau sunxi to be included to xf86-video-sunxi ?
<libv> haha, drm interface :)
<wingrime_> libv: ?
<libv> i hadn't realized until now that this would be a _third_ block which should not have been mashed in with the rest of drm
<libv> only now are they starting to realize that maybe mashing in kms with the rest of drm was pretty shortsighted
<libv> actual display developers would've never messed display stuff as badly together with 3d engine
<libv> but i hadn't realized that, yes, some parts of media now might also fall under drm
<wingrime_> libv: so _can_ we use drm like 3d engine for cedar?
<wingrime_> libv: claim MMIO and do our work like before?
<libv> wingrime_: my feeling is that intel and radeon work like this (i have not looked into radeons uvd engine or the more general vdpau - the last time i did media stuff was 2009)
<libv> but don't take my word for it
<libv> but it shows (once again) the massive shortcomings in the thinking of the people who have been stuffing everything into drm in the last 4-5 years
<wingrime_> libv: I fail in instant sadness loking at how much code radeon and intel have in drm kernel folder, and who a hell will write thats all for sunxi....
<libv> wingrime_: look into the x86 desktop implementations, i seem to remember that there were some attempts to get radeons uvd supported in the open source driver
<libv> wingrime_: no-one, and no-one should
<libv> wingrime_: in my world-domination view, things have structure, and organized logically.
<libv> (which is why kms has the notion of things like crtcs and encoders)
<libv> graphics driver stacks are spread all over the place, and this is fundamentally wrong.
<libv> it hampers development and proliferation, giving a bad experience for all parties involved
<libv> so having a huge kernel driver, which is supposed to only exist in the linus kernel, is counterproductive
<wingrime_> libv: I thinking for a first trial get framebuffer work on uboot
<oliv3r> wingrime_: there are example drivers for other chips; but it won't deffinatly fit into the SPL
<libv> wingrime_: no, first add good debugfs support to the existing display driver
<wingrime_> libv: that driver are defentetly piece of shit
<oliv3r> libv: there' uvd opensource support these days :) since april i think?
<libv> oliv3r: i am not sure, tbh, as my radeonhd trauma and my focus on arm has kept me from most x86 stuff, but i think i heard some noise
<libv> oliv3r: yeah, you're right
<oliv3r> libv: yeah, in april they pushed uvd support, it was merged into mesa 9.2 and the kernel support arrived in 3.10; UVD is exposed via vdpau :)
<libv> hah, patch for drivers/gpu/drm/radeon/radeon_uvd.c
<libv> so yes, thrown into the drm mess
<libv> in my past 10 yes, the inability for the community to see any structure has more than amazed me
<libv> 10 years even
<oliv3r> heh yeah
<oliv3r> linux-media says to use mem2mem drivers for hardware acceleration
<libv> wingrime_: first, add register dumping for the display driver
<libv> wingrime_: then mash things up so that a rudimentary drm driver can also use the memory ranges mapped by the display driver, perhaps as an extension to the disp driver
<libv> and then slowly add basic kms support inside the same disp driver
<libv> the basics should not be hard
<libv> but it should not be done as a completely different driver, as that would mean throwing away everything disp offers (badly), and will only get 10% of the functionality in the reworked disp/kms driver
<wingrime_> libv: as I remeber ther sunxi-reg drvier that can read any regs , not only disp's
<oliv3r> wingrime_: sunxi-reg driver?
<oliv3r> libv: well we have full source of the disp driver; its just ah uge piece of shit
<wingrime_> oliv3r: something I saw ....
<libv> oliv3r: it is a huge piece of shit indeed, but a very good source of information
<wingrime_> libv: we have docs too
<libv> wingrime_: docs only tell you so much.
<oliv3r> so we have docs, source, that makes things a lot easier
<oliv3r> but, just a lot of work to actually execute
ZetaNeta has quit [Changing host]
ZetaNeta has joined #linux-sunxi
<libv> yes, but it can be done in relatively small steps
<oliv3r> oh libv! have you read the last phoronix news
<mouchon> hno: if i remove CONFIG_SPL_OS_BOOT it will boot ?
atiti has joined #linux-sunxi
<oliv3r> n01: did you add sun7i support to your wdt before v7?
<oliv3r> mouchon: you will have a smaller SPL and that should boot
<oliv3r> mouchon: what is more interesting is why my gcc 4.63 produces a smaller binary then your 4.6.3
<mouchon> oliv3r: which use flags are using for gcc
<hno> mouchon, when you get sunxi-spl.bin down to at most 24KB it will boot. Removing CONFIG_SPL_OS_BOOT most likely accomplishes that.
<n01> oliv3r: nope, not yet ... anything changed in wdt between A10 and A20?
<mouchon> hno: thanks i will check that
<n01> honestly I'm still trying to understand on which branch is better to start work again
<mouchon> hno: u-boot-spl.bin size is now 23956
<hno> oliv3r, gcc-4.6.3 != gcc-4.6.3... almost every distribution GCC release is patched. For example Linaro patched GCCs are quite different from upstream gcc.
<hno> even different Linaro releases with the same GCC version is quite different.
<mouchon> hno: sunxi-spl.bin size 24064
<hno> mouchon, then you should be fine now.
<mouchon> hno: indeed it works :-)
<hno> Disabling SPL_OS_BOOT by default on sun4i & sun7i. But leaving it on by default on sun5i.
Black_Horseman has joined #linux-sunxi
<hno> and added ..._Falcon board types for the more interesting sun4i/sun7i boarts to experiment with Falcon mode on.
<hno> mouchon & Turl, can you please test.
<atsampson> hno: what's Falcon mode?
<libv> oliv3r: yeah, good progress indeed
<wingrime_> libv: h264 and mpeg12
<hno> atsampson, direct boot to Linux from u-boot SPL, skipping the full u-boot.
<hno> atsampson, see doc/README.falcon for details.
<mouchon> hno: still booting after compile with you commit :-)
<wingrime_> oliv3r: drivers/misc/sunxi-dbgreg.ko
<mouchon> hno: i used A20-OLinuXino_MICRO. When i use A20-OLinuXino_MICRO_Falcon, arm-linux-gnueabihf-ld.bfd: u-boot-spl section `.data' will not fit in region `.sram'
<mouchon> arm-linux-gnueabihf-ld.bfd: region `.sram' overflowed by 380 bytes
<wingrime_> oliv3r: very funny a10_config have no sound onboard
<wingrime_> oliv3r: arch/arm/configs/sun4i_defconfig
<hno> mouchon, good. Sou need to find 380 bytes somewhere to shave off from the SPL binary for Falcon mode to fit with your toolchain.
<wingrime_> mnemoc: arch/arm/configs/sun4i_defconfig now have no sound onboard
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
n01 has quit [Quit: leaving]
\\Mr_C\\ has quit []
n01 has joined #linux-sunxi
<mouchon> hno: may be disabling some stuff like led board ?
<wingrime_> hno: have you printf like functions in spl?
<wingrime_> hno: they can be very big for it
<hno> yes, i know. But also very nice to report DRAM size etc.
Soru has quit [Read error: No route to host]
<wingrime_> hno: add #define for such
rellla has joined #linux-sunxi
<hno> wingrime, patches welcome to shave away unneeded stuff from SPL.
Soru has joined #linux-sunxi
<wingrime_> hno: can I use pull ?
\\Mr_C\\ has joined #linux-sunxi
<hno> wingrime, what do you mean? github pull requests? Sure, but mailinglist is better.
<hno> mouchon, led support is not in the SPL.
<hno> see spl/ for details what is (and is not) in the built SPL.
vinifr has joined #linux-sunxi
<techn__> somewhy it tries to force 8byte alignment for vst1 instruction
notmart has joined #linux-sunxi
atiti has quit [Ping timeout: 260 seconds]
<techn__> .. that pointer shifting is just for demonstrating 4byte alignment
rz2k has joined #linux-sunxi
popolon has quit [Quit: Quitte]
atiti has joined #linux-sunxi
\\Mr_C\\ has quit []
<wingrime_> mnemoc: ping
<atsampson> hno: ah, cool
<hno> wingrime, that pointer arithmetic do not make any extra alignment at all.
<ssvb> techn__: yes, gcc assumes 8 bytes alignment for the pointer to your structure
rellla has quit [Quit: Nettalk6 -]
<techn__> ssvb: cool
<ssvb> techn__: if you convert the source file to assembly (gcc -S ...), sed replace ":64]" with "]" and compile it, then it works
<hno> ah, you meant mis-alignment..
<techn__> ssvb: how I can tell for compiler that?
\\Mr_C\\ has joined #linux-sunxi
<hno> techn__, you want to tell the compiler to not assume 8-byte alignment of long long?
<techn__> hno: yes
<wingrime_> hramrach: ping
<techn__> seems that I can add any other type before those, then it will use non neon optimization code for it
iamfrankenstein has joined #linux-sunxi
<wingrime_> Tsvetan: ping
<hno> techn__, I suppose you can use attribute ((aligned(4))) on the members. Or declare the struct as packed.
<techn__> I also can add __attribute__((packed)) for that struct.. but I wouldn't like to make 8bit or 16bit integers smaller
<hno> ah, you need both.
<techn__> but maybe that is the only option
<hno> packed do not make types smaller, it just declares that the compiler should not add padding between members for alignment.
<hno> and consequently also tells the compiler that it can not assume data is suitably aligned for their types..
<ssvb> techn__: "4 DATA TYPES AND ALIGNMENT" section in
<ssvb> techn__: violating the ABI assumptions is always a dangerous business
<ssvb> techn__: from man malloc: "The malloc() and calloc() functions return a pointer to the allocated memory that is suitably aligned for any kind of variable"
<techn__> ssvb: yeah. but I have custom allocator which has 4byte alignment :p
<ssvb> techn__: then don't use a standard C compiler with it :)
<techn__> but it seems that we need to make it work with ABI
<ssvb> techn__: yeah, you need to make your own ABI variant, which only requires 4 bytes alignment for any data types and add support for it in gcc
<ssvb> techn__: or resort to all kind of hacks to workaround the things which break all over the place
<techn__> ssvb: thanks a lot for clarifying things :)
<techn__> btw I saw a lot stuff what you have done with NEON :)
<techn__> when googling trough internet
<ssvb> techn__: btw, for armv5 and older processors, 8 bytes alignment was mandatory for LDRD and LDM instructions, armv6 and later relaxed it to just 4 bytes
<ssvb> techn__: this information can be found in ARM Architecture Reference Manual
<ssvb> techn__: and the kernel has an interesting behaviour if you tweak /proc/cpu/alignment
<ssvb> techn__: if /proc/cpu/alignment is set to 3 (fixup+warn) instead of 4 (signal), then you still get a SIGBUS in a pretty much messed up way (gdb pointing to a wrong instruction)
massi has joined #linux-sunxi
notmart has quit [Quit: notmart terminated!]
<techn__> ssvb: yeah.. I noticed that in some situation that unaligned code worked
<techn__> code works if you remove no-unroll and no-inline from compile line :p
Soru_ has joined #linux-sunxi
Soru has quit [Ping timeout: 248 seconds]
<NotTooGood> So as for A10 and A20 devices can i load linux on to any of those tiny TV boxes?
<mouchon> hno: thanks will look at this
<techn__> NotTooGood: sure
<NotTooGood> So is it fairly straight forward to put something on the onboard flash?
<NotTooGood> Most things are one the CHIP correct? so the major differences is the board layout, and what IO options they choose to use.?
<techn__> NotTooGood: you need to do couple addional steps if there is no support for that specific device
<NotTooGood> ?
<techn__> you may need to get dram parameters and .fex file from orginal firmware
<NotTooGood> Is that something you could walk me through or does a decent and easy to follow HOWTO exist?
<techn__> but if that specific device can be found from supported list it should work oob
<NotTooGood> techn__: If i'm re-purposing a bunch of these devices, it there a quick and easy way to batch load new system onto them?
<techn__> NotTooGood: which distro you want to use?
<NotTooGood> I visited one tablet factory some time back and they seem to do it in a very cumbersome way.... some consumer grade looking software running on a bunch of old WinXP computers... and a bunch of teenagers doing a lot of manual work
ganbold__ has joined #linux-sunxi
<NotTooGood> techn__: for speed and stability, which distro would you recomend
<NotTooGood> ?
<techn__> oh you mean re-purposing thousands of devices?
<NotTooGood> Starting out with a few hundred
<n01> mripard: Added to linux-watchdog-next :))) finally
<NotTooGood> The problem im having is every damn factory i talk to seem to not really know much about what they are doing... even the ones with SMT production line
<techn__> you need then some sdcards with automatic scrpits to do the work.. ofcourse someone needs to be inserting the sdcard
ganbold_ has quit [Ping timeout: 264 seconds]
<NotTooGood> So system can be installed from SD card?
<techn__> sure.. check ie berryboot
<NotTooGood> Then thats probably the best way then
<NotTooGood> The stack of windows XP computers just didnt seem very professional
<NotTooGood> Back in the day... When i worked for a small company that made their own desktop brand... I made a linux box that semi automatically preloaded the systems harddrive using dd
<NotTooGood> That was a big step up from the manual install they were doing before... that kind of felt like the most efficient way of doing it
<NotTooGood> Are A10 devices more supported at the moment?
<NotTooGood> Should i start out with A10 and move to A20 once support for A20 matures.......
<NotTooGood> ?
<vinifr> n01, about rtc
akaizen_ has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
<techn__> NotTooGood: I was just about to say that :)
<NotTooGood> techn__: Is it a big issue to change the boot logo etc on these boards?
<wingrime_> libv: /dev/drm can be opened only using libdrm?
<techn__> yes. it is just a picture
<wingrime_> libv: witch access requirements for /dev/drm ?
akaizen has quit [Ping timeout: 264 seconds]
<mnemoc> wingrime_: driver unification side effect?
<mnemoc> the sound thing
<wingrime_> mnemoc: yes,
<wingrime_> mnemoc: also a13 have no audio in config
<wingrime_> mnemoc: I send cleanup patch for disp,in ML, not change any logic ,but removes #if 0 blocks
<mnemoc> ok
deasy_ has joined #linux-sunxi
deasy_ has quit [Client Quit]
<n01> vinifr: what
<wingrime_> mnemoc: looked in #ifdef a13 but much of it looks like improvements , so after I deal with cedar on a13 I will try unfiy
<mnemoc> cool
<vinifr> Was it merged?
<n01> vinifr: not yet ... I have to rewrite it in human form before submitting
<wingrime_> mnemoc: but jemk's vdpau seems not work for a13
<wingrime_> mnemoc: disp related
<vinifr> n01, 'human form'? :)
<wingrime_> ssvb: ping
<n01> vinifr: hahah, the actual code is horrible, I need to clean and review it
<n01> wanna help? :)
<vinifr> no, i don't
<NotTooGood> techn__: is there a software/firmware setting for making a board boot the moment it gets power, without anyone having to press a power button?
<n01> ... well .... ok ... o_o
<wingrime_> ssvb: ping
<ssvb> wingrime: pong
<wingrime_> ssvb: I find some interesting bug in your XV implementation
<wingrime_> ssvb: easy to reproduce
<wingrime_> ssvb: it also same with jemk's
<ssvb> wingrime: this would be a good place to report it -
<wingrime_> ssvb: if you move video-window over a top for a while , entire screen begins shifts down and right
<wingrime_> ssvb: its looks like disp bug
setkeh has quit [Ping timeout: 245 seconds]
\\Mr_C\\ has quit [Read error: Connection reset by peer]
kaspter has quit [Ping timeout: 246 seconds]
_enrico_ has quit [Ping timeout: 245 seconds]
massi has quit [Ping timeout: 246 seconds]
massi has joined #linux-sunxi
lkcl_ has joined #linux-sunxi
vinifr has quit [Ping timeout: 260 seconds]
massi has quit [Quit: Leaving]
vinifr has joined #linux-sunxi
NotTooGood has quit [Read error: Connection reset by peer]
<buZz> wow
<buZz> i heard a rumor
<buZz> is someone implementing an opensourced wrapper for cedarx?
<buZz> the rumor was; 17:34:50 < deasy> i'm glad than the a10 come probably the first soc to have an open driver for video decoding acceleration :)
<buZz> zomg
geecko has joined #linux-sunxi
geecko has quit [Read error: Connection reset by peer]
dwilkins has quit [Ping timeout: 264 seconds]
<wingrime_> ssvb: but realay in disp, but I currently have no idea how to fix correct way, simply say, there is no code that handle negative src_win_x and src_win_y , more interesting that are defined as _signed_ type but in disp_layer,c it suddenly copies to __unsigned__ x,y
dwilkins has joined #linux-sunxi
NotTooGood has joined #linux-sunxi
geecko has joined #linux-sunxi
\\Mr_C\\ has joined #linux-sunxi
<ssvb> wingrime: ok, thanks, managed to reproduce this
dwilkins has quit [Ping timeout: 268 seconds]
dwilkins has joined #linux-sunxi
Soru_ has quit [Ping timeout: 260 seconds]
Soru has joined #linux-sunxi
vinifr has quit [Ping timeout: 260 seconds]
ganbold__ has quit [Remote host closed the connection]
ganbold_ has joined #linux-sunxi
NotTooGood has quit [Ping timeout: 256 seconds]
n01 has quit [Ping timeout: 246 seconds]
<wingrime_> mnemoc: ping
rings_IIV has joined #linux-sunxi
<wingrime_> jukivili: ping
NotTooGood has joined #linux-sunxi
NotTooGood has quit [Client Quit]
<ssvb> wingrime: yes, it looks like this can be fixed in the kernel disp driver
<ssvb> wingrime: the DRI2 hardware overlays are not affected, possibly because they are not using scaling
<ssvb> wingrime: these XV glitches can be also workarounded in the xorg driver (if we want to support older kernel users), but I guess that the negative window position is not a common use case
<wingrime_> ssvb: I can add easy fix to kernel , change all negative positons to 0
<wingrime_> ssvb: or trow error
<wingrime_> ssvb: but full fix is different as we use many colorspaces
<ssvb> I believe it would not be the right fix, we also need to recalculate the visible part of the buffer
<ssvb> so that the correct rectangle from the lower right corner of the buffer gets scaled to the the correct rectangle in the top left corner of the screen
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
<wingrime_> ssvb: I can add abs(x) to width and same for y
popolon has joined #linux-sunxi
<wingrime_> ssvb: but I have no idea how correctly crop buffer with hw
<rah> I have flashed an A31 box with a buildroot image
<rah> unfortunately boot1 doesn't seem to want to load u-boot
<rah> that's the output on the serial port
<rah> any ideas?
<rah> the only error that's reported is abuot finding an image file which can't image would be a fatal error
<wingrime_> oliv3r: ping
setkeh1 has joined #linux-sunxi
setkeh1 is now known as setkeh
setkeh has quit [Changing host]
setkeh has joined #linux-sunxi
Soru has quit [Read error: Connection reset by peer]
Soru has joined #linux-sunxi
vinifr has joined #linux-sunxi
jemk has joined #linux-sunxi
<mripard> oliv3r: Turl: hmmm ?
atiti has quit [Read error: Operation timed out]
<Turl> mripard: hm what? :)
<hramrach> wingrime_: pong
<wingrime_> hramrach: who a touched usb last time
<wingrime_> hramrach: a13 broken
<hramrach> iirc somebody was complaining, yes
<hramrach> and iirc the last thin was around sun[457]i unification
<hramrach> and I have no sun5i so can't really tell how long it's been broken or anything
<wingrime_> hramrach: also, you touched rock-chip VPU ?
<hramrach> I have no RK device
<hramrach> I was looking into RK but the Linux support there is even worse than AW
<hramrach> I have an Exynos5 with no VPU support whatsoever as well
<wingrime_> hramrach: what a hell, I have to bissect
<hramrach> tbh the sun5i device are cheap and easy to get but I have no use for more arm machines
<oliv3r> mripard: hmm?
akaizen has joined #linux-sunxi
<oliv3r> n01: wdt should just work; probably change the dts and your golden
<Turl> mripard: wim took the watchdog driver btw :)
<wingrime_> hramrach: also, current configs have no sound included )
<hramrach> heh
<hramrach> that's probably because the sound was unified but config not updated
<hramrach> or some default changed and removed a dependency
shineworld has joined #linux-sunxi
<wingrime_> hramrach: you have odroid?
<hramrach> chromebook
vinifr has quit [Quit: Saindo]
<hramrach> odriod is still exynos4
<hramrach> but there is arndale or w/e for Exynos5 devboards
<wingrime_> hramrach: how much it faster a10/a20 ?
<hramrach> *much*
<hramrach> but if you want numbers look at ssvb's membench page
<wingrime_> hramrach: but we have opennes
<hramrach> about as open as Exynos.
<hramrach> yeah, you get buggy libs only for Android but in the end it does not make that much of a difference
<oliv3r> wingrime_: maybe sun4i_deconfig lost sound due to transistion to sunxi sound?
<hramrach> we get libs for Linux that fail in different way from the Andriod ones :S
<hramrach> yeah, probably
<wingrime_> oliv3r: looks like
<wingrime_> oliv3r: but I have no usb on a13
shineworld has quit [Remote host closed the connection]
geecko has quit [Ping timeout: 245 seconds]
hramrach has quit [Ping timeout: 240 seconds]
techn__ has quit [Ping timeout: 248 seconds]
<oliv3r> nottoogood: i guess the quickest way would be to FEL load an image, but we are far from achiving that :)
techn_ has joined #linux-sunxi
_enrico_ has joined #linux-sunxi
<mripard> oliv3r: Turl: don't know, you tell me, you hl'd me several times last night :)
<Turl> mripard: don't recall tbh :)
ykchavan has joined #linux-sunxi
hramrach has joined #linux-sunxi
<oliv3r> hramrach: DK is worse? i thought they where trying to be better
<oliv3r> hramrach: i did change the sound to sunxi, but somehow it muist have gone missing
<oliv3r> hramrach: how is exynox equal to AW with regards to opensource; we have everything now. very badly done atm, but that's being improved, there's no blob left
<oliv3r> mripard: Turl i think it was with regard to the single regster for temp
<oliv3r> mripard: the temp sensor is part of the Touchscreen register block
<oliv3r> mripard: if we want a seperate temperature sensor, how do we do this in the DT? 2 regions for touchpanel, skip the 1 register?
<Turl> nice, ODROID-XU+E
<Turl> ssvb might be interested in that :)
<Turl> ah, powervr :(
<ssvb> Turl: yeah, I'm not interested in powervr. And I already have an exynos5250 chromebook, so I have no need for yet another sample of Cortex-A15 hardware
<oliv3r> Shun the powerVR; SHUN IT I SAY!
<mripard> oliv3r: hmmm, looks like an ADC register block to me :)
<oliv3r> mripard: it is; with the latest A20 SDK
<oliv3r> we actually got a working driver for the temp sensor, which uses that register block
<mripard> but either make a driver that is both an input and hwmon driver, and will report both the input events and the temperature
<oliv3r> but how do we make 2 drivers from 1 thing
<mripard> or just don't bother in the touchscreen, and do two distinct drivers.
<ssvb> Turl: big.LITTLE MP hardware could be interesting, but ODROID-XU+E does not support it
<mripard> how do you think the watchdog driver has been made ? :)
<mripard> it's part of the timer IP
<Turl> ssvb: how come? that's their pitch line
<oliv3r> i know but
<oliv3r> this is 1 register in a block
<Turl> ssvb: "first big.LITTLE bare board computer"
<oliv3r> mripard: and the timer uses the first block, and wdt the last i think; so easy to seperate
<oliv3r> mripard: so if you use a register in ablock, do you simply list 2 regions? the before/after?
<mripard> why?
<oliv3r> mripard: and then when you request the area in your driver, the hole will remain?
<ssvb> Turl: they only support big.LITTLE cluster migration, but not big.LITTLE MP
<Turl> mripard: just use overlapping regions :)
<Turl> err oliv3r ^
<Turl> I think that's what mripard is suggesting
<oliv3r> so both drivers have to make sure they don't use eachothers registers?
<Turl> ssvb: is there a hw impediment to it?
<Turl> or just missing work on the sw side?
<mripard> oliv3r: well, yes.
<mripard> or just make one single driver.
<Turl> oliv3r: you could use the simple mmio access api
<Turl> but you can worry about that when you write the ts driver :)
<oliv3r> well you can repurpose the touchpanel as a generic ADC
<oliv3r> which means you'd need a iio -> input driver anyway
<mripard> or just make one single driver that reports to input and hwmon
<mripard> you don't absolutely need IIO
<oliv3r> well temp would also be an input thing
<ssvb> Turl: yes, there is a hardware bug in exynos5410, which makes big.LITTLE MP (all A15 cores and all A7 cores working at the same time) unusable
<Turl> ssvb: :(
<ssvb> Turl: this bug is supposed to be fixed in a newer exynos5420
akaizen_ has joined #linux-sunxi
<Turl> ssvb: interestingly, they don't mention the model #
<Turl> just "exynos5 octa"
<ssvb> Turl: these models are having a notable difference - exynos5410 is using powervr and exynos5420 is using mali :)
<oliv3r> mripard: so if i get it right, you use the DT to tell the driver what to do, input + temp; adc + temp; or just temp; just adc/temp?
akaizen has quit [Ping timeout: 240 seconds]
<mripard> hmmm, no
<Turl> ssvb: ah :)
<mripard> the DT only tells what IP there is at which address
<mripard> it's up to the driver to know what it's capable of
rellla has joined #linux-sunxi
<oliv3r> mripard: well the drive can drive both
<oliv3r> the dt makes pinmuxing happen right?
<oliv3r> (in the driver?)
<oliv3r> or what if there's 2 drivers, 1 for adc, 1 for input
<oliv3r> how does the dt setup the board to use either adc or input?
<mripard> touchscreen pins are not muxed iirc.
<oliv3r> since the driver only gets loaded when the DT tells it to be loaded i think you once said
<oliv3r> mripard: well you configure the touchscreen as either ADC or as ts
akaizen has joined #linux-sunxi
dwilkins has quit [Quit: ZNC -]
wingrime has quit [Ping timeout: 264 seconds]
<mripard> didn't you tell me that they were different registers set ?
<mripard> (temp and touchscreen)
<oliv3r> sno, touchscreen/adc is the same
<oliv3r> temp is a seperated register in the same block
<mripard> yes.
akaizen_ has quit [Ping timeout: 256 seconds]
<oliv3r> but i only mean adc/input now
<mripard> so how are they mutually exclusive ?
<oliv3r> you configure the registers to be either/or
<oliv3r> so you either have a generic ADC, or a touchpanel input
<mripard> yes, usual stuff
<mripard> I still don't get why you want to make two drivers out of it.
<oliv3r> so how does the driver know what to be? :)
<mripard> use a dt property.
<mripard> if it there => behave as touchscreen, if it's not => behave as adc ?
<mripard> but you really got me confused with your brain thinking faster than what you were actually typing.
<mripard> so I'm not sure I actually got the problem right
<oliv3r> lol
<oliv3r> ok, we have 1 registerblock, with 5 or so registers in it, #3 is the temperature sensor and the rest is for the ADC, which also functions as resistive touchscreen driver
<oliv3r> ignoring the temp sensor for a minute
<oliv3r> you either have 2 drivers, 1 for ADC (iio?) and 1 for input/touchpanel
<oliv3r> or 1 driver that reports either as ADC/input
<oliv3r> which would be a multipurpose device?
<oliv3r> so the dt will somehow make it load as either the ADC or as the TP driver?
<mripard> yes
<mripard> look at the ADC driver for mxs for example.
<mripard> it's exactly what's being done
geecko has joined #linux-sunxi
<oliv3r> excellent
<oliv3r> so then with the temp sensor, just add it in the same way
<mripard> yep
<oliv3r> since most of the time, we'll only want that anyway
<oliv3r> i guess you can't use the framework register calls though
akaizen has quit [Ping timeout: 264 seconds]
<mripard> ?
<mripard> what "framework register calls" are you talking about?
akaizen has joined #linux-sunxi
<oliv3r> input_platform_register() combined with iio_module_register()? i don't know yet, still reading :)
akaizen_ has joined #linux-sunxi
akaizen has quit [Ping timeout: 256 seconds]
Black_Horseman has joined #linux-sunxi
<mripard> oliv3r: why couldn't you ?
<oliv3r> i ment the equivalent of module_platform_register() which is a macro that does the _init and _exit
<oliv3r> still looking for which imx chip you where refering too though ;) looking at the dts's now
<wingrime_> oliv3r: a20 can alpha blending layers .....
<oliv3r> i think a10 too
Seppoz has quit [Remote host closed the connection]
Seppoz has joined #linux-sunxi
<mripard> oliv3r: imx28
<oliv3r> i started at 60
<mripard> I said mxs
<mripard> not imx
<oliv3r> heh; which mxs would that have been? i know of none :)
<mripard> there's only two of them, imx23 and imx28
<mripard> looking at mach-mxs would have helped you :)
<oliv3r> i did ctrl-f for mxs :(
<mripard> but you'll only have a single module_platform_register.
<mripard> it's in your probe that you will register against multiple framework
<oliv3r> ah ok
rellla has quit [Quit: Nettalk6 -]
<oliv3r> mripard: is the adc connected to the lradc or the hsadc
<oliv3r> ohh, wait, staging has something!
robb83 has quit [Quit: - A hand crafted IRC client]
<wingrime_> ssvb: what do you think about add kms interface on current disp driver
<oliv3r> but it looks like you can have AND the touchscreen AND 7 ADC's
<wingrime_> ssvb: simple driver that will expose mem ranges
<oliv3r> wingrime_: i think if you'd want kms driver, you'd have to do it from scratch
<oliv3r> but yeah, ssvb is probably best to answer that
<wingrime_> ssvb: and other question, where layer handing must be , in libdrm , kernel, or xf86-driver ?
<wingrime_> oliv3r: I fucked 6 hours with disp bug
<wingrime_> oliv3r: and still not find good solution
<oliv3r> wingrime_: yeah, disp is really bad
<oliv3r> wingrime_: but hacking it around is nasty too i guess
<ssvb> wingrime_: you are better to ask robclark about the modern frameworks, I'm not really tracking this stuff
<ssvb> wingrime_: libv may also have some relevant opinion on this matter
<wingrime_> ssvb: witch channel?
<ssvb> maybe #lima
<oliv3r> wingrime_: rob clark is of freedreno fame
<oliv3r> mripard: yeah the mxs driver does explain it all I suppose, it's till a module_platform_driver; whilst registering with the frameworks it needs; i think i understand atleast some of it now
<wingrime_> ssvb: libv answered , 1) do debug interface for reg dumping 2) do simple kms that expouse reg to userspace
* ssvb does not know if there is any better irc channel for general discussion about graphics support in arm devices
<wingrime_> oliv3r: we have to do it with disp, mailine leaves useless without it
<wingrime_> oliv3r: but when you do disp support , other drivers not a issue
<oliv3r> well with mainline, as far as I understand it, the cedarX kernel module will be a v4l mem2mem kind of device
<wingrime_> oliv3r: no,
<oliv3r> erm pretty sure yeah
<oliv3r> i asked on linux-media :)
<oliv3r> they said, hardware decoders are simply mem2mem devices
<wingrime_> oliv3r: it will be exposed memranges to /dev/kms
<oliv3r> what i'm really worried about is useless copying around of data slowing things down a lot
<wingrime_> oliv3r: sur
<wingrime_> oliv3r: /dev/drm
rz2k has quit []
<wingrime_> oliv3r: libv sayed that radeon do same
<oliv3r> mripard: though I think the mxs does it all; and doesn't have an 'either/or' think, so you'd need a special property in the DT to tell the driver how to behave. The mxs does this by checking how many wires of a certain ADC are used for touchscreen, being 0, 4 or 5 and the driver configures itself appropiatly
<oliv3r> wingrime_: libv also said that radeon is a bit messy :)
<mripard> oliv3r: yep, it's exactly what I said
<oliv3r> mripard: aye, i understand now :)
<oliv3r> mripard: i guess it doesn't matter if a driver can do both, or it switches; the DT will tell it how it will work
binaryferret has quit [Quit: Reconnecting]
binaryferret has joined #linux-sunxi
_enrico_ has quit [Quit: Bye]
<hramrach> wingrime_: well, Cedar *is* a mem2mem device. You would need a very good reason to make it something else. What disp kms/drm gives you are memory buffers to which Cedar can output which also happen to be rendered on-screen
jemk has quit [Remote host closed the connection]
<oliv3r> hramrach: intergrate it with disp due to performance :)
<hramrach> you don't want that. does not work without buffer management. You need to tell it to either render to screen directly ore render off-screen so you can display in a window which is what drm is supposed to be for
<oliv3r> hramrach: aye
<wingrime_> hramrach: cedar need pyhsicaly continuous memory
<oliv3r> wingrime_: you should get that via the kernel normally
<hramrach> I don't think that's too exceptional. Many device do.
<hramrach> does it need just one block or each buffer continuous but different buffers placed freely?
focus_it has joined #linux-sunxi
igor- has joined #linux-sunxi
<oliv3r> oh looks like i started a discussion again; hardware acceleration api should be discussed at the mini-summit
igor- has quit [Ping timeout: 260 seconds]
<wingrime_> ssvb: I find correct workable fix
<ssvb> wingrime_: good
<wingrime_> ssvb: take a look
<wingrime_> ssvb: all works correctly, if window begin < 0 , than we simple crate layer from 0,0
<ssvb> does it provide sane results?
<wingrime_> ssvb: yes
<wingrime_> ssvb: you can check
<wingrime_> ssvb: works with xf86-video sunxi and libvdpau
<wingrime_> ssvb: but also I have say to jemk not use that expensive calls all time , your implementation better
<wingrime_> ssvb: I send patch tomorrow
geecko has quit [Read error: Connection reset by peer]
wingrime_ has quit [Ping timeout: 268 seconds]
focus_it has quit [Quit: Leaving]
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
ykchavan has quit [Quit: Leaving]
ganbold has quit [Remote host closed the connection]