hno changed the topic of #linux-sunxi to: /Allwinner/sunxi development discussion - Don't ask to ask. Just ask and wait! - See | | Logs at
<naobsd> is there any missing driver for A20 to use libvdpau-sunxi? I can't find any detail about it
<naobsd> (it was mentioned on cubieboard google groups)
<naobsd> I guess they are talking about 3.4 kernel, I'm not sure
<naobsd> I'm not sure missing == not ported yet, or == only binary blobs for 3.3 are available
<naobsd> I think there is no binary blob in 3.3 kernel...
popolon has quit [Quit: Quitte]
jlj has joined #linux-sunxi
akaizen_ has quit [Remote host closed the connection]
<hno> naobsd, there is plenty of blobs in the 3.3 kernel, but none that is relevant to CedarX.
<naobsd> hno: thanks
<hno> but I am not sure if the CedarX driver in 3.3 kernel is compatible, or if the A20 and A10 CedarX is identical.
<naobsd> ah, I see
akaizen has joined #linux-sunxi
<hno> The hardware quite likely is the same, just not sure. Not actively working on those parts.
<naobsd> if software is incompatible, driver or library need to be fixed. if hardware is incompatible, need more RE. from message on google groups, it sounds something need to be provided from allwinner, I felt strangeness
egbert has quit [Disconnected by services]
egbert_ has joined #linux-sunxi
<naobsd> is u-boot built with thumb(2)?
<naobsd> oops, where is my working dir...
<hno> u-boot is not build with thumb. Alla arm32.
<naobsd> did you try CONFIG_SYS_THUMB_BUILD?
<hno> No.
<hno> which message indicated something needs to be provided by allwinner?
robb83 has joined #linux-sunxi
<naobsd> I have no idea about "allwinner cedarx drivers"
<hno> that's the binary blobs.
<naobsd> I just think it's in kernel source
<hno> no, it's userspace libs.
<naobsd> well
<naobsd> maybe
robb83 has quit [Client Quit]
<naobsd> used for early xmbc/vlc work?
<hno> the kernel CedarX driver is really stupid.
<hno> yes
<naobsd> I think there is no direct relation between such an old thing and recent libvdpau-sunxi
akaizen_ has joined #linux-sunxi
akaizen has quit [Read error: Connection reset by peer]
<hno> libvdpau-sunxi is using the same kernel driver for now.
<naobsd> but there is no binary blobs provided by allwinner, right?
<hno> correct
<naobsd> I see, thanks
egbert has joined #linux-sunxi
<naobsd> hmm, only omap4_common.h defines CONFIG_SYS_THUMB_BUILD
<hno> libvdpau-sunxi is all free software.
<hno> highbank also.
egbert_ has quit [Ping timeout: 264 seconds]
<hno> size significantly smaller.
<naobsd> i'm trying... is there any chance to enable falcon again ;)
<naobsd> ?
<hno> Looks promising. Cubieboard2 booted fine in thumbs mode.
<naobsd> oh, very good!
<hno> but my toolchain works in arm32 mode too.. some bytes left.
<naobsd> I don't know well about thumb(2)
<naobsd> maybe it's compatible(can be mixed w/o special handling) with arm32(armv7) code?
<hno> u-boot is just one program. no need to mix.
<naobsd> I think some code are written in arm32 asm
<naobsd> but I guess they use same ABI etc... sorry, I really have no knowledge about them ;)
<hno> ABI is a little different. asm is mostly the same and easy to write asm that works in both modes.
<hno> wow.. several KB free space in thumb mode.
<naobsd> I worried if it needs additional code
<naobsd> but it seems it's running, no problem :)
<hno> -rwxrwxr-x. 1 henrik henrik 18412 1 sep 03.18 build/Cubieboard2_Falcon_T-4.8/spl/u-boot-spl.bin
<naobsd> hno: very nice :)
<hno> U-Boot SPL 2013.10-rc1-00602-gd787d30-dirty (Sep 01 2013 - 03:17:40)
dlan has quit [Ping timeout: 240 seconds]
<hno> that's with latest linaro gcc 4.8 which can't otherwise fit the spl if falcon mode is enabled.
<naobsd> oops, I'm still on sunxi-current
<naobsd> grr
<naobsd> retrying with sunxi...
<hno> naobsd, what board do you have?
<naobsd> cb2
<hno> Cubieboard2_Falcon_T arm armv7 sunxi - sunxi sun7i:CUBIEBOARD2,SPL,SPL_OS_BOOT,SUNXI_EMAC,STATUSLED=244,SYS_THUMB_BUILD
<hno> in boards.cfg dfines a thumbs build with falcon.
<naobsd> thanks, I added CONFIG_SYS_THUMB_BUILD in include/configs/sunxi-common.h :)
Soru has quit [Read error: Connection reset by peer]
<hno> You also need SPL_OS_BOOT for falcon.
<hno> CONFIG_... if set by #define
<naobsd> I see, there is Cubieboard2_Falcon in boards.cfg
<hno> yes
<naobsd> I did git pull on sunxi :)
Soru has joined #linux-sunxi
<hno> Looks very promising. But haven't tried to load a kernel yet.
<naobsd> -rwxr-xr-x 1 fun fun 18340 2013-09-01 10:34 u-boot-spl.bin (with linaro gcc 4.7)
<naobsd> I guess there is some optimization which is enabled only on non-thumb mode...
<naobsd> on 4.8
<naobsd> I also not tried to load yet
<naobsd> I have to open my gadget box to try
<hno> please test what you can test. Time for bed here. Have a meeing in some hours..
<naobsd> ... and clean my desk...
<naobsd> hno: I see, good night
\\Mr_C\\ has quit []
<naobsd> hmm, I have to go out, see you later...
naobsd has quit [Quit: Page closed]
[7] has quit [Disconnected by services]
TheSeven has joined #linux-sunxi
massi has joined #linux-sunxi
massi has quit [Quit: Leaving]
wingrime has joined #linux-sunxi
<wingrime> jukivili: ping
<wingrime> ssvb: ping
<wingrime> ssvb: are you tested small patch?
robb83 has joined #linux-sunxi
sud0x3 has quit [Ping timeout: 256 seconds]
<wingrime> Tsvetan: ping
<wingrime> oliv3r: for such things like history we have versioning system - git
<wingrime> oliv3r: we much not have #if 0 code
<jukivili> wingrime: ping
<wingrime> jukivili: you broke a13 usb
<wingrime> jukivili: ((
<wingrime> jukivili: there something different in a13 usb that not handled by current code
<jukivili> hm.. which commit?
<wingrime> jukivili: have no idea,
<wingrime> jukivili: my older kernel was before unification
<wingrime> jukivili: I tryed remove sunxi_is_sun5i() or invert but useless
<wingrime> jukivili: so there something you lost during unification
<jukivili> which kernel you are using?
<wingrime> 3.4
<wingrime> stage
<jukivili> are you sure it's the unification that went wrong? .. there has been alot of patches to clean up usb host drivers lately
<wingrime> jukivili: don't know
<wingrime> jukivili: but I tested same code with a10 and a13
<wingrime> jukivili: on a13 usb have no any thign of life
deasy has joined #linux-sunxi
naobsd has joined #linux-sunxi
<oliv3r> wingrime: yeha but if i'd start porting/writing a new disp driver i'd look at the current code, not at the history; btw, it doesn't happen to be that #if 0; #if 1 etc should have been ARCH_SUN4I; ARCH_SUN5I? You know how allwinner is, fork code, and change it for the platform
<oliv3r> wingrime: jukivili arokux1 did a lot with USB too
<jukivili> wingrime: can you test the non-stage sunxi-3.4? It does not appear to have those clean-up patches yet.
<wingrime> jukivili: I will try
<wingrime> oliv3r: git for that
<oliv3r> wingrime: ok you voulenteerd to rewrite disp :D
<oliv3r> i kid i kid
<wingrime> oliv3r: you can comparea any file in any branch with GIT
<wingrime> oliv3r: we have firstly drop all non used code
RaYmAn_ is now known as RaYmAn
<leviathanch> Turl: hi
<wingrime> jukivili: unfortunly current sunxi-3.4 even not builds
<mnemoc> o_O
<leviathanch> I'm working on the sunxi-mci driver for linux-next right now
<leviathanch> unfortunately I don't know how to cleanly access the registers of the mod0 clock
* leviathanch still trying to figure it out
<leviathanch> wingrime: my branch is building allthough it's not doing anything useful yet
<leviathanch> >_>
<wingrime> mnemoc: proof
_enrico_ has joined #linux-sunxi
n01 has joined #linux-sunxi
<oliv3r> leviathanch: you are not supposed to touch the mod0 registers, you use the clock framework to set/get a clock
<oliv3r> leviathanch: have you been in touch with mripard as he also did a mmc/SDIO driver or is working on one
wingrime has quit [Ping timeout: 264 seconds]
<mripard> leviathanch: this is exactly what Emilio's patches I've pointed you to are doing.
<mripard> hno: ping?
<leviathanch> mripard: uh?
<leviathanch> I'm working on emilio's branch right now
<leviathanch> ok
<mripard> (basically, you don't touch the mod0 registers directly, you just use the clock framework functions)
<leviathanch> mripard: how do I choose the clock source?
<leviathanch> set_parent?
<leviathanch> mripard: you know that ahb is basically only a clock multiplexer
<leviathanch> so the question is how do I tell it which clock source to use?
<mripard> i think you don't need to worry about this, and clk_set_rate will take care of reparenting the clock if it needs to, but I'm not sure
<mripard> Turl: ?
<leviathanch> mripard: if so, I could delete a whole bunch of code
<mripard> that's the plan, yes.
<oliv3r> leviathanch: if your working in porting the current mmc code; most probably, it's a huge pile of mess that dates back to the sun3i days, probably even from before that
<oliv3r> it might be worth exploring if there's other mmc drivers that are almost the same? its not unlikely they've used some IP for the mmc :)
<mripard> drachensun: ping?
wingrime has joined #linux-sunxi
<oliv3r> mripard: today a good day to resubmit the cleaned up version? or wait a little more for comments?
atiti has joined #linux-sunxi
<leviathanch> oliv3r: I've got u-boot-sunxi in front of me as well
<leviathanch> as well as the A20 user manual
<leviathanch> but it's no good
<leviathanch> all the same hackish approaches
<oliv3r> oh that's even a bigger pile of shit
<oliv3r> :)
<mripard> oliv3r: yeah, just send the patch
<leviathanch> mripard: nope, it's not doing it right
<leviathanch> [ 0.892277] [mmc]: MMC Driver init host -1
<leviathanch> [ 0.919476] [mmc]: sunxi_mmc_set_ios, ios->clock: 400000
<leviathanch> [ 0.924790] [mmc]: sunxi_mmc_set_ios, rate now: 10000000
<leviathanch> [ 0.896368] [mmc]: sdc-1 power on!
<leviathanch> 10MHz is a little bit too much
<wingrime> jukivili: ping
<wingrime> mnemoc: ping
<mnemoc> wingrime: i hadn't notice the v3.4.43-r1 tag Turl did
<mnemoc> seriosly need to rent a place when I can work somewhere beside the bed...
<mnemoc> where*
<mnemoc> not th emost productive/motivating position
<wingrime> mnemoc: if I use old _config_ all builds for a13
<wingrime> mnemoc: _config_ from non stage
<mnemoc> I built every defconfig in stage the 28 with success
<mripard> leviathanch: why do you disable the clock?
<wingrime> mnemoc: yeax,
<oliv3r> mnemoc: do you have a desk?
<wingrime> mnemoc: I simply used config from stage to non - statge
<mnemoc> oliv3r: no
<oliv3r> oh so you sit on the berd
<mnemoc> yes
<oliv3r> :S
<mnemoc> or toilet
<oliv3r> yeah not ideal
<oliv3r> lol
<mnemoc> both kill your back
<leviathanch> mripard: in case it got disabled already :-)
<oliv3r> no chair then
<leviathanch> mripard: even if I don't put these two lines there
<leviathanch> the same happens
<leviathanch> ...
<mnemoc> oliv3r: ack
<oliv3r> :(
<mnemoc> belly-down with the laptop in front ended been the less painful position for typing
<mnemoc> but far from productive anyway
<oliv3r> oh i cant do that too long, my back doesnt liker that at all
<oliv3r> well neck rather
<mripard> leviathanch: then maybe the reparenting part is missing from Turl's patches
<leviathanch> mripard: it is Turls branch
<leviathanch> can't be
<leviathanch> I pulled the branch from his bitbucket repo
<oliv3r> leviathanch: but what if he hasn't implemnted it yet? :)
<leviathanch> oliv3r: hrhr
<leviathanch> yeah
<leviathanch> different kind of story
<leviathanch> I'm basing my work on WIP linux-upstream stuff here
<mnemoc> will do a test build of non-stage 3.4 now
<mripard> leviathanch: yes, we know that, but Turl's patches are wip, and probably there's some bits he didn't think about
<mripard> debugging what could go wrong/missing is part of the job.
<leviathanch> nice thing then
<leviathanch> that someone of me is using his code
<leviathanch> :-)
<leviathanch> *like
<leviathanch> well
<leviathanch> I can commit and push what I've got so far
<oliv3r> leviathanch: all of sunxi is very much 'wip'
<leviathanch> oliv3r: hrhr
<leviathanch> yeah
<wingrime> jukivili: ping
<leviathanch> I gotta go onto the bus in some minutes
<leviathanch> fishing
<jukivili> wingrime: pong
<leviathanch> :-)
<leviathanch> mripard: I've pushed the recent changes
<wingrime> jukivili: seems non-stage work
<jukivili> wingrime: ok, then some of the cleanup work has broken a13 usb
<leviathanch> mripard:;a=shortlog;h=refs/heads/sunxi-mmc-cleanup
<jukivili> arokux1: ping
<leviathanch> maybe someone can ping Turl when he is around that he might try out my branch and fix this issue
<leviathanch> :-)
<oliv3r> mripard: if i understand you right, you prefer having all 3 patches labeld as [PATCHv6 x/n] ARM: sunxi: (dt: for dt patch)? how do I do that with send-email? i know --subject-prefix='v6' is probably the thing for the [PATCH] bit, but after that i draw a blank
<oliv3r> though reading if it mentions anything
<jukivili> wingrime: does reverting 5443e361562b0d30f18fdbde7ee8bce468cdc37a help?
<mripard> leviathanch: or you can try to fix this yourself if you're so eager
<wingrime> jukivili: whait I now also testing more one patch for a10
<mripard> oliv3r: commit log?
<oliv3r> the subject
<oliv3r> ohh, yes! i know what yo mean, not on the 0/n mail; got ya
<wingrime> oliv3r: have a20 / a31 IEP ?
<oliv3r> wingrime: i don't think so, i belive it's an A13-only thing
<oliv3r> Image Enhancement Processor
<oliv3r> like 'flicker filtering' etc
<oliv3r> it may be a modified g2d, something sun5i lacks if i'm not mistaken
<wingrime> oliv3r: thats only deflicker
<oliv3r> wingrime: yeah it doesn't do a lot, but it's for tablets
<mnemoc> wingrime: just built sunxi-3.4's head for all our defconfigs without troubles
<mnemoc> so back to stage, what do you think it's missing for merging it to non-stage?
<wingrime> mnemoc: better add sound + codedcs
<wingrime> to configs
<leviathanch> mripard: ok!
<leviathanch> I could
<techn_> hno: fel-boot has changed?
Soru has quit [Ping timeout: 264 seconds]
Soru has joined #linux-sunxi
<n01> mripard: if I want to start working again on mainlining on which branch of yours is better to use?
<mripard> sunxi-next
<mripard> pretty much everything's merged now
<n01> got it
<oliv3r> techn_: u-boot has changed slightly all over
<oliv3r> mripard: there, v6 on the interwebs
<Turl> morning
<oliv3r> Turl: lo
<oliv3r> jukivili: UsbPhyInit() doesn't sound much like no-op (pure by the name of it)
<Turl> leviathanch: ping
<wingrime> mnemoc: what do you think abour #if 0 block cleaup form disp?
<Turl> mripard: ping
<wingrime> mnemoc: also I fill send #ifdef UNUSED blocks
<oliv3r> wingrime: btw, i never said it was a bad idea :)
<wingrime> oliv3r: for all crap we have lincee branches
<oliv3r> wingrime: that is very very true; good point
<oliv3r> wingrime: clean it!
robb83 has quit [Quit: - A hand crafted IRC client]
<oliv3r> wingrime: I retract my comment :)
<wingrime> oliv3r: also I will remove AVS driver - thats not used by any cedar blocb
<oliv3r> wingrime: Audio Video sync
<wingrime> oliv3r: sun7i also have no
<oliv3r> it's just a timer isn't it
<mripard> Turl: hi :)
<wingrime> oliv3r: current cedar use hres timer
<wingrime> oliv3r: also this is cedar - only driver
<oliv3r> wingrime: isn't the hres timer used by the kernel?
<oliv3r> wingrime: i thought in mainline mripard used it for that
<wingrime> oliv3r: yes, any player will use hres
<Turl> hi mripard
<wingrime> oliv3r: avs from sun3i times
<oliv3r> wingrime: a20 still has the AVS counter
<oliv3r> wingrime: so we could just rename it and make it CNTR0
<Turl> mripard: I see a lot of highlights about clocks but I didn't get where's the issue fully
<oliv3r> since that's all it does, it's a counter, probably with its timings in sync, but still a counter only anyway
<oliv3r> Turl: leviathanch is missing mmc clocks
<Turl> oliv3r: which one? I think I implemented them already
<wingrime> oliv3r: sun4i_avs was broken untill hramrach fixed it
<wingrime> oliv3r: sun4i stock never have it build in
<oliv3r> wingrime: so yeah, we don't have an AVS, we have a counter0 :)
<wingrime> oliv3r: but this is private api /dev/avsdev
<wingrime> oliv3r: also sun4i_cedar have own ioctrl to it
<oliv3r> yeah but if you say it's not needed and software has a much more accurate timer, then why would we need it
<wingrime> oliv3r: I will unify cedar soon, also I want clean it
<oliv3r> wingrime: didn't you unify it a while ago? i thought those patches landed allready
<wingrime> oliv3r: still no
<oliv3r> atleast we have an up-to-date staging tree again
<hno> techn_, not that I know of. Script been called usb-boot for a very very loing time
<wingrime> mnemoc: ping
<mripard> oliv3r: I'm using what for what?
<mouchon> hello
<mripard> Turl: the issue leviathanch seems to have is that the mod0 clocks don't change their source clock when you actually call an impossible set_rate for the current clock it uses
<mouchon> i made some test to change i2c freq to 50khz and seem to work :-)
<Turl> mripard: well, the clocks don't have "upstream" knowledge
<Turl> mripard: they do their best effort to round and that's it right?
<mripard> leviathanch: btw, 400kHz ? for a SDIO driver? it seems way too low
<jukivili> oliv3r: the thing is that UsbPhyInit() modifies register space of the otg controller, and at least on sun4i omitting that function from usb-host driver has no adverse effect
<mripard> Turl: the weird thing is that it asks for 400kHz, and gets 10MHz
<oliv3r> mripard: hi-res timer source for the kernels timer
<mripard> at what frequency are the mod0 clocks running?
<mripard> oliv3r: no, I'm not using it currently
<mripard> I have patches working on all SoCs but the A31, I'd like to get why before sending the patches
fredy has quit [Excess Flood]
<oliv3r> jukivili: maybe people are using the wrong USB port! :D
fredy has joined #linux-sunxi
<Turl> mripard: on which parent?
<jukivili> oliv3r: if reverting patch fixes the issue, then I think correct place for UsbPhyInit() is outside usb-host and otg driver.. move phy initialization to arch/arm/plat-sunxi/
<mripard> Turl: hosc, pll5 and pll6
<Turl> mripard: yeah but which one was active for it? :)
<Turl> mripard: pasting /d/clk/clk_summary would be nice ;)
<mripard> don't know, ask him :)
<mripard> leviathanch: ^
<Turl> (/d/ is debugfs, and you need to enable CLK_DEBUG)
<mripard> you're such an Android guy :)
<Turl> mripard: /d/ is just so more convenient than punching /sys/kernel/debug/ on a keyboard each time :)
<wingrime> oliv3r: take a look to ML
robb83 has joined #linux-sunxi
<oliv3r> what'st that #UNUSEd table for?
<oliv3r> looks almost like firmware
<wingrime> oliv3r: Fir
<wingrime> oliv3r: do you know what it means?
<oliv3r> fir is?
<oliv3r> FIrmware? :op
<wingrime> oliv3r: no
<oliv3r> could even relate ti infraread
<wingrime> oliv3r: ni,no
<Turl> mripard: if you need a 400kHz clock, parent can't be higher than ~50Mhz
<wingrime> oliv3r: this is digital filer coefs
<wingrime> oliv3r: finite responce filter
<Turl> mripard: mod0 only has a /8 and a /16
<wingrime> oliv3r: looks like AW add special table for video playback , but newer used it
<oliv3r> wingrime: ohh yeah i've heard of that I think
<oliv3r> wingrime: i've done some FIR filters in FPGA once
<wingrime> oliv3r: it very simple thing
<wingrime> oliv3r: also ther many soft that can generate such table
shineworld has joined #linux-sunxi
<Turl> mturquette: ping
Dreadlish is now known as Lotysz
Lotysz is now known as Dreadlish
<mouchon> still have a question regarding A20 i2c. Does 7bit or 10bit address is used ?
<oliv3r> mouchon: i doubt we know by heart, best is to check documentation :)
<oliv3r> we do know the i2c IP isn't from AW; the good news is, in the mainline kernel we are re-using the existing driver :)
<mouchon> oliv3r thanks for the info. But which doc you are talking about ? kernel, olimex , aw ? sorry for this silly question
<oliv3r> the A20 usermanual
<oliv3r> the 'datasheet' for the A20 :)
<oliv3r> it's on
<mouchon> ok thanks i will dl it
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
rz2k has joined #linux-sunxi
<mouchon> found my answer seem to be 10bits
<shineworld> mouchon, are you trying to use i2c with cb2 ?
<mouchon> no with olimex A20
<shineworld> I don't know a lot Olimex A20... is better than cb2 how hardware combo ?
<mouchon> can not really compare, i don't have cb2. But olimex a20 has many GPIO
<buZz> cb2 has 96 pins
<shineworld> for eg: can olimex A20 power the RTC circuit so I can lost every time the timer ?
<shineworld> can't
<Turl> shineworld: olimex publishes schematics, you can take a look :)
<mouchon> shineworld: no on board battery, but you can connect lipo
<oliv3r> cb2 is nice and compact; olimex is big but has tons of pins connected
<oliv3r> olimex is opensource hardware
<shineworld> I will purchase it ... so I will try
<shineworld> thanks
<oliv3r> shineworld: olimex has a battery connection, but not specifically only for RTC; cubietruck will have that though
<shineworld> cubietruck isn't available yet
<oliv3r> :)
<oliv3r> olimex a20 is the same board as A10 with different chip; so not much change there yet
<shineworld> actually I've 10 cb1 and 2 cb2 running and one cb2 on my desk for development
<oliv3r> i'd expect the next itteration to possibly have it
<oliv3r> Tsvetan: ^
<shineworld> cb1 are running in a 24/24 7/7 plant without problems
<shineworld> cb2 sometime restart or crashes
<shineworld> all with android OS (for HMI interface)
<shineworld> cb1 is enough robust hardware and software
<oliv3r> cb1 and cb2 use same pcb
<oliv3r> so if there's crashes, eitehr bad chip or bad software :)
kaspter has joined #linux-sunxi
<shineworld> I guess is a software question... or something with dram speed
<shineworld> I don't know really
<shineworld> because happens only in plant
<shineworld> at home all works fine ... perhaps a temperature question ? boh ...
<shineworld> or a power issue with board load
<shineworld> what customer say is that system reboot
<Turl> shineworld: A20 uses more power, maybe a psu issue?
<shineworld> could be ... the temperature on plant is high so I need to check all variables of equation ... but are prototypes so customer is not strict on that
<shineworld> and I've filled boards of tropicalization product so...
<shineworld> *tropicalised varnish
<buZz> you are varnishing plants?
<buZz> poor plants
<shineworld> ha ha ha ... I mean industrial plant :)
<shineworld> sorry for my very bad english
vicenteH has quit [Read error: Connection reset by peer]
<wingrime> oliv3r: I making patch that makes disp works with fully sun5i/sun4i detection
vicenteH has joined #linux-sunxi
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
shineworld has quit [Remote host closed the connection]
<buZz> :)
ZetaNeta has quit [Ping timeout: 245 seconds]
<Turl> oliv3r: found a typo on your patch
<Turl> oliv3r: 'very rarly probed'
<Turl> oliv3r: also I think the sunxi_sid_of_match can be __initconst
<Turl> mripard: ^ thoughts?
<mripard> Turl: nope
<mripard> you'll have a section mismatch
<mripard> since it's referenced by both probe and the platform_driver structure that aren't __init
<Turl> probe is __init
<mripard> it shouldn't
<Turl> why? :)
<mripard> because the kernel might need probe after having freed the init section
<mripard> it even causes a warning
<Turl> isn't the free ran after everything is set up?
<mripard> not necessarily
<mripard> what if you have a USB driver, and that the device is plugged later on?
<mripard> => boom
<Turl> mripard: a USB driver won't run the sid probe code :)
popolon has joined #linux-sunxi
<mripard> I'm talking about a generic case, you're talking about a specific case :)
<Turl> mripard: SID is non-hotpluggable
<Turl> USB is
<mripard> yes, I'm talking about "all the drivers", you're talking about "the non-hotpluggable ones"
<Turl> so? :)
<mripard> in this case, yep, the kernel won't use it
<mripard> yet, probe shouldn't be __init.
<mripard> in *any* case
<mripard> for all you know, it could become somewhat hotpluggable.
<mripard> think about the DT overlays mechanism, that allows to inject later on in the system dt chunks
<Turl> "probably from an __init section"
<mripard> yes, and that's not what the sid driver uses.
geecko has joined #linux-sunxi
<Turl> mripard: it should move to module_platform_driver_probe(..) then?
<mripard> probably, or drop the __init from probe
<mripard> anyway, the of_match table will never be __initconst
<Turl> I'm a fan of saving bytes as you can see :)
ykchavan has joined #linux-sunxi
<mripard> :)
n01 has quit [Ping timeout: 260 seconds]
<mnemoc> Turl: around?
<Turl> mnemoc: yep
<mouchon> yes finaly got uart.6 and uart.7 working. seem that fex file from olimex is not correct and i forgeted to disabled hardware flow conrol in minicom
* Turl is now intrigued
vicenteH has quit [Read error: Connection reset by peer]
rings_IIV has quit [Read error: Connection reset by peer]
rings_IIV has joined #linux-sunxi
<mnemoc> Turl: I would like to merge the current stage in 3.4 to non-stage. currently both pass my defconfig build tests, but I still haven't been able to get back into the ML
<mnemoc> Turl: is there any known issue or important outstanding patchset?
<wingrime> mnemoc: a13 usb not works
<Turl> mnemoc: I've not been following it much, but there's that
<Turl> and I think mali had build problems on anything but sun7i, probably got addressed already
<mnemoc> wingrime: defconfig issue or pending patch?
<mnemoc> Turl: I fixed the mali compilation issue tthe 28th after merging hansg's for-amery
<mnemoc> but no idea if it actually works :(
<mnemoc> it's merely a compile test
<wingrime> mnemoc: no , pending patch
<mnemoc> wingrime: subject/date ?
<wingrime> mnemoc: but I am unsure
<wingrime> mnemoc: can you wait I finsh disp dynamic sun45 select
<mnemoc> sure, no rush
<wingrime> mnemoc: than I should rebuild kernel for a13 and test without this patch
<mnemoc> i only wanted to do the merge due to shame on the lack of work :(
<wingrime> mnemoc: you can merge my disp fixes in ML
<wingrime> mnemoc: 2 cleanups and 1 patch (its looks like protection but not full solution)
<mnemoc> 2814 unread mails in my linux-sunxi folder.... a subject/date hint would be appreciated
<wingrime> [PATCH] sunxi:disp: remove bloat-code
<wingrime> removes #0 blocks
<wingrime> #if 0
<mnemoc> what about lost knowledge?
<wingrime> mnemoc: we have git
<mnemoc> ok
<wingrime> mnemoc: #if 0 code freaks me
<wingrime> [PATCH] sunxi:disp: Fix problems with negative overlay position
<wingrime> that workaround, our disp can't handle negative layer positions
<wingrime> so if you move XV video or pdpau video
<wingrime> to negative offset (window header over top)
<wingrime> so you get funny bugs
<wingrime> [PATCH] sunxi:disp: expose or remove #ifdef UNUSED codeblocks
<wingrime> thats expose blocks but gives warning at build
<wingrime> Now I working on sun457 dynamic sinxi_is_ select
<wingrime> for disp
<mnemoc> thanks, i'll merge those three into stage
<wingrime> two?
<wingrime> witch is wrong
<wingrime> ?
<wingrime> mnemoc: thanks
<mnemoc> you pasted 3 [PATCH]
<mnemoc> i didn't say "two"
<wingrime> mnemoc: yes
<wingrime> mnemoc: all tested
<wingrime> mnemoc: for a10
<mnemoc> let's hope they don't destroy the rest of the sunxi world
<wingrime> mnemoc: but this patches not change logics
<wingrime> mnemoc: almost
gnufan has joined #linux-sunxi
ZetaNeta has joined #linux-sunxi
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
<wingrime> jukivili: I tested that patch, no
<wingrime> jukivili: still not work after revert
<jukivili> wingrime: can you do git bisect from sunxi-3.4 to stage/sunxi-3.4?
<jukivili> it's about 7 kernels to test
<wingrime> jukivili: not sure all workable
BJfreeman has quit [Quit: had a good time]
<wingrime> jukivili: but I try
<oliv3r> mripard: so remove the __init from probe?
<oliv3r> Turl: if i get more comments, i'll fix that rarly :)
rings_VII has joined #linux-sunxi
<Turl> oliv3r: I replied with a lot more nitpicking :) don't kill me :p
<oliv3r> Turl: you should have replied v5! so i could have changed it in v6 :)
<oliv3r> you just want to drive v nummer up
<Turl> v9001! :)
<oliv3r> hehe; fine i'll do a v7 :(
rings_IIV has quit [Ping timeout: 256 seconds]
<Turl> oliv3r: well, there's the probe issue to fix :)
<oliv3r> also, 5 versions and nobody notices!
<Turl> oliv3r: in theory if it's __init and something decides to probe it later on, after being freed, kernel may explode
<oliv3r> i'm telling you, this will be the most well pollished microdriver ever!
<Turl> oliv3r: haha yeah
<Turl> oliv3r: it all started because I wanted the of table to be __initconst and mripard said it'd create a warning because probe wasn't __init
<wingrime> oliv3r: v7 ?
<wingrime> oliv3r: WHF
<oliv3r> yeah turl and mripard bring up little things after i push a new version :)
<Turl> oliv3r: well I couldn't spot anything else so you won't get further comments from me :P
<oliv3r> hahaha
<Turl> oliv3r: there's also a "labeled" in there, which is technically correct, but not the UK spelling
<oliv3r> i need vim spellcheck
<oliv3r> I prefer the US spelling :p
<Turl> oliv3r: yeah, or thunderbird :P
<oliv3r> git send-email -> thunderbird?
<oliv3r> i have tripple language checking in tbird
<Turl> oliv3r: when I reply it highlights the typos for me :P
<oliv3r> oh yeah
<oliv3r> so i guess my typing wasn't too bad concidering I didn't even have spellcheck on
<oliv3r> Turl: but for your pleasure, it and pushed it to my github
<oliv3r> modified *
<oliv3r> Turl: this resuls in
<oliv3r> you missed that one
deasy has joined #linux-sunxi
<Turl> oliv3r: :)
<Turl> oliv3r: which branch?
<oliv3r> typo-free
<Turl> oliv3r: I got confused by the "10 days ago"
<oliv3r> yeah, i don't know how it figures that
<Turl> it's the commit date
<oliv3r> yeah
<Turl> but each time I rebase (and therefore rewrite them) it gets updated
<oliv3r> i should rebase shouldn't I :p
<Turl> dunno why yours say 10d ago :p
<Turl> what do you do?
<oliv3r> rebasing tends to make a horible mess
<Turl> as long as you rebase over the same commit, it's np :p
<oliv3r> i had to cherry-pick a few times to a 'clean' tree because rebasing failed somewhere inbetween
<Turl> git rebase --interactive HEAD^^^
<Turl> so you don't need to remember which branch you based your stuff on :)
<oliv3r> well once we have the 'basics' in place more, it should all be upstream anyway
<oliv3r> and writing a new driver is just that
<oliv3r> but now i needed stuff from mripards tree
<Turl> yeah, deps are a pain
<oliv3r> thing is,t he stuff that was giving conflicts, was from old commits that we both hadn't touched i would have guessed
<rz2k> region `.sram' overflowed by 20 bytes
<rz2k> hmm
<rz2k> seems like I'm unlucky with linaro gcc latest
<oliv3r> bin getting to big :90
<oliv3r> i really hoped we could do a 30k binary :S
<rz2k> i probably should not ask if we can throw some printf's like "u-boot spl %version" and have that 20 bytes free, right?
<rz2k> s/throw/throw away/
<Turl> rz2k: is uboot built with -Os?
n01 has joined #linux-sunxi
<rz2k> I redirect that question to hno
<rz2k> :p
<Turl> rz2k: hno was playing with thumb mode the other day, that'd make it smaller too
<rz2k> I'm trying to build Falcon binary for A20 olinuxino
<rz2k> yes thumb binaries is known to be smaller
wingrime_ has joined #linux-sunxi
<Turl> the real question is why is linaro making toolchains that produce fatter binaries :P
<oliv3r> Turl: yes it is
<rz2k> no idea, but I guess because they care about back compat
<oliv3r> falcon mode gobbles up quite some space
<rz2k> like if they change something hardcorely, ton of old code will die
<oliv3r> i guess when we really start to save some bytes we'd have to move the printing stuff to u-boot entirly and make spl silent, which makes it horrible to debug
<Turl> oliv3r: thumb would be a decent alternative :)
<oliv3r> thumb?
<oliv3r> you mean compile with thumb-mode enabled
<oliv3r> hno: ^ :)
<Turl> yeah
<Turl> hno was playing with it already
robb83 has quit [Quit: - A hand crafted IRC client]
robb83 has joined #linux-sunxi
<hno> yes, I have u-boot running in thumb mode.
<hno> Cubieboard2_Falcon_T arm armv7 sunxi - sunxi sun7i:CUBIEBOARD2,SPL,SPL_OS_BOOT,SUNXI_EMAC,STATUSLED=244,SYS_THUMB_BUILD
<hno> show what is needed for Cubieboard2. Maps 1-1 to A20 OLinuXIno.
<oliv3r> u-boot should be nearly interchangeable onthose two
<oliv3r> hno: how much smaller does the thumb build get?
<hno> 25% iirc.
<oliv3r> oh wow, so 18k?
<hno> -rwxrwxr-x. 1 henrik henrik 18412 1 sep 03.18 build/Cubieboard2_Falcon_T-4.8/spl/u-boot-spl.bin
<hno> -rwxrwxr-x. 1 henrik henrik 17636 1 sep 03.12 build/Cubieboard2_Falcon_T/spl/u-boot-spl.bin
<hno> the -4.8 is with latest Linaro 4.8 toolchain.
<oliv3r> very nice indeed
<oliv3r> so thumb mode is coming up as next big change?
<hno> Just need to look into if there is any disadvantages from it. But does seem to load fine. Have not tried loading a kernel yet, but I see no obvious reasons why that would not work.
rellla has joined #linux-sunxi
<oliv3r> hno: good good
rellla has quit [Quit: Nettalk6 -]
<wingrime> jukivili: ping
<wingrime> jukivili:
ykchavan has quit [Remote host closed the connection]
<jukivili> wingrime: hm.. can you copy-paste 'git bisect log'?
<jukivili> thanks
<jukivili> so are you having problem with usb-host (ehci/ohci) or with otg-host?
<wingrime_> host
<wingrime_> jukivili: not otg
<wingrime_> jukivili: I have not tested gadgets
<wingrime_> jukivili: I only connect mouse to tablet using micro-to-usb cable
<jukivili> ah.. and mouse stops working with stage/sunxi-3.4
<jukivili> ?
<wingrime_> yes
<wingrime_> no power light
<wingrime_> for any usb device
<techn_> wingrime_: what kind problem you have ?
<techn_> ah.. you told already
<wingrime_> techn_: host on a13 not works with stage
<jukivili> wingrime_: can you give 'lsusb' with working kernel?
<wingrime_> jukivili: whait a second
<techn_> jukivili: btw. I tried musb pherephial mode with a13.. didn't work :(
<jukivili> techn_: ok :/ .. have you tried host mode?
<techn_> jukivili: no
<wingrime> jukivili:
<techn_> jukivili:
<jukivili> wingrime: thanks.. how about 'lsusb -vvv'?
\\Mr_C\\ has joined #linux-sunxi
vicenteH has joined #linux-sunxi
<wingrime> jukivili:
<jukivili> techn_: well.. I have only tested g_ether gadget myself
<techn_> yeah.. there is differences between gadgets :(
<jukivili> wingrime: ok.. problem is with otg-host driver, not ehci/ohci. Your micro-to-usb cable is OTG-host cable
<wingrime_> jukivili: are you find witch wrong
rings_VII has quit [Ping timeout: 268 seconds]
<jukivili> wingrime_: sun[45]i_usb unification changes names of kernel config knobs.. maybe it's config problem. Can you give your stage/sunxi-3.4 config?
<wingrime_> jukivili: cp arch/arm/configs/sun5i_defconfig -- something like
<techn_> wingrime_: that may not be the real config
<techn_> find .config
<hramrach> you use that config by make sun5i_defconfig
<hramrach> it does not have defautls so does not work as .config
<wingrime_> techn_: I used that config , all otherthings are default
<techn_> it might be broken after some bisecting.. if cleanup wasnt done
Soru has quit [Read error: No route to host]
Soru_ has joined #linux-sunxi
gnufan has quit [Ping timeout: 240 seconds]
<techn_> wingrime_: are you using pure host or otg mode?
<wingrime_> techn_: otg
<wingrime_> techn_: but there is no much differnece between
<techn_> wingrime_: no other differences that config changes..
<techn_> and one change which seems to be slipped trough
<techn_> msleep(3000); in static int usb_hardware_scan_thread(void * pArg)
<techn_> usb_manager.c
Black_Horseman has joined #linux-sunxi
Black_Horseman has quit [Changing host]
Black_Horseman has joined #linux-sunxi
<hramrach> hmm, when I use the vdpau cedar lib I get a crash in /usr/lib/arm-linux-gnueabihf/neon/vfp/
<hramrach> hmm, also when not using the module
<hramrach> I guess there is some general problem with vdpau
<hramrach> actually there's no other module to use so I guess it gets used regardless
<hramrach> ii libvdpau1:armhf 0.6-2
<hramrach> wingrime_: on what system is the libvdpau sunxi module supposed to work?
<wingrime_> hramrach: a10
<wingrime_> hramrach: a13 need fix for display
<hramrach> it crashes before it even displays anything for me
<hramrach> on a10
<wingrime> hramrach: it crashed where?
<hramrach> /usr/lib/arm-linux-gnueabihf/neon/vfp/
<wingrime_> hramrach: try buind mplayer by hand
<wingrime_> hramrach: thats ffmpeg crash
<hramrach> yes, it just does not happen when not using vdpau
<rz2k> techn_: jukivili: any idea whats happening here?
<wingrime_> hramrach: thats not common codec
<oliv3r> wingrime_: what happened to your sunxi-ir driver merge?
<rz2k> this keeps happenning frequently
<hramrach> that's the codedc that has the cedar module :p
<wingrime_> oliv3r: clocks not there
<oliv3r> wingrime_: i meant for 3.4
<oliv3r> i know shutko supplied a driver too, but did either get merged?
<wingrime_> hramrach: I builded mplayer from csv
<wingrime_> oliv3r: no
<hramrach> there is no mplayer from cvs. Old maplyer uses svn, new uses git
<wingrime_> hramrach: snv
<hramrach> so the old one
<wingrime_> hramrach: svn yes, but mplayer 2 is not new mplayer
<wingrime_> hramrach: just fork
<hramrach> with more updates
<oliv3r> wingrime_: we still need that driver merged for 3.4 then
<wingrime_> oliv3r: ask mnemoc
<oliv3r> mnemoc: ^
<hramrach> mplayer configure does not detect neon and thumb :/
<wingrime_> hramrach: you need --enable-vdpau to ./configure
<wingrime_> hramrach: also you can supply something for neon
<hramrach> vdpau is detected fine but not neon
* hramrach building
atiti has quit [Read error: Operation timed out]
<leviathanch> Turl: ping
<Turl> leviathanch: pong
<leviathanch> how do I determine which clock has been selected by mod0?
<leviathanch> aldo, the mod0 can select 24MHz as input
<leviathanch> so basically it should select this one
<leviathanch> and even lower
<leviathanch> LOSC
<leviathanch> from AHB
<leviathanch> bits 00
* leviathanch is looking at the manual
<Turl> leviathanch: if you enable CLK_DEBUG you can check clk/clk_summary on debugfs
<Turl> it prints a pretty tree of all clocks and their frequencies
<Turl> very useful and handy to have when debugging :)
<leviathanch> I fished a 10 inch fish today btw :-D
<leviathanch> (the reason why I was AFK till now)
<Turl> :)
<leviathanch> tasted delicious
<leviathanch> just had it for dinner now
<leviathanch> :-D
<leviathanch> so
<leviathanch> kernel compiled, and initrd copied
<leviathanch> I'll try to boot with rootfs from ram
<leviathanch> and see what debugfs tells me
<hramrach> bah, the libav in mplayer 1 does not know how to build with neon enabled
wingrime_ has quit [Ping timeout: 240 seconds]
wingrime has quit [Ping timeout: 245 seconds]
geecko has quit [Quit: Quitte]
<leviathanch> Turl: I've got your email
<leviathanch> so you aren't doing automagic reparenting
<leviathanch> ok
<leviathanch> the question is: how do I reliably get osc24 out of the device tree?
ganbold_ has quit [Remote host closed the connection]
n01 has quit [Ping timeout: 240 seconds]
<Turl> leviathanch: you pass it on clocks = ..., just like the other two
<leviathanch> ?
<leviathanch> you mean adding these two clocks to the list of the clocks for the sdc0 device?!
<Turl> leviathanch: yes
<Turl> leviathanch: implementing automagic reparenting would be nice though, I'm going to look into it
<Turl> but for the time being you can do that
<leviathanch> Turl: ok
<leviathanch> I'm already tring to make this approach work
<leviathanch> wow
<leviathanch> the code is exploding if doing it this way
<leviathanch> would be nicer if this gate selection would happen automagical
<leviathanch> Turl: ok! works this way!
<leviathanch> one issue less
<leviathanch> clocks are managed now :-)
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
_enrico_ has quit [Quit: Bye]
<Turl> leviathanch: :)
ganbold has joined #linux-sunxi
naobsd has quit [Quit: Page closed]