Re: ieee1394 feature needed: overwrite SPLIT_TIMEOUT from userspace

[Kristian HÃgsberg]

On 1/15/07, Philipp Beyer <philipp.beyer@xxxxxxxxxxxxxxxxxxx> wrote:
> Thanks for your input. My post was based on the (wrong) idea that
> the kernel already uses different timeout values per node.
>
> Therefore, having read your answer, I have a different opinion about
> how to solve this now.
>
> About your suggestions:
> Unfortunately sending an early response and using a secondary register
> as indication for completed flash writes doesnt work. In short, the
> device isn't able to process packets while writing to flash and an early
> answer followed by a period of non-responsiveness might lead to problems
> on the windows side.
>
> Also I dont like the idea of having such a big timeout for every bus
> transaction. In case of 'normal' operation the device runs fine with
> a standard timeout value.

I read the thread briefly, so I may be off here, but another solution
is to implement an FCP-style protocol.  That is, instead of trying to
cram a long operation into the SPLIT_TIMEOUT window, just use two
write transactions to device specific address areas: one for the
request from the PC and one for the response from the device.  Or you
could even use a vendor specific FCP frame.

If you use unified transactions (i.e. your devices sends ACK_COMPLETE
when it receives the write) it doesn't even generate more traffic on
the bus.  And since the device will send the response write request
once it has completed programming the flash, it doesn't need to
respond to packets while it is programming.  But even if the write
transactions themselves are split transactions, it is still a low
overheads solution to your problem that avoids messing with
SPLIT_TIMEOUT.

cheers,
Kristian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/