On 1/15/07, Philipp Beyer <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
