attached
who knows why I can't get port 4 to go ....
mystery so far.
ron
On 03.06.2008 07:51, ron minnich wrote:
attached
who knows why I can't get port 4 to go ....
mystery so far.
ron
This patch gets usb port 3 on dbe62 working and sets up a dts-based way to map USB EHCI power control registers to power enables pins 1 and 2.
Nice work! Do you plan to add that sort of info to your geode/cs5536 info dumper?
Why doesn't port 4 work? Who knows. That's a problem for another day.
Signed-off-by: Ronald G. Minnich rminnich@gmail.com
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net with one minor cosmetic change (see below).
Index: southbridge/amd/cs5536/cs5536.c
--- southbridge/amd/cs5536/cs5536.c (revision 687) +++ southbridge/amd/cs5536/cs5536.c (working copy) @@ -454,8 +454,34 @@ *(bar + UOCMUX) |= PMUX_HOST;
/* Overcurrent configuration */
printk(BIOS_DEBUG, "UOCCAP is %x\n", *(bar + UOCCAP));if (sb->enable_USBP4_overcurrent) *(bar + UOCCAP) |= sb->enable_USBP4_overcurrent;
/* power control. This is bit USB_PWR_EN2 in the UUCO.* From Jordan: The kernel never sees a header for* this device. It used to provide a OS visible* device, but that was defeatured. There are still* some registers in the block that are useful for the* firmware to setup, but nothing that a kernel level* driver would need to consume.** That said, VSA _does_ provide the header under* device ID PCI_DEVICE_ID_AMD_CS5536_OTG, but it is* hidden when 0xDEADBEEF is written to config space* register 0x7C* (southbridge/amd/cs5536/cs5536.c:492).** If you need to write the port power settings you* can find the resource in the PCI config space and* write to it as usual, just make sure that you do it* before the block gets DEADBEEFed.*/if (sb->pph) {*(bar + UOCCAP) &= ~0xff;*(bar + UOCCAP) |= sb->pph;}printk(BIOS_DEBUG, "UOCCAP is %x\n", *(bar + UOCCAP));}
/* PBz#6466: If the UOC(OTG) device, port 4, is configured as a
Index: southbridge/amd/cs5536/dts
--- southbridge/amd/cs5536/dts (revision 687) +++ southbridge/amd/cs5536/dts (working copy) @@ -37,8 +37,31 @@ enable_ide_nand_flash = "0";
/* Enable USB Port 4 (0:host 1:device). */
- /* This means that the board or whatever would be a "gadget", i.e.
Please merge these two comment blocks (remove termination from the first one, remove beginning from the second one).
* you connect it to a computer and it looks like a storage or camera* or printer.*/enable_USBP4_device = "0";
/* This is a tad confusing, but it's hard to make it easy.
* These are the PPH bits (port power handling) in the* USB Option Capability register. They are 4 2-bit fields* that correspond to the four ports. This chip has two PWR ENABLE* pins, and what you can do is, for each of the four fields,* map which port controls which pin. It is common to map* ports 1&2 to PWR_EN_1, and ports 3&4 to PWR_EN_2.* The two bit fields are as follows:* 00 -- no power ever* 01 -- power control in EHCI will turn on both.* 10 -- power control will turn on EN1* 11 -- power control will turn on EN2* This is all very wiring dependent, and there is a default value,* so we let this default to 0, which to the driver means "do nothing",* but if the mainboard sets it, then it will be set into the UOCCAP.* for reference, DBE62 seems to want xx111010 -- xx because we* can get port 3 to work, but not port 4.*/pph = "0"; /* 0:off, xxxx:overcurrent setting, e.g. 0x3FEA.
- See CS5536 - Data Book (pages 380-381).
*/
Index: mainboard/artecgroup/dbe62/dts
--- mainboard/artecgroup/dbe62/dts (revision 687) +++ mainboard/artecgroup/dbe62/dts (working copy) @@ -52,6 +52,8 @@ com2_address = "0x3f8"; /* Set com2 IRQ to be what is usually COM1 */ com2_irq = "4";
/* USB Port Power Handling setting. */pph = "0xf5";
Regards, Carl-Daniel
On 02/06/08 22:51 -0700, ron minnich wrote:
attached
who knows why I can't get port 4 to go ....
mystery so far.
ron
This patch gets usb port 3 on dbe62 working and sets up a dts-based way to map USB EHCI power control registers to power enables pins 1 and 2.
Why doesn't port 4 work? Who knows. That's a problem for another day.
Are you sure that the enable_USBP4_device = "0" code is working? The port defaults to being off - you have to specifically enable it to either be a host or a device.
Signed-off-by: Ronald G. Minnich rminnich@gmail.com
Index: southbridge/amd/cs5536/cs5536.c
--- southbridge/amd/cs5536/cs5536.c (revision 687) +++ southbridge/amd/cs5536/cs5536.c (working copy) @@ -454,8 +454,34 @@ *(bar + UOCMUX) |= PMUX_HOST;
/* Overcurrent configuration */
printk(BIOS_DEBUG, "UOCCAP is %x\n", *(bar + UOCCAP));/* power control. This is bit USB_PWR_EN2 in the UUCO.* From Jordan: The kernel never sees a header for* this device. It used to provide a OS visible* device, but that was defeatured. There are still* some registers in the block that are useful for the* firmware to setup, but nothing that a kernel level* driver would need to consume.** That said, VSA _does_ provide the header under* device ID PCI_DEVICE_ID_AMD_CS5536_OTG, but it is* hidden when 0xDEADBEEF is written to config space* register 0x7C* (southbridge/amd/cs5536/cs5536.c:492).** If you need to write the port power settings you* can find the resource in the PCI config space and* write to it as usual, just make sure that you do it* before the block gets DEADBEEFed.*/
Please get rid of this - you don't need 20 lines of comment to explain three lines of code.
if (sb->pph) {*(bar + UOCCAP) &= ~0xff;*(bar + UOCCAP) |= sb->pph;}printk(BIOS_DEBUG, "UOCCAP is %x\n", *(bar + UOCCAP));}
/* PBz#6466: If the UOC(OTG) device, port 4, is configured as a
Index: southbridge/amd/cs5536/dts
--- southbridge/amd/cs5536/dts (revision 687) +++ southbridge/amd/cs5536/dts (working copy) @@ -37,8 +37,31 @@ enable_ide_nand_flash = "0";
/* Enable USB Port 4 (0:host 1:device). */
/* This means that the board or whatever would be a "gadget", i.e.
* you connect it to a computer and it looks like a storage or camera* or printer.*/enable_USBP4_device = "0";
/* This is a tad confusing, but it's hard to make it easy.
* These are the PPH bits (port power handling) in the* USB Option Capability register. They are 4 2-bit fields* that correspond to the four ports. This chip has two PWR ENABLE* pins, and what you can do is, for each of the four fields,* map which port controls which pin. It is common to map* ports 1&2 to PWR_EN_1, and ports 3&4 to PWR_EN_2.* The two bit fields are as follows:* 00 -- no power ever* 01 -- power control in EHCI will turn on both.* 10 -- power control will turn on EN1* 11 -- power control will turn on EN2* This is all very wiring dependent, and there is a default value,* so we let this default to 0, which to the driver means "do nothing",* but if the mainboard sets it, then it will be set into the UOCCAP.* for reference, DBE62 seems to want xx111010 -- xx because we* can get port 3 to work, but not port 4.*/pph = "0"; /* 0:off, xxxx:overcurrent setting, e.g. 0x3FEA.
- See CS5536 - Data Book (pages 380-381).
*/
Index: mainboard/artecgroup/dbe62/dts
--- mainboard/artecgroup/dbe62/dts (revision 687) +++ mainboard/artecgroup/dbe62/dts (working copy) @@ -52,6 +52,8 @@ com2_address = "0x3f8"; /* Set com2 IRQ to be what is usually COM1 */ com2_irq = "4";
/* USB Port Power Handling setting. */pph = "0xf5";
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Tue, Jun 3, 2008 at 7:44 AM, Jordan Crouse jordan.crouse@amd.com wrote:
/* power control. This is bit USB_PWR_EN2 in the UUCO.* From Jordan: The kernel never sees a header for* this device. It used to provide a OS visible* device, but that was defeatured. There are still* some registers in the block that are useful for the* firmware to setup, but nothing that a kernel level* driver would need to consume.** That said, VSA _does_ provide the header under* device ID PCI_DEVICE_ID_AMD_CS5536_OTG, but it is* hidden when 0xDEADBEEF is written to config space* register 0x7C* (southbridge/amd/cs5536/cs5536.c:492).** If you need to write the port power settings you* can find the resource in the PCI config space and* write to it as usual, just make sure that you do it* before the block gets DEADBEEFed.*/Please get rid of this - you don't need 20 lines of comment to explain three lines of code.
I want that comment somewhere. This stuff is obvious to knowledgeable amd guys but not as obvious to those of us out here.
thanks
ron
On 03/06/08 07:54 -0700, ron minnich wrote:
On Tue, Jun 3, 2008 at 7:44 AM, Jordan Crouse jordan.crouse@amd.com wrote:
/* power control. This is bit USB_PWR_EN2 in the UUCO.* From Jordan: The kernel never sees a header for* this device. It used to provide a OS visible* device, but that was defeatured. There are still* some registers in the block that are useful for the* firmware to setup, but nothing that a kernel level* driver would need to consume.** That said, VSA _does_ provide the header under* device ID PCI_DEVICE_ID_AMD_CS5536_OTG, but it is* hidden when 0xDEADBEEF is written to config space* register 0x7C* (southbridge/amd/cs5536/cs5536.c:492).** If you need to write the port power settings you* can find the resource in the PCI config space and* write to it as usual, just make sure that you do it* before the block gets DEADBEEFed.*/Please get rid of this - you don't need 20 lines of comment to explain three lines of code.
I want that comment somewhere. This stuff is obvious to knowledgeable amd guys but not as obvious to those of us out here.
I would agree, if any of the comment actually explained what you are doing here. If there needs to be documentation about how DEADBEEF works, then so be it, but this comment is out of place and, IMHO not very well written.
Jordan
try this.
ron
Better. Thanks.
On 03/06/08 08:02 -0700, ron minnich wrote:
try this.
ron
This patch gets usb port 3 on dbe62 working and sets up a dts-based way to map USB EHCI power control registers to power enables pins 1 and 2.
Why doesn't port 4 work? Who knows. That's a problem for another day.
Signed-off-by: Ronald G. Minnich rminnich@gmail.com Index: southbridge/amd/cs5536/cs5536.c =================================================================== --- southbridge/amd/cs5536/cs5536.c (revision 687) +++ southbridge/amd/cs5536/cs5536.c (working copy) @@ -454,8 +454,16 @@ *(bar + UOCMUX) |= PMUX_HOST;
/* Overcurrent configuration */
printk(BIOS_DEBUG, "UOCCAP is %x\n", *(bar + UOCCAP));if (sb->enable_USBP4_overcurrent) *(bar + UOCCAP) |= sb->enable_USBP4_overcurrent;
/* power control. see comment in the dts for these bits */if (sb->pph) {*(bar + UOCCAP) &= ~0xff;*(bar + UOCCAP) |= sb->pph;}printk(BIOS_DEBUG, "UOCCAP is %x\n", *(bar + UOCCAP));}
/* PBz#6466: If the UOC(OTG) device, port 4, is configured as a
@@ -481,7 +489,17 @@ } }
- /* Disable virtual PCI UDC and OTG headers. */
- /* Disable virtual PCI UDC and OTG headers. The kernel never
* sees a header for this device. It used to provide an OS* visible device, but that was defeatured. There are still* some registers in the block that are useful for the firmware* to setup, but nothing that a kernel level driver would need* to consume.** As you can see above, VSA does provide the header under* device ID PCI_DEVICE_ID_AMD_CS5536_OTG, but it is hidden* when 0xDEADBEEF is written to config space register 0x7C.*/Index: southbridge/amd/cs5536/dts
--- southbridge/amd/cs5536/dts (revision 687) +++ southbridge/amd/cs5536/dts (working copy) @@ -36,9 +36,34 @@ /* 0:IDE 1:FLASH, if you are using NAND flash instead of IDE drive. */ enable_ide_nand_flash = "0";
- /* Enable USB Port 4 (0:host 1:device). */
/* Enable USB Port 4 (0:host 1:device).
* This means that the board or whatever would be a "gadget", i.e.* you connect it to a computer and it looks like a storage or camera* or printer.*/enable_USBP4_device = "0";
/* This is a tad confusing, but it's hard to make it easy.
* These are the PPH bits (port power handling) in the* USB Option Capability register. They are 4 2-bit fields* that correspond to the four ports. This chip has two PWR ENABLE* pins, and what you can do is, for each of the four fields,* map which port controls which pin. It is common to map* ports 1&2 to PWR_EN_1, and ports 3&4 to PWR_EN_2.* The two bit fields are as follows:* 00 -- no power ever* 01 -- power control in EHCI will turn on both.* 10 -- power control will turn on EN1* 11 -- power control will turn on EN2* This is all very wiring dependent,* and there is a default hardware value (0xea),* meaning port 4 is EN2 and the rest are EN1.* So we let this default to 0, which to the driver means "do nothing",* but if the mainboard sets it, then it will be set into the UOCCAP.* for reference, DBE62 seems to want xx111010 -- xx because we* can get port 3 to work, but not port 4.*/pph = "0"; /* 0:off, xxxx:overcurrent setting, e.g. 0x3FEA.
- See CS5536 - Data Book (pages 380-381).
*/
Index: mainboard/artecgroup/dbe62/dts
--- mainboard/artecgroup/dbe62/dts (revision 687) +++ mainboard/artecgroup/dbe62/dts (working copy) @@ -52,6 +52,8 @@ com2_address = "0x3f8"; /* Set com2 IRQ to be what is usually COM1 */ com2_irq = "4";
/* USB Port Power Handling setting. */pph = "0xf5";
Committed revision 688.
-
Carl-Daniel Hailfinger -
Jordan Crouse -
ron minnich