ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development discussion - Don't ask to ask. Just ask! - See http://linux-sunxi.org | https://github.com/linux-sunxi/ | Logs at http://irclog.whitequark.org/linux-sunxi
<Turl> n01|away: what branches did you merge?
<Turl> make sure you get clk-next from mike turquette and matching dt from mripard_
torqu3e has joined #linux-sunxi
drachensun has quit [Read error: No route to host]
drachensun has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
rav0__ has quit [Read error: Connection reset by peer]
rav0__ has joined #linux-sunxi
tinti has quit [Quit: Leaving]
hipboi|cubie has joined #linux-sunxi
hipboi|cubie has quit [Read error: Connection reset by peer]
ganbold_ has quit [Remote host closed the connection]
ganbold has joined #linux-sunxi
Wetomelo has joined #linux-sunxi
<Wetomelo> Hello
<Wetomelo> i'm trying to compile some modules for minix box running some flavor of linaro
<Wetomelo> but __LINUX_ARM_ARCH__ undefined is shown in the make process
<Wetomelo> the make file assigns value to __LINUX_ARM_ARCH__ depending on values on the .config file
<Wetomelo> but the config file has the values assigned but seems that make isn't "listening"
Wetomelo has quit [Quit: Ex-Chat]
jochensp has quit [Read error: Connection reset by peer]
jochensp has joined #linux-sunxi
jochensp has quit [Read error: Connection reset by peer]
jochensp has joined #linux-sunxi
rellla has joined #linux-sunxi
<mripard_> n01|away: you're also missing this patch: http://www.spinics.net/lists/kernel/msg1499954.html
<n01|away> mripard_: uhm in which branch is this one ?
<mripard_> in the uart's maintainer branch
n01|away is now known as n01
rellla2 has joined #linux-sunxi
<n01> *_* ok ... ehm, which repo
<n01> ?
rellla2 has quit [Remote host closed the connection]
<n01> gosh, sometimes it is confusing with all these repositories around
<Turl> it should be trivial when 3.10-rc1 lands :)
<Turl> I want to maintain a sunxi-next branch after that, to keep everything there for ease of testing
<oliv3r> god please do
<n01> yes please :D
<n01> Turl: I merged both branches from mripard_ (core-for-3.10 and dt-for-3.10) ... but it seems I'm missing the turquette branch
<Turl> n01: git://git.linaro.org/people/mturquette/linux.git clk-for-3.10
<n01> tnx
ZaEarl has quit [Ping timeout: 245 seconds]
hansg has joined #linux-sunxi
shineworld has joined #linux-sunxi
Undertasker has joined #linux-sunxi
hipboi|cubie has joined #linux-sunxi
<mripard_> n01: keep in mind that you have to merge such an amount of patches only because you need the clocks
<mripard_> once the clock will be there, you will be able to just use the last rc
<n01> yep, at the moment what I need is a working kernel with dt support to test my patches
<mripard_> then, take 3.9-rc1
<mripard_> if you don't need the clocks, you don't need more
<n01> yeah, yesterday in despair I worked on 3.9-rc5 and it seemed good :)
<mripard_> well, yes, basicall every 3.9-rc would work :)
<oliv3r> n01: doesn't the wdt require the clocks?
<oliv3r> i actually found one example for the sid that setup some form of clocks, but I highly doubt any clocks are needed to read the registers i need to read
<oliv3r> though i'm struggling mostly with sysfs atm :)
<oliv3r> was reading chappter 14 of ldd3 (and boy is that a long chapter and tries to explain the innards)
slash_m_a_x has joined #linux-sunxi
<n01> oliv3r: yes, I just assume that the clock is correctly configured even in 3.9-rcX
slash_m_a_x has quit [Client Quit]
hipboi has joined #linux-sunxi
<oliv3r> n01: never assume anything :p
<oliv3r> n01: but i don't know how dt, clocks and the wdt hang together. who inits the clocks, what does the wdt require; i don't know :(
<n01> actually wdt requires OSC24M, I hope it is enabled :D anyway I'll check
<mripard_> of course it's enabled :)
<mripard_> and we're using the watchdog to reboot
<mripard_> so I think you won't need anything fancy
<hipboi> mripard_, how is the a31 kernel going now
<hipboi> mripard_, i can test it
<mripard_> hipboi: didn't have time to make progress on it, I'm sorry :(
<hipboi> mripard_, it's ok, i will look at it
<mripard_> If you know device tree, it should not be much complicated than creating a dumb dts that inherits from sun6i.dtsi
<mripard_> that is already there
simosx_ has joined #linux-sunxi
simosx_ is now known as simosx
simosx has quit [Client Quit]
simosx has joined #linux-sunxi
simosx has joined #linux-sunxi
<Turl> n01: that's the main oscillator :) if that's disabled either your board is off or you did some magical vodoo which is not yet implemented :p
<n01> lol ok ok, I wasn't concerned about OSC not working _at all_, but eventually on its precision :D please be easy on me :P
<Turl> n01: how's the watchdog driver going? :)
<n01> Turl: it's finished actually but I have to test it
<Turl> nice :)
<n01> it not much different from the hno's one
<Turl> n01: you should be able to drop the pr_fmt macro
<n01> yep, it needs cleanup
<n01> :D but every comment is welcome
<mripard_> n01: it looks good :)
<n01> I'm not sure about reading the register before writing it again ... I always do that even though I don't know if it is really usefull or just waste of time
<n01> mripard_: thank you :)))
<n01> I need also to add hno in authors, sorry for that
<mripard_> n01: also, add the licence on top
<n01> ok
<Turl> according to the docs, the control register has some reserved bits that are not zero, so reading it isn't that bad of an idea
<n01> yeah I had the same thought
<Turl> mode looks like you can write directly
<mripard_> n01: I have a few comments, as usual, but I guess you can send it
<mripard_> it's good enough now :)
<n01> yes, I'll send it to ml
<n01> ASAP I test it a bit
<Turl> it's way more readable now that it's using the watchdog framework
<Turl> way less boilerplate code
<Turl> n01, mripard_: the compatible string should be sun4i now, shouldn't it?
<mripard_> yep
<n01> yes, but that code is based on 3.9-rc5 where IIRC it was still sunxi
<mripard_> it doesn't really matter actually
<mripard_> as long as it's the same in the dt node and in the driver, it just works
<mripard_> aaah, but I was already using this compatible
<mripard_> right
<mripard_> nevermind :)
<Turl> yeah the node is already mainlined :)
<Turl> and I think you renamed it to sun4i with the arch rework
<mripard_> yes, but it will be renamed in 3.10
<oliv3r> what will be the final name?
<Turl> oliv3r: allwinner,sun4i-wdt
<oliv3r> ok, good
<oliv3r> n01: also, PERSONALLY! (i think mripard_ doesn't care and says use whatever :p nofi) ioread*/iowrite* should be prefered over read*/write*. ioread DOES eventually call read* and write* anyway. See http://lxr.free-electrons.com/source/lib/iomap.c?a=arm#L112
<oliv3r> the wdt, is that concidered a 'platform' device?
<mripard_> oliv3r: it is
<oliv3r> and a PCI device bus, would plug into the platform then aswell?
<oliv3r> or is the PCI bus the 'top' next to the platform device?
<mripard_> the pci bus master yes
<oliv3r> what does platform fall under then?
<oliv3r> or is that the top? (I would assume so)
<mripard_> platform devices is basically every device that are directly mapped in memory
<oliv3r> kk
<n01> oliv3r: I agree even though I think in this case ioread*==read* ... But I'll change it
<oliv3r> mripard_: btw lxr.free-electrons.com is your handywork? I've used it a LOT latly :)
<oliv3r> n01: i think ioread does some checks before calling read or something
<oliv3r> n01: i know nothing how the kernel interacts with watchdog devices etc, but can a user do anything with it? And how is that normally handled by others? E.g. if i want to change the wdt timeout value. Module paramter? Sysfs?
<mripard_> oliv3r: it's just an instance that we host
<mripard_> we don't develop lxr
<mripard_> but we use it all the time, so we host one :
<mripard_> oliv3r: usually, it's to the user to kick on a regular basis the watchdog
<mripard_> and iirc, it's done using a device file
<oliv3r> ah, google always puts yours ontop :)
<oliv3r> mripard_: ah ok didn't see that in the code
<Turl> usually you have an userspace daemon that arms it, configures the interval and then kicks it
<Turl> busybox has an implementation you can use
<oliv3r> yeah, I figured as much; so a userspace program constantly 'wakes' the watchdog (or resets it or something)
<oliv3r> but didn't see anything in n01 's code. Just the heartbeat time, which will be the amount of time the watchdog has to be kicked
<oliv3r> or does the 'watchdog framework' handle all that? that would actually make sense ;)
<oliv3r> watchdog_register_device();
<oliv3r> nevermind; i did nto say a thing
<oliv3r> hmm, i still don't understand; the wdt is registered by watchdog_register, but it still is a platform_device?
<oliv3r> a little confusing, but I guess I get it :p
<mripard_> oliv3r: there's two thing to conider when writing a driver
<mripard_> what type of device it is and what bus it's on
<mripard_> platform_device states that it's on the "memory" bus
<mripard_> while watchdog_register_device states that your driver is for a watchdog
<mripard_> a watchdog over i2c would still call watchdog_register_device
<mripard_> but it would be an i2c_device instead of a platform device
<oliv3r> ah of course
<oliv3r> just trying to put things together; still have to let chapter 14 sink in :)
<oliv3r> just so much to learn and know :(
hipboi has quit [Quit: Leaving]
<oliv3r> n01: mripard_ ok, if I understand the watchdog timer correctly (though this is a more general question), you define a pointer for iomap, that takes the exact same structure as the register layout. Thus when accessing the pointer, you are really accessing the registers directly. Rule is however, you can only read or write to them using the ioread*/iowrite* calls?
<oliv3r> allthough that structure mapping need not be, its only to easy access to the registers.
<mripard_> hmmm, there's several different things in your queestion
<mripard_> iomap maps a physical address to a virtual one, so that you can access it
<mripard_> you could very well access it using a volatile pointer
<oliv3r> of_iomap(); i speak of
<oliv3r> so if you have only 1 register, or a series of registers (continous) you could just map 1 volatile pointer to the first element
<mripard_> except that is has several drawbacks, the main one being that you have to do all the barriers and such by yourself
<oliv3r> and just use offsets to go through it
<oliv3r> or, define a structure, to match the layout of the registers you are accessing, and thus have easy access to exactly where you want to be
<oliv3r> e.g. wdt_reg
<mripard_> this is also why you usually don't use a structure, because there's no way to specify a barrier, or an endianness conversion, etc.
<oliv3r> mripard_: i don't follow
<oliv3r> i see lots of structures mapping to the registers
<mripard_> where?
<mripard_> in allwinner code, yes
<mripard_> in mainline, not so much
<oliv3r> wdt_reg :p
<oliv3r> do you have a nice example to follow in mainline?
tinti has joined #linux-sunxi
<mripard_> hmmm, you're right, n01 did that wrong :)
<oliv3r> oh, i quite liked his approach :p
<n01> sorry I was at lunch
<oliv3r> so pointer to register + offset is better
<oliv3r> like I did before?
<mripard_> he's accessing every pointer twice
<mripard_> hmmm, no, revermind
<n01> mripard_: sooo, no struct but base + offset?
<n01> isn't it the same?
<mripard_> in your case, it's not so different
<mripard_> precisely because you use your struct only to store the addresses
<mripard_> you never write directly to the struct
<mripard_> which is good, but it makes no difference from using offsets :)
<n01> I use the struct only to easily get the register _address_
<mripard_> yes
<n01> :) good
<mripard_> well, that's what you currently do
rz2k has joined #linux-sunxi
<mripard_> what i meant is, the structure in itself already defines the offset
<mripard_> so it makes *no* difference with using defined offsets, we agree on that
<n01> yes
<mripard_> the only thing I'm concerned is that it's not really consistent with what every other driver makes in mainline
<mripard_> that's it :)
<n01> yeah I agree ... I use struct just because I like structs more than defines :)
<n01> anyway I'll change it
<mripard_> n01: in this case, I would agree with you, but defines have advantages
<mripard_> like when you have the excat same layout repeated several times
<mripard_> like for gpio banks, timers, etc.
<mripard_> here, the struct becomes struct within struct arrays, etc.
<mripard_> while with a define, you just have a simple macro
<n01> ok I got it
<mripard_> hence why I prefer defines
<arete74> hi, how to upload an tar.gz file to wiki?
shineworld has quit [Quit: Leaving]
<oliv3r> arete74: left colloumn there's the 'upload file' dialog
<oliv3r> arete74: but don't know if it's a good idea to host big files on sunxi (like android images or kernels); best to use bitbucket or the like?
<oliv3r> mripard_: then yes, what I did before, map reg (base)
<oliv3r> as*
<mripard_> of course you need to map the registers
<mripard_> you always need to
<mripard_> if you don't, this is called a segfault in userspace :)
<arete74> oliv3r: the file is 84.5 kb, but on the wiki i can upload only pdf, jpg ecc
<Turl> segfaults - so much fun to debug! :P
<oliv3r> mripard_: i ment only map the base register :p
<mripard_> Turl: the worst I had was segfault in a FIQ handler :)
<oliv3r> mripard_: why would you not use the (unlikly) as n01 did on the timer?
<mripard_> oliv3r: because I always forget
<mripard_> and in a probe, it's not that useful
<oliv3r> mripard_: no judgement here, only trying ot learn 'what is best'
<oliv3r> i take it unlikly is to help the kernel/compiler to assume it's hihgly unlikly that the map will fail?
<mripard_> you'll gain a few cycles once during the boot
<mripard_> yes, and it makes better branch prediction
<n01> I always use unlikely() during error checking
<n01> yeah, it saves 2ns :D
ganbold_ has joined #linux-sunxi
<Turl> mripard_: a bit offtopic, but have you seen the trustzone bug they found on qcom motorolas?
<Turl> it's an interesting read if you haven't :) http://blog.azimuthsecurity.com/2013/04/unlocking-motorola-bootloader.html
<mripard_> Turl: hmm, I'll look at it, thanks
<oliv3r> n01: 2 ns here, 2 ns there, 2 ns everywhere adds up :)
<oliv3r> Turl: i've linked it on the wiki allready ;)
<oliv3r> i did read it and it is very interesting
<oliv3r> it also tells us that you need to load a trustzone 'OS' into the arm to be executed in the arm trustzone
<oliv3r> and that boot0 has access to sram b :)
<n01> oliv3r: linked where? wometimes I feel like I need and index for the wiki :)
<n01> tnx :)
ZaEarl has joined #linux-sunxi
wingrime has joined #linux-sunxi
shineworld has joined #linux-sunxi
jelly has joined #linux-sunxi
<mnemoc> Tsvetan was just told by eva the A20 has gmac.... and after checking the a20-dev branch, there is both emac and gmac drivers with sun7i specific changes
<oliv3r> mnemoc: what does that mean?
<oliv3r> it doesn't have pins for both; but the pins (that I saw int he olimex stuff) clearly stated gmac (and no emac)
<oliv3r> dual personality pins? emac and gmac? or maybe they made two drivers :p
<mnemoc> oliv3r: the A10 exposed a mii interface. for gmac the A20 would need gmii <http://en.wikipedia.org/wiki/Media_Independent_Interface#Gigabit_Media_Independent_Interface>
shineworld has quit [Quit: Leaving]
<jinzo> hm just noticed, interestingly they don't use MP4 Mali
<mnemoc> a40!
<mnemoc> 4xA7 + MP4 :p
<oliv3r> jinzo: a20 has mp2
<oliv3r> mnemoc: i've studied those documents, but wasn't it known it would feature a gmac?
<jinzo> and the VP8 hardware decode looks interesting, did they list that in previous chips too?
<jinzo> oliv3r, yes I know - that's what I find interesting.
<oliv3r> jinzo: i think it's probably just cedarX improvement
<mnemoc> oliv3r: I hadn't noticed gmac on a20 before.... but it's confusing they list both. and sun7i has both drivers
<jinzo> still interesting
<jinzo> and the TV decoder... hopefully not only china TV
<jinzo> but I guess the chances of us seeing more info on that front are slim
<jinzo> also wow, there's A31s
<mnemoc> that's their chip for phones
hansg has quit [Quit: Leaving]
<rz2k> slapin_nb: are you sure you've done the ddr3 lenght check?
<slapin_nb> rz2k: that will be next step, I want everything but DDR without errors...
<slapin_nb> rz2k: in Kicad I need to look at all wires by hand for length matching
<slapin_nb> rz2k: it is quite big task in itself, but happily, not a lot of pins need to be matched
jukivil1 is now known as jukivili
tinti has quit [Ping timeout: 256 seconds]
tinti has joined #linux-sunxi
wingrime has quit [Read error: No route to host]
<gzamboni> slaping_nb i think there is an option for the route lengths in kicad
ganbold_ has quit [Remote host closed the connection]
<oliv3r> jinzo: a10 had tv decoder allready
n01_ has joined #linux-sunxi
n01 has quit [Disconnected by services]
n01_ is now known as n01
<rm> hm
<rm> wifi is very very slow on this MK802II
<mnemoc> tried on performance?
<rm> ah.. bizzare
<rm> ok, I don't get this anymore
<rm> switched to performance, solved; switched back, still works
<rm> checked frequency after switching back: 408 Mhz
<rm> going to power off now completely then boot-up and re-check
<rm> maybe it's just how wifi is
<mnemoc> 408M is a pretty good for "idling linux". 60 is not
<oliv3r> review that? how did you make that slapin_nb ? kicad or geda
<mnemoc> and usb is very cpu dependent
<mnemoc> freq also affects sata and ethernet
<rm> yes okay this is solved
<rm> also, does anyone use the rtl8192cu driver?
<oliv3r> o/
<rm> I was under impression it works
<rm> but even a simple ifup + ifdown caused all sorts of issues
<rm> ending with the wlan0 interface disappearing completely
<rm> and various cryptic errors in dmesg
rellla has quit [Quit: Nettalk6 - www.ntalk.de]
<rm> so I ended up blacklisting it, "8192cu" seems to be a lot more stable
<mnemoc> the allwinnerized driver turns on/off the usb controller
<mnemoc> changing script.bin to start with this usbc pre-enabled, you can freeely use mainline's driver
Turl has quit [Ping timeout: 245 seconds]
<Undertasker> H. How do I setup a biuld environment to compile drivers for kernel 3.08+?
<n01> Undertasker: well, at least you need a crosscompiler and the kernel sources :)
<Undertasker> Any link to a doc?
<oliv3r> rm: native kernel wifi is bad
<n01> Undertasker: it is not really sunxi-specific. Also LDD3 could be a good resource
<Undertasker> Thing is, my A13 pad has kernel 3.08+. I want to compile backported dvb-t usb drivers for this
<jukivili> rm: there are patches in stable 3.4.38 for making rtl8192cu work.. 'rtlwifi: rtl8192cu: Fix problem that prevents reassociation'
<oliv3r> sometimes drops during standby
<n01> Undertasker: to start with http://linux-sunxi.org/FirstSteps
<oliv3r> often; and hardly ever turns on again
<oliv3r> on hansg it's ok
<oliv3r> but sometimes the IP resets so must be some dc
paulk-desktop has joined #linux-sunxi
<rm> <mnemoc> changing script.bin to start with this usbc pre-enabled, you can freeely use mainline's driver
<rm> mine has it pre-enabled
<rm> else there wouldn't have been any wifi in lsusb to begin with
<rm> also
<rm> 8192cu is not just "allwinnerized"
<rm> it seems to be a vastly different driver
<rm> my guess is forked from older (newer?) realtek code
<jinzo> oliv3r, is there any info on it? I can't find anything...
Turl has joined #linux-sunxi
<rm> has LOTS more options, doesn't need external firmware (it's built-in?), has an actual version number.... etc
san has joined #linux-sunxi
<oliv3r> jinzo: the TV Decoder?
<jinzo> yes
torqu3e has quit [Quit: torqu3e]
<mnemoc> rm: iirc rtlwifi drivers are made from scratches by a community, while the other is the official by realtek
<rm> I don't think so
<rm> or hmm
<rm> if it was made from scratch, would it still require Realtek-supplied firmware
<rm> actually maybe yes
<mnemoc> sure, the firmware is a blob to make the chip work, the driver is to use the chip
<rm> I mean the
<rm> I mean e.g. the "from scratch" radeonhd driver did not require AMD/ATI firmware to operate the Radeon video cards
<rm> driving them on a lower level than through the firmware
<mnemoc> in this case I didn't mean any REing or similar, just writting a decent kernel driver
<mnemoc> have you see the size of official rtl drivers?
<n01> oliv3r: I was looking for the ioread32/readl thing ... readl is waaaay more common in linux kernel than ioread32 (the same for write)
<n01> dunno why (yet)
<mripard_> n01: the only difference between the two is that ioread makes endianness conversion
<n01> then why readl/writel are more used? I'm a bit puzzled :)
torqu3e has joined #linux-sunxi
<mnemoc> wrappers take time to be adopted
<mripard_> because most of the architecture don't care about endianness :)
<n01> :D ok then, let's switch to io*32
<slapin_nb> oliv3r: Kicad
vinifm has joined #linux-sunxi
Zenton has quit [Ping timeout: 256 seconds]
shineworld has joined #linux-sunxi
<oliv3r> n01: because ioread32 is newer :)
<mnemoc> but mripard_ is right... when doing platform stuff you rarely need to care about endianness...
<mnemoc> it just... happens
<oliv3r> you don't need to care, true, but being concistant and 'clean' is better imo
<mnemoc> true
<oliv3r> and while the internal interface is available; i'd still avoid it
<oliv3r> I think you can compile time optimize it away
<jinzo> damn, do I love that Firefox PDF viewing :D
<jinzo> thanks for the info oliv3r
<oliv3r> jinzo: but the tvin_para isn't used anywhere in the 3.4 stageing source (git grep)
<jinzo> I did locate some A10 based devices that supposedly can recieve cable TV
shineworld has quit [Ping timeout: 264 seconds]
<jinzo> that would be a very interesting feature I must say
<oliv3r> then we could write code at some point
<oliv3r> Very interesting yes
<vinifm> and satellite tv
shineworld has joined #linux-sunxi
<oliv3r> let me see if we actually have info
<oliv3r> registers etc
<oliv3r> well makes sense, dump the (decrypted!!) transport stream directly into the soc, it can handle mpeg and h264 decoding
<oliv3r> and appearantly analog video in :)
<oliv3r> I bet it does dvb-T aswell
<oliv3r> but!
<oliv3r> you very probably needa demodulator
<oliv3r> demodulator, tuner
<jinzo> DVB-* would be killer feature
<oliv3r> the entire frontend basically
<oliv3r> you do need extra hardware
<techn__> crypto IP isn't fast enough for SDTV?
<jinzo> how's the encode and decode parts, can you decode and encode at the same time?
<oliv3r> techn__: you probably can use oscam, shouldn't be a problem at all on resources
<jinzo> because that would allow some serious good transcoding
<oliv3r> jinzo: cedarx's?
<jinzo> yeah
<oliv3r> doubt it
<vinifm> the bradcom have all-in-one SOC
<oliv3r> cheaper to use 1 unit for both
<jinzo> indeed. with the SoM form factor and with the ability to transcode TV streams... that would probably make my month, not only day :D
<oliv3r> A20?
<jinzo> or that, it _should_ be the same price range as A10...
<vinifm> whre to use Tvheadend?
<oliv3r> maybe
<techn__> Turl: havent tested that. But seems really good improvement :)
Undertasker has left #linux-sunxi [#linux-sunxi]
wingrime has joined #linux-sunxi
<wingrime> possible buy cubie-board for btc
<wingrime> ?
<n01> lol ok guys I have some small problem with the watchdog :DD it seems it needs a bit more testing :P
shineworld has quit [Quit: Leaving]
<wingrime> ?
<wingrime> what problem?
<wingrime> your wd have reset support?
<n01> wingrime: I'm investigating but it seems my driver does not correctly set the timeout. start->set timeout = 5 s->first kick-> and after a couple of seconds -> reboot
san has quit [Quit: Leaving]
<mnemoc> any comment regarding regressor/alexandr shutko's IR driver?
<oliv3r> new driver? haven't seen it
<oliv3r> fix or mainline quality driver?
<vinifm> I thought there was a IR driver :)
wingrime has quit [Ping timeout: 264 seconds]
<mnemoc> [linux-sunxi] [PATCH v2] Added sunxi CIR rc driver 2013-03-30
<mnemoc> i'm impressed no one has said a word
* mnemoc hates patchsets without cover letter :(
<techn__> mnemoc: for me it looks good :)
<mnemoc> but "< vinifm> I thought there was a IR driver :)"
<techn__> there is :/
<vinifm> because i saw something in cubieboard forum
<vinifm> about IR support
<techn__> those are same dribver
<techn__> *driver
<techn__> same base address
<techn__> but other one uses rc_register_device and other input_register_device
tinti has quit [Quit: Leaving]
<n01> gosh hipboi|cubie: the next cubie with a poweron/off button please :D
<mnemoc> n01: the current has it too
<mnemoc> but userspace is usually not configured to poweroff on simple press
<n01> ok, I need to configure it then
<oliv3r> my Dlink router has a (light) switch on the power line (after the wall wart) it loosk really funny, like turning a light on/off (it's always on)
paulk-desktop has quit [Quit: Ex-Chat]
<mnemoc> n01: poweroff by command line and then you can turn it on by pressing the power button
<n01> BTW mnemoc the FEL button in usable like a normal GPIO button?
<oliv3r> n01: i don't think so
<oliv3r> it's a special key/pad
<oliv3r> pin*
<hramrach> n01: gnome can use the power button just fine
<hramrach> it emulates acpi power key
rz2k has quit []
<n01> no X at the moment
<hramrach> hmm, I got the prestigio reader
<hramrach> it is glacially slow and reads books
<oliv3r> n01: 'poweroff' works (or should)
<n01> not on my configuration :) but I'm using a _very_ minimal system
<hramrach> if poweroff does not work something is wrong
<hramrach> what device?
<n01> cubie
<n01> 3.9-rc5
<oliv3r> that could be a 3.9 issue tbh
<oliv3r> we don't have i2c yet on 3.9 afaik
<oliv3r> ax209 talks to the SoC via i2c
<oliv3r> ax209 is in charge of power off :)
<oliv3r> n01: what happens when you do halt/power off?
<n01> System halted. and nothing else
<oliv3r> yeah ax209 then :)
<oliv3r> ax209 removes the power
<hramrach> well, axp driver not in kernel
<oliv3r> and no i2c either :)
<oliv3r> so it's ipmossilbe with 3.9
<vinifm> Qiang's sunxi uboot MTD NAND boot, enables us to boot from nand?
<oliv3r> vinifm: sort of
<vinifm> really really?
<hramrach> not really I suspect
<oliv3r> you boot from mtd nand
<hramrach> how do you read FAT with MTD driver?
<hramrach> stored on top of sunxi wear levelling layer
<vinifm> "Good news! The uboot can boot up on MTD nand."
<hramrach> it kind of can but is totally incompatible with what we have now afaik
<hramrach> so you have to install a kernel with the mtd driver, wipe the nand clean, format, install u-boot ..
<hramrach> livesuite is no use then either
<oliv3r> you don't have to wipe per say :p but yes, reformat
<oliv3r> so if you read from mtd the 'nanda' how do you read your mtd kernel; its empty :)
<mnemoc> that explains it
<mnemoc> err.... wrong scroll :(
<n01> good ... the A10 datasheet is wrong
<n01> A10 User Manual V1.20 p.99 -> WDOG_CTRL_REG the value 0x333 is wrong
<n01> hno is right and the correct value is A57
<mnemoc> wiki wiki :)
<n01> O_O
<n01> where
<mnemoc> WTD's page?
<n01> c'moooon nobody told me a WDT page exists
<n01> :D
<mnemoc> probably doesn't
<mnemoc> but as we can't rely in the datasheet/usermanual, we need to construct our own documentation
<n01> well it seems the only error so far
<mnemoc> based on experience and code more than pdfs
<oliv3r> n01: I haven't written the wdt page
<mnemoc> lazy oliv3r
<oliv3r> n01: also compare the A13 page
<oliv3r> mnemoc: !! :(
<n01> I wonder how hno guessed the value
<oliv3r> wait
<oliv3r> I DID WRITE IT!
<mnemoc> :D
<n01> lol
<n01> where is it?
<vinifm> n01, where i found A10 User Maunual?
<mnemoc> vinifm: dl.linux-sunxi.org
<oliv3r> hmm, someone renamed the registers page :)
<oliv3r> bah
<oliv3r> i stopped half way :p
<mnemoc> lazy oliv3r
<vinifm> good!
<oliv3r> mnemoc said he would finish it
<mnemoc> o.o
<n01> seriously hno` how did you get the correct value?
<oliv3r> n01: we have sources
<oliv3r> n01: AW gave us a source dump
<oliv3r> or someone
<oliv3r> n01: those SHOULD be more accurate then the user manual
<n01> oooh the lichee branches?
<mnemoc> in code we trust
<oliv3r> yeah
<oliv3r> check those :)
<oliv3r> sun4567i
<oliv3r> and compare
<mnemoc> and import any interesting change
<oliv3r> and wiki :p
<n01> :D ok ... meanwhile can you make me an account on the wiki?
<mnemoc> and poke lazy mnemoc about pending commits on the ML
<mnemoc> n01: there is a [Create account] in the top right corner
<n01> sorry ç_ç I'm stupid when I'm tired
<oliv3r> lazy mnemoc
<oliv3r> btw, I think i did the WDT CLOCK
<oliv3r> no, i'm an idiot
<oliv3r> i did do it
<n01> you mean the wiki page or the driver? O_o
<oliv3r> there
<oliv3r> clicky clicky
<n01> done. Page modified
<n01> now I can go to sleep
<oliv3r> which one was invalid?
<oliv3r> and how certain are you its right now? :)
<oliv3r> its marked 'reserved'!
<oliv3r> name it :p (and use a lowercase a :p it's prettier)
<n01> yeah, but you need to actually write that value to reset the wdt
<vinifm> It can spread these datasheets for everyone?
<n01> and I'm sure simply because now it is working whereas with 0x0333 it doesn't work
<n01> and also in the old hno's old driver he uses 0x0A57
<n01> c ya tomorrow .. 'night
<vinifm> :)
<oliv3r> n01: 0xa57 probably comes from the driver, for now, we should call it 'WDT reset'? i'll check your code for the values if you update your gh
n01 has quit [Ping timeout: 245 seconds]
<mnemoc> iirc hno made a lot of jtag/fel work to get the wdt working
<oliv3r> actualyl debugged it?
<mnemoc> afaik, yes
<oliv3r> very cool
<oliv3r> AW didnt use it?
<oliv3r> orw as that before the first code dump
<mnemoc> they actually added hno's driver to their tree
<mnemoc> but an old version with a bug :p
<oliv3r> oh wow
<mnemoc> and the bug remains in -dev
<oliv3r> lol
<oliv3r> i'll check sun7i for new register names
<oliv3r> and update the wiki
<mnemoc> for sun67i prefer the import/lichee-3.3/{a20,a31}-dev branches
<mnemoc> those are rebased and sanitized
<oliv3r> yeah
<oliv3r> i'll compare those for registers
<mnemoc> the gmac/emac thing in sun7i really bothers me
<mnemoc> haven't checked the registers, but they have both drivers, and both with sun7i related changes after the initial import
vinifm has quit [Quit: Saindo]
<oliv3r> they probably copied the emac driver to create the gmac driver, but forgot to remove it
<mnemoc> fair enough
<oliv3r> PIO is GMAC
<oliv3r> i ... think.
<mnemoc> does gmii use more pins than mii?
<oliv3r> no idea
<oliv3r> can't find the pins :(
<oliv3r> found it
<oliv3r> D5-D13
<oliv3r> E5-E12
<oliv3r> +C13
<oliv3r> though in the A20 olinoxio docs; its not connected :)
<mnemoc> the reference design doesn't connect sata pins either
<jinzo> damn those chineese, if they would listen for a minute...
<jinzo> also, A10 has jelly bean?
<jinzo> damn.
ssvb has quit [Read error: Operation timed out]
ssvb has joined #linux-sunxi
tinti has joined #linux-sunxi
torqu3e has quit [Quit: torqu3e]