but again,
the only situation when parent device matter is runtime PM,
which is not implemented for Timberdale.
Signed-off-by: Pawel Moll
---
drivers/mmc/host/sdhci-pltfm.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/m
On Mon, 2014-08-11 at 10:07 +0100, Ulf Hansson wrote:
> On 8 August 2014 18:36, Pawel Moll wrote:
> > On Fri, 2014-07-25 at 15:23 +0100, Pawel Moll wrote:
> >> The code selecting a device for the sdhci host has been
> >> continuously tweaked (4b711cb13843f5082e82970
On Fri, 2014-07-25 at 15:23 +0100, Pawel Moll wrote:
> The code selecting a device for the sdhci host has been
> continuously tweaked (4b711cb13843f5082e82970dd1e8031383134a65
> "mmc: sdhci-pltfm: Add structure for host-specific data" and
> a4d2177f00a5252d825236c5124bc1
but again,
the only situation when parent device matter is runtime PM,
which is not implemented for Timberdale.
Cc: Chris Ball
Cc: Anton Vorontsov
Cc: Ulf Hansson
Cc: linux-mmc@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Signed-off-by: Pawel Moll
---
This patch is a part of effort to re
On Mon, 2013-07-29 at 14:30 +0100, Guennadi Liakhovetski wrote:
> Yes, this is also a possibility, but it seems only a little bit better.
> Why should a DT node on SoC vN have a compatible string with SoC vK for
> some random for an abstract user absolutely unrelated SoC version?... And
> that v
On Mon, 2013-07-29 at 13:05 +0100, Guennadi Liakhovetski wrote:
> No, that's exactly the problem. We absolutely do not want to write
> compatible="vendor,soc-v1"; in a .dts file for SoC v2 just because we
> currently think, that we don't have to distinguish between those SoC
> versions in this s
On Mon, 2013-07-29 at 12:27 +0100, Guennadi Liakhovetski wrote:
> On Mon, 29 Jul 2013, Pawel Moll wrote:
>
> > On Mon, 2013-07-29 at 08:18 +0100, Guennadi Liakhovetski wrote:
> > > A short addendum. At least with Renesas SoCs I see the situation in the
> > > f
On Fri, 2013-07-26 at 18:10 +0100, Stephen Warren wrote:
> > +- uhs-sdr12: the host supports UHS SDR12 mode
> > +- uhs-sdr25: the host supports UHS SDR25 mode
> > +- uhs-sdr50: the host supports UHS SDR50 mode
> > +- uhs-sdr104: the host supports UHS SDR104 mode
> > +- uhs-ddr50: the host supports
On Mon, 2013-07-29 at 08:18 +0100, Guennadi Liakhovetski wrote:
> A short addendum. At least with Renesas SoCs I see the situation in the
> following way: new SoC versions appear relatively frequently.
What frequency are we talking about? Once per year? Once per month? I'm
not trying to be picky
On Fri, 2013-07-26 at 15:49 +0100, Dinh Nguyen wrote:
> Dinh please...
Uh, accept my apologies. I know exactly how it feels ;-)
> > I've also noticed that Exynos defines almost identical bindings:
> >
> > > samsung,dw-mshc-ciu-div
> > > samsung,dw-mshc-sdr-timing
> > > samsung,dw-mshc-ddr-timing
Hello Ding,
Excuse me if the questions below were already asked and feel free to
point me at the appropriate mail archive...
On Thu, 2013-07-25 at 23:04 +0100, dingu...@altera.com wrote:
> Add bindings for SD/MMC for SOCFPGA.
> Add "syscon" to the "altr,sys-mgr" binding.
Are those two related? A
On Thu, 2013-01-24 at 12:57 +, Chris Ball wrote:
> Hi Pawel,
>
> On Fri, Dec 14 2012, Pawel Moll wrote:
> > The Versatile Express IOFPGA as shipped on VECD 5.0 (bitfiles v108/208
> > and v116/216) contains a modified version of the PL180 MMCI, with
> > PeriphID Con
Hi Chris,
On Fri, 2012-12-14 at 15:38 +, Pawel Moll wrote:
> The Versatile Express IOFPGA as shipped on VECD 5.0 (bitfiles v108/208
> and v116/216) contains a modified version of the PL180 MMCI, with
> PeriphID Configuration value changed to 0x2.
>
> This version adds an opt
Hello Ulf,
On Fri, 2012-12-21 at 11:05 +, Ulf Hansson wrote:
> On 14 December 2012 16:38, Pawel Moll wrote:
> > The Versatile Express IOFPGA as shipped on VECD 5.0 (bitfiles v108/208
> > and v116/216) contains a modified version of the PL180 MMCI, with
> > PeriphI
On Fri, 2012-12-14 at 17:11 +, Russell King - ARM Linux wrote:
> On Fri, Dec 14, 2012 at 03:38:46PM +0000, Pawel Moll wrote:
> > The Versatile Express IOFPGA as shipped on VECD 5.0 (bitfiles v108/208
> > and v116/216) contains a modified version of the PL180 MMCI, wi
omatically disabled when FIFO is
about to over/underflow and re-enabled once the host retrieved some
data. This makes the controller immune to over/underrun errors caused
by big interrupt handling latencies.
This patch adds relevant device variant in the driver.
Signed-off-by: Pawel Moll
---
driver
M PRIMECELL MMCI PL180/1 DRIVER
> -S: Orphan
You probably meant
+S: Maintained
> +M: Linus Walleij
> +L: linux-mmc@vger.kernel.org
> F: drivers/mmc/host/mmci.*
>
> ARM PRIMECELL BUS SUPPORT
By all means!
Acked-by: Pawel Moll
Cheers!
Paweł
--
To
.
Tested-by: Pawel Moll
Cheers!
Paweł
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Chris,
> New IO FPGA implementation for Versatile Express boards contain
> MMCI (PL180) cell with FIFO extended to 128 words (512 bytes).
>
> Signed-off-by: Pawel Moll
How about this change? Matt Waddel tested it and Linus Walleij doesn't
mind it ;-)
Cheers!
Paweł
--
To
> If your hardware engineers are listening, I suggest that hardware clock
> gating (as suggested in some earlier mail)
I've discussed this idea with our FPGA magician at the very beginning,
but for some reason we wasn't very happy about this... I can't really
blame him - it's not really his job to
> > > New IO FPGA implementation for Versatile Express boards contain
> > > MMCI (PL180) cell with FIFO extended to 128 words (512 bytes).
> > >
> > > Signed-off-by: Pawel Moll
> >
> > Tested-by: Matt Waddel
> >
> > This patch im
New IO FPGA implementation for Versatile Express boards contain
MMCI (PL180) cell with FIFO extended to 128 words (512 bytes).
Signed-off-by: Pawel Moll
---
drivers/mmc/host/mmci.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b
Hi,
> The adaptive clock
> rate algorithm can probably do with a lot more work to avoid it up-
> clocking to a rate which has proven to never work. I'd actually go as
> far as to say that the algorithm probably has a lot to be desired - but
> it seems to work for my test scenarios.
I've just gav
If the MMC host controller does not support waiting for card signaling
busy state (MMC_CAP_WAIT_WHILE_BUSY cap), there is no point in prining
the relevant warning message.
Signed-off-by: Pawel Moll
---
drivers/mmc/card/mmc_test.c |7 ---
1 files changed, 4 insertions(+), 3 deletions
On Mon, 10 Jan 2011 07:50:42 +0900, Simon Horman
wrote:
> Documentation/arm/SH-Mobile/Makefile |8 +
> Documentation/arm/SH-Mobile/vrl4.c| 169
+
How about putting those two into "tools" (in particular "tools/arm")
instead of "Documentation
25 matches
Mail list logo
