> -----Original Message----- > From: David Brownell [mailto:davi...@pacbell.net] > Sent: Wednesday, June 03, 2009 6:41 PM > To: Paulraj, Sandeep > Cc: davinci-linux-open-source@linux.davincidsp.com > Subject: Re: [PATCH] DaVinci SPI Support > > Some key problems with this code *still* haven't been fixed. > I've been waiting for those fixes before I try this code... > > Specifically, most of the u32 flags in the following structure > should be removed: [Sandeep] I removed the ones which could be removed using the SPI MODE flags > > On Tuesday 02 June 2009, s-paul...@ti.com wrote: > > +struct davinci_spi_config { > > + /* SPIFMT */ > > + u32 wdelay; > > + u32 odd_parity; > > + u32 parity_enable; > > + u32 wait_enable; > > + u32 timer_disable; > > + /* SPIGCR1 */ > > + u32 clk_internal; > > + /* SPIDAT1 */ > > + u32 cs_hold; > > + /* SPIINTLVL1 */ > > + u32 intr_level; > > + /* Others */ > > + enum spi_pin_op_mode pin_op_modes; > > + u32 poll_mode; > > +}; > > The *correct* way to handle them is to take their settings from > the spi_devie->mode mask ... that's the portable way to do it, drivers > are allowed to rely on those flags (but not soc-specific things > like that struct), and it even saves 31 bits per flag. > > Until this uses spi_device.mode flags, this driver will continue > to get a well deserved NAK. > > I believe I also cc'd you on the patch that adds mode flags to [Sandeep] No you did not but I know you did mention something sbout you adding more flags > make sure the "pin_op_modes" thing isn't needed: SPI_NO_CS to > support that flavor of 3-wire SPI; and SPI_READY to support the > additional "fifth wire" (or fourth, in some cases0 used by the > slave for flow control. [Sandeep] Those will help me get rid of the enum but not the others. Maybe I could put it in the platform data? >
_______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
