Compartir a través de

Problemas comunes de hardware con la implementación de U1 o U2

En este tema se describe el mecanismo LPM para ahorrar energía y se describen varios problemas comunes detectados en el hardware USB 3.0 actual. La certificación USB-IF requiere que los dispositivos, los concentradores y los controladores implementen U1 y U2 correctamente. La certificación tiene como objetivo aplicar ese requisito a través de pruebas de cumplimiento. La pila de controladores USB de Microsoft (incluida con Windows 8) aprovecha al máximo el mecanismo U1 y U2 para lograr el máximo ahorro de energía. Por lo tanto, los problemas como los descritos en este tema se verán con más frecuencia. Estos problemas pueden dar lugar a una experiencia de usuario deficiente y podrían impedir que Windows logre el ahorro de energía ofrecido por la especificación USB 3.0.

Los proveedores de hardware deben tomar medidas para evitar los problemas que se describen en este tema. En el caso del hardware publicado actualmente con problemas, los proveedores deben publicar el firmware actualizado con correcciones lo antes posible y deben trabajar con sus asociados para asegurarse de que las actualizaciones se proporcionan a los clientes.

LPM puede ahorrar energía significativamente y provocar una mayor duración de la batería. Por lo tanto, es imperativo que tanto el software como el hardware admitan LPM en su mayor medida. Sin embargo, algunos de los primeros prototipos de hardware USB 3.0 tienen problemas comunes en la implementación de LPM que pueden dar lugar a una experiencia de usuario final deficiente. El propósito de esta sección es identificar esos problemas.

  • No se admite U1 o U2

    Algunos dispositivos nunca inician transiciones U1 y U2 y siempre rechazan las transiciones iniciadas por el host, aunque no haya transferencias durante mucho tiempo y el efecto de rendimiento de LPM no sea significativo. Esos dispositivos no solo impiden el ahorro de energía para su vínculo, sino que también impiden que los vínculos ascendentes entren U1 o U2.

  • Implementación de paquetes diferida incorrecta

    Como se describe en Aplazamiento de paquetes, después de que un dispositivo haya enviado ERDY, el dispositivo debe mantener el vínculo en U0 hasta que el host envíe una respuesta a ERDY o tERDYTimeout . Algunos dispositivos no pueden enviar ERDY después de recibir una notificación de paquetes diferida. Esto puede provocar una situación problemática en la que una transferencia nunca se completa.

  • Error al enviar Ping.LPFS en U1

    El puerto de EE. UU. del dispositivo debe seguir enviando Ping.LPFS cuando el vínculo está en U1. Algunos dispositivos no pueden hacerlo, lo que hace que el asociado de vínculo suponga que el dispositivo se ha quitado. Esto puede hacer que el vínculo entre en un estado de error y puede provocar que se vuelva a enumerar el dispositivo.

  • Error de transferencia de SET_SEL

    El software envía una transferencia de control SET_SEL para informar al dispositivo sobre las distintas latencias de salida de U1 y U2. Algunos dispositivos se detuvo esa transferencia. Esto puede provocar un error de enumeración o puede provocar que el software no habilite U1 o U2 para el dispositivo.

  • Error de transferencia de SET_FEATURE (U1_ENABLE o U2_ENABLE)

    El software habilita o deshabilita la capacidad del dispositivo para iniciar una transición U1 o U2 mediante el envío de una transferencia de control SET_FEATURE. Algunos dispositivos se detuvo esa transferencia. Esto puede provocar un error de enumeración o el software que no habilita U1 o U2 para el dispositivo.

  • No se admiten temporizadores U1 o U2

    Uno de los problemas más comunes con la implementación de LPM es el error al iniciar la transición de U1 o U2 cuando expira el temporizador. Incluso después de que el software haya programado valores de tiempo de espera U1 o U2 para los puertos DS, algunos concentradores o controladores no inician una transición a U1 o U2 en la expiración del temporizador. Este comportamiento evita el ahorro de energía a través de LPM.

  • Valores de tiempo de espera U1 o U2 codificados de forma rígida

    Algunos controladores host admiten transiciones U1 y U2, pero tienen un valor de tiempo de espera codificado de forma rígida. Antes de que se agote el tiempo de espera, no inician estas transiciones y rechazan las transiciones iniciadas por el asociado de vínculo. Este comportamiento da lugar a oportunidades perdidas para las transiciones U1 y U2 y, por tanto, puede evitar algunos ahorros de energía.

  • Implementación incorrecta del paquete diferido

    Como se describe en Aplazamiento de paquetes, los concentradores son responsables de devolver el encabezado de paquete de bits diferido al host que debe procesar el paquete, similar a una notificación NRDY del dispositivo. Algunos centros no pueden enviar el paquete diferido al host o al dispositivo. Algunos hosts no procesan correctamente el paquete de bits diferido o vuelven a enviar la transferencia cuando el dispositivo envía ERDY en última instancia. Esto conduce a errores de transferencia y comportamiento no confiable.

  • No enviar el puerto ascendente a U2 cuando no hay ningún dispositivo conectado

    Algunos concentradores no inician una transición U1 o U2 para el puerto de EE. UU. cuando no hay ningún dispositivo de bajada conectado. Algunos centros envían el vínculo a U1, pero no se envían a U2 en este escenario. Este problema se ha observado en muchas de las implementaciones de envío actuales del hardware USB 3.0, a partir de la fecha de lanzamiento de este documento. Este comportamiento evita un ahorro óptimo de energía.

  • No realizar la transición del puerto de EE. UU. de U1 a U2

    Algunos centros no pueden realizar la transición del puerto de EE. UU. de U1 a U0 a U2 cuando los puertos DS del concentrador pasan de U1 a U2 o un estado inferior. Esto ocurre si el temporizador de inactividad del puerto DS al que está conectado el concentrador se establece en 0xFF. Este comportamiento evita un ahorro óptimo de energía.

  • Transición de U1/U2 a U3

    Si un puerto DS de un concentrador o controlador está en U1 o U2 y el software inicia una transición U3 en el puerto, el concentrador principal o controlador es responsable de realizar la primera transición del vínculo a U0 y, a continuación, a U3. Algunos concentradores y controladores no controlan ese requisito correctamente. Esto puede hacer que el vínculo escriba un estado de error y puede provocar la nueva enumeración del dispositivo.