<DocScrutinizer05>
apelete: please don't tell you have to mess with MG musb_core :-O
<DocScrutinizer05>
it's some heap of code junk almost as ugly as tty_serial, in linux. Makes your eyes bleed
<DocScrutinizer05>
actually musb_core engine itself gives you brain cancer
<DocScrutinizer05>
a state machine in hw, with no means whatsoever to externally control the state it's in, via sw
<DocScrutinizer05>
so musb_core kernel driver implements another state machine that mirrors the hw state machine and gets synced to it by the messages aka interrupts the hw sends
<DocScrutinizer05>
two state machines that run in sync, unbearably stupid design
<wpwrak>
routine business in communications :)
<DocScrutinizer05>
and then you got power management, not only for musb_core but also for the ULPI and the CPU<->musb_core bus domains
<DocScrutinizer05>
of course each one separate from the other ones, but with obvious dependencies
<DocScrutinizer05>
on top of that you get OTG suspend
<DocScrutinizer05>
and in the end the whole friggin mus_core hw burns an unbelievable 60mA just for idling, as soon as you power it up
<DocScrutinizer05>
at least that's what I wasn't able to forget, from my enterprise with N900 hostmode
<DocScrutinizer05>
IOW: IIRC
<wpwrak>
nice :) i guess the 60 mA are to provide the little demons inhabiting the design with a familiar environmental temperature ;-)
<DocScrutinizer05>
obviously TI thought when a device is operating in hostmode, then energy saving isn't a topic worth considering
rz2k has quit []
<DocScrutinizer05>
I only hope for Nikolaus' statement to be correct, that the other USB cores are less greedy. Otherwise the USB link to modem in GTA04 is prone to kill the design
<DocScrutinizer05>
since that suspend-to-ram concept for OMAP phones is a silly idea
<DocScrutinizer05>
and no modem will really support it
<DocScrutinizer05>
OM only chosen this approach since the S3C24xx were utter crap and had NFC about zero-clock
<DocScrutinizer05>
at least I hope it was the reason to choose this broken-by-design approach
<DocScrutinizer05>
wpwrak: do you recall what's been the deal when considering zero-clock versus suspend-to-ram?
<DocScrutinizer05>
no kernel support (yet) for NOTICK?
<DocScrutinizer05>
or was it actually just the lack of static registers in S3Cxxxx?
<DocScrutinizer05>
I'm *really* unhappy with this USB interface to modem. I just recall that N900 keeps CPU active at 500MHz as long as anything is plugged to USB. I guess that's for a reason - prolly the musb-core can't wake the CPU
<DocScrutinizer05>
and - depending on modem chipset - I might figure that same happens to the ARM and usb-core used in modem
dos1 has quit [Ping timeout: 248 seconds]
<DocScrutinizer05>
I wouldn't like to see both systems (APE and modem) power-up, enumerate, transfer 1 byte, power-down the USB 200 times per second
<DocScrutinizer05>
particularly since this wouldn't be possible to get done 200 times per second
<DocScrutinizer05>
I guess USB ENUM overhead is just too huge for doing that
<wpwrak>
(zero clock) hmm no, don't remember. maybe it wasn't as power-efficient as real suspend, with all the special hw tweaks ?
<wpwrak>
ah, no dedicated interrupt line ? that sucks :)
<DocScrutinizer05>
given the difficulties I recall we had with just changing CPU clock frequency in S3C24xx, I doubt it could zero-clock at all, particularly not when peripherals like UART shall still stay on standby and even operational ready to receive a byte to buffer
<DocScrutinizer05>
iirc everything been just cpu clock * $multiplier
<DocScrutinizer05>
so when changing cpu clock (by freq-governor) you had the problem of glitches in UART etc unless you temporarily suspend them, which you can do only after stopping/finishing any ongoing transmission
<DocScrutinizer05>
just that you don't know about 1st byte of a newly started transmissin inbound, before the byte completely is in buffer
<DocScrutinizer05>
(interrupt line) well for sure there's no interrupt line to wake CPU and musb_core, on ULPI level
<DocScrutinizer05>
dunno if there's a wake-irq from musb_core to CPU
<DocScrutinizer05>
ok, on hindsight - and looking on the facts I just summarized - it might have been just the CPU running at 500MHz without any break that caused the 60mA increased system power consumption that we observed as soon as musb_core active
<DocScrutinizer05>
and funny enough this "patch" to nail cpu clock to 500 when USB, it got introduced by Nokia as late as maemo fremantle PR1.2 iirc
<wpwrak>
well, you lose uart either way ...
<DocScrutinizer05>
hmm?
<DocScrutinizer05>
when uart has own stable clock, you can mess around with cpu clock all you like
<wpwrak>
whether you stop the clock or suspend the whole cpu. uart is gone then. all you have are your interrupt lines. and maybe rtc and such.
<wpwrak>
okay, if :)
<wpwrak>
but just keeping the oscillator running is pricy ...
<DocScrutinizer05>
I talked about changing cpu clock (in S3C24xx) not about +stopping* it
<DocScrutinizer05>
been a PITA in GTA02 since you always had windows where you get transmission errors on UART, aiui
<wpwrak>
(interrupt line) well, the module may have some more signals than just usb ? of course, if they really do everything over usb, you lose ...
<wpwrak>
that's why you want robust protocols :)
<DocScrutinizer05>
all you can do is unset CTS and wait if another few bytes may come in, before you mess around with (uart) clock
<DocScrutinizer05>
I didn't get it why Nikolaus used USB to link to Option module, to start with
<DocScrutinizer05>
there are PCM and serial interface as well
<wpwrak>
ask him ?
<DocScrutinizer05>
I did, and I admit I forgot his rationale
<DocScrutinizer05>
maybe sth along the line of "so we don't need muxer"
<DocScrutinizer05>
which otoh opens a path for a sw fix, when we just ignore USB and actually use muxer on serial
<DocScrutinizer05>
heck, GTA04 even has a PHY to talk to Option module
<DocScrutinizer05>
:-o
<DocScrutinizer05>
with charge pump and all
<DocScrutinizer05>
just no VBUS ;-P
<DocScrutinizer05>
and I'm pretty puzzled that Option actually seems to work even without VBUS, in peripheral mode
<DocScrutinizer05>
but there's a ticker along the line of "frequent re-ENUM on modem USB"
<DocScrutinizer05>
ticket even
<DocScrutinizer05>
I wonder why ;-)
<DocScrutinizer05>
USB is a terribly complex module with a lot of overhead, for a simple task like "shuffle bytes between A and B, at high speed with no delay and no errorchecks"
<DocScrutinizer05>
s/module/protocol/
<qi-bot>
DocScrutinizer05 meant: "USB is a terribly complex protocol with a lot of overhead, for a simple task like "shuffle bytes between A and B, at high speed with no delay and no errorchecks""
<DocScrutinizer05>
*ENUM* says it all
<wpwrak>
no delay ? you can't mean USB then ...
<DocScrutinizer05>
that's my point, well one of them
<DocScrutinizer05>
USB is overly complex to replace a simple A<->B bytestream single channel duplex connection
<DocScrutinizer05>
feels like using tcp/ip to replace a rs232
<DocScrutinizer05>
actually cheapernet tcp/ip
<DocScrutinizer05>
wpwrak: do you recall who stated that USB was too power greedy and too much overhead and we shouldn't use it for the MC75, back in OM GTA03 days? The Siemens guys? Or sb of OM, even you?
<wpwrak>
i does sound like something i may say. not sure if i was involved in that discussion, though.
<wpwrak>
tcp/ip is MUCH lighter than USB
<DocScrutinizer05>
indeed
<DocScrutinizer05>
never heard of tcp/ip ENUM or SNP or HNP or suspend, and ports are only a poor description of EP, and UDP not really a similar technics than isochronous
xiangfu has joined #qi-hardware
xiangfu has quit [Ping timeout: 264 seconds]
xiangfu has joined #qi-hardware
viric has quit [Remote host closed the connection]
viric has joined #qi-hardware
<roh>
DocScrutinizer05: the serial interfaces usually dont get you full datarates possible via 3g
<roh>
most end at 1.2-2mbit
<roh>
so for hsdpa and similar one might need usb(2) to gain from that. for long-term powersaving usb sucks. correct. thats why basically all these modules do multiple links or augment the usb with proprietary extensions.. and if it only may be 1-2 gpio/irq lines to trigger wakeups or 'resume polling'
<roh>
in openmoko times.. well.. usb1 host would have been what we could have done.. but without 3g on the modem that never made sense ;)
<roh>
also the calypso doesnt know usb, so that would have been with a hypothetical module which wasnt in discussion since we had to use the fic owned calypso design.. you remember? ;)
wolfspraul has joined #qi-hardware
wolfspraul has quit [Quit: leaving]
wolfspraul has joined #qi-hardware
wej has quit [Ping timeout: 245 seconds]
wej has joined #qi-hardware
panda|x201 has joined #qi-hardware
<DocScrutinizer05>
I remeber talking to the siemens guys about MCi75 module, for GTA03. But yes, you're basically right
<DocScrutinizer05>
we found serial been fast enough for edge
apelete has left #qi-hardware ["ERC Version 5.3 (IRC client for Emacs)"]
apelete has joined #qi-hardware
<DocScrutinizer05>
I wish the Option would support SSI/HSI
<DocScrutinizer05>
I guess we will have lots of fun with USB drivers until this contraption works like expected, without burning energy for idle standby or introducing seconds of delay for ENUM on start of each transmissin after a few seconds of idle
<DocScrutinizer05>
(this contraption == Option601/801 on OMAP via USB)
<wpwrak>
i think you want to look for alternative signaling mechanisms to use in parallel to USB, as roh has suggested
<wpwrak>
e.g., get a dedicated interrupt/wakeup line, and only bring up USB when that one tells you there's work to do
<apelete>
Hi there
<apelete>
DocScrutinizer05 wpwrak: just read the log of last night conversation about dealing with musb
<apelete>
it's funny how every single kernel hackers seem to think that dealing with usb/musb is a messy enterprise :-)
<DocScrutinizer05>
wpwrak: it's not about the concept - it already occurred to me. It's about the overhead of "bringing up"
xiangfu has quit [Ping timeout: 252 seconds]
<DocScrutinizer05>
USB prolly times out when simply stopped
<apelete>
since I know little about usb to begin with, I guess I can't tell the difference between what's messy and what's not ;-)
<DocScrutinizer05>
apelete: well for me it was, when I tried to make (and finally made) usb hostmode work on N900, despite the hw bugs
<apelete>
<DocScrutinizer05> apelete: please don't tell you have to mess with MG musb_core :-O
<apelete>
DocScrutinizer05: what does MG stands for ?
<DocScrutinizer05>
mentor graphics
<apelete>
ok
<DocScrutinizer05>
a company that better gets erradicated from God's great earth
<apelete>
:)
<DocScrutinizer05>
wpwrak: (USB) ...so at very least I guess you need to suspend the USB
<DocScrutinizer05>
if that's feasible at all with non-OTG devices
<DocScrutinizer05>
otherwise you need to re-ENUM and that will take seconds
<DocScrutinizer05>
luckily we don't plan to follow the suspend-to-ram strategy in our frankeN900 aka Neo900, and thus we can tickle USB every second with low penalty in power consumption
<DocScrutinizer05>
but I doubt this will help to wake up the musb-core when modem wants to talk to APE
<DocScrutinizer05>
would need some sort of flow control for USB, and I never heard of such thing
* DocScrutinizer05
feels nausea
<DocScrutinizer05>
apelete: can you help me out?
<apelete>
DocScrutinizer05: sure, help with what ? (don't know if I can, I'm really a noob when it comes to usb :-) )
<DocScrutinizer05>
oh, I got you wrong then
<DocScrutinizer05>
hanks anyway
<DocScrutinizer05>
thanks*
<wpwrak>
suspend doesn't require OTG. not sure how long it takes, though. i regularly choose not to implement it ;-)
<wpwrak>
and the wakeup wouldn't come over USB itself but via some additional signal the module may have (just like it probably does for UART, etc.)
wolfspraul has quit [Quit: leaving]
panda|x201 has quit [Ping timeout: 240 seconds]
<whitequark>
wpwrak: iirc suspend takes about 5ms or so
<whitequark>
it counts missed frames, when it's 4 it suspends
<whitequark>
I think
viric has quit [Ping timeout: 240 seconds]
viric has joined #qi-hardware
woakas has quit [Read error: Operation timed out]
woakas has joined #qi-hardware
viric has quit [Ping timeout: 240 seconds]
viric has joined #qi-hardware
<DocScrutinizer05>
wow
<DocScrutinizer05>
so basically auto-suspend?
<DocScrutinizer05>
wpwrak: UART can happily idle along and resume/wake CPU when a byte in buffer
<DocScrutinizer05>
even on start bit getting transmitted I guess
<whitequark>
rechecked. it's 3ms
<whitequark>
DocScrutinizer05: yeah
<whitequark>
from the looks of it usb doesn't seem like a power hungry thing (while in idle at least)
<roh>
whitequark: well.. maybe that without special extra lines there is no real idle
<roh>
one needs to poll every 100ms
<roh>
you only can cheat stuff, like not enumerate the bus and hardcode stuff
<roh>
but you cannot come around the polling while the link is active, even when there is no traffic
<roh>
the 'expensive' part is more in the protocol handling. wastes a lot of cputime when all you want to do is what hdlc and serial lines were designed for ;)
<roh>
well but thats life. sometimes there is no nice way around it. maybe there are modules with fast spi which can do full 3g/4g datarates. dunno.
wej has quit [Ping timeout: 260 seconds]
wej has joined #qi-hardware
viric has quit [Ping timeout: 240 seconds]
<wpwrak>
(checked USB suspend/resume) there is non-polling wakeup from both sides. so an all-USB solution (without wakeup signal) should be sufficient. you still need to provide 5 V, though. (unless you have a private agreement among your devices to not need that)
viric has joined #qi-hardware
viric has quit [Ping timeout: 240 seconds]
viric has joined #qi-hardware
viric has quit [Ping timeout: 240 seconds]
<whitequark>
roh: rs485!
<whitequark>
why does one need to poll each 100ms?
<roh>
whitequark: dont ask me. thats how usb works
<whitequark>
roh: first time I hear that; I could use some reference
<roh>
usb works by pollin
<roh>
g
<whitequark>
oh
<roh>
there is no irq line.
<whitequark>
that's each 1ms
<roh>
basically the host needs to ask all devices periodically and the idle poll is atleast 100hz or so
<whitequark>
well, it depends on speed I think. full-speed has sof at each 1ms
<whitequark>
and on high-speed it's each 125us
<whitequark>
roh: but, if the device is in sleep mode, there's no activity on bus, and wakeup is asynchronous
<whitequark>
so it's essentially interrupt-driven if you aggressively put the bus to sleep
<roh>
whitequark: ive never seen that
<roh>
usually the bus sleeps when you suspend the machine and else not
<whitequark>
roh: which part?
<whitequark>
oh
<roh>
most disable suspend because its buggy with loads of devices
<whitequark>
true dat
<roh>
how should a not polled (sleeping) bus client wake up the host?
<whitequark>
however if you control the whole system you can make it work
<whitequark>
roh: it pulls up one of the lines
<whitequark>
or maybe both. same idea
<roh>
true. still nasty complicated for somesthing that simple
<roh>
ah. ok. like a i2c bus?
<whitequark>
sorta
<wpwrak>
more like high/low speed detection
<whitequark>
the timing's not cool though
<whitequark>
When the host wants to wake the device up after a suspend, it does so by reversing the polarity of the signal on the data lines for at least 20ms. The signal is completed with a low speed end of packet signal.
<whitequark>
It is also possible for a device with its remote wakeup feature set, to initiate a resume itself. It must have been in the idle state for at least 5ms, and must apply the wakeup K condition for between 1 and 15 ms. The host takes over the driving of the resume signal within 1 ms.
<wpwrak>
in idle/suspend, the bus is J, in resume, it's K. see also figure 11-17 on page 333 of the USB 2.0 spec
<wpwrak>
yeah, that one :)
<whitequark>
newer phones (eg SGS2) use an USB-ish protocol
<whitequark>
it's USB2 above physical layer, and on physical they did something to transceivers
<whitequark>
to make them eat less
<whitequark>
I'm not sure what in particular though
<roh>
yeah. dont worry.. in a few years we will use pci-express links anyhow for internal modems
<whitequark>
riiight, let them be bus masters again
<whitequark>
what could go wrong
<wpwrak>
nothing. trust us :)
viric has joined #qi-hardware
* whitequark
. o O ( when was wpwrak recruited by NSA? )
<roh>
whitequark: bus masters? not the issue.. thats what iommu are for
<whitequark>
iommus are still 'high end' even for pcs
<larsc>
whitequark: who do you think sponsors the anelok development
<whitequark>
though I can see how that changes in ~5yrs before we see phones with pcie modems
<roh>
whitequark: youve seen the arduino from intel?