From: Stefan Roese <sr@denx.de>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Peter Korsgaard <jacmet@sunsite.dk>,
Andrei Konovalov <akonovalov@ru.mvista.com>,
Rick Moleres <Rick.Moleres@xilinx.com>,
linuxppc-embedded@ozlabs.org
Subject: Re: [RFC] Xilinx SystemACE device driver
Date: Mon, 16 Apr 2007 07:28:15 +0200 [thread overview]
Message-ID: <200704160728.16608.sr@denx.de> (raw)
In-Reply-To: <1176600194262-git-send-email-grant.likely@secretlab.ca>
Hi Grant,
On Sunday 15 April 2007 03:23, Grant Likely wrote:
> Add support for block device access to the Xilinx SystemACE Compact
> flash interface
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> I think this driver is in pretty good shape. I've got a few things to
> clean up a bit. Specifically, I'm still working on error handling and
> making sure that the state machine is sane at all times.
I tested the driver on my system (Katmai 440SPe). Both CF's work correctly
regarding reading and writing. No problems so far.
> I would appreciate any review/comments. One area where I am undecided is
> the format of the state machine. The current code uses one big function
> with a large switch() statment for each state. I'm considering breaking
> this up into a seperate function for each state, and adding a static
> state table with pointers to each state function.
I have no real preference here. I don't mind if the code stays in this large
switch statement. It's not that much code.
Two small issues though:
> +config XILINX_SYSACE
> + tristate "Xilinx SystemACE support"
> + depends on XILINX_VIRTEX
> + help
> + Include support for the Xilinx SystemACE CompactFlash interface
Please remove the XILINX_VIRTEX dependency here. It makes it impossible to use
the driver on my 440SPe system.
> +/* register access macros */
> +#if 1 /* Little endian 16-bit regs */
> +#define ace_reg_read8(ace, reg) in_8(ace->baseaddr + reg)
> +#define ace_reg_read16(ace, reg) in_le16(ace->baseaddr + reg)
> +#define ace_reg_readdata(ace, reg) in_be16(ace->baseaddr + reg)
> +#define ace_reg_read32(ace, reg) ((in_le16(ace->baseaddr + reg+2) << 16) |
> \ + (in_le16(ace->baseaddr + reg)))
> +#define ace_reg_write16(ace, reg, val) out_le16(ace->baseaddr + reg, val)
> +#define ace_reg_writedata(ace, reg, val) out_be16(ace->baseaddr + reg,
> val) +#define ace_reg_write32(ace, reg, val) { \
> + out_le16(ace->baseaddr + reg+2, (val) >> 16); \
> + out_le16(ace->baseaddr + reg, val); \
> + }
> +#else /* Big endian 16-bit regs */
> +#define ace_reg_read8(ace, reg) in_8(ace->baseaddr + reg)
> +#define ace_reg_read16(ace, reg) in_be16(ace->baseaddr + reg)
> +#define ace_reg_readdata(ace, reg) in_le16(ace->baseaddr + reg)
> +#define ace_reg_read32(ace, reg) ((in_be16(ace->baseaddr + reg+2) << 16) |
> \ + (in_be16(ace->baseaddr + reg)))
> +#define ace_reg_write16(ace, reg, val) out_be16(ace->baseaddr + reg, val)
> +#define ace_reg_writedata(ace, reg, val) out_le16(ace->baseaddr + reg,
> val) +#define ace_reg_write32(ace, reg, val) { \
> + out_be16(ace->baseaddr + reg+2, (val) >> 16); \
> + out_be16(ace->baseaddr + reg, val); \
> + }
> +#endif
We should make the endianess selectable (I need big endian). You talked about
autodetecting the endianess once, but that would add extra code on every
register access. So I suggest to just add a configuration option for the
endianess selection.
> I feel this driver is pretty close to done, and I'd like to get it into
> mainline for the 2.6.22 timeframe.
Yes, please.
Best regards,
Stefan
next prev parent reply other threads:[~2007-04-16 5:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-15 1:23 [RFC] Xilinx SystemACE device driver Grant Likely
2007-04-16 5:28 ` Stefan Roese [this message]
2007-04-16 16:32 ` Andrei Konovalov
2007-04-16 16:33 ` Grant Likely
2007-04-16 16:53 ` Andrei Konovalov
2007-04-19 18:32 ` [RFC] add 8-bit bus support to the Xilinx SystemACE device driver + minor clean-ups Andrei Konovalov
2007-04-27 6:28 ` Grant Likely
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=200704160728.16608.sr@denx.de \
--to=sr@denx.de \
--cc=Rick.Moleres@xilinx.com \
--cc=akonovalov@ru.mvista.com \
--cc=grant.likely@secretlab.ca \
--cc=jacmet@sunsite.dk \
--cc=linuxppc-embedded@ozlabs.org \
/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).