All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sami Kantoluoto <sami.kantoluoto@embedtronics.fi>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] MCI support for AT91 family processors.
Date: Mon, 31 Aug 2009 14:22:47 +0300	[thread overview]
Message-ID: <20090831112247.GH16004@embedtronics.fi> (raw)
In-Reply-To: <20090829230827.GE4150@pc-ras4041.res.insa>

On Sun, Aug 30, 2009 at 01:08:27AM +0200, Albin Tonnerre wrote:
> On Sat, Aug 29, 2009 at 08:18:32PM +0300, Sami Kantoluoto wrote :
> > Fixed to parse CSD correctly on little endian processors as gcc orders
> > bitfields differently between big and little endian ones.
> 
> Please also see this patch, which will fix those bugs as weel, while switching
> to the new GENRIC_MMC API:
> http://lists.denx.de/pipermail/u-boot/2009-August/059456.html
> I'd highly appreciate if you could test it, to get some feedback

Thanks, I'll test when I get some time later this week but I think (by 
reading the patch so I probably missed something) it won't solve the CSD
problem. The real reason of the "CSD problem" of course is that how the
mmc_csd structure is defined (host byte order not taken in account or
at least how gcc handles bitfields).

[snip]

> the configuration for the MCI controller, which should be done in the
> at91sam*_devices.c files. See the attached patch (relying on the patch
> mentionned above) that adds such support. It's not complete yet either: it
> partially lacks support for models which have 2 MCI controllers, but
> that's not the case of the 9G20 anyway (that's just a matter of putting
> proper ifdefs before defining AT91_BASE_MCI).
> If what I've done in this patch is not the way to go, I'd appreciate
> guidance on how to do it correctly.

It seems ok to me except one comment about the interface:

> diff --git a/include/asm-arm/arch-at91/at91_common.h b/include/asm-arm/arch-at91/at91_common.h
>
> +void at91_mci0_hw_init(int);
> +void at91_mci1_hw_init(int);

I'm just wondering if the bus width should be configurable. It's probably
quite unusual to use just one data bit but not impossible though. So maybe
the interface call could be:

void at91_mci0_hw_init(int bwForSlotA, bwForSlotB)

Where the bwForSlot<X> is either 0 (which means slot is not used), 1 or 4.


     -sk

  parent reply	other threads:[~2009-08-31 11:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-29 17:18 [U-Boot] [PATCH] MCI support for AT91 family processors Sami Kantoluoto
2009-08-29 18:33 ` Albin Tonnerre
2009-09-05  1:21   ` Jean-Christophe PLAGNIOL-VILLARD
2009-09-05  9:03     ` Albin Tonnerre
2009-09-05 11:35       ` Jean-Christophe PLAGNIOL-VILLARD
     [not found] ` <20090829230827.GE4150@pc-ras4041.res.insa>
2009-08-31 11:22   ` Sami Kantoluoto [this message]
2009-08-31 11:39     ` Albin Tonnerre
2009-08-31 11:47       ` Sami Kantoluoto
2009-09-01 13:59       ` Sami Kantoluoto
2009-09-10 13:05 ` Albin Tonnerre

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=20090831112247.GH16004@embedtronics.fi \
    --to=sami.kantoluoto@embedtronics.fi \
    --cc=u-boot@lists.denx.de \
    /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.