diff mbox series

[2/7] spi: fsi: Fix clock running too fast

Message ID 20200820170228.42053-3-eajames@linux.ibm.com (mailing list archive)
State New, archived
Headers show
Series spi: Fix FSI-attached controller and AT25 drivers | expand

Commit Message

Eddie James Aug. 20, 2020, 5:02 p.m. UTC 
From: Brad Bishop <bradleyb@fuzziesquirrel.com>

Use a clock divider tuned to a 200MHz FSI clock.  Use of the previous
divider at 200MHz results in corrupt data from endpoint devices. Ideally
the clock divider would be calculated from the FSI clock, but that
would require some significant work on the FSI driver.

Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
 drivers/spi/spi-fsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Mark Brown Aug. 20, 2020, 5:12 p.m. UTC | #1 
On Thu, Aug 20, 2020 at 12:02:23PM -0500, Eddie James wrote:
> From: Brad Bishop <bradleyb@fuzziesquirrel.com>
> 
> Use a clock divider tuned to a 200MHz FSI clock.  Use of the previous
> divider at 200MHz results in corrupt data from endpoint devices. Ideally
> the clock divider would be calculated from the FSI clock, but that
> would require some significant work on the FSI driver.

Presumably this divider was chosen for FSI clocks that aren't 200MHz -
how will those be handled?
Eddie James Aug. 20, 2020, 9:06 p.m. UTC | #2 
On 8/20/20 12:12 PM, Mark Brown wrote:
> On Thu, Aug 20, 2020 at 12:02:23PM -0500, Eddie James wrote:
>> From: Brad Bishop <bradleyb@fuzziesquirrel.com>
>>
>> Use a clock divider tuned to a 200MHz FSI clock.  Use of the previous
>> divider at 200MHz results in corrupt data from endpoint devices. Ideally
>> the clock divider would be calculated from the FSI clock, but that
>> would require some significant work on the FSI driver.
> Presumably this divider was chosen for FSI clocks that aren't 200MHz -
> how will those be handled?


They aren't handled at the moment, but 200MHz FSI represents the worst 
case, as it's the maximum. Slower FSI clocks will simply result in 
slower SPI clocks.

Thanks,

Eddie
Joel Stanley Aug. 25, 2020, 7:10 a.m. UTC | #3 
On Thu, 20 Aug 2020 at 21:06, Eddie James <eajames@linux.ibm.com> wrote:
>
>
> On 8/20/20 12:12 PM, Mark Brown wrote:
> > On Thu, Aug 20, 2020 at 12:02:23PM -0500, Eddie James wrote:
> >> From: Brad Bishop <bradleyb@fuzziesquirrel.com>
> >>
> >> Use a clock divider tuned to a 200MHz FSI clock.  Use of the previous
> >> divider at 200MHz results in corrupt data from endpoint devices. Ideally
> >> the clock divider would be calculated from the FSI clock, but that
> >> would require some significant work on the FSI driver.
> > Presumably this divider was chosen for FSI clocks that aren't 200MHz -
> > how will those be handled?
>
>
> They aren't handled at the moment, but 200MHz FSI represents the worst
> case, as it's the maximum. Slower FSI clocks will simply result in
> slower SPI clocks.

That would be a good addition to the commit message, as I had the same
question too.

Cheers,

Joel
diff mbox series

Patch

diff --git a/drivers/spi/spi-fsi.c b/drivers/spi/spi-fsi.c
index 8f64af0140e0..559d0ff981f3 100644
--- a/drivers/spi/spi-fsi.c
+++ b/drivers/spi/spi-fsi.c
@@ -350,7 +350,7 @@  static int fsi_spi_transfer_init(struct fsi_spi *ctx)
 	u64 status = 0ULL;
 	u64 wanted_clock_cfg = SPI_FSI_CLOCK_CFG_ECC_DISABLE |
 		SPI_FSI_CLOCK_CFG_SCK_NO_DEL |
-		FIELD_PREP(SPI_FSI_CLOCK_CFG_SCK_DIV, 4);
+		FIELD_PREP(SPI_FSI_CLOCK_CFG_SCK_DIV, 19);
 
 	end = jiffies + msecs_to_jiffies(SPI_FSI_INIT_TIMEOUT_MS);
 	do {