Active Topics
-
The N900 is now 15 years old! (7)
to Nokia N900 by Danct12 - 3 days, 21 hrs ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 4 days, 17 hrs ago - more...
| The Following 2 Users Say Thank You to daperl For This Useful Post: | ||
 |
|
2010-05-07
, 18:37
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#772
|
Originally Posted by egoshin
But save for maybe id or vbus monitoring (not pumping since we can't use it) there's no other use for twl3040 in our current use case. Basically, twl3040 should be out of the picture, and we'd need only accesses either SoC registers (via mapped i/o) or isp1707 registers (via ulpi, either using Nokia's musb_ulpi accesor functions or manually writing the SoC registers).
To make TWL4030 configuration working I did some tricks - power registers are protected and you can't change some TWL4030 USB registers while it is sleeping.
Also more importantly and along the lines of what you noticed is that you cannot get to the isp1707 while it is in standby (/lowpower protocol) or entirely shut down. And the twl3040-usb driver uses the vbus change interrupt to decide whether to power the phy on or off (and this does affect the real isp1707 I believe) -- to write or read a single register out of it you need to either have vbus or manually give power and reset the 1707. The latter is what I did to be able to write to the OTG_CTRL registers when setting H via procfs.
Last edited by javispedro; 2010-05-07 at 18:39.
| The Following User Says Thank You to javispedro For This Useful Post: | ||
|
|
2010-05-07
, 18:38
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#773
|
Originally Posted by daperl
I am already using my N810 for comparisons
So, once again, I think it's all about the software. Except this time, let's forget about the Beagleboard, let's make it all about the n800 and why it works.
Of course a way more similar configuration is the Beagleboard -- and the reason execution traces of its driver would be much interesting.
|
|
2010-05-07
, 18:54
|
|
Posts: 1,258 |
Thanked: 672 times |
Joined on Mar 2009
|
#774
|
4030 vbus sysnode flipped to 1 really easily when I was experimenting with charging (for minutes on just remaining voltage in small capacitors while battery charger is trying to charge from it). I wouldn't trust it as a measure that useful vbus is present.
| The Following 2 Users Say Thank You to shadowjk For This Useful Post: | ||
|
|
2010-05-07
, 18:57
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#775
|
Originally Posted by shadowjk
On the current flowchart I've been making in my head of what the driver is doing (usual disclaimer: might be wrong) it uses the twl3040 vbus sense to notify bme which then runs isp1707 manual charger detection. So for anything serious it does a second check; but seemingly uses vbus sense alone for powering on/off the PHY.
4030 vbus sysnode flipped to 1 really easily when I was experimenting with charging (for minutes on just remaining voltage in small capacitors while battery charger is trying to charge from it). I wouldn't trust it as a measure that useful vbus is present.
Last edited by javispedro; 2010-05-07 at 19:00.
| The Following User Says Thank You to javispedro For This Useful Post: | ||
|
|
2010-05-07
, 19:45
|
|
Posts: 306 |
Thanked: 566 times |
Joined on Jan 2010
@ Romania
|
#776
|
@javispedro
behavior you described have sense for detecting high power charger.
when vbus is detected, then by enabling D+ pull up resistor (& disabling precious 15 K resistors) this apply voltage on D+ line and if the voltage is returned on D- line mean high power charger which have D+ and D- shorted by standard
enabling D+ resistor is not made for peripheral mode in this case.
bme interferences are very annoying
Last edited by blue_led; 2010-05-07 at 20:39.
When vbus is detected by twl3040 twl3040-usb fires a sysfs-node changed event (linkstat) which I believe bme is listening to, which then proceeds to read the charger sysfs node thus causing musb_verify_charger to run thus causing DP & DM pull downs to be disabled and strong pull up on DP to be enabled (thus entering gadget/peripheral mode).
when vbus is detected, then by enabling D+ pull up resistor (& disabling precious 15 K resistors) this apply voltage on D+ line and if the voltage is returned on D- line mean high power charger which have D+ and D- shorted by standard
enabling D+ resistor is not made for peripheral mode in this case.
bme interferences are very annoying
Last edited by blue_led; 2010-05-07 at 20:39.
| The Following 4 Users Say Thank You to blue_led For This Useful Post: | ||
|
|
2010-05-07
, 20:52
|
|
Posts: 992 |
Thanked: 995 times |
Joined on Dec 2009
@ California
|
#777
|
Originally Posted by javispedro
OK, I just looked into ways to switch USB subsystem to HOST mode. And I tried to powerup USB stick a little. Looks successful, because N900 USB subsystem feels USB stick attachment.
But save for maybe id or vbus monitoring (not pumping since we can't use it) there's no other use for twl3040 in our current use case. Basically, twl3040 should be out of the picture, and we'd need only accesses either SoC registers (via mapped i/o) or isp1707 registers (via ulpi, either using Nokia's musb_ulpi accesor functions or manually writing the SoC registers).
The real decision about TWL4030 VBUS can be done with multimeter (poisoned to by another USB-USB connector and disassemble it to measure).
Also more importantly and along the lines of what you noticed is that you cannot get to the isp1707 while it is in standby (/lowpower protocol) or entirely shut down.
| The Following 2 Users Say Thank You to egoshin For This Useful Post: | ||
 |
|
2010-05-07
, 21:10
|
|
Posts: 2,222 |
Thanked: 12,651 times |
Joined on Mar 2010
@ SOL 3
|
#778
|
please be very clear about what we are talking about
VBUS *DETECTION* can be done inside TWL4030, ISP1707, and bq24150
VBUS *POWERSUPPLY* can be done by bq24150 ONLY
So no use in "The real decision about TWL4030 VBUS can be done with multimeter", as TWL4030 is missing a capacitor and thus can NOT provide VBUS power
Also refer to previous post of mine regarding i2cset - you can power VBUS for up to 32sec, if you -sigstop BME prior to twiddling with bq24150 (even longer if you issue a watchdog timer clear cmd to bq24150 every 30sec at latest). After some 60sec the system watchdog will reboot your device due to bme stopped, unless you -sigcont it prior to that. But 30sec should be more than enough to make decent tests on whether usb hostmode is working (unless of course when MUSB_HDRC or whatever kernel driver for USB is depending on BME, of course)
/j
Last edited by joerg_rw; 2010-05-07 at 21:23.
VBUS *DETECTION* can be done inside TWL4030, ISP1707, and bq24150
VBUS *POWERSUPPLY* can be done by bq24150 ONLY
So no use in "The real decision about TWL4030 VBUS can be done with multimeter", as TWL4030 is missing a capacitor and thus can NOT provide VBUS power
Also refer to previous post of mine regarding i2cset - you can power VBUS for up to 32sec, if you -sigstop BME prior to twiddling with bq24150 (even longer if you issue a watchdog timer clear cmd to bq24150 every 30sec at latest). After some 60sec the system watchdog will reboot your device due to bme stopped, unless you -sigcont it prior to that. But 30sec should be more than enough to make decent tests on whether usb hostmode is working (unless of course when MUSB_HDRC or whatever kernel driver for USB is depending on BME, of course)
/j
Last edited by joerg_rw; 2010-05-07 at 21:23.
| The Following 5 Users Say Thank You to joerg_rw For This Useful Post: | ||
|
|
2010-05-07
, 21:23
|
|
Posts: 306 |
Thanked: 566 times |
Joined on Jan 2010
@ Romania
|
#779
|
and if we find what bme discuss with system watchdog a simple timer routine can tickle both bq24150 and system watchdog every 30s to leave us alone with our tests.
| The Following 2 Users Say Thank You to blue_led For This Useful Post: | ||
 |
|
2010-05-07
, 21:23
|
|
Posts: 2,427 |
Thanked: 2,986 times |
Joined on Dec 2007
|
#780
|
Originally Posted by javispedro
Cool, then a few more thoughts and I'll get out of the way.
I am already using my N810 for comparisons
What about a binary search type algorithm to try and morph the n8x0 USB kernel/driver code towards the Fremantle code until it breaks usbcontrol and host mode on your n810.
How about those Android kernels that people were porting to the n8x0? I seem to remember those being anywhere from 2.6.29 - 2.6.31. Doesn't plenty of USB stuff work out-of-the-box with those kernels? If so, getting host mode working with your n810 shouldn't be monumental. That code would probably be easier to put into a Fremantle kernel and driver than 2.6.21 code.
Aren't the MeeGo guys already running a 2.6.33 kernel with USB networking. Maybe that USB code has yet to be gifted all the n900 OTG/host disabling stuff. A quick MeeGo compile of usbcontrol and who knows.
Lastly, if a contrast with the n900 would be helpful (or even possible), and if you don't already have it, stskeeps posted some code and notes about BME for the n8x0. It's probably over at the Mer Wiki if needed. Worst case, I could dig it out of my basement if I have to.
__________________
N9: Go white or go home
N9: Go white or go home
| The Following User Says Thank You to daperl For This Useful Post: | ||
 |
| Tags |
| awesomeness in the works, boulevard of broken deals, host, i am the dealbreaker, inspector gadget lies, mobidapter is a scam, nokia fanbois, otg, over 9000, usb, usbcontrol |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 22:12.
Isn't the n800 considered a "dumb" USB device? By "dumb," I mean that the hardware and the software (pre n810 kernel?) of an n800 knows nothing about USB OTG or USB charging.
If the above is true, and USB hardware and software is supposed to be backwards compatibile, I find it hard to believe that the USB chips are gonna try and be too smart. What I mean is, isn't it likely that the isp1707 and/or the TWL4030 are suppose to work in a scenario with two "dumb" USB devices?
Again, if the above is true, the hardware shouldn't care about what role the device it's in is playing. My n800's battery can power a USB music card and a pair of usb speakers at the same time!
So, once again, I think it's all about the software. Except this time, let's forget about the Beagleboard, let's make it all about the n800 and why it works. I realize there are crazy changes between 2.6.21 and 2.6.28, but the USB spec for "dumb" devices hasn't changed at all.
So, I agree with blue_led, let's turn of charger detection and roll back the n900 to the "dumb" USB device that it is. But looking too closely at the Fremantle USB kernel/driver code is muddying the waters, in my opinion. Quite frankly, that might be the last code you want to look at. Or at least do a diff with the 2.6.28 or the 2.6.27 baselines.
N9: Go white or go home