>>* when should the mapping table be rebuilt ?
>> START_STOP time & ALLOW_MEDIUM_REMOVAL time aren't quite suitable...
>> Or ist there just an easy mount option which forces READ_CAPACITY to
>> always be called ?
>
>Dunno... This is probably related to the "mount/umount/mount" problem in
>my driver. Something else to investigate.
Let me know if you find something..
>>* Creating the mapping table currently takes 17 sek. for a 64 MB card
>>(4096 blocks) with the carry reader (two bulk urb's per block). Why on
>>earth is this so slow ? scheduling problem or is the device just so slow ?
>> 17/(4096*2) == 20,7mSek ?= 2*10mSek schedules ???
>
>That's pretty slow... The SDDR reads the whole thing in one shot (32MB
>card under one second). Couldn't your driver do the same, doing a
>read_redundancy for more than one block?
And it then returns 2048*16 -> 32K bulk data in one go ? Of course the
redundacy infos of each page within one block are supposed to be the same,
but what does the SDDR return if not ? Check comment in
ssfdc_mgr.c/ssfdc_build_mapping() near if( blockstat == SSFDCPB_BAD ).
Carry's command-set can't. It's also seems limited to 4K per bulk transfer.
Hm. Then we have to change ssfdc_build_mapping() to alloc buffer big enough
for all redundancy infos, and then call a new read_redundancy() which isn't
block-limited.
At the moment I have to do following for the redundancy each block:
* submit command (request redundancy for block x) as bulk URB (8 bytes)
* Wait for it to complete (usb_stor_bulk_msg)
* submit read from epx as bulk URB (waiting for the 16 bytes)
* Wait for the read to complete (again usb_stor_bulk_msg)
Now what i could do, which would possibly save a little latency:
* submit command bulk-urb, with _cmd_sent_callback()
* submit read-data bulk-urb, with _data_recv_callback()
then in
_cmd_sent_callback()
{
if( ! transfer_ok() )
cancel_the_other_read_data_urb();
wake_up_somebody();
}
Would this work ?? I mean: is the other urb already on the wire during the
callback, or can it still be cancelled in case of failure ?
The other question ofcourse is: will this give us a noticeable speedup ?
If yes, one should possibly implement this in
transport.c/usb_stor_Bulk_transport() and thus speed up all
plain-Bulk-stype devices ???
Would possibly also help devices like the Datafab (Custon but plain bulk
interface).
(Note: this could be a problem of the way USBSnoop displays URB', but under
Win98 they seem to send both bulk URB's async)
>What do you do when you want to read 2 sectors of data only? It looks like
>you'd call read_raw(.....,1024) which would read one sector, 8 bytes of
>redundancy, and then a partial sector?
The you use the read_data_func(..,..,1024), not the read_raw_func().
The current implementation of ssfdc_read_data() does just this, including
the translation on 256 -> 512 byte sectors.
I can possibly lay my hands on a 2MB devcice soon, so i can test the
translation.
------
Added following to ssfdc_mgr.h:
#define SSFDCDA_HAS_READ_ALL_REDUNDANCYS 0x0001
#define SSFDCDA_HAS_COPY_PAGE 0x0002
#define SSFDCDA_HAS_WRITE_AND_ERASE 0x0004
typedef struct ssfdc_card_info {
....
// Which functions does the decice support.
int device_attributes;
...
int (*read_all_redundancy_func)(struct ssfdc_card_info
*ssfdci,int blocks,char *data,int totalsize);
}
What should the (*write_and_erase_func)( ... ) look like ?
-
sda
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
