> I'll whip up the changes and see how invasive it gets as a -pltfm
> driver. It shouldn't be too bad. I'll repost the series that way, but
> I will still keep the quirks for now and do a pass reworking these as
> well as others separately (see below).
Sounds great!
> Anyway, I wonder if it does
On Wed, Dec 15, 2010 at 12:59:11PM +0100, Wolfram Sang wrote:
>
> > > If there is something yet missing in sdhci-pltfm which you need, it
> > > probably is worth adding it there. Chances are good that other
> > > pltfm-users might want that, too.
> >
> > Taking that to an extreme, any sdhci drive
> > If there is something yet missing in sdhci-pltfm which you need, it
> > probably is worth adding it there. Chances are good that other
> > pltfm-users might want that, too.
>
> Taking that to an extreme, any sdhci driver should plug into sdhci-pltfm and
> just add the hooks needed. It will re
On Wed, Dec 15, 2010 at 11:37:30AM +0100, Wolfram Sang wrote:
>
> > Still, I don't see the point -- the amount of code would be about the
> > same between wrapping it with a coat of workarounds and op structures,
> > gpio setup, etc, and just doing a separate simple driver. The code shared
> > is
> > Return value is not checked.
>
> Good catch. Thanks.
It is checked in sdhci-pltfm.c ;)
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
On Wed, Dec 15, 2010 at 05:03:44PM +0530, Pavan Kondeti wrote:
> On 12/15/2010 10:19 AM, Olof Johansson wrote:
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + if (res == NULL)
> > + return -ENODEV;
> > +
> > + ioaddr = ioremap(res->start, res->end - res->star
On 12/15/2010 10:19 AM, Olof Johansson wrote:
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (res == NULL)
> + return -ENODEV;
> +
> + ioaddr = ioremap(res->start, res->end - res->start);
> +
Return value is not checked.
> + sdhci = sdhci_alloc_ho
Hi,
On Wed, Dec 15, 2010 at 01:23:58PM +0200, Mike Rapoport wrote:
> Hi Olof,
>
> Overall looks good, just some nitpicking comments.
>
[...]
> > +struct tegra_sdhci_platform_data {
> > + int cd_gpio;
> > + int wp_gpio;
> > + int power_gpio;
>
> The power_gpio seems to be unused...
Yep,
Hi Olof,
Overall looks good, just some nitpicking comments.
On 12/15/10 06:49, Olof Johansson wrote:
> SDHCI driver for Tegra. Pretty straight forward, a few pieces of
> functionality left to fill in but nothing that stops it from going
> upstream. Board enablement submitted separately.
>
> This
> Still, I don't see the point -- the amount of code would be about the
> same between wrapping it with a coat of workarounds and op structures,
> gpio setup, etc, and just doing a separate simple driver. The code shared
> is really just the resource allocation pieces.
? Saving 150 out of 260 lin
On Wed, Dec 15, 2010 at 02:43:07AM -0600, Olof Johansson wrote:
> Hi,
>
> On Wed, Dec 15, 2010 at 09:35:46AM +0100, Wolfram Sang wrote:
>
> > Can't you just use sdhci-pltfm?
>
> Not if I want to hide some of the SoC-specific errata with driver-local
> workarounds instead of polluting the global
Hi,
On Wed, Dec 15, 2010 at 09:35:46AM +0100, Wolfram Sang wrote:
> Can't you just use sdhci-pltfm?
Not if I want to hide some of the SoC-specific errata with driver-local
workarounds instead of polluting the global quirk namespace with them.
Otherwise, yeah, it'd be a good candidate for it.
Hi Olof,
On Tue, Dec 14, 2010 at 10:49:36PM -0600, Olof Johansson wrote:
> SDHCI driver for Tegra. Pretty straight forward, a few pieces of
> functionality left to fill in but nothing that stops it from going
> upstream. Board enablement submitted separately.
>
> This driver is based on an origin
SDHCI driver for Tegra. Pretty straight forward, a few pieces of
functionality left to fill in but nothing that stops it from going
upstream. Board enablement submitted separately.
This driver is based on an original one from:
Signed-off-by: Yvonne Yip
Misc fixes and suspend/resume by:
Signed-
14 matches
Mail list logo
