Message ID | BYAPR20MB2472717D5AC20E7702329996BCF79@BYAPR20MB2472.namprd20.prod.outlook.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | Allwinner R329 SPI support | expand |
On 4/22/22 10:56 AM, icenowy@outlook.com wrote: > From: Icenowy Zheng <icenowy@aosc.io> > > R329 has two SPI controllers. One of it is quite similar to previous > ones, but with internal clock divider removed; the other added MIPI DBI > Type-C offload based on the first one. > > Add basical support for these controllers. As we're not going to > support the DBI functionality now, just implement the two kinds of > controllers as the same. I'm curious what speeds you were able to use SPI at. On D1, with effectively these same changes, I would always get corrupted data when reading from the onboard SPI NAND on the Nezha board. However, if I enabled the "new mode of sample timing" (bit 2 in GBL_CTL_REG), I got the correct data. Regards, Samuel
在 2022-04-22星期五的 18:59 -0500,Samuel Holland写道: > On 4/22/22 10:56 AM, icenowy@outlook.com wrote: > > From: Icenowy Zheng <icenowy@aosc.io> > > > > R329 has two SPI controllers. One of it is quite similar to > > previous > > ones, but with internal clock divider removed; the other added MIPI > > DBI > > Type-C offload based on the first one. > > > > Add basical support for these controllers. As we're not going to > > support the DBI functionality now, just implement the two kinds of > > controllers as the same. > > I'm curious what speeds you were able to use SPI at. On D1, with > effectively > these same changes, I would always get corrupted data when reading > from the > onboard SPI NAND on the Nezha board. However, if I enabled the "new > mode of > sample timing" (bit 2 in GBL_CTL_REG), I got the correct data. Oh my usage never read from device now, because it's a write-only MIPI DBI panel. > > Regards, > Samuel
在 2022-04-22星期五的 18:59 -0500,Samuel Holland写道: > On 4/22/22 10:56 AM, icenowy@outlook.com wrote: > > From: Icenowy Zheng <icenowy@aosc.io> > > > > R329 has two SPI controllers. One of it is quite similar to > > previous > > ones, but with internal clock divider removed; the other added MIPI > > DBI > > Type-C offload based on the first one. > > > > Add basical support for these controllers. As we're not going to > > support the DBI functionality now, just implement the two kinds of > > controllers as the same. > > I'm curious what speeds you were able to use SPI at. On D1, with > effectively > these same changes, I would always get corrupted data when reading > from the > onboard SPI NAND on the Nezha board. However, if I enabled the "new > mode of > sample timing" (bit 2 in GBL_CTL_REG), I got the correct data. See 7.3.3.10 of R329_User_Manual_v1.0.pdf ? (named SPI sample mode and Run Clock configuration) > > Regards, > Samuel
diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c index fc81afc3a963..c4bd8ea31b43 100644 --- a/drivers/spi/spi-sun6i.c +++ b/drivers/spi/spi-sun6i.c @@ -716,9 +716,21 @@ static const struct sun6i_spi_cfg sun8i_h3_spi_cfg = { .has_clk_ctl = true, }; +static const struct sun6i_spi_cfg sun50i_r329_spi_cfg = { + .fifo_depth = SUN8I_FIFO_DEPTH, +}; + static const struct of_device_id sun6i_spi_match[] = { { .compatible = "allwinner,sun6i-a31-spi", .data = &sun6i_a31_spi_cfg }, { .compatible = "allwinner,sun8i-h3-spi", .data = &sun8i_h3_spi_cfg }, + { + .compatible = "allwinner,sun50i-r329-spi", + .data = &sun50i_r329_spi_cfg + }, + { + .compatible = "allwinner,sun50i-r329-spi-dbi", + .data = &sun50i_r329_spi_cfg + }, {} }; MODULE_DEVICE_TABLE(of, sun6i_spi_match);