From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751511AbdHJFYp (ORCPT ); Thu, 10 Aug 2017 01:24:45 -0400 Received: from fllnx210.ext.ti.com ([198.47.19.17]:33079 "EHLO fllnx210.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751332AbdHJFYo (ORCPT ); Thu, 10 Aug 2017 01:24:44 -0400 Subject: Re: [PATCH 1/7] mtd: spi-nor: cadence-quadspi: add a delay in write sequence To: Rob Herring CC: Marek Vasut , Cyrille Pitchen , Santosh Shilimkar , "David Woodhouse" , Brian Norris , , , , References: <20170801045434.8733-1-vigneshr@ti.com> <20170801045434.8733-2-vigneshr@ti.com> <20170810000545.hphnihd5ghugfbof@rob-hp-laptop> From: Vignesh R Message-ID: <86dc7599-bf45-504e-2bbd-ef72054d0a6f@ti.com> Date: Thu, 10 Aug 2017 10:54:01 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170810000545.hphnihd5ghugfbof@rob-hp-laptop> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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