linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Pitre <nico@cam.org>
To: Stephen Street <stephen@streetfiresound.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
	dvrabel@arcom.com, David Brownell <david-b@pacbell.net>,
	spi-devel-general@lists.sourceforge.net,
	Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] spi: Updated PXA2xx SSP SPI Driver
Date: Fri, 10 Feb 2006 17:45:41 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0602101732590.5397@localhost.localdomain> (raw)
In-Reply-To: <1139609981.30189.84.camel@ststephen.streetfiresound.com>

On Fri, 10 Feb 2006, Stephen Street wrote:

> On Fri, 2006-02-10 at 12:40 -0500, Nicolas Pitre wrote:
> > [...]
> > 
> > +#define SSP_REG(x) (*((volatile unsigned long *)x))
> > 
> > Don't do that.  Instead, please use:
> > 
> > #define DEFINE_SSP_REG(reg, off) \
> > static inline u32 read_##reg(void *p) { return __raw_readl(p + (off)); \
> > static inline void write_##reg(u32 v, void *p) { __raw_writel(v, p + (off)); }
> > 
> > DEFINE_SSP_REG(SSCR0,	0x00)
> > DEFINE_SSP_REG(SSCR1,	0x04)
> > DEFINE_SSP_REG(SSSR,	0x08)
> > DEFINE_SSP_REG(SSITR,	0x0c)
> > DEFINE_SSP_REG(SSDR,	0x10)
> > DEFINE_SSP_REG(SSTO,	0x28)
> > DEFINE_SSP_REG(SSPSP,	0x2c)
> > 
> Ok,  I'll do this (Andrew made a similar comment). But...
> 
> I modeled my SSP_REG on the contents of include/asm-
> arm/arch_pxa/pxa_reg.h which makes extensive use of __REG defined in
> include/asm-arm/arch_pxa/hardware.h as
> 
> #define __REG(x) (*((volatile u32 *)io_p2v(x)))
> 
> which is effectively my SSP_REG without the io_p2v because I preloaded
> the virtual SSP register addresses in the pxa2xx_spi_probe function.

True. But you should pretend to never have seen that.  This macro is low 
level stuff and if it changes for whatever reason it is better if driver 
code didn't reimplement it. Furthermore the argument to __REG() is 
always a constant not a variable making it a simple absolute address 
that the compiler can use and optimize for pretty effectively.

> For my education:
> 
> Why are __raw_readl and friends better than exploiting the memory map
> I/O nature of the PXA2xx and other SOCs?  

Actually, it will do almost the same as you originally did if you look 
at its definition.  However, because a solution needs to be implemented 
to support multiple ports then using __raw_readl() at the driver level 
is more familiar to other kernel people.

> Especially since something like
> 
> SSP_REG(sscr1) &= ~SSCR1_TIE;
> 
> becomes
> 
> write_SSCR1(read_SSCR1(reg) & ~SSCR_TIE, reg);
> 
> Further what should I do with the DMA register accesses (i.e. DCSR,
> DCMD, etc)?

They are fine already.

In fact, if there was only one SSP port, I'd have asked you to use 
SSPCR0, SSPDR, etc. directly.  But the fact that the driver can handle 
multiple ports makes it rather messy (and the SSP*_P() macros in 
pxa-regs.h are an abomination IMHO).


Nicolas

  reply	other threads:[~2006-02-10 22:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-07  3:06 [PATCH] spi: Add PXA2xx SSP SPI Driver stephen
2006-02-07  4:22 ` [PATCH] pxa2xx_spi, board support for Lubbock David Brownell
2006-02-07 11:50 ` [PATCH] spi: Add PXA2xx SSP SPI Driver David Vrabel
2006-02-07 15:05   ` David Vrabel
2006-02-07 21:27     ` Stephen Street
2006-02-07 21:17   ` Stephen Street
2006-02-10  1:38 ` [PATCH] spi: Updated " Stephen Street
2006-02-10  2:18   ` Andrew Morton
2006-02-10 23:07     ` Stephen Street
2006-02-10 23:49       ` Andrew Morton
2006-02-10 17:40   ` Nicolas Pitre
2006-02-10 22:19     ` Stephen Street
2006-02-10 22:45       ` Nicolas Pitre [this message]
2006-02-10 23:22         ` Stephen Street
2006-02-14  1:35   ` [PATCH] spi: Code Review " Stephen Street

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=Pine.LNX.4.64.0602101732590.5397@localhost.localdomain \
    --to=nico@cam.org \
    --cc=akpm@osdl.org \
    --cc=david-b@pacbell.net \
    --cc=dvrabel@arcom.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=spi-devel-general@lists.sourceforge.net \
    --cc=stephen@streetfiresound.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 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).