> On 04.01.2016, at 14:51, Stephan Olbrich <stephanolbrich@xxxxxx> wrote: > > According to the spi documentation [1]: "CPHA indicates the clock phase used > to sample data; CPHA=0 says sample on the leading edge, CPHA=1 means the > trailing edge." > Which is from my understanding different from what the BMC2835 ARM Peripherals > [2] says for BCM2835_AUX_SPI_CNTL0_CPHA_IN: > "If 1 data is clocked in on the rising edge of the SPI clock > If 0 data is clocked in on the falling edge of the SPI clock" > > I would expect the bits to be set dependant on the clock polarity (CPOL). I am only having “typical” devices with do Mode 0,0 or 1,1 for which it works. Please come up with the “correct” logic for this to be set up correctly and create the corresponding patch, as I do not have a corresponding device for testing. > > The other issue I have, is that the chip select is set before the clock > polarity and the polarity is reset and set again between each transfers of a > message. If CPOL is set to 1 this leads to additional rising and falling edges > of the clock while chip select is active, where no data is sampled. > This is something I have seen before with the main spi HW. We may need to port the same thing there. The corresponding patch for spi-bcm2835.c is this: acace73df2c1913a526c1b41e4741a4a6704c863 So we may need to move the corresponding logic in the same manner. But this may be a more common problem when using GPIO-CS which may need to get addressed at the spi-core level to avoid such complications in other/future drivers - or it needs to be “well documented” and may require a different “hook”, as the use of prepare_message may not be 100% correct... Martin -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html