<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 X.org 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>
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
<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
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]
<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>
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
<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.
<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?