From: Paul Mundt <lethal@linux-sh.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Magnus Damm <magnus.damm@gmail.com>,
spi-devel-general@lists.sourceforge.net,
dbrownell@users.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] spi: SuperH MSIOF SPI Master driver
Date: Thu, 26 Nov 2009 15:43:16 +0900 [thread overview]
Message-ID: <20091126064315.GA6580@linux-sh.org> (raw)
In-Reply-To: <20091125121152.4ccf03dc.akpm@linux-foundation.org>
On Wed, Nov 25, 2009 at 12:11:52PM -0800, Andrew Morton wrote:
> On Tue, 24 Nov 2009 21:55:31 +0900
> Magnus Damm <magnus.damm@gmail.com> wrote:
> > +struct sh_msiof_spi_priv {
> > + struct spi_bitbang bitbang; /* must be first for spi_bitbang.c */
>
> Well if that's the case then spi_bitbang.c needs smacking. What causes
> this requirement?
>
spi_bitbang causes this requirement by being lazy with regards to
private data stashing. Both the drivers and the bitbang code use
spi_master_get_devdata() for getting their private data, which wraps
in to a dev_get_drvdata().
This needs to be reworked so that struct spi_master has its own private
data pointer which helper code like spi_bitbang can use, while freeing up
the struct device private data pointer so it can be freely used by
drivers as normal.
This is the same sort of private data through casting whimsy that the
framebuffer drivers used to employ, only fortunately that behaviour never
made it out of 2.3.x kernels -- until now!
> > + void __iomem *mapbase;
> > + struct clk *clk;
> > + struct platform_device *pdev;
> > + struct sh_msiof_spi_info *info;
> > + struct completion done;
> > + unsigned long flags;
> > + int tx_fifo_size;
> > + int rx_fifo_size;
> > +};
> > +
> >
> > ...
> >
> > +static void sh_msiof_modify_ctr_wait(struct sh_msiof_spi_priv *p,
> > + unsigned long clr, unsigned long set)
> > +{
> > + unsigned long mask = clr | set;
> > + unsigned long data;
> > +
> > + data = sh_msiof_read(p, CTR);
> > + data &= ~clr;
> > + data |= set;
> > + sh_msiof_write(p, CTR, data);
> > +
> > + while ((sh_msiof_read(p, CTR) & mask) != set)
> > + ;
>
> hm, confidence. No timeout needed here?
>
This definitely needs a timeout, nothing involving SPI inspires
confidence. A cpu_relax() to prevent the compiler from optimizing the
loop out would help, too.
next prev parent reply other threads:[~2009-11-26 6:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-24 12:55 [PATCH] spi: SuperH MSIOF SPI Master driver Magnus Damm
2009-11-25 20:11 ` Andrew Morton
2009-11-26 6:37 ` Magnus Damm
2009-11-26 6:43 ` Paul Mundt [this message]
[not found] ` <20091126064315.GA6580-M7jkjyW5wf5g9hUCZPvPmw@public.gmane.org>
2009-11-26 7:07 ` Andrew Morton
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=20091126064315.GA6580@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=akpm@linux-foundation.org \
--cc=dbrownell@users.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=magnus.damm@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).