torqu3e has quit [Read error: Connection reset by peer]
torqu3e has joined #linux-sunxi
Guest10764 has quit [Remote host closed the connection]
christopher has joined #linux-sunxi
christopher is now known as Guest13955
uro has quit [Ping timeout: 264 seconds]
ZaEarl has quit [Ping timeout: 264 seconds]
Guest13955 is now known as anunnaki
anunnaki has quit [Quit: Leaving]
anunnaki has joined #linux-sunxi
Dave77 has joined #linux-sunxi
Dave77 has quit []
uro has joined #linux-sunxi
rellla has joined #linux-sunxi
eebrah has joined #linux-sunxi
<uro>
R
<oliv3r>
those A20 devices are all pre-orders though I assume
shineworld has joined #linux-sunxi
uro has quit [Ping timeout: 248 seconds]
plan_b has joined #linux-sunxi
shineworld has quit [Quit: Leaving]
mdfe has joined #linux-sunxi
zub_ is now known as zub
eebrah has quit [Ping timeout: 252 seconds]
paulk-desktop has joined #linux-sunxi
eebrah has joined #linux-sunxi
plan_b has quit [Quit: plan_b]
eebrah has quit [Quit: Leaving]
rellla has quit [Remote host closed the connection]
wingrime has joined #linux-sunxi
von_fritz has joined #linux-sunxi
<wingrime>
hramrach: are you here ?
anunnaki has quit [Ping timeout: 248 seconds]
rz2k has joined #linux-sunxi
<hramrach>
wingrime:
<wingrime>
hramrach: I think we can make suspend work without that image suspend.bin
<wingrime>
If we remove disable interpurt in suspend functions in drivers
<wingrime>
I mean wakeup sources
<hramrach>
did not look what the image does
<hramrach>
but don't see anything much bad with the image in general
<wingrime>
1) save wakeup sources reqs
eebrah has joined #linux-sunxi
<wingrime>
2) configure irq controler for wakeup sources
<wingrime>
3) suspend dram
<wingrime>
4) suspend cpu
<wingrime>
5) resume dram
<wingrime>
6) restore Irq config
<wingrime>
7) restore wake sorce regs
<hramrach>
3 and 5 needs to be done in sram presumably
anunnaki has joined #linux-sunxi
<wingrime>
we can simply not suspend dram
<hramrach>
that wil give less power saving
<wingrime>
or we can use kernel attributes to place funtion to SRAM
<wingrime>
or we can write this part on asm
<wingrime>
this will be small function
<wingrime>
all we have to make likner place this in SRAM
<wingrime>
kernel support this AS I saw
<hramrach>
well, it should be possible to get usable standby by running the sram code in cpu_do_idle except 3) and 5)
<wingrime>
we can skip all stuff related saving / restoring HW registers, simply removing IRQ suspend on driver
<wingrime>
as IRQ enabled it will wakeup
<wingrime>
suspend cpu is simple
<wingrime>
WFI asm command
<hramrach>
that will need quite a bit driver cleanup I suspect :<
<wingrime>
not much
<wingrime>
only for wakeup source
<wingrime>
add some Kconfig for it
<hramrach>
I looked at usb driver
<wingrime>
I don't know what problem
<hramrach>
it does not even register the function that would get what suspend state the system is entering
<wingrime>
but my USB mouse loss power after wakeup
<hramrach>
that's probably A13 specific
<wingrime>
who controls USB power
<hramrach>
the usb driver using a gpio presumably
<hramrach>
there is a config for it in .fex file
ssvb_ has quit [Read error: Connection reset by peer]
ssvb has joined #linux-sunxi
<hramrach>
hcd registers struct platform_driver.driver.pm.suspend but disp registers platform_driver.suspend. the latter gets state, the earlier does not
<hramrach>
meant to look for some linux documentation that specifies wth these are supposed to do
<hramrach>
but did not get to it
<wingrime>
I see functions exist but not used
<wingrime>
i get it right?
<wingrime>
hramrach: why not add this to platform_driver
<hramrach>
well, you probably can just drop the driver.pm and register driver.suspend instead
<hramrach>
did not try if that breaks something
<wingrime>
hramrach: usb code look like piece of shit
<wingrime>
hramrach: it relay need deep rewrite
<wingrime>
hramrach: it looks strange
<wingrime>
hramrach: but suspend calls
<wingrime>
hramrach: but resume noy
<wingrime>
*not
<wingrime>
hramrach: it relay strange.....
<wingrime>
I commented out resume in sw_hcd0.c
<wingrime>
usb after resume begin to work then , power down
<wingrime>
reconneced, and begin to work
ZaEarl has joined #linux-sunxi
ganbold___ has joined #linux-sunxi
ganbold__ has quit [Remote host closed the connection]
<wingrime>
Now i fix checkpatch warnings for zet6221 driver
<mnemoc>
wingrime: for defconfig changes I need commits that change them all consistently, can you send me such patch?
<mnemoc>
also, we keep `savedefconfig`ed files, not full .config copied over
<wingrime>
mnemoc: if you taking about wifi patch, i say: not now, now I do zet6221 cleanup for checkpatch
<mnemoc>
wingrime: i'll try to cherry-pick the driver part later tonight.
<wingrime>
mnemoc:thanks, I make configs patches later
<wingrime>
also a13 required some stuff for add such PM and CPUFREQ
<wingrime>
in config
<mnemoc>
in defconfigs the idea (ok, my idea) is to keep 3 variants for each SoC (nothing per-device). one for android, one for linux desktop and one for headless (but supporting humble dynamic fb) linux
<mnemoc>
and all consistent between each other
<mnemoc>
[help wanted]
<wingrime>
need some one who have such variants
<hramrach>
i wonder
<hramrach>
should a defconfig include everything, kitchensink included
<hramrach>
like people wanting nfs root
<hramrach>
that's general non-sunxi-specific option
<hramrach>
you can enable it in any config that allows for networking
<hramrach>
why defconfig
<hramrach>
does x86 defconfig have that?
<jelly-home>
less work for distro kernel maintainers if you already enable everything
<wingrime>
hramrach: x86 have make allyesconfig
<hramrach>
hmm, that fails on sunxi I suspect
<jelly-home>
(and less work for me if there already are drivers for hid_lenovo_tpkbd and snd-usb-audio and usb ethernet and... the kitchen sink)
<jelly-home>
which versions of sunxi-3.4 had slow/buggy wemac, I suppose that's fixed now?
<hramrach>
not really
<hramrach>
all are buggy in different ways from what I see on the ml
<jelly-home>
ok, then I still want that usb ethernet thingy
<wingrime>
if I have some devboard maybe I can look into ethernet
<hramrach>
well, then you can enable everything USB in the defonfig because the boards do have USB
<hramrach>
why is any USB device disableb?
<jelly-home>
the only answer I can think of is "dev can't bother waiting more than 5 minutes for build"
<mnemoc>
hramrach: I don't mean kitchensink included, I mean sunxi-related stuff and basic suppoty only
<mnemoc>
hramrach: disabling mali is not trivial. enabling android is not trivial
<mnemoc>
hramrach: just a base line, but consistent, and useful for testing
<libv>
mdfe had to enable quite a few things for plasma active, not sure what the diff is like though
<wingrime>
I prefer not think about plasma speed on a10....
<mdfe>
nod
<mdfe>
however, any interrest to the overhault kernel config?
<mdfe>
does not sound so
<ssvb>
hramrach: I generally don't like begging people to reconfigure and recompile their kernel just to run some tests
<ssvb>
hramrach: if "hwpacks" are provided, they are better to include everything and a kitchen sink as long as this does not regress anything (other than the slight increase of the code size)
<hramrach>
well, then it should include all USB devices ;-)
<Turl>
techn_: did you rebuild uboot and set up script.bin?
<Turl>
you need to disable mmc on script.bin too, pins conflict iirc
<wingrime>
Who can add some timeout and try again on error in SPL
<mnemoc>
ssvb: I someone takes care of improving the defconfigs I have to trouble of building (and uploading to dl.linux-sunxi.org) a tarball of each every time something gets merged (3.0 and 3.4, and stages too)
<wingrime>
than a don't need to long press button 5 times to reboot
<techn_>
Turl: yes.. I added UART0_PORT_F for my board.. and changed scrpt.bin to use correct uart (I'm trying this with a13 board)
<wingrime>
mnemoc: whats wrong with gaget
<wingrime>
why It not merged by default in 3.4
<mnemoc>
wingrime: reason was it's implemented in android.c, and we first went to 3.3 (without android.c) before jumping to 3.4
<mnemoc>
wingrime: and anyhow, we can't have android-only usb gadget
<wingrime>
mnemoc: you want simply port android based gadget to 3.4
<wingrime>
mnemoc: or make it work without ?
<mnemoc>
wingrime: I want a gadget/sunxi.c :)
<mnemoc>
after that we can obsolete 3.0 and focus in 3.4 (and forward sun6i/sun7i there)
calris has quit [Ping timeout: 246 seconds]
<mnemoc>
hope it makes sense
<wingrime>
so better, at first move android gadget to 3.4 ?
<mnemoc>
wingrime: I think it's better to move android gadget to android-less in 3.0
<mnemoc>
and then it will be trivial to forward to 3.4
<mnemoc>
but on a base where gadget works already
<wingrime>
mnemoc: I saw usb infrastucture
<wingrime>
sunxi usb look like pice of shit
<mnemoc>
yes, it needs to be reimplemented
<mnemoc>
but we can refactor just enough to get gadget on not-android and then deprecate 3.0
<mnemoc>
before taking the huge enterprise of making a new sunxi-usb
<wingrime>
mnemoc: I think that we can drop suspend.bin rewited no-dram place in ASM and place it to SDRAM using sections
<mnemoc>
(or refactoring the current "pice of shit" into sanity)
<mnemoc>
wingrime: in sun7i that's even harder, as suspend is handled by an openrisc core :<
<Turl>
techn_: I suspect 1 is on the same side as 1 on the sd part
<Turl>
techn_: it'd make no sense to cross over the lines
<mnemoc>
wingrime: but surely I would love to get rid of that bin
<wingrime>
mnemoc: Anyway, I wan't make code for mainline , and more one on sun67 nothing changes becose we STILL wait interupt
<wingrime>
Or something like
<techn_>
Turl: ok.. no help yet :(
<wingrime>
or I don't know other way Stop CPU
<wingrime>
or they poweroff whole cpu ?
<wingrime>
mnemoc: any way, we can simply make #define for sun6-7
<techn_>
Turl: how about.. should I update spl when I'm updating u-boot.. and where I should put SPL on flash?
<mnemoc>
anything that means cleaning without reducing functionality is 100% welcomed. but it's prefered if it comes after unifying the corresponding mach-sun?i/ things
<Turl>
techn_: spl? wut
<mnemoc>
wingrime: sun7i (A20) seems to be just like sun4i/sun5i in this regard
<techn_>
Turl: sunxi-spl.bin
<Turl>
techn_: if you're going to use the sd port to debug, you need to boot from nand
<Turl>
so you'd use the lichee branch with nand support
<Turl>
I don't think it produces spl
<techn_>
Turl: oh.. forgot that
torqu3e has quit [Ping timeout: 245 seconds]
<techn_>
but shouldn't it give output to serial.. even it wont boot?
<Turl>
boot0/1 on nanda will load your uboot bin and run it
<Turl>
if uboot has the right config it'll output stuff
<Turl>
not sure where do boot0/1 output to
n01 has quit [Quit: leaving]
<mnemoc>
wingrime: sure we can #ifdef ... 3.4 isn't multiplatform, but having #ifdef's get us in better shape for mainlining that completely separated files/trees as today
<mnemoc>
the initial we used for sunxi-3.0, when we trashed our old work on 2.6.36
<ssvb>
rz2k, wingrime : looks like a real unencrypted little endian openrisc code :) because 0x15000000 is NOP for openrisc and I see quite a lot of these in "ar100.code" file :)
eebrah has quit [Quit: Leaving]
<hramrach>
that long for nop
<wingrime>
hramrach: simpler cpu have fixed size instruction
<ssvb>
just ordinary fixed size 32-bit instructions
<ssvb>
btw, the output of "./objdump -EL --target binary --architecture or32 -D ar100.code" looks sane
<ssvb>
I'm not participating in reverse engineering efforts, but you can be sure that it's 100% openrisc
<wingrime>
If this core placed on same bus as cpu
<wingrime>
and have dram access
<wingrime>
it may be intresting to implemnt some interesing stuff
<ssvb>
if you want a very short code snippet, then it's:
<ssvb>
43e8:00 00 25 bc l.sfnei r5,0x0
<ssvb>
43ec:fc ff ff 13 l.bf 0x43dc
<ssvb>
43f0:00 00 00 15 l.nop 0x0
wingrime has quit [Ping timeout: 264 seconds]
<ssvb>
a comparison with 0, conditional branch and NOP in the branch delay slot
<Turl>
putting nops on delay slots is for lazy people :)
<jelly-home>
I remember trying to remove those on 32bit sparc, it would break things for some reason!
<Turl>
removing nops from delay slots?
<ssvb>
jelly-home: the instructions in the branch delay slot are always executed before branch, it's kind of optimization which makes the assembly code a bit more difficult to read and write
<Turl>
it's a drawback of pipelined design
<Turl>
by the time you evaluate the branch, the instruction after it will have been decoded
<Turl>
so they just let it execute and start grabbing new instructions from whatever the branch chose
<Turl>
so if you have code on C like a +=1; if(c){..}else{..}
<Turl>
on assembler with delay slots you can actually test, branch, a+=1