On Thursday 10 August 2017 05:35 AM, Rob Herring wrote: > On Tue, Aug 01, 2017 at 10:24:28AM +0530, Vignesh R wrote: >> As per 66AK2G02 TRM[1] SPRUHY8F section 11.15.5.3 Indirect Access >> Controller programming sequence, a delay equal to couple QSPI master >> clock(~5ns) is required after setting CQSPI_REG_INDIRECTWR_START bit and >> writing data to the flash. Add a new compatible to handle the couple of >> cycles of delay required in the indirect write sequence, since this >> delay is specific to TI 66AK2G SoC. >> >> [1]http://www.ti.com/lit/ug/spruhy8f/spruhy8f.pdf >> [...] >> + /* >> + * As per 66AK2G02 TRM SPRUHY8F section 11.15.5.3 Indirect Access >> + * Controller programming sequence, couple of cycles of >> + * QSPI_REF_CLK delay is required for the above bit to >> + * be internally synchronized by the QSPI module. Provide 5 >> + * cycles of delay. >> + */ >> + ndelay(cqspi->wr_delay); >> >> while (remaining > 0) { >> write_bytes = remaining > page_size ? page_size : remaining; >> @@ -1213,6 +1222,9 @@ static int cqspi_probe(struct platform_device *pdev) >> } >> >> cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk); >> + if (of_device_is_compatible(dev->of_node, "ti,k2g-qspi")) >> + cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC, >> + cqspi->master_ref_clk_hz); > > Use the data pointer in the of_device_id table and put the delay value > there. > I thought about this, but for a given SoC, delay value might vary depending on what frequency QSPI master_ref_clk is set to. So hard coding will not help. How about having a flag (CQSPI_NEEDS_WR_DELAY) in data pointer and then using that to determine whether or not to calculate and set delay here? >> >> ret = devm_request_irq(dev, irq, cqspi_irq_handler, 0, >> pdev->name, cqspi); >> @@ -1285,6 +1297,7 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = { >> >> static const struct of_device_id cqspi_dt_ids[] = { >> {.compatible = "cdns,qspi-nor",}, >> + {.compatible = "ti,k2g-qspi",}, >> { /* end of table */ } >> }; >> >> -- >> 2.13.3 >> -- Regards Vignesh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
