We have upcoming ones not related to the E1 interface, so really
it make more sense to not have those in usb_e1.c
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I686916bb2b2cb90e94ac9c595deab19f189fcd49
The init already takes care of both port and also calling
e1_init, so it makes sense to have a usb_e1_poll() that
encapsulate both the actual e1 hardware poll and running
the usb stuff for both port.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Icf81efcdc5c8f13480ba2652bc6e7c1ca226ae4d
Previously we were just doing a hard reset, calling init again.
And to stop, it was a bit harsh as well, just calling init with
0 as argument, not cleaning pending descriptors and such.
Now, the HW is initialized once and there is proper startup and
shutdown procedure, leaving things in the proper state.
Init of e1 hardware (call to e1_init) is also delegated to usb_e1
since it's that module that handles all state changes and config
so it makes sense it handles init too rather than calling it from
fw_app.c
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I639f90ce3488a1a08e87854e74e0586010264f5d
Currently all the users of those function just statically use port 0
only.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I17671be65543f5a2bf3d16ba2b5a5081eb38ebdf
This introduces a number of vendor-specific control requests for
configuration of the icE1usb from the host software.
Closes: OS#4675
Change-Id: I9d28566ba21a2a78def5e4a0ba07ecbc4a583aa9
Also default build to it since very few people would want to build
firmware targetted to the prototypes ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Currently only the icE1usb-proto is supported. Adaptation for the
final production hardware is yet to be done.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Sylvain Munaut
Harald Welte