<bbrezillon>
ddc: have you tried to detach/attach the mtd part before rebooting ?
<ddc>
yep
<bbrezillon>
and it shows the same errors .
<bbrezillon>
?
<ddc>
bbrezillon: yes
<ddc>
Sorry: this only happen after rebooting
Skaag_ is now known as Skaag
<bbrezillon>
ddc: is anyone else touching mtd2 before booting the linux kernel ?
boycottg00gle has joined #linux-sunxi
<ddc>
detach/reboot/attach
<bbrezillon>
ddc: I think you're writing on bad blocks (0, 1, 12, ...) are the one mentioned as bad by mtd tools
<bbrezillon>
can you revert the patch forcing BB erasure
<bbrezillon>
then re format your partition
<bbrezillon>
ddc: BTW, regarding the read retry question you asked me yesterday -> the Micron read retry handling has already been merged, but it's only applicable to Micron NANDs
<bbrezillon>
ddc: and, as usual, HW manufacturers like to do their own (proprietary) stuff to implement common features :-), this is why we'll have to implement read retry for each an every manufacturer (if not for every NAND chips requiring read retry) :-(
FR^2 has joined #linux-sunxi
Renard has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
focus has quit [Remote host closed the connection]
montjoie has quit [Quit: Leaving]
popolon has joined #linux-sunxi
avsm has joined #linux-sunxi
<libv>
wens: smashing stuff :)
F1skr has joined #linux-sunxi
FunkyPenguin has quit [Ping timeout: 255 seconds]
<libv>
Q88 will also be ndhed now, as i just received one
<libv>
ah, no, the motherboard is slightly different, and will have to be called q88db
petr has quit [Ping timeout: 246 seconds]
<libv>
aha, forfun q88db
montjoie has joined #linux-sunxi
focus has joined #linux-sunxi
notmart has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
akaizen has quit [Ping timeout: 240 seconds]
<libv>
heh, this one actually has HH-Q8 in relief on the back panel
FunkyPenguin has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 250 seconds]
Gerwin_J has joined #linux-sunxi
quitte has joined #linux-sunxi
quitte_ has quit [Read error: Connection reset by peer]
<quitte>
ddc: it seems you have various sunxi devices? could you set BLOCKSIZE to 1024 in u-boots tools/mksunxiboot.c to check that it doesn't break the spl on any of those over time?
<libv>
aha, seems i still need to upload the Q8 info as well
<quitte>
bbrezillon: I guess it makes more sense to ask you: the read blocks on NAND chips are usually 512bytes but the hynix' is 1024?
<ddc>
quitte: I'm not currently working on u-boot. I'm just testing the kernel driver
MasterChief4942 has joined #linux-sunxi
<MasterChief4942>
Hello, please help mounting *.img as file system, searched lots via Google but nothing works. here is output of fdisk -l /media/gaga/e75534d5-38df-4e36-bbae-bdd2d5124473/Cubian-base-r8-a10.r3p2-01rel2.qt530.img
<ddc>
bbrezillon: UBI: good PEBs: 2218, bad PEBs: 6, corrupted PEBs: 0
<bbrezillon>
ddc: can you reboot your system and check that it detects 6 BB at boot ?
<[7]>
oh, nice to hear people talking about mtd ;)
<[7]>
is that somewhat close to usable yet?
<ddc>
bbrezillon : [ 0.790890] Bad eraseblock 2 at 0x0000002fe000 [ 0.797658] Bad eraseblock 3 at 0x0000003fe000
<ddc>
bbrezillon: that is all
<bbrezillon>
[7]: it depends on what you by usable :P
<bbrezillon>
ddc: and [ 0.791066] Bad eraseblock 2 at 0x0000002fe000
<ddc>
yep
<bbrezillon>
ddc: and what about /sys/class/mtd/mtd2/bad_blocks ?
<ddc>
before or after attaching ?
<bbrezillon>
before
<ddc>
0
bengal has joined #linux-sunxi
<bbrezillon>
ddc: I think the problem is here ;-)
<bbrezillon>
ddc: the other isue I see, is that it doesn't detect BB 12, 13, 1726 and 1727
<bbrezillon>
ddc: can you also check /sys/class/mtd/mtd[0-1]/bad_blocks ?
<ddc>
bbrezillon: all zeros
<quitte>
bbrezillon: I was talking about the reasoning behind the nand1k write. eGON does checks on blocks. That seem to be of at least 512 bytes size. I was hoping you could shed some light on why yuq used 1k blocks instead.
<quitte>
bbrezillon: got eGON to boot u-boot spl.
<bbrezillon>
quitte: this has to do with how the ROM code is reading the boot0 partition. As far as I can for A10 SoC it only uses 1k of data on each page, no matter what the NAND page size is
<bbrezillon>
quitte: I remember seeing different behaviour on A20 (but I'm not sure)
<bbrezillon>
quitte: great, how did you program it ?
<quitte>
bbrezillon: nothing to program. I just needed to realize that I have to change the 512byte alignment of mksunxiboot to 1024 byte alignment
<quitte>
oh you mean program as in flash? that was with nand write.1k
<quitte>
i also added a line making the padding 0xff instead of uninitialized. I don't know if that matters
<quitte>
everything yuq did years ago
<bbrezillon>
quitte: you're working on a cubietruck, right ?
<quitte>
yes
<bbrezillon>
quitte: could you try to dump boot0 from Linux (using nanddump /dev/mtd0 -f /tmp/boot0)
<quitte>
i already did. doesn't work. strings /tmp/boot0 doesn't show eGON
<quitte>
oh that's not true
<quitte>
I get flipped bits and ecc errors or something
<quitte>
and then strings doesn't show egon
<quitte>
at one point i could dump successfully but then I noticed that spl was gone. I probably erased that
<bbrezillon>
quitte: and you kept the nand parititions as defined in my patch series ?
<quitte>
I renamed boot0 to spl but kept it. changed the others, though
<ddc>
quitte : as bbrezillon said the BROM code access the first 128 pages in 1k with random enabled.
<quitte>
so now there are 4 hw-syndrome partitions
<bbrezillon>
quitte: should not be a problem, as long as you keep randomizer enabled (set to hw), and do not change the rnd seeds for boot0 and boot0-recovery
yann_s|AFK has joined #linux-sunxi
yann_s|AFK is now known as yann_s
<quitte>
why boot0-recovery?
<bbrezillon>
quitte: don't remember exactly, but I noticed there were two identical erase blocks when programming with AW tool
<quitte>
so probably for livesuite compatibility. either way i renamed it to uboot, but the size is still 2M
<quitte>
bbrezillon: you said you dumped and flashed successfully. did you look for eGON or any other strings?
<bbrezillon>
quitte: yep
<bbrezillon>
it was there
<bbrezillon>
can you dump the first mtd0 page without ECC correction (nanddump /dev/mtd0 -f /tmp/boot0 -n -l 8192)
<bbrezillon>
quitte: you miss this property nand-rnd-mode = "hw"; in your sp part
<bbrezillon>
quitte: s/sp/spl/
<quitte>
weird. I think I copy&pasted that. recompiling....
<ddc>
bbrezillon: Do u have any idea why the nand scan takes that long during bootup
<bbrezillon>
ddc: because it's the 2 last pages of each block (to check BB markers)
<bbrezillon>
ddc: I haven't tried on-flash BBT, but I think we can try it as soon as everything works
<bbrezillon>
ddc: just need to add nand-on-flash-bbt property to your NAND node in your DT ;-)
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
nedko has quit [Quit: kernel panic]
nedko has joined #linux-sunxi
<quitte>
bbrezillon: still no eGON in the strings. can i doublecheck that i enabled nand-rnd-mode = "hw" in proc? catting the file didn't yield any information
<bbrezillon>
quitte: it does not include all the stuff needed for randomization, per-partition ECC, ...
ddc has quit [Ping timeout: 272 seconds]
<quitte>
i even asked beforehand ;)
<bbrezillon>
quitte: it was intended to get the first part of sunxi NAND driver mainlined
ddc has joined #linux-sunxi
<Turl>
hramrach: unlikely
<bbrezillon>
quitte: this is why randomization is not working on your system
<quitte>
bbrezillon: is there any point in approaching this today for you? otherwise I'd start cherrypicking nand-spl
hramrach has quit [Quit: WeeChat 0.4.3]
ricardocrudo has joined #linux-sunxi
ddc has quit [Ping timeout: 272 seconds]
<bbrezillon>
quitte: I sent you an email with an archive containing all the patches extracted from my sunxi-nand branch
<bbrezillon>
quitte: but please try to use git, this would be much easier for both of us
<quitte>
lovely. thanks. I'll look into applying those in the next days. I'd better finsish u-boot and clean it up before I forget how i did things
avsm has quit [Quit: Leaving.]
<quitte>
bbrezillon: the problem is that I want patches for openwrt's kernel. I don't know how to get that kernel under git control in a sane way. it's in a directory that is created by openwrts build system
<bbrezillon>
quitte: if you need the patches, you could clone my repo and use git format-patch (that's exactly what I did to send you the patches) ;-)
<quitte>
how did you filter out your mtd related work?
<oliv3r>
quitte: did you port bbrezillon's patches to u-boot?
<quitte>
oliv3r: no
<quitte>
I guess I'll start merging bbrezillon with yuq u-boot once I got it to fully boot. (and if i'm still not sick of it)
<bbrezillon>
quitte: that, you couldn't guess, but I often leave my work on top of a branch, in this case you had to take the last 24 patches
<quitte>
...fully nand boot ...
<bbrezillon>
quitte: but I would have told you that ;-)
rafaelMOD has joined #linux-sunxi
<quitte>
bbrezillon: the next time i'm at the university i'll pull the 4Gb
F1skr has joined #linux-sunxi
<quitte>
bbrezillon: how do you get those to stay on top? rebasing?
F1skr has quit [Read error: Connection reset by peer]
<bbrezillon>
quitte: yep
F1skr has joined #linux-sunxi
<bbrezillon>
quitte: git rebase --onto <the-branch-you-want-to-rebase-on>
jemk has joined #linux-sunxi
F1skr has quit [Read error: Connection reset by peer]
F1skr has joined #linux-sunxi
sehraf has quit [Read error: Connection reset by peer]
<quitte>
i sure could use some handholding with git
<quitte>
and i'm not sure how to solve all the conflicts I get when i try to cherry pick that commit
F1skr has quit [Read error: Connection reset by peer]
F1skr has joined #linux-sunxi
F1skr has quit [Read error: Connection reset by peer]
<bbrezillon>
quitte: which branch are you currently based on, do you have any commit on top of this branch, and most importantly what do you want to do (rebase you work on yuq's branch or select part of yuq's works to apply it on your branch) ?
F1skr has joined #linux-sunxi
<quitte>
bbrezillon: I'm on rgwan sunxi-current. I have a bunch of commits on top of that. I want to select parts of yuq's work
<quitte>
right now i have a bunch of modifieds in git status i don't know how to handle
<quitte>
how do i choose wether to use mine or theirs?
<quitte>
also there is a change to .gitignore that I do not want to commmit even if it applies fine
<bbrezillon>
quitte: first of all you'll have to commit or stash your changes
<quitte>
yes. I did that. git status didn't havge anything to say before I started cherry picking
F1skr has quit [Read error: Connection reset by peer]
<bbrezillon>
and then you got conflicts ?
<quitte>
then i added the yuq remote
<quitte>
no
<quitte>
i have to check the bash history. but i ended up cherry picking that specific commit
<quitte>
and now i have conflicts
<traeak>
well i'll try to the boot cycling with the soc hot and see if it'll boot into android after it starts consistently crashing with 3.4.90 or whatever
F1skr has joined #linux-sunxi
F1skr has quit [Read error: Connection reset by peer]
<quitte>
ok git log yuq/mtd. then git cherry-pick 5fe3e8
<bbrezillon>
you ended with conflicts when cherry picking or when applying back the previously stashed changes
<quitte>
when cherry picking
<quitte>
add remote;check log;cherry pick
F1skr has joined #linux-sunxi
<quitte>
that's what (as far as i know) i did effectively to get at the current point
<quitte>
no. how do i choose "mine" for a specific conflict?
<bbrezillon>
I use git gui
<bbrezillon>
to visually identify the conflicts
<quitte>
my mouse is broken on the linux machine :/
<oliv3r>
are there lime a20 with 1gbit ram?
<bbrezillon>
and then manually fixed those conflitc
<oliv3r>
gbyte
<bbrezillon>
quitte: but you can do this with a simple editor too
notmart has quit [Quit: notmart terminated!]
<bbrezillon>
quitte: just edit your conflicting files and fix the part where you see
<bbrezillon>
>>>>>>>>>>>>>>>>
<bbrezillon>
=============
<bbrezillon>
<<<<<<<<<<<<<<<<<<<<<
<bbrezillon>
or something like that :-)
<quitte>
oh. never crossed my mind that the actual files right now might have changed already
F1skr has quit [Read error: Connection reset by peer]
<quitte>
still - how do i simply say: keep my version of this file?
<bbrezillon>
are you sure you want to keep your version
<bbrezillon>
?
<quitte>
yes.
F1skr has joined #linux-sunxi
<quitte>
it's .gitignore
<bbrezillon>
then just git checkout <path-to-your-file>
<quitte>
of course!
<bbrezillon>
quitte: oh wait
<quitte>
yes. doesn't work
<andoma>
checkout --ours
<andoma>
or
<andoma>
checkout --theirs
<andoma>
IIRC
<quitte>
no
dll has joined #linux-sunxi
<dll>
hi, i have a problem with a13 3.0.80 kernel. i get "BUG: scheduling while atomic: " while using i2c in an interrupt driven tty/serial driver. can anyone help me on this. ?
<bbrezillon>
quitte: can you paste git diff result
<bbrezillon>
?
_massi has quit [Remote host closed the connection]
<quitte>
I don't understandd the <<<<<< >>>>>> stuff. what are the reasonable changes i can make in there now
HeHoPMaJIeH has quit [Quit: Konversation terminated!]
zeRez has quit []
notmart has joined #linux-sunxi
notmart has quit [Client Quit]
notmart has joined #linux-sunxi
zeRez has joined #linux-sunxi
<Turl>
quitte: <<<< old code ==== new code >>>>
quitte_ has joined #linux-sunxi
quitte has quit [Read error: Connection reset by peer]
avsm has joined #linux-sunxi
mawe242 has joined #linux-sunxi
zeRez_ has joined #linux-sunxi
<paulk-aldrin>
problem: allwinner tablet with a windows-mobile-ripoff-ui doesn't ship with root
<mawe242>
hi! has anybody managed to use the 12-bit SAR ADC of the A20 under linux?
zeRez has quit [Read error: Connection reset by peer]
<mawe242>
is there a device driver for the ADC, or some detailed instructions as to how to use it? the official A20 datasheet is rather limited wrt the adc usage...
<libv>
paulk-aldrin: and fel doesn't work either?
<paulk-aldrin>
libv, I want root to run serial_noise
<paulk-aldrin>
fel won't help much I suppose
zeRez_ has quit [Client Quit]
zeRez has joined #linux-sunxi
<libv>
paulk-aldrin: just reboot a few times :)
<libv>
or is it not too obvious which is which?
<paulk-aldrin>
nah it's not
<paulk-aldrin>
but yeah, I'll reboot
<paulk-aldrin>
or maybe I find some way to spam dmesg from userspace
<libv>
you'll reboot that thing often enough in its life ;)
quitte has joined #linux-sunxi
dack_ has joined #linux-sunxi
mawe242_ has joined #linux-sunxi
rafael_MOD has joined #linux-sunxi
crudo has joined #linux-sunxi
crudo is now known as Guest9961
AleRoss has joined #linux-sunxi
<AleRoss>
Hi All :)
forcev has joined #linux-sunxi
xavia has joined #linux-sunxi
<mawe242_>
i see there should be support for the LRADC on A10/A13, but is the A20 also supported? I can't find a sunxi adc driver in the sunxi-3.4 kernel for my cubieboard2....
libcg has quit [Remote host closed the connection]
quitte_ has quit [Ping timeout: 245 seconds]
ricardocrudo has quit [Ping timeout: 245 seconds]
dack has quit [Ping timeout: 245 seconds]
mawe242 has quit [Ping timeout: 245 seconds]
rafaelMOD has quit [Ping timeout: 245 seconds]
FunkyPenguin has quit [Ping timeout: 245 seconds]
Zboonet has quit [Remote host closed the connection]
diego71 has quit [Ping timeout: 240 seconds]
diego71 has joined #linux-sunxi
AleRoss has quit [Quit: Page closed]
bonbons has joined #linux-sunxi
souther has quit [Ping timeout: 272 seconds]
<Turl>
mawe242_: can't you use the same driver? SUN4I_KEYBOARD does not seem to be limited to sun4/5i
souther has joined #linux-sunxi
dack_ has quit [Remote host closed the connection]
Guest9961 has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
akaizen has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
rafael_MOD has quit [Quit: Saindo]
rafaelMOD has joined #linux-sunxi
techn has joined #linux-sunxi
boycottg00gle has quit [Remote host closed the connection]
linkmauve1 has joined #linux-sunxi
hramrach has joined #linux-sunxi
<hramrach>
hmm, so the thing seems to support exfat *and* SDXC
<hramrach>
the thing being the manufacturer pre-installed android on inet86vs
FreezingAlt is now known as FreezingCold
bertrik has joined #linux-sunxi
<paulk-aldrin>
oh freaking great, now this thing fried my UART adapter
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
<quitte>
hramrach: it's rather sad than special if sdxc is not supported.
avsm has quit [Quit: Leaving.]
diego_r has quit [Quit: Konversation terminated!]
<libv>
paulk-aldrin: :(
<libv>
paulk-aldrin: but been there, done that
<oliv3r>
damn cheap uarts!
amitk has quit [Quit: leaving]
<paulk-aldrin>
well, it's not like I don't have a few other options for UART, but still, it sucks
<libv>
paulk-aldrin: after i killed my first one, i ordered a pair, but i probably should've ordered 5
<paulk-aldrin>
lol
<mawe242_>
Turl: I probably could, you're right. But i just realized what the "LR" in LRADC means... low resolution (6 bit). not very useful for me.
<mawe242_>
Turl: but the touchpad interface has a 12-bit ADC built in, and according to the datasheet it also support "auxiliary" ADC conversions, differential and single ended. sounds great, I will try to hack the touchpad driver.
Guest17052 is now known as w00tc0d3
FR^2 has quit [Quit: Connection reset by peer]
w00tc0d3 is now known as Guest20054
Guest20054 has joined #linux-sunxi
Guest20054 has quit [Changing host]
Guest20054 has quit [Changing host]
Guest20054 has joined #linux-sunxi
Guest20054 is now known as netchip
souther has quit [Ping timeout: 260 seconds]
Gerwin_J has quit [Quit: Gerwin_J]
<mnemoc>
libv: thank you for the sanity checks on fexc... that was on my TODO since the begining
<libv>
mnemoc: np, after the idiocy with jannf yesterday, it was just something that needed to be done
notmart has quit [Quit: notmart terminated!]
souther has joined #linux-sunxi
<rafaelMOD>
I am getting confused with all this FEX and DTS differences. Does the linux-sunxi 3.4.90-rc1 works only with FEX (no dts on arch/arm/boot/dts for sunXi)? And does the linux-sunxi in the mainline works only with DTS?
<bonbons>
rafaelMOD: yes, that's the way it is
souther has quit [Ping timeout: 240 seconds]
<rafaelMOD>
So now there are two development fronts, with different drivers and patches?
souther has joined #linux-sunxi
<rafaelMOD>
And the drivers and patches are exclusive for FEX or for DTS? The device driver implementation is totally different for DTS and for FEX?
patap has joined #linux-sunxi
<patap>
rafaelMOD: I'd say more like patches for mainline kernel and time-to-time fixes for 3.4
<mnemoc>
talking about that... are there (important) outstanding fixes for 3.4?
<mnemoc>
i'm lost on a see of 10k+ unread mails :\
<jemk>
mnemoc: that is what I remember, maybe there are more
<mnemoc>
jemk: thanks. i'll handle them now
souther has quit [Ping timeout: 260 seconds]
<mnemoc>
jemk: do you know if people has tried the current stage/sunxi-3.4? can v3.4.102-r1 "graduate" from stage?
mawe242_ has quit [Ping timeout: 240 seconds]
rz2k has joined #linux-sunxi
quitte has quit [Read error: Connection reset by peer]
souther has joined #linux-sunxi
dll has quit [Quit: Page closed]
quitte has joined #linux-sunxi
<jemk>
mnemoc: no, i don't know, and i didn't try .102 myself
<libv>
mainliners: is there any reason for this? compatible = "allwinner,sun5i-a10s-i2c", "allwinner,sun4i-a10-i2c";
<rafaelMOD>
What are the big driver coding differences for FEX and DTS? DTS doesn't uses functions like "script_parser_fetch(...)"? And can I use functions like "gpio_set_value(...)" with FEX? Any good gide on that?
<mnemoc>
mainline takes EVERYTHING from the DTS. legacy takes the enable/disable and the pinmuxes from FEX only
FR^2 has joined #linux-sunxi
dack has joined #linux-sunxi
<mnemoc>
FEX drivers check on init if the thing is enabled, while DTS works the other way around. the kernel knows something is present somewhere specificly and probes for drivers
<mnemoc>
and FEX drivers are mostly standalone while mainline drivers use common frameworks
<rafaelMOD>
I'm starting to understand the differences, thanks. But will legacy 3.4 ever evolve to 3.5 and so? Or will it be deprecated?
<mnemoc>
it's stuck there
<mnemoc>
there was the idea of making a sunxi-3.10 or 3.14 stable branch, backporting newer things... but lack of man power have not made it possible
<mnemoc>
this stable branch was also intended to get magic glue to be able to drop in the legacy drivers not yet supported by mainline
<mnemoc>
but well... it seems it's not going to happen
<rafaelMOD>
All manpower is now on mainline?
<mnemoc>
mostly
souther has quit [Ping timeout: 272 seconds]
<Turl>
libv: eh..
<libv>
Turl: it just uselessly diverges dtses
<Turl>
libv: maybe the sun5i IP has some new feature?
<libv>
a grep for that string brings up nothing
<Turl>
indeed, nothing seems to use the compatible to this day
<Turl>
but that's future-proofing
<libv>
oh, the second compatible string is used
<Turl>
if it weren't it wouldn't work :p
<libv>
it's not as if dtses of yesterday will work with kernels of tomorrow
<libv>
so that rules out that future-proofing
<Turl>
libv: that's the ultimate plan
<libv>
Turl: which is never going to happen
<libv>
secondly...
<libv>
doesn't the second compatible string rule out the first?
<Turl>
libv: marvell guys seem to be executing it successfully so far
<libv>
it makes the first string totally irrelevant
<mripard_>
libv: none besides the i2c maintainer being picky about it
<rafaelMOD>
mnemoc: The functions for device driver development in FEX and DTS are that different? Like, can I call i2c_add_driver() in a module in FEX?
<libv>
Turl: is that ordering codified as such today?
<mripard_>
his point was that if there ever was a bug or some behaviour difference in the sun5i IP, we wouldn't have to update the DT
<Turl>
libv: pretty sure it is
<libv>
Turl: ok
<Turl>
libv: you can even see it being used on the machine compatible
<Turl>
compatible = board, soc
<mripard_>
and since like Turl is saying, DT backward-compatibility is the hype du jour, well....
<libv>
mripard_: people are kidding themselves
<mripard_>
even if we're not close to that on sunxi.
<libv>
mripard_: they should just own up to the fact that that will never happen
<libv>
well, some people know, but are still marketing it differently
<libv>
as otherwise people would or would've been even more against dt
<mripard_>
libv: you're preaching to the choir
<libv>
:)
forcev has quit [Ping timeout: 260 seconds]
<mripard_>
it's something we should tend to, but it's not something that should be enforced as an ABI stability imo
<mripard_>
if we ever have a good reason to change it, we should be able to...
<Turl>
it should be ABIish when you actually ship it
<mripard_>
anyway... we've never really been bothered by that, so I'm not really worrying too much about it for now.
<Turl>
and even then, you could change it up to some extent
<libv>
Turl: drivers should try to gracefully catch that though
<libv>
but again, in an ideal world
<mripard_>
besides whenever there's a maintainer meetup and this issue in brought to the table again...
<mripard_>
Turl: as long as it's not set in a ROM, you can ship it however you want
<mripard_>
just like a bootloader.
souther has joined #linux-sunxi
<libv>
mripard_: btw, boo for ahb_hdmi0 and ahb_de_fe/ahb_de_be/ahb_lcd
<libv>
there really was no reason for naming these things differently
<mripard_>
that can definitely change
<libv>
but then, i also have no real reason to check these names from u-boot apart from pointing out that something might be conceptually awry
<mripard_>
if you come up with a better name that makes your life easier, do so
<libv>
yeah, now that hansg catched the second changes, i will
<libv>
for hdmi/hdmi0 i wasn;t bothered enough yet
<libv>
s/catched/caught/
<Turl>
libv: that check is completely redundant :)
<Turl>
if you see it's compatible already
<libv>
Turl: well, not entirely, but that's a few lines up in this irc log
quitte has quit [Read error: Connection reset by peer]
<Turl>
libv: you already know the clocks exist because you turned the IP on, you're just adding code to break in case you rename the stuff in the future or anything like that
<Turl>
like it happened with hans
hramrach has quit [Remote host closed the connection]
<libv>
Turl: v3 was not going to return anymore
quitte has joined #linux-sunxi
<libv>
i forgot to remove the returns for v2
<libv>
as i had planned on removing those already
<Turl>
so you'll just print a warning?
<libv>
so i'd just complain
<libv>
yup
<Turl>
that's better but still pretty pointless imo :)
souther has quit [Ping timeout: 272 seconds]
<libv>
no, i believe that <&label bit> is pretty wrong still, and that that will change in near or slightly further future. i just want to make this line in the sand
<libv>
but for simplefb, i am already complaining about, but not bailing on clocks i cannot resolve in the hope that things work out anyway
<libv>
in the kernel code that is
<libv>
that does make my returns in uboot code seem just as assymetric as the clock handling is :)
<Turl>
libv: if it changes you'll need to fix the hardcoded bits in uboot anyway
deasy has joined #linux-sunxi
hramrach has joined #linux-sunxi
FunkyPenguin has joined #linux-sunxi
Faisal has joined #linux-sunxi
patap has quit [Quit: Page closed]
<paulk-aldrin>
wtf, there is 36V on the board…
<Turl>
you mean 3.6?
mawe242_ has joined #linux-sunxi
ninolein has quit [Ping timeout: 246 seconds]
<rafaelMOD>
The functions for device driver development in FEX and DTS are totally different? Any recommended doc on that? I need to use and i2c inside an asoc driver in 3.4.90-r1 FEX
Nyuutwo has joined #linux-sunxi
<paulk-aldrin>
no, it really measures at 36V!
ninolein has joined #linux-sunxi
<paulk-aldrin>
and makes nice sparks when shorted to ground
<Turl>
paulk-aldrin: o.O what board?
<paulk-aldrin>
Ampe A76
<paulk-aldrin>
on test points
<paulk-aldrin>
no wonder why it fried my UART
<Turl>
rafaelMOD: fex is more like the "old school" way, with platform devices
Skaag has quit [Ping timeout: 240 seconds]
<Turl>
rafaelMOD: have a look at the touchscreen drivers with fex support to get an idea of how it works
<Turl>
most of them are i2c
dack has quit [Remote host closed the connection]
<rafaelMOD>
Thanks!
<rafaelMOD>
BTW, I am developing a driver for Cirrus Codec CS4245 in 3.4.90-r1
<rafaelMOD>
And I want it to have alsa controls so I can work with alsa mixer.
<rafaelMOD>
How is the dma and i2s drivers in the mainline for sun7i? Any WIP?
<paulk-aldrin>
have you ever seen board with no UART pad?
<paulk-aldrin>
s/board/tablets/
<paulk-aldrin>
it's starting to look that way
<Turl>
rafaelMOD: DMA is being reviewed, and Jon is working on I2S, he got it more or less working the other day