Handling hardware resource limitiations in HCDs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,
While working on the i.MX21 HCD I have a few questions on how hardware
resource limits should be handled.

The hardware has 32 "ETDs", my driver allocates an ETD for each active
endpoint. That is the ETD is allocated in the urb_enqueue() function IF
there is no URB already equeued for the endpoint and is freed when there
are no more URBs for the endpoint.

If no more ETDs are available can the driver return a failure status for
urb_enqueue() or must it queue locally?
In the former case which status (ENOMEM, ENXIO ??)
In the latter should there be a limit on the queue size?

As isoc transfers use 2 ETDs for double buffering this limits the number
of non-isoc active endpoints to 32 - 2*isoc

Furthermore the hardware has 4K of "data memory" which must be allocated
to transfers.
Non isoc transfers each require 2*maxpacket of data memory.

With no isoc transfers worst case data memory usage (full speed only) 32
* 64 * 2 =  4K => no data memory exhaustion.

When isoc transfers come into play its gets a bit more complicated.
Taking table 5-4 from the USB spec and eliminating the cases that are
impossible for this hardware (32 ETD limit, 2 ETDs/isoc => 16 max
simultaneous). Then calculating memory usage:

Payload      #Transfers   DMEM used    ETDs used    DMEM left    ETDs
left    DMEM/ETD     maxPacket    max64      
128          10           2560         20           1536        
12           128          64           12         
256          5            2560         10           1536        
22           69           34           12         
512          2            2048         4            2048        
28           73           36           16         
1023         1            2046         2            2050        
30           68           34           16      


maxPacket = max packet size for non isoc endpoints if all available ETDs
used
max64 = number of 64 byte endpoints that could be supported concurrently
with the isoc transfers

So this shows the 128byte payload cannot not exhaust memory either but
the others could.

In fact it could be worse because the 4K data memory is shared between
the USB host and USB function modules although there is no gadget driver
code yet.

My current idea is :
1) urb_enqueue() will fail for all transfer types if no ETD is available.
2) urb_enqueue() for isoc transfers will attempt to allocate data memory
immediately (and fail if there isn't enough).
3) urb_enqueue() for non isoc transfers will not allocate data memory.
4) when data memory for non isoc transfers is required and not available
the transfer will be put on a "pending" queue and processed  when memory
becomes available.

Is this reasonable?

Thanks,

Martin


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux