On Sun, Jun 2, 2013 at 11:25 PM, Simon Glass <s...@chromium.org> wrote: > Hi, > > On Sun, Jun 2, 2013 at 10:24 AM, Jagan Teki <jagannadh.t...@gmail.com> > wrote: >> >> On Wed, May 29, 2013 at 11:40 AM, Rajeshwari Shinde >> <rajeshwar...@samsung.com> wrote: >> > A SPI slave may take time to react to a request. For SPI flash devices >> > this time is defined as one bit time, or a whole byte for 'fast read' >> > mode. >> > >> > If the SPI slave is another CPU, then the time it takes to react may >> > vary. It is convenient to allow the slave device to tag the start of >> > the actual reply so that the host can determine when this 'preamble' >> > finishes and the actual message starts. >> > >> > Add a preamble flag to the available SPI flags. If supported by the >> > driver then it will ignore any received bytes before the preamble >> > on each transaction. This ensures that reliable communication with >> > the slave is possible. >> > >> > Signed-off-by: Simon Glass <s...@chromium.org> >> > Signed-off-by: Rajeshwari Shinde <rajeshwar...@samsung.com> >> > --- >> > Changes in V2: >> > - None >> > Changes in V3: >> > - None. >> > Changes in V4: >> > - None. >> > Changes in V5: >> > - In commit message header changed SPI to spi. >> > include/spi.h | 5 +++++ >> > 1 files changed, 5 insertions(+), 0 deletions(-) >> > >> > diff --git a/include/spi.h b/include/spi.h >> > index 3fe2e1e..1638b50 100644 >> > --- a/include/spi.h >> > +++ b/include/spi.h >> > @@ -37,11 +37,16 @@ >> > #define SPI_LSB_FIRST 0x08 /* per-word >> > bits-on-wire */ >> > #define SPI_3WIRE 0x10 /* SI/SO signals >> > shared */ >> > #define SPI_LOOP 0x20 /* loopback mode >> > */ >> > +#define SPI_SLAVE 0x40 /* slave mode */ >> > +#define SPI_PREAMBLE 0x80 /* Skip preamble >> > bytes */ >> > >> > /* SPI transfer flags */ >> > #define SPI_XFER_BEGIN 0x01 /* Assert CS before >> > transfer */ >> > #define SPI_XFER_END 0x02 /* Deassert CS after >> > transfer */ >> > >> > +/* Header byte that marks the start of the message */ >> > +#define SPI_PREAMBLE_END_BYTE 0xec >> >> I think this 0xec is a value of rx_data what does it indicates and >> does this value specific to hw? > > > We have a later change which generalises this using the device tree, but it > is dependent on various other patches and adjusts the generic SPI interface. > If we can get this one in then I'm sure Vadim will supply a new patch for > consideration.
Means this value is specific to exynos is it? -- Thanks, Jagan. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot