>-----Original Message----- >From: [email protected] >[mailto:[email protected]] On Behalf >Of Mike Frysinger >Sent: Wednesday, June 09, 2010 11:57 AM >To: [email protected] >Subject: Re: [U-Boot-devel] GPIO CS support in Blackfin SPI driver > >On Thu, Jun 3, 2010 at 16:19, Mike Frysinger wrote: >> On Wed, Jun 2, 2010 at 22:37, Mike Frysinger wrote: >>> i have the following patch which allows any GPIO to be used >as a CS in >>> the Blackfin SPI driver. the only annoying thing is that >all command >>> line options are now in terms of GPIOs and not SSELs. so doing 'sf >>> probe 1' will probe the spi flash on GPIO 1, not SSEL1. that's the >>> only reason ive held of committing this. any proposals ? >the current >>> linux MAX_CTRL_CS handling is an obnoxious hack, but i dont see any >>> other way of expressing this in u-boot. >> >> thinking about it some more, this would mean we either keep the >> existing SPI CS logic in parallel (like the kernel), but for the >> purposes of u-boot, that sucks because the hardware CS in certain >> modes gains us nothing (we dont support auto dma at all). > >turns out this isnt true for all parts. the BF537 has a few SPI CS >pins on Port J which cannot be driven as GPIOs and can only be driven >via peripheral mode. so we have to retain the parallel functionality. > Yes. For users who have desighed boards whose portj is used as SPI CS, hardware controlled CS is the only choice.
>i'll restore the hardware CS behavior and add what we do in the kernel >(MAX_CTRL_CS cruft). >-mike >_______________________________________________ >U-Boot-devel mailing list >[email protected] >https://blackfin.uclinux.org/mailman/listinfo/u-boot-devel > _______________________________________________ U-Boot-devel mailing list [email protected] https://blackfin.uclinux.org/mailman/listinfo/u-boot-devel
