On Thu, Aug 09, 2018 at 11:03:11AM +0800, Baolin Wang wrote: > Hi Trent, > > On 9 August 2018 at 02:57, Trent Piepho <tpiepho@xxxxxxxxxx> wrote: > > On Wed, 2018-08-08 at 11:54 +0100, Mark Brown wrote: > >> On Wed, Aug 08, 2018 at 06:35:28PM +0800, Baolin Wang wrote: > >> > On 8 August 2018 at 17:50, Mark Brown <broonie@xxxxxxxxxx> wrote: > >> > > Right, I don't think we added this yet (if we did I can't see > >> > > it). I'd > >> > > add a new field to spi_transfer for this, then other controllers > >> > > with > >> > > the same support can implement it as well and drivers can start > >> > > using > >> > > it too. > >> > OK. So I will name the new filed as 'word_delay', is it OK for you? > >> > >> Sounds good, yes. > > > > Should it be in µs like the existing iter-transfer delay? I think > > perhaps units of cycles of the SPI clock make more sense? > > Since some SPI controllers just want some interval values (neither µs > unit nor cycles unit ) set into hardware, and the hardware will > convert to the correct delay time automatically. So I did not force > 'word_delay' unit as µs or cycle, and just let the slave devices > decide the unit which depends on the SPI hardware requirement. This needs to be defined units in DT, not decided by each controller. The controller capabilities just affect what are valid values (or what the resolution is). Rob
