Advent Vega kernel source code now available!

[Guest Cass67]

Have go got USB working?

I have just reverted a .config change: https://github.com/D...816230cd6842a8f

The kernel was crashing when try to enable usb gadget using cyanogenmod - but this configuration was working on ventana system.img

In the currect kernel config usb is working just fine for us with cyanogenmod. So you can take our stuff as a reference to get usb working...

Thanks .. ill look to that ... im pulling a new 14r7 incase mine is corrupt in some way but ill test this meantime ...

nope, seems usb does not work, should work going with all the other configs im looking at .. trying now with oldusb stuff included ...

Edited January 27, 2012 by Cass67

[Guest brucelee666]

Cass,

Did you try what Eduardo mention re. usb gadget for adb/mtp/usb ? Seems adam devs used it also ventana boot image.

You have to update 3 things, unpack ventana boot image to see:-

Need to re-create "init.nv_dev_board.usb.rc" for the vega/boot image.

Look at "init.ventana.rc" need to add "import init.nv_dev_board.usb.rc" to appropriate vega/harmony rc file

Look at ventana image "init.rc" and scroll down you will see a number of statements for adb/mtp/usb these need to be duplicated in vega/boot init.rc.

If you added all this and adb/mtp/usb did not work then I guess usb gadget needs some more work.

[Guest Cass67]

Cass,

Did you try what Eduardo mention re. usb gadget for adb/mtp/usb ? Seems adam devs used it also ventana boot image.

You have to update 3 things, unpack ventana boot image to see:-

Need to re-create "init.nv_dev_board.usb.rc" for the vega/boot image.

Look at "init.ventana.rc" need to add "import init.nv_dev_board.usb.rc" to appropriate vega/harmony rc file

Look at ventana image "init.rc" and scroll down you will see a number of statements for adb/mtp/usb these need to be duplicated in vega/boot init.rc.

If you added all this and adb/mtp/usb did not work then I guess usb gadget needs some more work.

Yeah i have all that in place ... even tried changing the id's to match what we set in the usb boardfile .. no go .... .config has been changed to what others have too ... im keeping looking ... it will be something daft...

Cheers

Cass

Edited January 27, 2012 by Cass67

[Guest ejtagle]

Yeah i have all that in place ... even tried changing the id's to match what we set in the usb boardfile .. no go .... .config has been changed to what others have too ... im keeping looking ... it will be something daft...

Cheers

Cass

Problably something in platform data... I will also look at this ... ;)

Regarding buffer lock issues, the problem is reported by gralloc ... gralloc.tegra.so ...

The idea behind looking at debugfs/nvhost is to check how much memory pressure is in the GPU pool... I mean, if we are reaching the maximum possible or not..

Edited January 27, 2012 by ejtagle

[Guest DrMon]

With regards to usb, you might want to take a look at our revised board-adam.c: https://github.com/E...ra/board-adam.c

We've changed up the USB init functions in there to be compatible with the new systems, board-adam-usb.c is in fact no longer used at all.

For the lockups, I'll look at mounting the the debugfs - not sure how to do it, It's new to me!

EDIT: I should add I upped out GPU reserved memory to 256MB to match ventana - still get lock ups.

Edited January 27, 2012 by DrMon

[Guest Cass67]

With regards to usb, you might want to take a look at our revised board-adam.c: https://github.com/E...ra/board-adam.c

We've changed up the USB init functions in there to be compatible with the new systems, board-adam-usb.c is in fact no longer used at all.

For the lockups, I'll look at mounting the the debugfs - not sure how to do it, It's new to me!

EDIT: I should add I upped out GPU reserved memory to 256MB to match ventana - still get lock ups.

I compared those with what we had to the best i could and for the most part what was there looked to be what we had as values .. you seem to be using a ulpi value which we dont .. fails when added too, didnt spend any time adding support for it either as going by the comments its not meant to be there ;) all i could think to was the ordering of some stuff causing issues as you lay things out in a diff structure ...

wrt to debugfs i assume you just cat the files and look to the values ... thats always how ive used /d anyway ...

[Guest ejtagle]

Well... reviewed the USB stuff of shuttle... There is no big difference between Adam and Shuttle. We don't USB OTG as Adam does, that is why we use our custom OTG driver and software to switch modes... But, i found that using the config file i supplied, android USB gadget subsystem was not being compiled in (USB_G_ANDROID must be defined, but it was not!) ... So, attached a new patch version that hopefully will work. I ran out of time today... Tomorrow will try to test it... At least, it compiles :)

To check debugfs

mkdir dbg

mount -t debugfs dbg dbg

cat /dbg/nvhost/ .... There are several interesting files there :)

Cass: You don't need to redownload the nvidia kernel git ... I am still learning git, but, it can reinit of the repo you have by using:

git clean -x -d -f <-erases all the files that are not part of the git repo

git reset --hard <-restores all files to the last valid commit, means to the branch tag status

Then, you can conmute branches by

git checkout origin/rel-14r7

or

git checkout origin/android-nv-tegra2.6.39

And you can list all branches by issuing

git branch -r

I find extremely useful this switching between branches without going online or downloading...

I also tend to use

git diff as a way to check differences between the branch and my modified version of it..

Hope it helps... I am still learning git,,, ;)

rel-14r7-shuttle support-v2.rar

Edited January 27, 2012 by ejtagle

[Guest Cass67]

Well... reviewed the USB stuff of shuttle... There is no big difference between Adam and Shuttle. We don't USB OTG as Adam does, that is why we use our custom OTG driver and software to switch modes... But, i found that using the config file i supplied, android USB gadget subsystem was not being compiled in (USB_G_ANDROID must be defined, but it was not!) ... So, attached a new patch version that hopefully will work. I ran out of time today... Tomorrow will try to test it... At least, it compiles :)

To check debugfs

mkdir dbg

mount -t debugfs dbg dbg

cat /dbg/nvhost/ .... There are several interesting files there :)

Cass: You don't need to redownload the nvidia kernel git ... I am still learning git, but, it can reinit of the repo you have by using:

git clean -x -d -f <-erases all the files that are not part of the git repo

git reset --hard <-restores all files to the last valid commit, means to the branch tag status

Then, you can conmute branches by

git checkout origin/rel-14r7

or

git checkout origin/android-nv-tegra2.6.39

And you can list all branches by issuing

git branch -r

I find extremely useful this switching between branches without going online or downloading...

I also tend to use

git diff as a way to check differences between the branch and my modified version of it..

Hope it helps... I am still learning git,,, ;)

Thanks, compiles and boots it seems but same result wrt to usb in my initial test ... i need to play more on this not much time right now ... I had the USB_G_ANDROID config in place with the last patchset so it was not that to blame ...

Glad your learning git, wont be long now before we see your commits on github eh and not these unruly bundles ;)

Cheers for the git clean command, i always used to just reset hard on this, nice :)

Ill check out the other branch when i have time also if i cant get anywhere with this one ...

Tx

Cass

[Guest DerArtem]

Hi,

I have isolated the freeze problem:

The tps6586x is doing >1000 IRQs per second.

You must remove the line

".irq = INT_EXTERNAL_PMU,"

from

static struct i2c_board_info __initdata ventana_regulators[] = {

{

I2C_BOARD_INFO("tps6586x", 0x34),

.irq = INT_EXTERNAL_PMU,

.platform_data = &tps_platform,

},

};

Then the problem will get solved, but USB gadget will stop working (kernel oops). Maybe a PINMUX change is required to get the tps6586x irq work correctly.

[Guest ejtagle]

Hi,

I have isolated the freeze problem:

The tps6586x is doing >1000 IRQs per second.

You must remove the line

".irq = INT_EXTERNAL_PMU,"

from

static struct i2c_board_info __initdata ventana_regulators[] = {

{

I2C_BOARD_INFO("tps6586x", 0x34),

.irq = INT_EXTERNAL_PMU,

.platform_data = &tps_platform,

},

};

Then the problem will get solved, but USB gadget will stop working (kernel oops). Maybe a PINMUX change is required to get the tps6586x irq work correctly.

DerArtem ... My specialty is , perhaps, ... to be honest, IS electronics (after all, i am an electronic engineer). I wish i had the schematics of the folio100 or the shuttle to help here...

As far as i know, the tps6586x is used as a multioutput programmable voltage regulator. And also as the RTC (realtime clock). This chip has also other features, as for example, it CAN be used as a complete battery management system, including battery charging via USB or via an external power supply. But, as far as i was able to tell, neither Folio nor shuttle uses any of those features... I do suspect that the interrupt line is not routed to the tegra chip, but i can't probe it .. Without schematics, trying to trace the PCB board is nearly impossible... But i know the tps interrupt was not used in the original .32 kernel, so i assume it is not routed. Of course, if you have ANY kind of information regarding this interrupt line being routed to the tegra chip, id really appreciate if you could give us a hint, to try to make it work.

I can't understand why you need that isr enabled to get USB gadget working... Even if the tps could be used to detect VBUS as a means of switchingUSB to gadget mode, as far as i can tell, it is not used,not connected to be used for such purpose. So, i am assuming the gadget problem is another one... not related to the TPS interrupt line itself...

Tegra2 has an specific driver to detect gadget(slave) or host mode. It is called tegra_otg. If the folio has an special 5 pin connector (an USB OTG connector), then you should use this driver instead of the TPS to detect it. And, if you don't have that connector, either you fix the USB port as a slave, you fix it as a host, or you use the modificed tegra_otg driver i wrote for shuttle that allows a software control of the mode...

Please, correct me if my assumptions are worng... I think that the USB problems we are getting on shuttle right now could be related to the ones you are getting ... and i also want to know what is the purpose of enabling the TPS isr, when there that line is not connected... Or it is? (if it is not, then no doubts you will get lots of spurious interrupts...) -- And probably lockups also...

Any info you have access to, could help... I have the complete TPS datasheet, if this canhelp you.. But no schematics neither from folio nor from shuttle itself...

AS far as i can tell, the TPS interrupt is not used by any linux driver to switch between gadget and host mode .... So, perhaps those unwanted parasitic interrupts have as a side effect making gadget/host mode switch work, but, perhaps it is just a secondary effect, and we should be switching using another different method...

TPS658621A1_IC-ON-LINE.CN.rar

Edited January 28, 2012 by ejtagle

[Guest DerArtem]

DerArtem ... My specialty is , perhaps, ... to be honest, IS electronics (after all, i am an electronic engineer). I wish i had the schematics of the folio100 or the shuttle to help here...

As far as i know, the tps6586x is used as a multioutput programmable voltage regulator. And also as the RTC (realtime clock). This chip has also other features, as for example, it CAN be used as a complete battery management system, including battery charging via USB or via an external power supply. But, as far as i was able to tell, neither Folio nor shuttle uses any of those features... I do suspect that the interrupt line is not routed to the tegra chip, but i can't probe it .. Without schematics, trying to trace the PCB board is nearly impossible... But i know the tps interrupt was not used in the original .32 kernel, so i assume it is not routed. Of course, if you have ANY kind of information regarding this interrupt line being routed to the tegra chip, id really appreciate if you could give us a hint, to try to make it work.

I can't understand why you need that isr enabled to get USB gadget working... Even if the tps could be used to detect VBUS as a means of switchingUSB to gadget mode, as far as i can tell, it is not used,not connected to be used for such purpose. So, i am assuming the gadget problem is another one... not related to the TPS interrupt line itself...

Tegra2 has an specific driver to detect gadget(slave) or host mode. It is called tegra_otg. If the folio has an special 5 pin connector (an USB OTG connector), then you should use this driver instead of the TPS to detect it. And, if you don't have that connector, either you fix the USB port as a slave, you fix it as a host, or you use the modificed tegra_otg driver i wrote for shuttle that allows a software control of the mode...

Please, correct me if my assumptions are worng... I think that the USB problems we are getting on shuttle right now could be related to the ones you are getting ... and i also want to know what is the purpose of enabling the TPS isr, when there that line is not connected... Or it is? (if it is not, then no doubts you will get lots of spurious interrupts...) -- And probably lockups also...

Any info you have access to, could help... I have the complete TPS datasheet, if this canhelp you.. But no schematics neither from folio nor from shuttle itself...

AS far as i can tell, the TPS interrupt is not used by any linux driver to switch between gadget and host mode .... So, perhaps those unwanted parasitic interrupts have as a side effect making gadget/host mode switch work, but, perhaps it is just a secondary effect, and we should be switching using another different method...

When enableling the tps6586x then 2 new IRQ's will be registered:

cat /proc/interrupts

118: 54528 0 GIC tps6586x

--> 432: 0 0 tps6586x tps6586x-rtc

-->434: 0 0 tps6586x usb_phy_vbus

When enabeling usb gadget without the tps6586x then the kernel will ops on NULL pointer reference. I guess that it is trying to find "usb_phy_vbus". And are you sure that the tps6586x-rtc is not used?

Update:

I have just compared it with the .32 kernel.

The IRQ 118 is used there. But it is always 0:

118: 0 0 PPI NvOsIrqKern0118

Update 2:

Also

85: 911709 0 GIC tegra-i2c

Generates to many IRQ's. Kenel .32: 85: 381 0 PPI NvOsIrqKern0085

Update 3:

Commenting out:

//.irq = INT_EXTERNAL_PMU,

in power config and

//.vbus_irq = TPS6586X_INT_BASE + TPS6586X_INT_USB_DET,

in the USB config will fix the problem. Usb gadget will keep working.

Regards, Artem

Edited January 28, 2012 by DerArtem

[Guest Cass67]

When enableling the tps6586x then 2 new IRQ's will be registered:

cat /proc/interrupts

118: 54528 0 GIC tps6586x

--> 432: 0 0 tps6586x tps6586x-rtc

-->434: 0 0 tps6586x usb_phy_vbus

When enabeling usb gadget without the tps6586x then the kernel will ops on NULL pointer reference. I guess that it is trying to find "usb_phy_vbus". And are you sure that the tps6586x-rtc is not used?

Update:

I have just compared it with the .32 kernel.

The IRQ 118 is used there. But it is always 0:

118: 0 0 PPI NvOsIrqKern0118

Update 2:

Also

85: 911709 0 GIC tegra-i2c

Generates to many IRQ's. Kenel .32: 85: 381 0 PPI NvOsIrqKern0085

Update 3:

Commenting out:

//.irq = INT_EXTERNAL_PMU,

in power config and

//.vbus_irq = TPS6586X_INT_BASE + TPS6586X_INT_USB_DET,

in the USB config will fix the problem. Usb gadget will keep working.

Regards, Artem

Thanks, though typically ours is way different code structure and this lot is not apparent :)

[Guest ejtagle]

When enableling the tps6586x then 2 new IRQ's will be registered:

cat /proc/interrupts

118: 54528 0 GIC tps6586x

--> 432: 0 0 tps6586x tps6586x-rtc

-->434: 0 0 tps6586x usb_phy_vbus

When enabeling usb gadget without the tps6586x then the kernel will ops on NULL pointer reference. I guess that it is trying to find "usb_phy_vbus". And are you sure that the tps6586x-rtc is not used?

Update:

I have just compared it with the .32 kernel.

The IRQ 118 is used there. But it is always 0:

118: 0 0 PPI NvOsIrqKern0118

Update 2:

Also

85: 911709 0 GIC tegra-i2c

Generates to many IRQ's. Kenel .32: 85: 381 0 PPI NvOsIrqKern0085

Update 3:

Commenting out:

//.irq = INT_EXTERNAL_PMU,

in power config and

//.vbus_irq = TPS6586X_INT_BASE + TPS6586X_INT_USB_DET,

in the USB config will fix the problem. Usb gadget will keep working.

Regards, Artem

I do understand... What was happening here is that the TPS was registering a new interrupt controller, and then, in tegra_usb_phy_setup(), platform data was using that new interrupt controller to register an interrupt handler for the USB VBUS change... You are right... Both lines should go away... :) .. Just as a curiosity, Does the folio support switching the USB port to host, or it only supports USB gadget mode ?

@Cass67: We could use exactly the same config as Folio does on USB, but we would losethe Gadget<-> Host switching... I had problems in .36 when i tried that same config, as the port was fixed into a given mode, and i was unable to switch it... Will try to do it again, and check what happens with the new USB stack... In the meanwhile, the patch against rel14r7 with the older USB stack should work,,,

[Guest Cass67]

I do understand... What was happening here is that the TPS was registering a new interrupt controller, and then, in tegra_usb_phy_setup(), platform data was using that new interrupt controller to register an interrupt handler for the USB VBUS change... You are right... Both lines should go away... :) .. Just as a curiosity, Does the folio support switching the USB port to host, or it only supports USB gadget mode ?

@Cass67: We could use exactly the same config as Folio does on USB, but we would losethe Gadget<-> Host switching... I had problems in .36 when i tried that same config, as the port was fixed into a given mode, and i was unable to switch it... Will try to do it again, and check what happens with the new USB stack... In the meanwhile, the patch against rel14r7 with the older USB stack should work,,,

I removed all the stuff we seemed not to need from the usb board file to get it as close to theirs as possible, but to no joy ... but .. all this may have been for nothing .. i need to start again and retest as i missed an import statement in int init.rc for the new usb userland stuff .. idiot ... ill get back to you on this ...

origin/android-nv-tegra-2.6.39 << framebuffer also seems to display with this kernel when stealing the tegra folder from the 14r7 kernel .. does not compile otherwise ...

EDIT - ok .. still have to work out the usb stuff but wrt the framebuffer problems, black screen etc on our rel14-r7.. if we steal the whole drivers/video/tegra dir from treznorx git . .we get output ... ive not compared the difference yet

https://github.com/t...2.6.39-rel-14r7

Now for usb ...

Edited January 28, 2012 by Cass67

[Guest brucelee666]

Cass/Eduardo,

Can I ask why we are using the "/include/video/tegrafb.h" from what appears to be the 36 kernel and not the one in the rel-14r7 kernel ?

Most of the stuff in the tegrafb.h in Eduardo's patch is now in tegra_dc_ext.h in the rel-14r7 kernel.

Edited January 28, 2012 by brucelee666

[Guest ejtagle]

Cass/Eduardo,

Can I ask why we are using the "/include/video/tegrafb.h" from what appears to be the 36 kernel and not the one in the rel-14r7 kernel ?

Most of the stuff in the tegrafb.h in Eduardo's patch is now in tegra_dc_ext.h in the rel-14r7 kernel.

There is no need to use it with the new libraries. The header itself defines some ioctls that were needed for older versions, and i added support for them in the tegra video subsystem ... But, the added support is optative, it does not need to be there and if we don't use it, then we can use the original header...

I was thinking on how to test the USB stuff ... The latest idea i had was to add a call to emergency_restart() in the shortlonggipio isr, and then boot a working kernel using fastboot.. So we willbe able to recover the kernel log.... I am curious to know why the new USB stack is not working... Or perhaps it is... I will continue investigation on this ...

[Guest Cass67]

There is no need to use it with the new libraries. The header itself defines some ioctls that were needed for older versions, and i added support for them in the tegra video subsystem ... But, the added support is optative, it does not need to be there and if we don't use it, then we can use the original header...

I was thinking on how to test the USB stuff ... The latest idea i had was to add a call to emergency_restart() in the shortlonggipio isr, and then boot a working kernel using fastboot.. So we willbe able to recover the kernel log.... I am curious to know why the new USB stack is not working... Or perhaps it is... I will continue investigation on this ...

Ive reverted all the changes in the usb / otg system to be stock r14r7 and made the board-shuttle-usb.c the same as the Adam / Gtab guys and nothing still outputs ... Only diff is Adam guys have stopped using the board-adam-usb.c and moved those changes into the board-adam.c .. Treznorx has not though and i assume it works for his gtab ....

Suppose ill try the legacy usb now see if i can make that work this time .... failed my last attempt... At this stage id be happy with that :)

edit :- yeah the legacy usb stuff does not work either ... something else must be up .. im giving up for tonight .. resume tomorrow ;)

edit2 - should also add before the legacy usb changes i changed the new usb stuff to match DerArtems .. same results ...

Edited January 29, 2012 by Cass67

[Guest DerArtem]

I do understand... What was happening here is that the TPS was registering a new interrupt controller, and then, in tegra_usb_phy_setup(), platform data was using that new interrupt controller to register an interrupt handler for the USB VBUS change... You are right... Both lines should go away... :) .. Just as a curiosity, Does the folio support switching the USB port to host, or it only supports USB gadget mode

I have no idea if the mini USB port can be used in HOST mode, as I don't have an adapter cable for it.

edit2 - should also add before the legacy usb changes i changed the new usb stuff to match DerArtems .. same results ...

After removing the TPS6586X stuff from the usb config the mini USB port is only working when thn tablet is connected to a PC during boot.

It also work if you connect the PC to the tablet while the tables is in LP0 sleep. - It does not work when you connect it while the tablet in normal operation.

Have you connected the USB port while the tablet was turned off? Have you also used the init.betelgeuse.usb.rc file (it gets included in init.betelgeuse.rc)?

Edited January 29, 2012 by DerArtem

[Guest Cass67]

I have no idea if the mini USB port can be used in HOST mode, as I don't have an adapter cable for it.

After removing the TPS6586X stuff from the usb config the mini USB port is only working when thn tablet is connected to a PC during boot.

It also work if you connect the PC to the tablet while the tables is in LP0 sleep. - It does not work when you connect it while the tablet in normal operation.

Have you connected the USB port while the tablet was turned off? Have you also used the init.betelgeuse.usb.rc file (it gets included in init.betelgeuse.rc)?

You have LP0 ? nice :) how did you manage that ? what revision of tegra you have? i assumed we had a bug that prevented LP0 in th early revision we have A02/3...

I have connected the usb in all manner of states. off/on/crashed/on fire :) no difference ... im using the same usb.rc file as the adam guys, i also edited one of my own to idProducts we had defined .. but i will check your one out too just to be consistent ... im not sure how we get the proper idProduct value now we don't define it in the usb boardfile, we used to in older releases ... i guess checking out your file will show if they default to some value ...

edit :- also .. did you make changes relating to the board.betelgeuse.h for USB

we have different values and im a bit confused as to why

we have

#define SHUTTLE_USB0_VBUS TEGRA_GPIO_PB0

#define SHUTTLE_USB1_RESET TEGRA_GPIO_PV1

and you have

#define BETELGEUSE_USB1_RESET TEGRA_GPIO_PV0

#define BETELGEUSE_USB0_VBUS TEGRA_GPIO_PD0

#define BETELGEUSE_USB2_VBUS TEGRA_GPIO_PD3

The reset values are different, 0 should be reset as far as comments on our code confirm ... Not tried with your values yet .. ill do later if an explination does not appear ...

Cheers

Cass

Edited January 29, 2012 by Cass67

[Guest DerArtem]

You have LP0 ? nice :) how did you manage that ? what revision of tegra you have? i assumed we had a bug that prevented LP0 in th early revision we have A02/3...

I have connected the usb in all manner of states. off/on/crashed/on fire :) no difference ... im using the same usb.rc file as the adam guys, i also edited one of my own to idProducts we had defined .. but i will check your one out too just to be consistent ... im not sure how we get the proper idProduct value now we don't define it in the usb boardfile, we used to in older releases ... i guess checking out your file will show if they default to some value ...

edit :- also .. did you make changes relating to the board.betelgeuse.h for USB

we have different values and im a bit confused as to why

we have

#define SHUTTLE_USB0_VBUS TEGRA_GPIO_PB0

#define SHUTTLE_USB1_RESET TEGRA_GPIO_PV1

and you have

#define BETELGEUSE_USB1_RESET TEGRA_GPIO_PV0

#define BETELGEUSE_USB0_VBUS TEGRA_GPIO_PD0

#define BETELGEUSE_USB2_VBUS TEGRA_GPIO_PD3

The reset values are different, 0 should be reset as far as comments on our code confirm ... Not tried with your values yet .. ill do later if an explination does not appear ...

Cheers

Cass

Yes, LP0 is working just fine for us with the r14 kernel. I have used a new touch screen driver and LP0 suddenly started working. The old touchscreen driver was pretty buggy and crashed the whole I2C bus pretty often....

I have the GPIO USB values from the .32 kernel. I can imagine that you may have to use your own values there. I think they are board specific.

[Guest ejtagle]

You have LP0 ? nice :) how did you manage that ? what revision of tegra you have? i assumed we had a bug that prevented LP0 in th early revision we have A02/3...

I have connected the usb in all manner of states. off/on/crashed/on fire :) no difference ... im using the same usb.rc file as the adam guys, i also edited one of my own to idProducts we had defined .. but i will check your one out too just to be consistent ... im not sure how we get the proper idProduct value now we don't define it in the usb boardfile, we used to in older releases ... i guess checking out your file will show if they default to some value ...

edit :- also .. did you make changes relating to the board.betelgeuse.h for USB

we have different values and im a bit confused as to why

we have

#define SHUTTLE_USB0_VBUS TEGRA_GPIO_PB0

#define SHUTTLE_USB1_RESET TEGRA_GPIO_PV1

and you have

#define BETELGEUSE_USB1_RESET TEGRA_GPIO_PV0

#define BETELGEUSE_USB0_VBUS TEGRA_GPIO_PD0

#define BETELGEUSE_USB2_VBUS TEGRA_GPIO_PD3

The reset values are different, 0 should be reset as far as comments on our code confirm ... Not tried with your values yet .. ill do later if an explination does not appear ...

Cheers

Cass

GPIO values are board specific... The values you see there were taken from the .32 kernel ... :( ..

I am sure the legacy USB code works... I am sure because i-ve been using it to access the tablet ... You know, i configure USB gadget to act as a serial port, and mount a serial console over it... Pretty useful, i'd say... But the new USB gadget code supplied by google requires more configuration, and i still did not figure out how to do the same thing ... It seems to be possible, ,nevertheless... This week i will try to figure out if this is a problem on the kernel, or just an Android config problem... Otherwise, we will be running in circles.... :(

[Guest Cass67]

GPIO values are board specific... The values you see there were taken from the .32 kernel ... :( ..

I am sure the legacy USB code works... I am sure because i-ve been using it to access the tablet ... You know, i configure USB gadget to act as a serial port, and mount a serial console over it... Pretty useful, i'd say... But the new USB gadget code supplied by google requires more configuration, and i still did not figure out how to do the same thing ... It seems to be possible, ,nevertheless... This week i will try to figure out if this is a problem on the kernel, or just an Android config problem... Otherwise, we will be running in circles.... :(

oh yeah i get the gpio is board specific i was just curious as to why we had the reset set to 1 and DerArtem had it set to 0, seems like the value is at odds for the same thing ... we have /* 0= reset */ comments in the .h file

I have used the usb as a serial port before when we were ramping up the .36 kernel but as you say in this .39 i have not been able to make it work, one of the first things i tried to eliminate Android as the culprit ... You can have it work with no android and just a simple ramdisk ? whats the kernel config for that as it does not appear as id expect in my hosts dmesg?

Edited January 29, 2012 by Cass67

[Guest ejtagle]

oh yeah i get the gpio is board specific i was just curious as to why we had the reset set to 1 and DerArtem had it set to 0, seems like the value is at odds for the same thing ... we have /* 0= reset */ comments in the .h file

I have used the usb as a serial port before when we were ramping up the .36 kernel but as you say in this .39 i have not been able to make it work, one of the first things i tried to eliminate Android as the culprit ... You can have it work with no android and just a simple ramdisk ? whats the kernel config for that as it does not appear as id expect in my hosts dmesg?

My busybox ramdisk... Use it with the kernel config i supplied with the rel-14r7 with the legacy USB stack.... ;) -- Works for me :)

And, use as a boot command line:

mem=512M@0M usbcore.old_scheme_first=1 console=tty0 ignore_loglevel

busybox-ramdisk.gz

Edited January 30, 2012 by ejtagle

[Guest ejtagle]

Hey Cass, look at this:

http://pastebin.com/e0SP00J5

This is the kernel log of the rel-14r7 kernel with the new USB stack and the patches to it i supplied. From lines 406 onwards, you see me plugging the tablet (that has its USB port in gadget mode) to the computer, and then unplugging it, and then plugging it again...

The lines

android_work: sent uevent USB_STATE=CONNECTED

android_work: sent uevent USB_STATE=DISCONNECTED

are saying that the new USB stack seems to work, but is requesting some action from userland... It is sending a message through an uevent called USB_STATE, and is expecting userland to enable the configured USB functionality.... This seems not to be happening, that is why we don't get USB gadget functionality working... Or, for some reason, the USB stack is aborting the transaction... I will continue investigation on this ....

[Guest ejtagle]

BTW, I compared treznorx tegra video subsystem with ours in rel-14r7, and they are exactly the same, except for the comments on the global gamma mapping functions. treznorx has the function commented out, but, according to DrMon, and I do believe him, that function, if commented out, makes the framebuffer console work, but makes Android transparency overlays not to work.. So, better keep the tegra video subsystem as the original rel-14r7 is right now., and android won't have problems with it.

I also will try to redo the USB gadget/host mode switching... There must be something very silly going on here ... :o