On Tue, Dec 15, 2009 at 01:45:52AM +0300, Anton Vorontsov wrote:
> On Mon, Dec 14, 2009 at 11:24:15PM +0100, Albert Herranz wrote:
> > This patch set adds support for the SDHCI controllers found in the
> > "Hollywood" chipset of the Nintendo Wii video game console.
> >
> > First, the existing sdhci-of driver is splitted into a core part and
> > a eSDHC-only part. Then the Nintendo Wii SDHCI support is added as an
> > add-on to that, re-using common code.
>
> All four patches
>
> Acked-by: Anton Vorontsov <avorontsov@xxxxxxxxxxxxx>
Interesting coincidence, I'd need to tackle these parts right now, too, just
with a different aim. The eSDHC-core was also used in the ARM-based imx35,
which means I need the code using a platform device. Just yesterday, I thought
about ways to do this. My favourite idea so far is to implement a
quirk-infrastructure. So, roughly:
Let the matching-structs look something like this:
static const struct of_device_id sdhci_of_match[] = {
{ .compatible = "fsl,mpc8379-esdhc", .data = "esdhc", },
...
}
Then, we have a sdhci-quirk.c making use of a struct like this:
struct sdhci_quirk_data {
char name[SDHCI_QUIRK_NAME_SIZE];
unsigned int quirks;
struct sdhci_ops *ops;
};
and exposing a function like
sdhci_apply_quirk(host, sdhci_match_data);
which will then go through the table of quirks to see if the match_data matches
a quirk-name. That could be used in sdhci-of.c and shdci-pltfm.c equally.
I am still looking into issues like abstracting the clock-handling, make bigger
quirks optional and checking if there is a graceful way for a quirk to keep
extra-data. I'd be happy to hear opinions about the current sketch
nevertheless.
Kind regards,
Wolfram
PS: This shouldn't affect the above patch-set IMHO. Factoring out the
esdhc-stuff is a step in the right direction in any case.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Attachment:
signature.asc
Description: Digital signature
