From: Felipe Balbi <balbi@ti.com>
To: Sourav Poddar <sourav.poddar@ti.com>
Cc: balbi@ti.com, broonie@kernel.org,
spi-devel-general@lists.sourceforge.net, grant.likely@linaro.org,
linux-omap@vger.kernel.org, rnayak@ti.com
Subject: Re: [PATCHv6 1/2] drivers: spi: Add qspi flash controller
Date: Mon, 29 Jul 2013 13:20:38 +0300 [thread overview]
Message-ID: <20130729102038.GK23710@radagast> (raw)
In-Reply-To: <51F63FF3.5070304@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2621 bytes --]
Hi,
On Mon, Jul 29, 2013 at 03:42:03PM +0530, Sourav Poddar wrote:
> >>+ frame_length = (m->frame_length<< 3) / spi->bits_per_word;
> >there's another way to optimize this. If you assume bits_per_word to
> >always be power of two you can:
> >
> > frame_length = (m->frame_length<< 3)>> __ffs(spi->bits_per_word);
> >
> >but that would need a comment stating that you're assuming bits_per_word
> >to always be a power of two. Not sure if this is a correct assumption.
> >
> I dont think it will be a correct assumption, since our controller is
> flexible to
> handle anything from 1 to 128 as bits_per_word.
right, but can the framework handle non-power-of-two bits_per_word ?
> >>+ spin_unlock(&qspi->lock);
> >You should, before releasing the lock, mask your IRQs, so that you can
> >get rid of IRQF_ONESHOT. Unmask them before returning from the IRQ
> >thread.
> >
> Sorry, did not get you here?
> I am reading interrupt status register before and clearing them in
> the threaded irq.
you need to mask the IRQs, clear WC and FIRQ in IRQENABLE register...
set them back at the end of the thread handler.
> >>+static int ti_qspi_probe(struct platform_device *pdev)
> >>+{
> >>+ struct ti_qspi *qspi;
> >>+ struct spi_master *master;
> >>+ struct resource *r;
> >>+ struct device_node *np = pdev->dev.of_node;
> >>+ u32 max_freq;
> >>+ int ret = 0, num_cs, irq;
> >>+
> >>+ master = spi_alloc_master(&pdev->dev, sizeof(*qspi));
> >>+ if (!master)
> >>+ return -ENOMEM;
> >>+
> >>+ master->mode_bits = SPI_CPOL | SPI_CPHA;
> >>+
> >>+ master->num_chipselect = 1;
> >again with the num_chipselect = 1 ? IIRC this controller has 4
> >chipselects, just read 24.5.1 on your TRM.
> >
> this is unnecessary. I intended to configure chip selects through
> dt)as done below).
> Will remove.
which brings me to the point of:
Do you review your own code before sending it out ? Doesn't look like...
> >>+ irq = platform_get_irq(pdev, 0);
> >>+ if (irq< 0) {
> >>+ dev_err(&pdev->dev, "no irq resource?\n");
> >>+ return irq;
> >>+ }
> >>+
> >>+ spin_lock_init(&qspi->lock);
> >>+
> >>+ qspi->base = devm_ioremap_resource(&pdev->dev, r);
> >>+ if (IS_ERR(qspi->base)) {
> >>+ ret = PTR_ERR(qspi->base);
> >>+ goto free_master;
> >>+ }
> >>+
> >>+ ret = devm_request_threaded_irq(&pdev->dev, irq, ti_qspi_isr,
> >>+ ti_qspi_threaded_isr, IRQF_NO_SUSPEND | IRQF_ONESHOT,
> >why do you need IRQF_NO_SUSPEND ?
> >
> I should get away with this.
why ? Do you need or do you *not* need it ? And in either case, why ?
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@ti.com>
To: Sourav Poddar <sourav.poddar@ti.com>
Cc: <balbi@ti.com>, <broonie@kernel.org>,
<spi-devel-general@lists.sourceforge.net>,
<grant.likely@linaro.org>, <linux-omap@vger.kernel.org>,
<rnayak@ti.com>
Subject: Re: [PATCHv6 1/2] drivers: spi: Add qspi flash controller
Date: Mon, 29 Jul 2013 13:20:38 +0300 [thread overview]
Message-ID: <20130729102038.GK23710@radagast> (raw)
In-Reply-To: <51F63FF3.5070304@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2621 bytes --]
Hi,
On Mon, Jul 29, 2013 at 03:42:03PM +0530, Sourav Poddar wrote:
> >>+ frame_length = (m->frame_length<< 3) / spi->bits_per_word;
> >there's another way to optimize this. If you assume bits_per_word to
> >always be power of two you can:
> >
> > frame_length = (m->frame_length<< 3)>> __ffs(spi->bits_per_word);
> >
> >but that would need a comment stating that you're assuming bits_per_word
> >to always be a power of two. Not sure if this is a correct assumption.
> >
> I dont think it will be a correct assumption, since our controller is
> flexible to
> handle anything from 1 to 128 as bits_per_word.
right, but can the framework handle non-power-of-two bits_per_word ?
> >>+ spin_unlock(&qspi->lock);
> >You should, before releasing the lock, mask your IRQs, so that you can
> >get rid of IRQF_ONESHOT. Unmask them before returning from the IRQ
> >thread.
> >
> Sorry, did not get you here?
> I am reading interrupt status register before and clearing them in
> the threaded irq.
you need to mask the IRQs, clear WC and FIRQ in IRQENABLE register...
set them back at the end of the thread handler.
> >>+static int ti_qspi_probe(struct platform_device *pdev)
> >>+{
> >>+ struct ti_qspi *qspi;
> >>+ struct spi_master *master;
> >>+ struct resource *r;
> >>+ struct device_node *np = pdev->dev.of_node;
> >>+ u32 max_freq;
> >>+ int ret = 0, num_cs, irq;
> >>+
> >>+ master = spi_alloc_master(&pdev->dev, sizeof(*qspi));
> >>+ if (!master)
> >>+ return -ENOMEM;
> >>+
> >>+ master->mode_bits = SPI_CPOL | SPI_CPHA;
> >>+
> >>+ master->num_chipselect = 1;
> >again with the num_chipselect = 1 ? IIRC this controller has 4
> >chipselects, just read 24.5.1 on your TRM.
> >
> this is unnecessary. I intended to configure chip selects through
> dt)as done below).
> Will remove.
which brings me to the point of:
Do you review your own code before sending it out ? Doesn't look like...
> >>+ irq = platform_get_irq(pdev, 0);
> >>+ if (irq< 0) {
> >>+ dev_err(&pdev->dev, "no irq resource?\n");
> >>+ return irq;
> >>+ }
> >>+
> >>+ spin_lock_init(&qspi->lock);
> >>+
> >>+ qspi->base = devm_ioremap_resource(&pdev->dev, r);
> >>+ if (IS_ERR(qspi->base)) {
> >>+ ret = PTR_ERR(qspi->base);
> >>+ goto free_master;
> >>+ }
> >>+
> >>+ ret = devm_request_threaded_irq(&pdev->dev, irq, ti_qspi_isr,
> >>+ ti_qspi_threaded_isr, IRQF_NO_SUSPEND | IRQF_ONESHOT,
> >why do you need IRQF_NO_SUSPEND ?
> >
> I should get away with this.
why ? Do you need or do you *not* need it ? And in either case, why ?
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2013-07-29 10:20 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-29 7:22 [PATCHv6 0/2] Add ti qspi controller Sourav Poddar
2013-07-29 7:22 ` Sourav Poddar
2013-07-29 7:22 ` [PATCHv6 1/2] drivers: spi: Add qspi flash controller Sourav Poddar
2013-07-29 7:22 ` Sourav Poddar
2013-07-29 9:31 ` Felipe Balbi
2013-07-29 9:31 ` Felipe Balbi
2013-07-29 10:12 ` Sourav Poddar
2013-07-29 10:12 ` Sourav Poddar
2013-07-29 10:20 ` Felipe Balbi [this message]
2013-07-29 10:20 ` Felipe Balbi
2013-07-29 11:04 ` Sourav Poddar
2013-07-29 11:04 ` Sourav Poddar
2013-07-29 11:09 ` Felipe Balbi
2013-07-29 11:09 ` Felipe Balbi
2013-07-29 11:15 ` Sourav Poddar
2013-07-29 11:15 ` Sourav Poddar
2013-07-29 12:35 ` Felipe Balbi
2013-07-29 12:35 ` Felipe Balbi
2013-07-30 7:34 ` Sourav Poddar
2013-07-30 7:34 ` Sourav Poddar
2013-07-30 7:38 ` Felipe Balbi
2013-07-30 7:38 ` Felipe Balbi
2013-07-29 7:22 ` [RFC/PATCH 2/2] driver: spi: Add quad spi read support Sourav Poddar
2013-07-29 7:22 ` Sourav Poddar
2013-07-29 9:32 ` Felipe Balbi
2013-07-29 9:32 ` Felipe Balbi
2013-07-29 9:43 ` Sourav Poddar
2013-07-29 9:43 ` Sourav Poddar
2013-07-29 9:59 ` Felipe Balbi
2013-07-29 9:59 ` Felipe Balbi
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=20130729102038.GK23710@radagast \
--to=balbi@ti.com \
--cc=broonie@kernel.org \
--cc=grant.likely@linaro.org \
--cc=linux-omap@vger.kernel.org \
--cc=rnayak@ti.com \
--cc=sourav.poddar@ti.com \
--cc=spi-devel-general@lists.sourceforge.net \
/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.