On Mon, 2010-11-08 at 23:03, Tormod Volden wrote: > On Mon, Nov 8, 2010 at 12:21 PM, Stefan Schmidt wrote: > >> Hopefully my previous patch makes this default transfer size > >> irrelevant in almost all cases :) > >> > >> Anyway, 1024 is a safer choice than 4096 which the previous > >> logic would provide on most (Linux) boxen. > > > > Why do you think that 1024 is more safe here. I'm not really against this > > patch > > and my testing showed that it breaks nothing for me but I wonder what it > > should > > help. > > As hinted in the FIXME below, the DFU standard says the effective > transfer size can be chosen from bMaxPacketSIze0 (often 64) up to the > real wTransferSize in the device. If we do not know the real value of > wTransferSize, going lower can only be safer.
And potential slower. :) I agree that it is not really good to set the value to high. I just did another test with this patch applied and did not spot any slowdown though :) Should be fine to go in. > I would guess that among > the broken devices where we can not read out wTransferSize, some have > little RAM and hence a small receive buffer. But how low should we go? > At least 1k should be better than 4k for these reasons. And it matches > the flash page size for many devices, if that is a factor. When I > first saw the "page_size" in the code I thought it referred to this, I > do not know if that was the intention at some point. Flash page size is a good point here I haven't thought to much about. Lets get this in. > But again, I hope my previous patch will squeeze the real > wTransferSize out of most devices. > > > > >> - if (transfer_size > page_size) > >> - transfer_size = page_size; > >> + /* FIXME: Ensure bMaxPacketSize0 <= transfer_size <= wTransferSize */ > > > > I was hoping we could reduce the FIXMEs instead adding new ones. :) > > We will eventually :) But for now it is better to have it documented > in the code than in my private to-do list. OK, leave it. Care to also add oit to the project todo list in the git repo? regards Stefan Schmidt _______________________________________________ devel mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/devel
