isable UHS modes" and "mmc: tegra: fix reporting of base
> clock frequency" applied)
Thanks very much Stephen, Russell for the series, and Ulf.
This seems like a good time to merge to mmc-next and call for testing
in linux-next -- I'm happy to merge a v2
- Chris.
--
Chris Ball <http://printf.net/>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
res
>
> I really think we should NOT utilize device tree for this.
Of course, we could also make both (or perhaps neither) of you happy by
merging both: if your DT says you don't support cmd23 *or* you hit the
driver's blacklist, we avoid it.
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
that sound okay?
>
> Why? I only ask because I agree with Scott that this means you have to
> update your device tree to get proper functionality.
Thanks, I'd missed that. I withdraw my preference; I'll pick up
whichever method you all prefer.
- Chris.
--
Chris Ball &l
ther than in driver code, so I'd prefer to just push the original
patch to mmc-next as-is. Does that sound okay?
(I think the argument that there isn't going to be any new hardware
with this problem is equally in favor of both methods.)
Thanks,
- Chris.
--
Chris Ball <http://pri
ork (vs Auto-CMD23).
It seems plausible that it's just not implemented on these controllers.
It's a little strange, since the command's been specified for so long
and we haven't seen any other controllers with problems. The patch
would be correct if this is true.
- Chris.
--
C
troller, and flags are runtime decisions on whether
to use that capability, based on e.g. the presence of a quirk.
So, I think the code's correct as written. Feel free to ask more
questions if you're investigating a specific problem that you haven't
mentioned yet.
Thanks,
- C
host->flags & (SDHCI_USE_SDMA | SDHCI_USE_ADMA)) {
> + if ((host->ops->enable_dma) && (mask & SDHCI_RESET_ALL))
> + host->ops->enable_dma(host);
> + }
> }
>
> static void sdhci_set_i
Kumar Gala
Pushed to mmc-next for 3.2 with Anton's ACK now, thanks.
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
btle ways -- we haven't had much testing from
the individual -pltfm driver maintainers yet -- and the mmc merge was
(relatively) huge already this cycle.
I'll certainly push it to linux-next as soon as -rc1 is released,
though. Sound okay?
Thanks,
- Chris.
--
Chris Ball <http
Hi,
On Wed, Sep 08, 2010 at 10:37:41PM +0100, Chris Ball wrote:
> Hi Andrew,
>
> On Tue, Sep 07, 2010 at 03:38:13PM -0700, Andrew Morton wrote:
> > > I noticed no throughput drop neither with PIO transfers nor
> > > with DMA (tested on MPC8569E CPU), while latenc
e grained locking.
I didn't know anything about a reported performance drop, and I don't
think Andrew did either -- Albert's test results don't seem to have
made it to this list, or anywhere else that I can see. Could you
link to/repost his comments?
(I'll be testing
ems yet, but may do so in the
> future and will impact the validity of any testing. It seems to be
> kind of stuck. Should I drop it all?
I suggest keeping it -- I'll find time to test it out here soon, and
will keep it in mind as a possible regression cause.
Thanks,
--
Chris Ball
13 matches
Mail list logo
