On Thursday 16 July 2009, Paulraj, Sandeep wrote: > > > Didn't touch: > > * All the stuff in davinci_spi_bufs_prep() which really belongs > > in davinci_spi_setup() ... it's just a slowdown, since the FMT > > register could be written just once. > > [Sandeep] I'll make change and test it across DM355, DM365 and DM6467.
OK. That will matter more when DMA support gets added ... but this is the sort of structural issue that's best fixed early (IMNSHO). > > * The WDELAY and parity stuff in davinci_spi_bufs_prep() which > > doesn't kick in for version 1 controllers (even though they > > support it) and which is handled as *global* options instead > > of per-device ones (controls are in per-device FMT registers): > > (a) set it with other updates to FMT register > > (b) make those per-device policies > > [Sandeep] I'll tell you what the real issue is. IN reality SPI module > on DM355, DM6467, DM355 and DA8xx are all different. You can maybe tell I was looking at dm365 docs for that. ;) Errata are a different story. DM355 seemed to have the worst story there. > IF you a take a close look at the Dm355 SPI module guide > http://focus.ti.com/lit/ug/sprued4b/sprued4b.pdf > > you will notice that it does not have the WDELAY and parity stuff. > > The DM365 IP itself is similar to DM355 so it was decided to use > the version 1 string for DM365 as well. > > There are differences also in the diff pin modes(3,4, 5 pins) > between all the different IPs. I see, then. Comments missing. :) This is the sort of thing which makes me want to put cpu_is_XXX() logic into drivers ... it's a good way to handle "lots of little differences". - Dave _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
