Here is an updated version of my patch using memcpy_toio. I also trimmed a bunch of extra debugging that I had added. This version also work fine for me here.
http://webcon.ca/~rhardy/patches/ivtv-0.8.0_svn3507-fix_firmware_loadingV2.patch.bz2 On Wed, 8 Nov 2006, Tyler Trafford wrote: > > The third call to load_fw_direct, was passing data[2] which was in > > theory seemed to be coming out of some decoder mailbox which, given > > the results, can obviously have garbage in it... Hard coding the third > > call too prevents this kind of problem. > > Ah, I was unaware of that- that is a real problem. Agreed :) > >>> v4l-cx2341x-dec.fw firmware (size=262144 bytes;fw->size=262144 bytes) > >>> v4l-cx2341x-init.mpg firmware (size=155648 bytes;fw->size=262144 bytes) > >> > >> Same here with the previous fw->size being returned. It's like there > >> needs to be some locking around the firmware retrieval code or > >> something... > > > > No question there is something foobar with fw->size but the bottom line is > > we can't and really shouldn't be trusting the contents of that memory > > location for determining the ranges for our memcpy/memcpy_toio or > > writel/iowrite32 loop. > > Apparently not. > > > Looking at a larger data set I don't think it is as simple as fw->size > > sometimes returning the previous firmware's fw->size. > > The fact that this could be worked around by adding a delay (and only > seems to effect SMP systems) makes me think it has to do with multiple > firmware_request calls stomping on each other. That sounds as plausible an explanation as any I've heard so far... Regards, Rob -- ---------------------"Happiness is understanding."---------------------- Robert Hardy, B.Eng Computer Systems C.E.O. Webcon Inc. rhardy <at> webcon <dot> ca GPG Key available (613) 276-7327 _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
