rodries escribió:Realmente los cambios son simples. Uso el adquireport antiguo si no tengo acceso al puerto y siempre realizo el USB_SetAlternativeInterface y el USBSTORAGE_GET_MAX_LUN
En USB_SetAlternativeInterface comento las lineas if(alternateSetting == 0) return -EINVAL;
Esto lo hago al ver como inicializa windows los usb, ya que los que fabrican los dispositivos muchas veces se encargan que sean compatibles con windows sin mirar si cumplen las especificaciones.
en USBStorage_Init
status = ehci_readl(&ehci->regs->port_status[i]);
if(!(status & 1))
{
ehci_adquire_usb_port(i);
s_printf("adquire port: %i\n",i);
}
status = ehci_readl(&ehci->regs->port_status[i]);
....
int ehci_adquire_usb_port(int port)
{
u32 __iomem *status_reg = &ehci->regs->port_status[port];
u32 status = ehci_readl(status_reg);
//if(!(PORT_CONNECT&status)) return -1; //port not connected
//change owner, port disabled
if(!(status & PORT_OWNER))
status ^= PORT_OWNER;
status &= ~(PORT_PE | PORT_RWC_BITS);
ehci_writel(status, status_reg);
ehci_mdelay(5);
status = ehci_readl(status_reg);
if(status & PORT_OWNER)
status ^= PORT_OWNER;
status &= ~(PORT_PE | PORT_RWC_BITS);
ehci_writel(status, status_reg);
ehci_mdelay(5);
//enable port
ehci_writel( 0x1801,status_reg);
ehci_mdelay(60);
return 1;
}
Hola tío!
Mucho me temo que no deba ser yo quien incluya esos cambios al programa: recuerda que estoy retirado y que en el momento actual, si no vuelvo a programar una línea en mi vida, no se pierde nada
rodries escribió:Otra cosa que he visto al portar tu ultimo driver al wiimc es que hay muchos dispositivos que no funcinan con irq y al final he tenido que revertir cambios y volver al sistema de pooling. Lo que podrías intentar es hacerlo mixto y poder elegir entre irq y pooling, aunque no he tenido tiempo de verlo, ya que el ios58 da soporte usb2 y posiblemente no usemos ningún cios en próximas versiones
Humm, algo no haréis bien. Ten en cuenta que el uso de interrupciones no tiene nada que ver en absoluto con la transferencia de los datos (no es un modo de los que se considera por interrupciones), si no que se limita a reaccionar ante los cambios de estado de dicho puerto... y eso no depende tanto del dispositivo, como del interface USB de la Wii. Los mismos flags se usan cuando trabajas en lo que tu consideras polling (supongo que has equivocado la palabra), con la diferencia de que tu estás intentando tomar el control cada pocos nanosegundos, tocando los cojones al resto de procesos al hacerlo (y seguramente a los timers...) y la interrupción solo toma el control cuando los flags cambian de estado, dejando un periodo de latencia entre interrupciones para que no se bloquee el sistema (es algo intrínseco que se puede ajustar y el motivo de que perdamos algo de velocidad en el driver, por cierto)
El método por interrupciones es irrenunciable y mezclar ambas cosas no tiene sentido, por que en el fondo estrangulamos otros procesos internos que es lo que se trata de evitar con el uso de interrupciones. Así que te tocaría mirar que narices es lo que ocurre que causa esa incompatibilidad aparente, pero no es un problema de interrupciones propiamente dichas y eso te lo aseguro (puede deberse a cualquier otra cosa, incluso fallo mío por ajustar algunos tiempos de timeout o en el procesado de errores, pero no del uso de interrupciones por si mismo, porque realmente, no se hace nada salvo esperar los cambios de los flags, ya sean flags de error o de transferencia completada).
Por cierto, ten cuidado con el número de lectores máximos que lees: en mi driver actual es mucho mas bajo debido a que hay dispositivos que no permiten lecturas mas grandes (dan problemas)
rodries escribió:Aprovecho para hacerte una consulta:
¿ Porqué creas y destruyes el timer de gestión de irq en vez de pararlo y hacerle restart (ehci_int_working_callback_part1 y ehci_int_working_callback_part2 en ehci_interrupt.c) ?
Una respuesta corta podría ser porque así eliminamos el uso de un timer que puede requerir cualquier otra cosa, o el tener que comprobar un timer en desuso de la cola de interrupciones del timer, consumiendo tiempo de reacción (aunque sea mínimo) y que un timer en modo repetición de corta duración, puede saturar la cola asociada a el.
Hay algo que debes entender de como trabajan los timers internamente: el Starlet tiene un único timer por hardware que es el que causa la interrupcíon y que debe ajustarse para tratar de cumplir con los timers por software. Por ejemplo, si yo programo dos timers, uno para activarse a los 100 us y otro a los 125us, en teoría, el timer debería reaccionar a los 100us y luego a los 25us el otro. Además, el timer se deberia ajustar dentro de la interrupción, obteniendo el valor actual (hardware), mirando entre los timers software el valor mas corto para la próxima activación, actualizar la alarma del timer (hardware) con el nuevo valor e incrementando los timers software en cuanto se produzca la siguiente interrupción y mandando mensajes si el tiempo se cumplió. De ahí se puede deducir que si el conteo es demasiado corto, se producen inexactitudes y que no tiene sentido tener timers ahí tocando la moral.
Pero la cosa no acaba aquí: cada timer está asociado a un semáforo, que depende de prioridades entre hilos y por tanto, el simple hecho de que se haya cumplido el tiempo, no significa que inmediatamente recibamos el control, por lo que esta solicitud de activación se almacenaría en la cola que está usando el timer y llegado el caso, podría producir la activación inadecuada del hilo, que desincronizaría todas nuestras respuestas o incluso, un desborde de la cola, si se almacenan muchas solicitudes.
Ahora bien, cuando tu activas un timer, este recibe dos parámetros de tiempo: el primero, es el tiempo que esperará el timer antes de mandar la primera señal (la precisión de tiempo real, dependerá de lo corto que sea ese intervalo y de las dificultades que encuentre ese hilo antes de activarse, como ya he explicado) y el segundo, es el tiempo de repetición indefinida del timer.
Eso significa que si yo especifico en el primer parámetro un tiempo de 10 us y en el segundo, un tiempo de 10 segundos, lo que debería esperar, con suerte, es que a los 10 us la cola recibiera un mensaje y luego, cada 10 segundos, fuera recibiendo mensajes.
Si yo quiero esperar un tiempo de 10 us y luego nada, podría hacerlo así y luego hacer un stop, pues ya tendría que ser chungo el problema para que se rebasara el tiempo que preciso para hacer un stop.
Ahora bien, si luego decido usar la función restart para ajustar un nuevo intervalo de 10 us, existe un problema: que no le estamos diciendo al timer que "cuente" hasta los 10 us y luego se pare, si no que le estamos diciendo que cada 10 us nos envíe un mensaje... ¿y que pasa si admites 8 o 16 mensajes en cola y por alguna razón, no consigues procesarlos?. Pues que tu cola se va a la mierda. ¿y que pasa si por alguna razón, resulta que esa cola está unida a un timer que solo puede recibir UN mensaje, porque si recibe más, produce errores y la cola recibe mas mensajes porque el intervalo es muy corto y no te da tiempo a desactivar el timer antes de la repetición?. Pues que la cagaste
.
Por eso lo mejor es matar el timer y volver a crearlo, porque si solo necesitas la primera cuenta y quieres evitar el efecto "rebote", es como se debería proceder: el tiempo necesario y un tiempo "infinito" para que se vuelva a repetir, que yo suelo dejar en 10 segundos si no recuerdo mal, que es mas que suficiente para mis usos. Eso y que uno sabe que la única manera de que un timer de error al crearse, es que no haya timers libres... y eso solo ocurre si empiezas a acapararlos
.
Y hasta aquí la explicación teórica (si no quedas conforme, tengo otra: porque me sale de los we...
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
, aunque si es verdad que durante el tiempo que espero la interrupción, el timer usa una cuenta larga y en ese caso específico, raro sería una repetición)
Un abrazo
![[ginyo]](/images/smilies/nuevos/guinyo_ani1.gif "guiñando")
![[risita]](/images/smilies/nuevos/sonrisa_ani1.gif "risita")
Also, Hermes said OFFICIALY that the RB store DOES NOT work. However, GH store does work great ![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
![[burla2]](/images/smilies/nuevos/burla_ani1.gif "burla2")
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
solo lo comentaba porque me parecía que los habías confundido y veía la posibilidad de alguna futura mejora en lo que nos ha puesto Josue ![[jaja]](/images/smilies/nuevos2/otrasonrisa.gif "otra sonrisa")
de todas formas por ahora con los cIOS actuales todo funciona a la perfección, si un juego se peta con el 224 con ponerlo en el 222 se soluciona. ![[buuuaaaa]](/images/smilies/nuevos/triste_ani3.gif "a lágrima viva")
) y todo ello para una posible leve mejora, que a lo mejor no viene a cuento.![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
![[babas]](/images/smilies/babas.gif "Babeando")
, aclaro que en realidad no tengo juegos del tipo que necesitan IOS37 (de hecho juego muy poco) como base para funcionar, pero me alegra ver mejoras en uLoader para beneficio de sus usuarios y por ello sin pensarlo haría el gasto para adquirir algún juego como el MHT (que ni me llama tanto 
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
http://gbatemp.net/t243995-hermes-retirement-hope-not 
...demasiado tiempo sin pasar por aquí.