deasy has quit [Remote host closed the connection]
issue_ has quit [Remote host closed the connection]
Skaag has quit [Ping timeout: 250 seconds]
wingrime1 has quit [Read error: Connection reset by peer]
wingrime has joined #linux-sunxi
wingrime has quit [Ping timeout: 260 seconds]
maksimlin has joined #linux-sunxi
egbert has quit [Ping timeout: 260 seconds]
Gerwin_J has quit [Quit: Gerwin_J]
<wens>
mripard_: i was hoping to get feedback on the pinctrl patches :)
rainbyte has joined #linux-sunxi
bhag has quit [Ping timeout: 250 seconds]
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
akaizen has quit [Ping timeout: 240 seconds]
akaizen has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
Skaag has joined #linux-sunxi
<Skaag>
any ideas why I don't see the SUNXI_WDT option when I go to Device Drivers -> Watchdog Timer Support, despite the search telling me it's there?
TheSeven has quit [Ping timeout: 272 seconds]
TheSeven has joined #linux-sunxi
xavia has joined #linux-sunxi
ccube has quit [Remote host closed the connection]
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
ccube has joined #linux-sunxi
akaizen has quit [Ping timeout: 240 seconds]
maksimlin has quit [Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140608211828]]
Gerwin_J has quit [Quit: Gerwin_J]
akaizen has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
mmarker has quit [Remote host closed the connection]
mmarker has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
apo__ has joined #linux-sunxi
apo_ has quit [Remote host closed the connection]
egbert has joined #linux-sunxi
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-sunxi
xavia has quit [Quit: Leaving.]
<Skaag>
ok I think my version/branch doesn't have the watchdog patch
<Turl>
Skaag: check that the dependencies are satisfied
<Turl>
the search shows them
focus has quit [Ping timeout: 256 seconds]
dlan has quit [Ping timeout: 240 seconds]
dlan has joined #linux-sunxi
bhag has joined #linux-sunxi
<Skaag>
the dependencies are wither sun4i or sun5i, both are not enabled
<Skaag>
I'm building for A20-Olinuxino
<Skaag>
so I am assuming this board is neither sun4i or sun5i (is it 7?)
<Skaag>
But I think the board does support the watchdog feature, at least in terms of the hardware
<Skaag>
software may just not have been written for it
focus has joined #linux-sunxi
Zboonet has quit [Quit: Leaving]
focus has quit [Ping timeout: 272 seconds]
diego_r has joined #linux-sunxi
diego_r has quit [Client Quit]
physis has quit [Ping timeout: 255 seconds]
focus has joined #linux-sunxi
physis has joined #linux-sunxi
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
akaizen has quit [Ping timeout: 245 seconds]
focus has quit [Ping timeout: 260 seconds]
bhag has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
focus has joined #linux-sunxi
focus has quit [Ping timeout: 272 seconds]
_massi has joined #linux-sunxi
focus has joined #linux-sunxi
bhag has quit [Ping timeout: 256 seconds]
issue_ has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
xeros has joined #linux-sunxi
bhag has joined #linux-sunxi
alexvf has quit [Ping timeout: 246 seconds]
bhag has quit [Ping timeout: 255 seconds]
focus has quit [Ping timeout: 245 seconds]
bhag has joined #linux-sunxi
focus has joined #linux-sunxi
kivutar has joined #linux-sunxi
focus has quit [Ping timeout: 245 seconds]
physis has quit []
shineworld has quit [Quit: Sto andando via]
focus has joined #linux-sunxi
paulk-aldrin has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
focus has quit [Ping timeout: 264 seconds]
deasy has joined #linux-sunxi
focus has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
focus has quit [Ping timeout: 255 seconds]
bhag has quit [Ping timeout: 245 seconds]
focus has joined #linux-sunxi
Andy-D has joined #linux-sunxi
focus has quit [Ping timeout: 240 seconds]
bhag has joined #linux-sunxi
FreezingCold has quit [Ping timeout: 260 seconds]
focus has joined #linux-sunxi
focus has quit [Ping timeout: 264 seconds]
philippe_fouquet has joined #linux-sunxi
philippe_fouquet has quit [Remote host closed the connection]
focus has joined #linux-sunxi
focus has quit [Ping timeout: 264 seconds]
focus has joined #linux-sunxi
Black_Horseman has quit [Remote host closed the connection]
afaerber has joined #linux-sunxi
focus has quit [Ping timeout: 250 seconds]
bhag has quit [Read error: Connection reset by peer]
rainbyte has quit [Read error: Connection reset by peer]
focus has joined #linux-sunxi
philippe_fouquet has joined #linux-sunxi
philippe_fouquet has quit [Remote host closed the connection]
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
focus has quit [Ping timeout: 260 seconds]
kivutar has quit [Remote host closed the connection]
Gerwin_J has joined #linux-sunxi
rainbyte has joined #linux-sunxi
focus has joined #linux-sunxi
kivutar has joined #linux-sunxi
bhag has joined #linux-sunxi
xinj has joined #linux-sunxi
kivutar has quit [Client Quit]
Quarx has joined #linux-sunxi
focus has quit [Ping timeout: 255 seconds]
ricardocrudo has joined #linux-sunxi
Quarx has quit [Ping timeout: 250 seconds]
rds has joined #linux-sunxi
<rds>
very quiet here... this is good, because it may indicate that finally LIBV is working on the kms driver! yesssssssssssssssssssssssss
rds has quit [Client Quit]
<libv>
now that's just trolling.
Renard has joined #linux-sunxi
<libv>
what a fucking selfcentered wanker.
<moofree>
yeah. obviously quiet in here equals gaben working on half life 3 for android
<libv>
i don't think rds every contributed anything in his life
focus has joined #linux-sunxi
rds has joined #linux-sunxi
<rds>
I don't have the skills to contribute yet
<libv>
then you're a useless, whining wanker.
<moofree>
except for sneaky irc skills ;)
<rds>
yes, that I have, since I am bored waiting the market to open.
<libv>
no, damaging is the word
<rds>
damage of what ?
<libv>
rds: you're actively encouraging me to not work on my kms code.
<moofree>
yeah if you want it so much, pay him a few million dogecoins for it
<moofree>
or do it yourself
<rds>
ok, this had the inverse effect that I was looking for. So, you never will hear from me again, about the KMS driver. This way it'll get done faster.
<rds>
bye, bye.
<moofree>
or now it'll never get done
<moofree>
out of spite
<moofree>
fight the power
<libv>
rds: and you figured this out only now?
<libv>
amazing.
<rds>
I am not as bright as you are!
Quarx has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
rds has quit [Quit: Page closed]
focus has quit [Ping timeout: 264 seconds]
petr has quit [Ping timeout: 245 seconds]
petr has joined #linux-sunxi
<deepe>
Hello, I need little help setting up SPI using .fex file
<deepe>
I need to use SPI_3WIRE and according to linux-sunxi.org/Fex_Guide#.5Bspi_devices.5D
<deepe>
in spi_board0 I need to set mode to 0x10
<deepe>
but when I set mode = 10
<deepe>
in hexa it is A and not 0x10(16 in decimal)
<libv>
ssvb: there is a serious problem with simplefb
<libv>
ssvb: where does the memory for it live?
<ssvb>
libv: anywhere in ram?
<libv>
ssvb: how does the linux kernel know?
<libv>
ssvb: it currently reserve certain areas, but i doubt it cares about what u-boot has to say
<ssvb>
libv: if I understand this correctly, the kernel should get this information with the dtb data
<ssvb>
libv: and simplefb is only relevant for the mainline kernel (it is not really needed for the sunxi-3.4 kernel)
<mripard_>
I don't have all the background on this, but yes, the memory area simplefb has to operate on is fed from the DT
<libv>
hrm, then the logic must be provided to both use and later on reclaim that memory when a proper driver is loaded
focus has joined #linux-sunxi
<libv>
if i then only take the memory i need, a single frame, then you get a nice bit of fragmentation there
<ssvb>
I have not checked this in details, but we could probably have a look at how it is done for the other platforms
<libv>
anyway, sunxi-3.4 only seems to reserve for cedar, g2d and disp atm, so if any of that goes upstream, it should be smarter about lightdm
<ssvb>
we are not pioneers with the simplefb driver, and this should make things easier :)
<libv>
perhaps i should a) just pick 1 frame off of the end of RAM b) make lightfb a build-time option
<libv>
as we probably should delay properly worrying about the memory mangling details later
<ssvb>
yes, just one frame is reasonable
focus has quit [Ping timeout: 240 seconds]
<ssvb>
because the kernel in any case has no facilities to change the active frame within the framebuffer or anything like this
<ssvb>
simplefb is extremely simple, and is not a replacement for a proper display driver
<ssvb>
just a placeholder at best
<libv>
sure, but the kernel needs to be smart enough to not use this memory if lightdm is desired or while the display engine is active
<libv>
and, it needs to be smart enough to reclaim this memory when a proper display driver is loaded
<ssvb>
what is the problem with lightdm?
<libv>
err, lightfb
<libv>
i am so used to typing start/stop/restart lightdm
<bonbons>
libv: if I recall correctly simplefb is the generic variant of vesafb. It gets the pointer to the memory from a platform device (display_info or screen_info, don't remember exact name)
<libv>
perhaps lightfb is not as much of a blessing as people think it is
<bonbons>
when a proper driver for the GPU gets loaded it is expected to kick out simplefb
<libv>
bonbons: i understand all that.
<bonbons>
the kick-out is done by conflicting resources during fbdev registration
<libv>
bonbons: read my statements again
<libv>
ok
<libv>
hrm, not sure how that would work
<bonbons>
once kicked-out the simplefb does not exist anymore, and I don't think and platform can resurrect it at a later time (except by creating a new platform device for it)
philippe_fouquet has joined #linux-sunxi
<libv>
and not sure how you would then integrate this 8mb back into a big cma area?
<libv>
this will probably become platform specific magic
<ssvb>
libv: are you worried about what would kick it out in the case of sunxi-3.4 kernel?
<libv>
ssvb: no, not at this time, it will be blindly claimed by cedar, g2d or disp
<libv>
whichever is built in
<bonbons>
the kick-out is triggered by remove_conflicting_framebuffers()
<bonbons>
from drivers/video/fbdev/core/fbmem.c
Gerwin_J has joined #linux-sunxi
<libv>
at suse we had a fun time when we started using the "new" intel driver (written by keithp and anholt, two people who never did any display work before in their lives)
<bonbons>
who manages that cma area?
<libv>
we had people screaming their heads off as you would see old memory garbage on your display for many many seconds
<libv>
and they thought their panels were being destroyed
<libv>
with the display engine running, and the memory getting reclaimed for general use, and no proper display driver getting loaded, we will be seeing a lot of fun things.
focus has joined #linux-sunxi
<bonbons>
that one could consider it reserved until informed by non-generic GPU driver that it took over from simplefb (or just unused platform frambuffer device!)
<libv>
we're on arm hw, i do not want to waste 8mb.
<bonbons>
because there will be someone who just builds in KMS driver and no simplefb/simpledrm!
<libv>
how will the kms driver know to reclaim this memory?
blsd has quit [Remote host closed the connection]
<libv>
it will properly set up the display engine, true, but it will not reclaim the memory
<libv>
there are issues at both ends of this lightfb story
<libv>
err, simplefb
<bonbons>
it should know about the platform firmware-setup framebuffer - as it takes over the GPU/Display device
<libv>
why do i keep messing that up?
<mripard_>
libv: I don't think simplefb is meant to be used with another display driver
<mripard_>
the point when it got merged was precisely to use it whenever you didn't have any display driver, but the bootloader already set up the display
deasy has joined #linux-sunxi
<ssvb>
mripard_: I guess the problems libv raises are:
<ssvb>
a) what if the user wants t run a headless system (who would shutdown the display hardware?)
<bonbons>
it's meant as a replacement for vesafb to have a framebuffer device until whatever better GPU driver takes over (like mod-probe later during boot process)
<libv>
which then means that the memory is forever lost, even if you, as a user do not want a display
<libv>
bonbons: but you could disable vesafb through the int10 vbe interface
<libv>
and in x86 land, the memory was always deemed lost
<ssvb>
b) if the kms driver is used, then how to smoothly move over to the new driver without showing ugly transitional garbage on screen and without wasting any memory?
HeHoPMaJIeH has quit [Remote host closed the connection]
<bonbons>
for b) I think the kms driver could consider the simplfb framebuffer area as initial framebuffer
<bonbons>
later framebuffer swapping would then release that memory are
<libv>
bonbons: the only proper solution is for the platform code to be smart about it all, and to be knowledgeable enough to disable the display.
<bonbons>
libv: how does x86 behave if you do so and still load vesafb?
<libv>
how does simplefb deal with dpms?
<bonbons>
libv: not at all I guess
<bonbons>
just write nice black picture to framebuffer an be done with it
<libv>
what do you refer to with "if you do so"?
tobrebski_ has joined #linux-sunxi
blsd has joined #linux-sunxi
<libv>
on x86, the memory for the display/gpu tends to be reserved at boot time, and then the kernel gets told by the pc bios that it only has a RAM - fb memory to allocate
<bonbons>
libv: disable vesa via int10 (in boot-loader), then start your kernel with vesafb driver (maybe even later with kexec?)
* bonbons
out to lunch - back later
<libv>
you then end up playing gart games to shove things back and forth. on my unichrome driver, for amd k8, i worked around bouncing over hypertransport to the northbridge, by mapping the reserved memory directly, so working around it that way.
<libv>
not sure what hsa does, i have not looked into it properly
<libv>
bonbons: display is enabled or disabled at boottime
<libv>
if the display is enabled, the memory is reserved, and the vga bios is loaded into memory
<libv>
if it is not enabled, no memory is reserved and no bios is loaded into memory
<libv>
things get interesting if you stick a discrete card in the machine and choose the discrete card as your primary device
<libv>
as then you have no vga bios to work with your onboard (ram using) graphics
<libv>
anyway, simplefb seems a pretty shortsighted hack that opens up a whole new can of worms
<ssvb>
at least we are lucky not to have to deal with these x86 things, so this is more like just a theoretical part of the discussion
<libv>
we are arm, we cannot afford to be as wasteful as x86 :)
<ssvb>
and we can still have a look at how this stuff is implemented on the other arm platforms :)
<libv>
but i have extensively dealt with this in my past
<libv>
or we can be smart on our own
<libv>
and be clueful enough to put the relevant engines into reset so no memory is read out anymore, and then reclaim the memory
<libv>
in the platform code
blsd has quit [Quit: Leaving]
Gerwin_J has quit [Quit: Gerwin_J]
blsd has joined #linux-sunxi
<libv>
or, always consider the memory lost
focus has quit [Ping timeout: 255 seconds]
enrico_ has joined #linux-sunxi
nashwhat_ has joined #linux-sunxi
<libv>
it is actually irrelevant whether we initialize simplefb or not
nashwhat has quit [Ping timeout: 255 seconds]
Skaag has quit [Ping timeout: 240 seconds]
<libv>
we either always loose the memory (and need to be told about it someway in the platform code), or we always need to know how to disable the use of this memory in platform code
<mripard_>
ssvb: for b), why would you probe simplefb in the first place then?
<mripard_>
a) is indeed an interesting issue
philippe_fouquet has quit [Remote host closed the connection]
Skaag has joined #linux-sunxi
<ssvb>
mripard_: I guess, the a) case could be solved by a headless bootloader :)
<libv>
people don't work like that
<mripard_>
ssvb: but then, if we had the display clocks, those will be automatically shutdown if no one uses them
focus has joined #linux-sunxi
<mripard_>
if there's regulators, that would be the case too
<mripard_>
and the memory that u-boot might have requested will be completely ignored by linux
<libv>
...
<libv>
anyway, the platform code will need to be clued up to deal with u-boots display code
<libv>
both sunxi-3.4 and mainline.
<libv>
either reserve the memory, or disable dram readout
<libv>
and some combination thereof in case someone wants to use simplefb, but might switch to a proper driver in future
<ssvb>
libv: if I understood mripard_ correctly, the mainline kernel will already shutdown the display clocks if nobody uses them
<arete74>
at suse we had a fun time when we started using the "new" intel
<arete74>
driver (written by keithp and anholt, two people who never did
<ssvb>
libv: and the sunxi-3.4 platform code could also do this
<arete74>
any display work before in their lives)
<libv>
from ccm
<arete74>
bad paste
<libv>
ssvb: we need to be clueful about that as well
<libv>
ssvb: what is "not used"
<libv>
how does the platform code know that these are used if simplefb is loaded?
<mripard_>
libv: everything that has not been enabled
<mripard_>
if you want some clocks to be always enabled, just add to the platform code those
<libv>
mripard_: enabled in hw, or enabled in the kernel?
<mripard_>
enabled in the kernel
<mripard_>
using clk_prepare_enable
<libv>
ok
<libv>
then... simplefb will never work without a lot of platform code
<mripard_>
we already have some of them hardcode
<mripard_>
such as the cpu, mbus, etc. ones
<mripard_>
to prevent them from shutting down, even though no driver explictly enable them
<libv>
simplefb is turning out quite a bit less than what it says on the box :)
Skaag has quit [Ping timeout: 245 seconds]
<mripard_>
well, it was aimed for the rpi :)
<mripard_>
what did you expect
mdp has quit [Ping timeout: 260 seconds]
nedko has quit [Quit: kernel panic]
<mripard_>
note that for a clock to be shutdown, the clock framework have to know about it
<mripard_>
so if we'd just "forget" about it, it wouldn't be shutdown
focus has quit [Ping timeout: 240 seconds]
issue_ has quit [Read error: Connection reset by peer]
xavia has joined #linux-sunxi
mdp has joined #linux-sunxi
T0mW has joined #linux-sunxi
<T0mW>
I have a basic question regarding the AllWinner ARM. What the heck are these 'Multi Driving Registers (0,1)'? Are these the output pin driver registers to set/reset GPIO pins?
<T0mW>
I see the GPIO pullup and direction regs, but am confused by the 'Muli Driving Regs'
<libv>
mripard_: hehe
<libv>
but even in the rpi case, they barely gained anything
<libv>
s/even/especially/
<libv>
since the videocode dsp does all the work
<mripard_>
T0mW: iirc, it's the current output on the pin
<libv>
they could've just added this handful of lines of code to the platform code
<libv>
that is actually the only way to deal with all the issues that simplefb exposes
<bonbons>
for headless the best certainly would be to disable (or not enable) GPU on bootloader side. For anything else either platform or whatever driver takes over should be able to undo things
<libv>
because in case of rpi, you have no real access to any display hw
<T0mW>
mripard_: ok, ..., how do you set the pin "high" or "low" ?
<libv>
you have, but you do not know how to handle it, as this is supposedly what the videocore does
<bonbons>
simplefb (or simpledrm) are too simple for that as they just assume a memory area they got told about it show somehow to the user
<bonbons>
so KMS driver would be in charge of taking over and then disabling whatever is not needed with all outputs are shut down - that's assuming GPU has been announced in ftd/fex
<libv>
or why spreading display drivers all over the place is a recipe for disaster
<libv>
and how the bcm design induces shortsighted solutions which do not provide complete answers
<mripard_>
I don't really see the relation between the GPU and the KMS driver
focus has joined #linux-sunxi
<libv>
mripard_: x86 thinking
<mripard_>
bonbons: you can have a DRM/KMS driver without a GPU, and a GPU without a DRM/KMS driver
<mripard_>
libv: ah, good, I'm not missing something then
<libv>
mripard_: i have been thinking for years that i actually should write s3 and tseng kms drivers now to show the stupidity of the drm crowd
<mripard_>
s3 and tseng?
<bonbons>
mripard_: depends on how you define GPU, but sure for SOCs it's not a "single piece of HW" as it's for x86.
<libv>
but then, they are now hard at work implementing stuff that would've been implemented in 2006 if the right people had been told by intel to fix the display driver
<libv>
mripard_: pci era hw, no 3d engine
<libv>
most have load detection, some have ddc
<libv>
and i have a wide collection of them
<T0mW>
mripard_: is there a spec for those drive levels?
<libv>
and i even REed the vga bioses to find out how ddc is wired up
<libv>
so there is no reason to refuse them as kms drivers
<libv>
apart from the fact that they very painfully show the stupidity of wholly mashing up display drivers with 3d interface drivers
issue_ has joined #linux-sunxi
<mripard_>
bonbons: well, a GPU is a Graphics Processing Unit.
<mripard_>
it just processes stuff
<mripard_>
never actually display them
<mripard_>
libv: a colleague of mine is actually writing a DRM/KMS driver for an SoC that doesn't have a GPU
<bonbons>
sure, but where does processing end? at byte thinking or converting to electrical signal on a connector?
<mripard_>
so you don't have to look that far back :)
<libv>
mripard_: yes, for arm, it's actually a problem
<libv>
oh, it was airlied who decided that drm drivers should live under drivers/gpu
<libv>
not drivers/graphics/
focus has quit [Ping timeout: 250 seconds]
<libv>
the whole thing reeks of shortsightedness through and through
<mripard_>
bonbons: it ends at when the computation are done
<libv>
bonbons: everything except the display engine takes stuff from some memory and sticks it into some memory
<bonbons>
mripard_: then inaccurate terminology from my side
<libv>
the display engine takes stuff from memory, and sticks it in interesting (but until recently mostly ignored) ways on a monitor or display somewhere
<T0mW>
mripard_: can they really do 40ma off those pins?!
<libv>
all the display engine needs to share with a gpu, 2d or media engine is: memory address and layout, and some signalling
<mripard_>
T0mW: yep
<mripard_>
at least, that's what my multimeter was saying
<bonbons>
so with simplefb and the like just the display engine is concerned - to use the right term
<mripard_>
yep
<bonbons>
:)
<libv>
yes, plain text consoles are drawn by the cpu
<mripard_>
bonbons: plus potentially some other components, like the CRTC, the interface controllers, etc.
<libv>
the crtc is part of the display engine
<mripard_>
and usually on your desktop, all that is packaged with the GPU, is the graphic card
<mripard_>
libv: is it? in the general case, or in the allwinner SoC
<mripard_>
?
<libv>
some encoders could be external, which is how i got to the crtc vs output abstraction to begin with (i called it output devices as egbert complained that an encoder does not equal a ramdac)
<libv>
mripard_: a crtc is the serializer, it decides the timing
<libv>
you often have like scalers and composer in front of that
<libv>
after it, the invididual pixels are sent to an encoder of some sort, then sent out a connector to a monitor.
<libv>
a crtc needs to be reasonably close to where the ram is
<T0mW>
mripard_: wow! thanks for all your help!
<mripard_>
yeah, but isn't it what allwinner calls the TCON ?
focus has joined #linux-sunxi
nedko has joined #linux-sunxi
focus_it has joined #linux-sunxi
focus has quit [Ping timeout: 260 seconds]
hypno__ has quit [Ping timeout: 240 seconds]
focus_it has quit [Ping timeout: 260 seconds]
akaizen has joined #linux-sunxi
focus_it has joined #linux-sunxi
libcg has quit [Remote host closed the connection]
akaizen has quit [Remote host closed the connection]
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
Andy-D has quit [Ping timeout: 240 seconds]
akaizen has quit [Ping timeout: 240 seconds]
formruga has joined #linux-sunxi
Andy-D has joined #linux-sunxi
sehraf has quit [Read error: Connection reset by peer]
sehraf has joined #linux-sunxi
techn has joined #linux-sunxi
akaizen has joined #linux-sunxi
tomboy64 has quit [Ping timeout: 264 seconds]
hramrach has quit [Ping timeout: 264 seconds]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 250 seconds]
FR^2 has quit [Quit: Connection reset by peer]
BorgCuba has joined #linux-sunxi
tomboy64 has joined #linux-sunxi
hramrach has joined #linux-sunxi
tomboy64 has quit [Remote host closed the connection]
leviathanch2 has joined #linux-sunxi
afaerber has quit [Quit: Verlassend]
<paulk-aldrin>
hey guys, can I expect to be able to decode 720p (say on xbmc) using the cubietruck and the free vdpau library for cedarx?
<paulk-aldrin>
or even using cpu only?
tomboy64 has joined #linux-sunxi
kuldeepdhaka has joined #linux-sunxi
<BorgCuba>
the xbmc x-compile guide doesnt work anymore. malideveloper url has changed as well as the location for libMali.so
diego_r has quit [Ping timeout: 240 seconds]
libv_ is now known as libv
rZr is now known as RzR
<libv>
wens: probably not this year, if a80 is anything to go by
<libv>
besides, the guys at SuSE only just got the first engineering samples of the juno board
<libv>
loads of stuff is still broken on it
<libv>
pci-e and sata if my info is right
eagles0513875 has quit [Changing host]
eagles0513875 has joined #linux-sunxi
eagles0513875 has joined #linux-sunxi
wickwire has quit [Quit: Leaving]
ikeeki has joined #linux-sunxi
netlynx has quit [Quit: Leaving]
<hramrach>
hello
<hramrach>
I wanted to check how much an A20 lime differs from A20 cubieboard
<hramrach>
but there is no a20 lime fex file in sunxi-boards !!!
<libv>
why the exclamation marks?
<libv>
only some engineering samples went out afaik
<libv>
but perhaps oliv3r has a board already
<hramrach>
paulk-aldrin: I would expect 720p to work unless it's 10bit or incorrectly encoded
<hramrach>
which reminds me to look into that bit-trashing feature added to Mesa, hmm
physis has joined #linux-sunxi
<hramrach>
but only for an interface no known media player uses. so useful !
notmart has quit [Quit: notmart terminated!]
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
ikeeki has quit [Quit: Saliendo]
issue_ has quit [Remote host closed the connection]
deasy has joined #linux-sunxi
afaerber has joined #linux-sunxi
<BorgCuba>
libv, are you (and others) currently working on the lima project? Whats the state of the mesa/ogl port? What about the progress on the compiler?
Andy-D has quit [Ping timeout: 245 seconds]
paulk-collins has joined #linux-sunxi
BorgCuba has quit [Quit: leaving]
issue_ has joined #linux-sunxi
xeros has quit [Ping timeout: 256 seconds]
<paulk-collins>
hey, how do I enable cdc_ether with fedora on sunxi?
Skaag has joined #linux-sunxi
physis has quit []
hramrach has quit [Ping timeout: 264 seconds]
xeros has joined #linux-sunxi
hramrach has joined #linux-sunxi
Andy-D has joined #linux-sunxi
paulk-collins has left #linux-sunxi ["Ex-Chat"]
formruga has quit [Quit: Konversation terminated!]
Skaag has quit [Ping timeout: 256 seconds]
techn has quit [Ping timeout: 260 seconds]
RzR is now known as rZr
Skaag has joined #linux-sunxi
<bonbons>
how should I proceed, Xpower's AXP driver is poking at undocumented 0xB? and 0xC? registers (apparently for OCV - open circuit voltage - for battery gauge?)
<bonbons>
should I just poke at them the same way?
<Turl>
bonbons: try to make sense of them and document them on the wiki :)
<bonbons>
can people share their values for reg 0x03 on AXP PMUs ()? Might be a PMU identification byte according to power-supply code
techn has joined #linux-sunxi
<bonbons>
Turl: sure - my 0x03 is 0x41 - AXP209 on cubietruck
<bonbons>
your 0xC? and 0xBA/0xBB regs do contain a few values, so probably also configured OCV
<bonbons>
Turl: which kernel is it, sunxi 3.4.x or mainline?
<Turl>
3.4.90+
<Turl>
note that there's no battery on this thing
<Turl>
and that I'm using the hwmon patches (not sure if that got ever merged)
<bonbons>
ok, will see how it looks here on mainline for those regs. 3.4.x does fill them with data, though would have to check if there is some bail-out for "no battery"