On Wed, Mar 02, 2016 at 07:48:55AM +0100, fixed-term.Oleksij.Rempel wrote:
> On 02.03.2016 03:46, Mark Brown wrote:
> > On Tue, Mar 01, 2016 at 03:43:15PM +0100, Oleksij Rempel wrote:
> > In the case above this looks like a normal interrupt from a device, I'm
> > not clear what is different here or why this is in the core?
> At least our HW use tree different signals for flow control. One of it
> is Request Signal.
That's still an interrupt, just on a different line to the main
interrupt.
> >> Flow control: ACK End of Data
> >> Master CS |______________________/2------|
> >> Slave FC |________________________/3----|
> >> DATA |__________________/1----------|
> > Why would anything care about this case and why is it part of the SPI
> > protocol rather than something that the device driver would do?
> This case covers real bugs and in our case we need to detect if master
> or slave stalls under one second. If communication problem is detected,
> some of recovery scenarios is initiated. Like i said, this protocol is
> used for automotive industry.
That doesn't answer the second part of my question. This doesn't seem
to be something that's anything to do with SPI, it's just your device
signalling things out of band.
> Please see two attached screen shots of Master and Slave initiated
> transfers.
Those tell me nothing.
> > Atomic operations are very hard to use safely, you need to really spell
> > out what you think this is doing from a synchronization point of view
> > and why it's safe.
> I'm trying to detect if we are on Master or Slave initiated transfer,
> which was detected by spi_fc_rq. Normally there should be no other
> interrupts on FC line and active_rq should not be changed until this
> transfer was processed. The "if (!spi_fc_equal_cs(spi))" check is in
> case my assumption is wrong or there is some HW issue. Do you have other
> suggestions?
Among other things it really needs to be crystal clear how this update
gets propagated to all CPUs in the system with no race conditions.
> >> + if (spi->mode | SPI_FC_REQUEST &&
> >> + !spi->cs_enabled && fc_enabled) {
> >> + atomic_set(&spi->active_rq, 1);
> >> + if (spi->request_cb)
> >> + spi->request_cb(spi);
> > This logic is all too complicated for me to follow. Why are we oring
> > things with spi->mode?
> I'm trying to checking here if fallowing case is actually expected by
> slave device. Other suggestions?
In what way are we checking what? The code is incomprehensible.
Again, you're ignoring my specific question about the or.
> > We can't support things only for DT, we need a way for things to be used
> > on other systemms.
> I have nothing against it, but i even do not have other HW to test if my
> assumptions are correct. Would you accept untested code? :)
In general the way we do DT code is that the DT parses into some data
structure and then we work with that data structure. This means that
everyone's code path is tested.
Attachment:
signature.asc
Description: PGP signature
