From: Vignesh R <vigneshr@ti.com>
To: Marek Vasut <marex@denx.de>,
Graham Moore <grmoore@opensource.altera.com>
Cc: <linux-mtd@lists.infradead.org>, <devicetree@vger.kernel.org>,
Alan Tull <atull@opensource.altera.com>,
Yves Vandervennet <yvanderv@opensource.altera.com>,
Dinh Nguyen <dinguyen@opensource.altera.com>,
Brian Norris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.
Date: Tue, 12 Jan 2016 10:29:11 +0530 [thread overview]
Message-ID: <5694881F.10707@ti.com> (raw)
In-Reply-To: <201601110550.25422.marex@denx.de>
Hi,
On 01/11/2016 10:20 AM, Marek Vasut wrote:
> On Monday, January 11, 2016 at 05:14:17 AM, R, Vignesh wrote:
>> Hi Marek,
>
> Hi!
>
>> On 08/21/2015 02:50 PM, Marek Vasut wrote:
>>> From: Graham Moore <grmoore@opensource.altera.com>
>>>
>>> Add support for the Cadence QSPI controller. This controller is
>>> present in the Altera SoCFPGA SoCs and this driver has been tested
>>> on the Cyclone V SoC.
>>
>> Thanks for the patch.
>> I have a TI EVM with Cadence QSPI controller connected to Spansion
>> flash(s25fl512s), and I gave this series a try. It worked with couple of
>> changes, please see comments inline.
>
> I just posted the latest greatest version I have in tree, could you give it
> a spin please ?
>
Thanks, I will test it soon.
>>> Signed-off-by: Graham Moore <grmoore@opensource.altera.com>
>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>> Cc: Alan Tull <atull@opensource.altera.com>
>>> Cc: Brian Norris <computersforpeace@gmail.com>
>>> Cc: David Woodhouse <dwmw2@infradead.org>
>>> Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
>>> Cc: Graham Moore <grmoore@opensource.altera.com>
>>> Cc: Vikas MANOCHA <vikas.manocha@st.com>
>>> Cc: Yves Vandervennet <yvanderv@opensource.altera.com>
>>> Cc: devicetree@vger.kernel.org
>
> [...]
>
>>> +static irqreturn_t cqspi_irq_handler(int this_irq, void *dev)
>>> +{
>>> + struct cqspi_st *cqspi = dev;
>>> + unsigned int irq_status;
>>> +
>>> + /* Read interrupt status */
>>> + irq_status = readl(cqspi->iobase + CQSPI_REG_IRQSTATUS);
>>> +
>>> + /* Clear interrupt */
>>> + writel(irq_status, cqspi->iobase + CQSPI_REG_IRQSTATUS);
>>> +
>>> + irq_status &= CQSPI_IRQ_MASK_RD | CQSPI_IRQ_MASK_WR;
>>> +
>>> + if (irq_status)
>>> + complete(&cqspi->transfer_complete);
>>> +
>>
>> You seem to signal completion even if the interrupt is
>> CQSPI_REG_IRQ_IND_(WR|RD)_OVERFLOW. Doesn't this lead to data loss on
>> overflow?
>
> That's a good question. The write routine, cqspi_indirect_write_execute(),
> always writes a page and then waits for completion, so the overflow should
> never happen.
>
> What would you suggest to do about write overflow interrupt anyway ? :(
>
My concern was signalling completion on CQSPI_REG_IRQ_IND_WR_OVERFLOW
interrupt which meant data loss.
But, I see you have disabled CQSPI_REG_IRQ_IND_WR_OVERFLOW in v10. This
addresses my concern.
>>> + return IRQ_HANDLED;
>>> +}
>
> [...]
>
>>> +static int cqspi_prep(struct spi_nor *nor, enum spi_nor_ops ops)
>>> +{
>>> + struct cqspi_flash_pdata *f_pdata = nor->priv;
>>> + struct cqspi_st *cqspi = f_pdata->cqspi;
>>> + const unsigned int sclk = f_pdata->clk_rate;
>>> +
>>> + /* Switch chip select. */
>>> + if (cqspi->current_cs != f_pdata->cs) {
>>> + cqspi->current_cs = f_pdata->cs;
>>> + cqspi_switch_cs(nor);
>>> + }
>>> +
>>> + /* Setup baudrate divisor and delays */
>>> + if (cqspi->sclk != sclk) {
>>> + cqspi->sclk = sclk;
>>> + cqspi_controller_disable(cqspi);
>>> + cqspi_config_baudrate_div(cqspi, sclk);
>>> + cqspi_delay(nor, sclk);
>>> + cqspi_readdata_capture(cqspi, 1, f_pdata->read_delay);
>>
>> I see bypass field value is being hard coded to 1. Atleast on TI SoC,
>> bypass=0 when SPI bus frequency is >= 50MHz. Therefore, is it possible
>> to provide a way to configure bypass bit from DT?
>> Or if bypass=0 for >=50MHz on your SoC too then, its better to configure
>> bypass bit based on SPI bus frequency.
>
> You can have multiple SPI peripherals attached to the QSPI block, each running
> at different bus speed, so I think the bypass should be configured based on the
> frequency of the active peripheral, not from OF.
I agree, if the dependency is uniform across SoCs, then bypass should be
configured based on the frequency of the active peripheral.
>
> I don't know exactly what impact configuring this bit has, the socfpga datasheet
> is not very clear about the meaning of this bit, so it'd be better if someone
> from Altera answered this question.
>
Have you tested the driver at SPI bus frequency >50MHz?
>>> + cqspi_controller_enable(cqspi);
>>> + }
>>> + return 0;
>>> +}
>
> [...]
>
[...]
>>> + ret = devm_request_irq(dev, irq, cqspi_irq_handler, 0,
>>> + pdev->name, cqspi);
>>> + if (ret) {
>>> + dev_err(dev, "Cannot request IRQ.\n");
>>> + return ret;
>>> + }
>>> +
>>
>> pm_runtime_enable(), pm_runtime_get_sync() might be needed here as QSPI
>> clocks may not be enabled by default on all platforms.
>
> Can you whip up a bit of code and test it on your platform ? I dont think
> socfpga has runtime PM yet. I'd like to add it into the driver or you can
> send a small patch later, whichever way you prefer.
>
Ok, I can send a patch once the driver is accepted.
>>> + cqspi_wait_idle(cqspi);
>>> + cqspi_controller_init(cqspi);
>>> + cqspi->current_cs = -1;
>>> + cqspi->sclk = 0;
>>> +
>>> + ret = cqspi_setup_flash(cqspi, np);
>>> + if (ret) {
>>> + dev_err(dev, "Cadence QSPI NOR probe failed %d\n", ret);
>>> + cqspi_controller_disable(cqspi);
>>> + }
>>> +
>>> + return ret;
>>> +}
>
> Thanks!
>
--
Regards
Vignesh
WARNING: multiple messages have this Message-ID (diff)
From: Vignesh R <vigneshr-l0cyMroinI0@public.gmane.org>
To: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>,
Graham Moore
<grmoore-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Alan Tull
<atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>,
Yves Vandervennet
<yvanderv-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>,
Dinh Nguyen
<dinguyen-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>,
Brian Norris
<computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Subject: Re: [2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.
Date: Tue, 12 Jan 2016 10:29:11 +0530 [thread overview]
Message-ID: <5694881F.10707@ti.com> (raw)
In-Reply-To: <201601110550.25422.marex-ynQEQJNshbs@public.gmane.org>
Hi,
On 01/11/2016 10:20 AM, Marek Vasut wrote:
> On Monday, January 11, 2016 at 05:14:17 AM, R, Vignesh wrote:
>> Hi Marek,
>
> Hi!
>
>> On 08/21/2015 02:50 PM, Marek Vasut wrote:
>>> From: Graham Moore <grmoore-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
>>>
>>> Add support for the Cadence QSPI controller. This controller is
>>> present in the Altera SoCFPGA SoCs and this driver has been tested
>>> on the Cyclone V SoC.
>>
>> Thanks for the patch.
>> I have a TI EVM with Cadence QSPI controller connected to Spansion
>> flash(s25fl512s), and I gave this series a try. It worked with couple of
>> changes, please see comments inline.
>
> I just posted the latest greatest version I have in tree, could you give it
> a spin please ?
>
Thanks, I will test it soon.
>>> Signed-off-by: Graham Moore <grmoore-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
>>> Signed-off-by: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
>>> Cc: Alan Tull <atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
>>> Cc: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> Cc: David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
>>> Cc: Dinh Nguyen <dinguyen-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
>>> Cc: Graham Moore <grmoore-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
>>> Cc: Vikas MANOCHA <vikas.manocha-qxv4g6HH51o@public.gmane.org>
>>> Cc: Yves Vandervennet <yvanderv-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
>>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>
> [...]
>
>>> +static irqreturn_t cqspi_irq_handler(int this_irq, void *dev)
>>> +{
>>> + struct cqspi_st *cqspi = dev;
>>> + unsigned int irq_status;
>>> +
>>> + /* Read interrupt status */
>>> + irq_status = readl(cqspi->iobase + CQSPI_REG_IRQSTATUS);
>>> +
>>> + /* Clear interrupt */
>>> + writel(irq_status, cqspi->iobase + CQSPI_REG_IRQSTATUS);
>>> +
>>> + irq_status &= CQSPI_IRQ_MASK_RD | CQSPI_IRQ_MASK_WR;
>>> +
>>> + if (irq_status)
>>> + complete(&cqspi->transfer_complete);
>>> +
>>
>> You seem to signal completion even if the interrupt is
>> CQSPI_REG_IRQ_IND_(WR|RD)_OVERFLOW. Doesn't this lead to data loss on
>> overflow?
>
> That's a good question. The write routine, cqspi_indirect_write_execute(),
> always writes a page and then waits for completion, so the overflow should
> never happen.
>
> What would you suggest to do about write overflow interrupt anyway ? :(
>
My concern was signalling completion on CQSPI_REG_IRQ_IND_WR_OVERFLOW
interrupt which meant data loss.
But, I see you have disabled CQSPI_REG_IRQ_IND_WR_OVERFLOW in v10. This
addresses my concern.
>>> + return IRQ_HANDLED;
>>> +}
>
> [...]
>
>>> +static int cqspi_prep(struct spi_nor *nor, enum spi_nor_ops ops)
>>> +{
>>> + struct cqspi_flash_pdata *f_pdata = nor->priv;
>>> + struct cqspi_st *cqspi = f_pdata->cqspi;
>>> + const unsigned int sclk = f_pdata->clk_rate;
>>> +
>>> + /* Switch chip select. */
>>> + if (cqspi->current_cs != f_pdata->cs) {
>>> + cqspi->current_cs = f_pdata->cs;
>>> + cqspi_switch_cs(nor);
>>> + }
>>> +
>>> + /* Setup baudrate divisor and delays */
>>> + if (cqspi->sclk != sclk) {
>>> + cqspi->sclk = sclk;
>>> + cqspi_controller_disable(cqspi);
>>> + cqspi_config_baudrate_div(cqspi, sclk);
>>> + cqspi_delay(nor, sclk);
>>> + cqspi_readdata_capture(cqspi, 1, f_pdata->read_delay);
>>
>> I see bypass field value is being hard coded to 1. Atleast on TI SoC,
>> bypass=0 when SPI bus frequency is >= 50MHz. Therefore, is it possible
>> to provide a way to configure bypass bit from DT?
>> Or if bypass=0 for >=50MHz on your SoC too then, its better to configure
>> bypass bit based on SPI bus frequency.
>
> You can have multiple SPI peripherals attached to the QSPI block, each running
> at different bus speed, so I think the bypass should be configured based on the
> frequency of the active peripheral, not from OF.
I agree, if the dependency is uniform across SoCs, then bypass should be
configured based on the frequency of the active peripheral.
>
> I don't know exactly what impact configuring this bit has, the socfpga datasheet
> is not very clear about the meaning of this bit, so it'd be better if someone
> from Altera answered this question.
>
Have you tested the driver at SPI bus frequency >50MHz?
>>> + cqspi_controller_enable(cqspi);
>>> + }
>>> + return 0;
>>> +}
>
> [...]
>
[...]
>>> + ret = devm_request_irq(dev, irq, cqspi_irq_handler, 0,
>>> + pdev->name, cqspi);
>>> + if (ret) {
>>> + dev_err(dev, "Cannot request IRQ.\n");
>>> + return ret;
>>> + }
>>> +
>>
>> pm_runtime_enable(), pm_runtime_get_sync() might be needed here as QSPI
>> clocks may not be enabled by default on all platforms.
>
> Can you whip up a bit of code and test it on your platform ? I dont think
> socfpga has runtime PM yet. I'd like to add it into the driver or you can
> send a small patch later, whichever way you prefer.
>
Ok, I can send a patch once the driver is accepted.
>>> + cqspi_wait_idle(cqspi);
>>> + cqspi_controller_init(cqspi);
>>> + cqspi->current_cs = -1;
>>> + cqspi->sclk = 0;
>>> +
>>> + ret = cqspi_setup_flash(cqspi, np);
>>> + if (ret) {
>>> + dev_err(dev, "Cadence QSPI NOR probe failed %d\n", ret);
>>> + cqspi_controller_disable(cqspi);
>>> + }
>>> +
>>> + return ret;
>>> +}
>
> Thanks!
>
--
Regards
Vignesh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-01-12 5:00 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-21 9:20 [PATCH V8 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver Marek Vasut
2015-08-21 9:20 ` Marek Vasut
2015-08-21 9:20 ` [PATCH 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller Marek Vasut
2015-08-21 9:20 ` Marek Vasut
2015-08-25 22:09 ` vikas
2015-08-25 22:09 ` vikas
2015-08-26 6:19 ` Marek Vasut
2015-08-26 6:19 ` Marek Vasut
2015-08-26 15:47 ` vikas
2015-08-26 15:47 ` vikas
2015-08-26 16:39 ` Marek Vasut
2015-08-26 16:39 ` Marek Vasut
2015-08-26 18:06 ` Brian Norris
2015-08-26 18:06 ` Brian Norris
2015-08-26 23:05 ` vikas
2015-08-26 23:05 ` vikas
2015-08-31 17:30 ` Graham Moore
2015-08-31 17:30 ` Graham Moore
2015-08-31 22:36 ` Marek Vasut
2015-08-31 22:36 ` Marek Vasut
2015-09-04 23:45 ` vikas
2015-09-04 23:45 ` vikas
2015-09-06 15:16 ` Marek Vasut
2015-09-06 15:16 ` Marek Vasut
2015-09-07 18:56 ` vikas
2015-09-07 18:56 ` vikas
2015-09-07 20:27 ` vikas
2015-09-07 20:27 ` vikas
2015-10-15 14:10 ` Graham Moore
2015-10-15 14:10 ` Graham Moore
2015-10-15 14:27 ` Marek Vasut
2015-10-15 14:27 ` Marek Vasut
2016-01-11 4:14 ` [2/2] " R, Vignesh
2016-01-11 4:14 ` R, Vignesh
2016-01-11 4:50 ` Marek Vasut
2016-01-11 4:50 ` Marek Vasut
2016-01-12 4:59 ` Vignesh R [this message]
2016-01-12 4:59 ` Vignesh R
2016-01-12 13:50 ` Marek Vasut
2016-01-12 13:50 ` Marek Vasut
2015-08-27 17:44 ` [PATCH V8 1/2] mtd: spi-nor: Bindings for Cadence Quad SPI Flash Controller driver vikas
2015-08-27 17:44 ` vikas
2015-08-27 18:12 ` Marek Vasut
2015-08-27 18:12 ` Marek Vasut
2015-08-27 20:18 ` vikas
2015-08-27 20:18 ` vikas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5694881F.10707@ti.com \
--to=vigneshr@ti.com \
--cc=atull@opensource.altera.com \
--cc=computersforpeace@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dinguyen@opensource.altera.com \
--cc=dwmw2@infradead.org \
--cc=grmoore@opensource.altera.com \
--cc=linux-mtd@lists.infradead.org \
--cc=marex@denx.de \
--cc=yvanderv@opensource.altera.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.