Re: [PATCH v3 13/13] mmc: tmio: add barriers to IO operations
On Wed, Feb 06, 2013 at 08:47:00PM +0100, Guennadi Liakhovetski wrote: > Without barriers SDIO operations fail with runtime PM enabled. > > Signed-off-by: Guennadi Liakhovetski > Cc: Paul Mundt > --- > > v3: use iowrite16_rep() and ioread16_rep() for consistency. > Looks better to me! Reviewed-by: Paul Mundt -- 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
Re: [PATCH] mmc: tmio: add barriers to IO operations
On Wed, Jan 23, 2013 at 05:46:18PM +0100, Guennadi Liakhovetski wrote:
> Without barriers SDIO operations fail with runtime PM enabled.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
> drivers/mmc/host/tmio_mmc.h | 14 --
> 1 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
> index d857f5c..ad1a1c6 100644
> --- a/drivers/mmc/host/tmio_mmc.h
> +++ b/drivers/mmc/host/tmio_mmc.h
> @@ -159,19 +159,20 @@ int tmio_mmc_host_runtime_resume(struct device *dev);
>
> static inline u16 sd_ctrl_read16(struct tmio_mmc_host *host, int addr)
> {
> - return readw(host->ctl + (addr << host->bus_shift));
> + return ioread16(host->ctl + (addr << host->bus_shift));
> }
>
> static inline void sd_ctrl_read16_rep(struct tmio_mmc_host *host, int addr,
> u16 *buf, int count)
> {
> + wmb();
> readsw(host->ctl + (addr << host->bus_shift), buf, count);
> }
>
Some reason to not use ioread16_rep() and friends?
--
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
Re: [PATCH] mmc: tmio: add barriers to IO operations
On Thu, Jan 24, 2013 at 12:20:19PM +0100, Guennadi Liakhovetski wrote:
> On Thu, 24 Jan 2013, Paul Mundt wrote:
>
> > On Wed, Jan 23, 2013 at 05:46:18PM +0100, Guennadi Liakhovetski wrote:
> > > Without barriers SDIO operations fail with runtime PM enabled.
> > >
> > > Signed-off-by: Guennadi Liakhovetski
> > > ---
> > > drivers/mmc/host/tmio_mmc.h | 14 --
> > > 1 files changed, 8 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
> > > index d857f5c..ad1a1c6 100644
> > > --- a/drivers/mmc/host/tmio_mmc.h
> > > +++ b/drivers/mmc/host/tmio_mmc.h
> > > @@ -159,19 +159,20 @@ int tmio_mmc_host_runtime_resume(struct device
> > > *dev);
> > >
> > > static inline u16 sd_ctrl_read16(struct tmio_mmc_host *host, int addr)
> > > {
> > > - return readw(host->ctl + (addr << host->bus_shift));
> > > + return ioread16(host->ctl + (addr << host->bus_shift));
> > > }
> > >
> > > static inline void sd_ctrl_read16_rep(struct tmio_mmc_host *host, int
> > > addr,
> > > u16 *buf, int count)
> > > {
> > > + wmb();
> > > readsw(host->ctl + (addr << host->bus_shift), buf, count);
> > > }
> > >
> > Some reason to not use ioread16_rep() and friends?
>
> Aren't they "raw," i.e. without barriers:
>
> #define ioread16_rep(p,d,c) __raw_readsw(p,d,c)
I wasn't talking about the barrier semantics, I meant for consistency, as
you are converting to the ioread/write API for everything else.
--
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
Re: [PATCH 3/4] dma: sh: provide a migration path for slave drivers to stop using .private
On Thu, Jul 12, 2012 at 06:55:32AM +0900, Magnus Damm wrote: > Hi Guennadi, > > [CC Paul] > > On Thu, Jul 5, 2012 at 1:17 AM, Guennadi Liakhovetski > wrote: > > This patch extends the sh dmaengine driver to support the preferred channel > > selection and configuration method, instead of using the "private" field > > from struct dma_chan. We add a standard filter function to be used by > > slave drivers instead of implementing their own ones, and add support for > > the DMA_SLAVE_CONFIG control operation, which must accompany the new > > channel selection method. We still support the legacy .private channel > > allocation method to cater for a smooth driver migration. > > > > Signed-off-by: Guennadi Liakhovetski > > --- > > Thanks for your efforts on this. Something that caught my eye in this > patch is this portion: > > +bool shdma_chan_filter(struct dma_chan *chan, void *arg); > > If we would use this function in our DMA Engine slave drivers (MMCIF, > SDHI, SCIF, FSI, SIU and so on) then wouldn't we add a strict > dependency on this symbol provided by this particular DMA Engine > driver implementation for the DMAC hardware (that your patch > modifies)? > > And what do we do if we want to use the same DMA Engine slave driver > with a different DMA Engine driver implementation? > > From my point of view, there must be some better way to not have such > tight dependencies between the DMA Engine slave consumer and the DMA > Engine driver. Not sure what that looks like though. This symbol > dependency is pretty far from great IMO. > I vaguely recall this coming up before, and it wasn't acceptable then either. We will by no means be adding driver-specific hooks in to other drivers that really couldn't care less what the underlying DMA engine driving them is. We already have CPUs with different DMA engines that can be used by the same drivers. As I said the last time, this needs to be fixed in the dmaengine framework, period. -- 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
Re: [PATCH 05/29] regulator: use IS_ERR_OR_NULL() instead of open-coding
On Fri, May 18, 2012 at 11:18:21AM +0200, Guennadi Liakhovetski wrote: > On Fri, 18 May 2012, Paul Mundt wrote: > > > On Thu, May 03, 2012 at 04:32:39PM +0100, Mark Brown wrote: > > > On Thu, May 03, 2012 at 05:05:34PM +0200, Guennadi Liakhovetski wrote: > > > > > > > - if (regulator == NULL || IS_ERR(regulator)) > > > > + if (IS_ERR_OR_NULL(regulator)) > > > > > > The bigger question here is why we're accepting NULL in the first place. > > > > I'm not sure about the regulator case, but it's been useful to support > > passing NULL around in the clock framework case. There are plenty of > > cases where a struct clk is optional and if we fail to find the clock we > > just set clk to NULL and continue on without having to constantly check > > the value of the clk pointer, which helps considerably when you consider > > the number of clk_enable/disable() pairs some drivers have. > > > > Presumably the same applies for regulators? > > Right, but you normally do something like > > priv->regulator = regulator_get(); > ... > regulator_put(priv->regulator); > > Since regulator_get() only returns either a valid pointer or an ERR_PTR() > value, priv->regulator won't be NULL. Doing something like > > priv->regulator = regulator_get(); > if (IS_ERR(priv->regulator)) > priv->regulator = NULL; > > would seem too weird to me. > Perhaps, but that's precisely what we do for struct clk in the case where it not existing is non-fatal. -- 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
Re: [PATCH 05/29] regulator: use IS_ERR_OR_NULL() instead of open-coding
On Thu, May 03, 2012 at 04:32:39PM +0100, Mark Brown wrote: > On Thu, May 03, 2012 at 05:05:34PM +0200, Guennadi Liakhovetski wrote: > > > - if (regulator == NULL || IS_ERR(regulator)) > > + if (IS_ERR_OR_NULL(regulator)) > > The bigger question here is why we're accepting NULL in the first place. I'm not sure about the regulator case, but it's been useful to support passing NULL around in the clock framework case. There are plenty of cases where a struct clk is optional and if we fail to find the clock we just set clk to NULL and continue on without having to constantly check the value of the clk pointer, which helps considerably when you consider the number of clk_enable/disable() pairs some drivers have. Presumably the same applies for regulators? -- 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
Re: [PATCH] sh: ecovec: switch SDHI controllers to card polling
On Wed, Mar 28, 2012 at 08:58:00AM +0200, Guennadi Liakhovetski wrote: > On Wed, 28 Mar 2012, Paul Mundt wrote: > > > On Sat, Jan 28, 2012 at 07:36:24PM +0100, Guennadi Liakhovetski wrote: > > > Polling for card hotplug events is a better option than using SDHI native > > > hotplug interrupt, because the latter option forces the controller to stay > > > permanently powered up and enabled. > > > > > > Signed-off-by: Guennadi Liakhovetski > > > --- > > > > > > It is a kind of an RFC. We do in general prefer SDHI polling to SDHI > > > native hotplug detection for the above reason, but there might well be > > > other reasons, why this is not a good idea in this specific case. If > > > there > > > are such, I'd love to hear about them. > > > > > I've not heard any more about this one way or the other, so should I > > assume you still want it applied? At least we can revert it if one of > > these cases pops up, and in the interim it's always preferable to lean > > towards better power management for a default. > > Yes, agree, since noone objected so far (as if I really expected dozens of > people to pay attention to random RFC patches on the sh list;-)) let's > apply it. > Applied. -- 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
Re: [PATCH] sh: ecovec: switch SDHI controllers to card polling
On Sat, Jan 28, 2012 at 07:36:24PM +0100, Guennadi Liakhovetski wrote: > Polling for card hotplug events is a better option than using SDHI native > hotplug interrupt, because the latter option forces the controller to stay > permanently powered up and enabled. > > Signed-off-by: Guennadi Liakhovetski > --- > > It is a kind of an RFC. We do in general prefer SDHI polling to SDHI > native hotplug detection for the above reason, but there might well be > other reasons, why this is not a good idea in this specific case. If there > are such, I'd love to hear about them. > I've not heard any more about this one way or the other, so should I assume you still want it applied? At least we can revert it if one of these cases pops up, and in the interim it's always preferable to lean towards better power management for a default. -- 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
Re: [PATCH 0/2] mmc: sh_mmcif: simplify platform DMA configuration
On Tue, Jan 17, 2012 at 05:39:55PM +0100, Guennadi Liakhovetski wrote: > Hi Paul > > On Mon, 5 Sep 2011, Paul Mundt wrote: > > > On Tue, Aug 30, 2011 at 06:26:34PM +0200, Guennadi Liakhovetski wrote: > > > A simple cosmetic clean-up, no functional changes. Patch 2/2 depends on > > > patch 1/2 and can wait until 3.3. Paul, would you be able to put it under > > > the carpet somewhere until then or shall I resend it after 3.2-rc1 is > > > out? > > > After both these patches have been applied, we can remove struct > > > sh_mmcif_plat_data::dma around 3.4 or 4.0 or whatever;-) > > > > > It's not a problem, I'll just flag it as awaiting upstream in the > > tracker. Anything flagged as such I generally give a once over after each > > merge window to see if their dependencies have been worked out. > > You certainly haven't forgotten about this patch;-), in which case it's > just me, unable to find it in your git branches. Could you give me a hint > where it can be? > Er, no, of course not ;-) It's out there now.. -- 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
Re: [PATCH 0/2] mmc: sh_mmcif: simplify platform DMA configuration
On Tue, Aug 30, 2011 at 06:26:34PM +0200, Guennadi Liakhovetski wrote: > A simple cosmetic clean-up, no functional changes. Patch 2/2 depends on > patch 1/2 and can wait until 3.3. Paul, would you be able to put it under > the carpet somewhere until then or shall I resend it after 3.2-rc1 is out? > After both these patches have been applied, we can remove struct > sh_mmcif_plat_data::dma around 3.4 or 4.0 or whatever;-) > It's not a problem, I'll just flag it as awaiting upstream in the tracker. Anything flagged as such I generally give a once over after each merge window to see if their dependencies have been worked out. -- 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
Re: [PATCH 1/2] sh-mobile: enable both edges GPIO interrupts on sh7372
On Fri, Jul 15, 2011 at 08:14:23PM +0900, Magnus Damm wrote: > On Fri, Jul 15, 2011 at 7:58 PM, Guennadi Liakhovetski > wrote: > > From: Magnus Damm > > > > IRQ-capable GPIOs on sh7372 can be configured to produce interrupts on > > both edges. > > > > Signed-off-by: Guennadi Liakhovetski > > Cc: Magnus Damm > > --- > > ?drivers/sh/intc/chip.c | ? ?3 +++ > > ?1 files changed, 3 insertions(+), 0 deletions(-) > > Acked-by: Magnus Damm Applied, thanks. -- 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
Re: [PATCH 5/5] ARM: mach-shmobile: ag5evm: SDHI requires waiting for idle
On Tue, Jun 21, 2011 at 12:10:22PM -0400, Chris Ball wrote: > On Mon, Jun 20 2011, Simon Horman wrote: > > Dependencies: > > "mmc: sdhi: Add write16_hook" > > "ARM: mach-shmobile: ag5evm: consistently name sdhi info structures" > > Could I get your ACK for this one, so that I can merge patches 1/2/3/5 > together via the MMC tree? > Well, this has a dependency on 4/5 which I've already applied. I was simply going to wait for 1-3 to be merged via your tree and then roll in this last one on top of that. If you want to take them all that's ok too, git should be able to deal with any merge conflicts fine. -- 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
Re: [PATCH 4/5] ARM: mach-shmobile: ag5evm: consistently name sdhi info structures
On Tue, Jun 21, 2011 at 08:00:11AM +0900, Simon Horman wrote: > Name the SDHI1 instance sh_sdhi1_info to be consistent with sh_sdhi0_info. > > Signed-off-by: Simon Horman > > --- > > Dependencies: None known Applied, thanks. -- 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
Re: [PATCH 3/5] mmc: sdhi: Add write16_hook
On Mon, Jun 20, 2011 at 03:06:53PM +0900, Simon Horman wrote:
> diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
> b/drivers/mmc/host/sh_mobile_sdhi.c
> index b365429..6c56453 100644
> --- a/drivers/mmc/host/sh_mobile_sdhi.c
> +++ b/drivers/mmc/host/sh_mobile_sdhi.c
> @@ -27,6 +27,8 @@
> #include
> #include
>
> +#include
> +
> #include "tmio_mmc.h"
>
linux/delay.h will suffice.
> +static void sh_mobile_sdhi_wait_idle(struct tmio_mmc_host *host)
> +{
> + int timeout = 1000;
> +
> + while (--timeout && !(sd_ctrl_read16(host, CTL_STATUS2) & (1 << 13)))
> + udelay(1);
> +
> + if (!timeout)
> + dev_warn(host->pdata->dev, "timeout waiting for SD bus idle\n");
> +
> +}
> +
> +static void sh_mobile_sdhi_write16_hook(struct tmio_mmc_host *host, int addr)
> +{
> + if (!(host->pdata->flags & TMIO_MMC_HAS_IDLE_WAIT))
> + return;
> +
> + switch (addr)
> + {
> + case CTL_SD_CMD:
> + case CTL_STOP_INTERNAL_ACTION:
> + case CTL_XFER_BLK_COUNT:
> + case CTL_SD_CARD_CLK_CTL:
> + case CTL_SD_XFER_LEN:
> + case CTL_SD_MEM_CARD_OPT:
> + case CTL_TRANSACTION_CTL:
> + case CTL_DMA_ENABLE:
> + sh_mobile_sdhi_wait_idle(host);
> + }
> +}
> +
The timeout error should really be handed down.
> diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
> index 0c22df0..5912cf3 100644
> --- a/drivers/mmc/host/tmio_mmc.h
> +++ b/drivers/mmc/host/tmio_mmc.h
> @@ -153,6 +153,8 @@ static inline u32 sd_ctrl_read32(struct tmio_mmc_host
> *host, int addr)
>
> static inline void sd_ctrl_write16(struct tmio_mmc_host *host, int addr, u16
> val)
> {
> + if (host->pdata->write16_hook)
> + host->pdata->write16_hook(host, addr);
> writew(val, host->ctl + (addr << host->bus_shift));
> }
>
If it times out you are unlikely to want to proceed with the write. At
best you end up with a lost write cycle, at worst potentially a bus
lockup you can't easily recover from.
--
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
Re: [PATCH 0/3] Make DMA slave ID 0 invalid to simplify platform data
On Tue, May 24, 2011 at 12:23:55PM +0200, Guennadi Liakhovetski wrote: > Currently platforms, using the SDHI TMIO driver, have to specify negative > DMA slave IDs to force PIO mode. If default 0 is left, the driver > recognises it as a valid DMA slave ID and tries to acquire channels. This > fails then, because the driver cannot allocate two channels with the same > ID, but it would be better to just make 0 an invalid ID to prevent this. > I suppose the ordering for this will be adding the invalid IDs for all of the CPUs first and then updating the SDHI driver accordingly during -rc2 or something like that. -- 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
Re: [PATCH] mmc, ARM: Add zboot from eSD support for SuperH Mobile ARM
On Thu, Mar 31, 2011 at 11:06:24AM +0900, Magnus Damm wrote: > On Wed, Mar 30, 2011 at 11:59 AM, Simon Horman wrote: > > This allows a ROM-able zImage to be written to eSD and for SuperH Mobile > > ARM to boot directly from the SDHI hardware block. > > > > This is achieved by the MaskROM loading the first portion of the image into > > MERAM and then jumping to it. ?This portion contains loader code which > > copies the entire image to SDRAM and jumps to it. From there the zImage > > boot code proceeds as normal, uncompressing the image into its final > > location and then jumping to it. > > > > Cc: Paul Mundt > > Cc: Magnus Damm > > Cc: Kuninori Morimoto > > Signed-off-by: Simon Horman > > Hi Simon, > > Thanks for your work on this. v6 of this patch looks good to me! > > Acked-by: Magnus Damm Likewise. Feel free to shovel it in to the patch tracker at your leisure. Acked-by: Paul Mundt -- 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
Re: mmc: zboot helpers
On Thu, Mar 24, 2011 at 04:04:36PM +0900, Simon Horman wrote: > [ repost as I included a bogus email address in my previous attempt ] > > Hi Paul, > > please consider merging the following two patches. > They are both pre-requisites for > "mmc, ARM: Add zboot from eSD support for SuperH Mobile ARM" > which I plan to submit to Russell King. > > These patches were originally submitted in a for patch series > however they do not depend on any of the other patches in the series > so I am posting them independently. > > These patches apply against Linus's current tree > and I am not aware of any particular prerequisites for them > other than that the 2nd patch depends on the 1st one. > Ok, I'll queue them up and send them along. -- 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
Re: [PATCH 0/6] mmc: split the tmio driver into several modules
On Wed, Mar 23, 2011 at 07:06:24AM +0900, Simon Horman wrote: > By 1-3 I was referring to the first three patches of > [PATCH 0/4] [rfc v3] mmc, ARM: Add zboot from eSD support for SuperH Mobile > ARM > > That is: > [PATCH 1/4] mmc: tmio_mmc: Move some defines into a shared header > [PATCH 2/4] mmc, ARM: Rename SuperH Mobile ARM zboot helpers > [PATCH 3/4] mmc: Add MMC_PROGRESS_* > > And by patch 4 I was referring to > [PATCH 4/4 v5] mmc, ARM: Add zboot from eSD support for SuperH Mobile > > I apologise for that being as clear as mud. > Ok, that makes a bit more sense, thanks for clearing it up. > Magnus raised a build issue with the series since my previous email. > I will investigate that and reply to him ASAP. Its probably best > to hold all the patches until then. > It looks like 1/4 is going to have to go through the MMC tree, and will have to layer on top of Guennadi's current patch stack. He's done a good job of summarizing the outstanding bits, so it should be trivial to build on top of that. Once 1/4 is merged I can easily merge 2 and 3/4 at pretty much any time during the -rc window, although I'd prefer to have it sorted out by -rc2 or -rc3 at the latest. This will just leave 4/4 for rmk's patch tracker and its respective scheduling. For now I'll punt the series from patchwork and await a resend with 1/4 rebased in such a way that it can trivially be picked up by the MMC tree. > With regards to > [PATCH 2/6] sh: ecovec: use the CONFIG_MMC_TMIO symbols instead of MFD > it looks like Magnus raised a few issues and Guennadi is going to repost > the patch. But I could be wrong. > Yes, already dealt with separately. -- 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
Re: [PATCH 0/6 v2] mmc: split the tmio driver into several modules
On Wed, Mar 23, 2011 at 02:42:29PM +0100, Guennadi Liakhovetski wrote: > This patch-series touches code under > > arch/arm/mach-shmobile > arch/sh/boards > drivers/mfd > drivers/mmc/host > > Perhaps, it would be best to collect necessary acks from Paul and push > them all via mmc? > That works fine for me, it would be better to keep these grouped together due to the ordering and it would take several merges to get everything in sync otherwise. The bulk of this is drivers/mmc churn, so I'll let Chris decide how he wants to handle it. Anyways, for the series: Acked-by: Paul Mundt -- 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
Re: [PATCH 0/6] mmc: split the tmio driver into several modules
On Tue, Mar 22, 2011 at 02:31:31PM +0900, Simon Horman wrote: > On Mon, Mar 21, 2011 at 12:38:10PM +0100, Guennadi Liakhovetski wrote: > > Hi Chris, Ian > > > > AFAICS there are currently still a few tmio patch-series outstanding: > > > > From: Guennadi Liakhovetski gmx.de> > > Subject: [PATCH 0/2] tmio_mmc: improve DMA reliability > > http://thread.gmane.org/gmane.linux.kernel.mmc/6485 > > > > From: Simon Horman verge.net.au> > > Subject: [PATCH 0/4] [rfc v3] mmc, ARM: Add zboot from eSD support for > > SuperH Mobile ARM > > http://thread.gmane.org/gmane.linux.kernel.mmc/6664 > > IMHO, Patch 1-3 are ready and can either be merged through the MMC > or one of Paul's trees. Although I should note that patches > 2 and 3 include changes to arch/arm/boot/compressed/mmcif-sh7372.c and > arch/sh/boot/romimage/mmcif-sh7724.c. > I'm having a hard time working out what these arbitrary 1-3 numbers map to in terms of actual series and patch numbers. As far as things with an sh or rmobile impact I see: sh: ecovec: use the CONFIG_MMC_TMIO symbols instead of MFD and [rfc v3] mmc, ARM: Add zboot from eSD support for SuperH Mobile ARM although it's not obvious how the latter is tied to a TMIO dependency (some SDHI header thing?). I'm happy to take the ecovec patch whenever, since it doesn't really hurt anything. Anything touching drivers/mmc I obviously prefer to go via Chris. I got buried in the fbdev patch queue today, so I'll be catching up on sh and rmobile stuff tomorrow. You're free to work out amongst yourselves what gets applied where in which order, or I'll simply guess. -- 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
Re: [PATCH 0/5] tmio PM: aggressive clock gating, register layout limitation
On Mon, Mar 07, 2011 at 07:47:45PM +0100, Guennadi Liakhovetski wrote: > 5 more patches, that fix high register access on sh-mobile in a correct > way and implement aggressive clock gating. Marked as RFC because testing > on non-SDHI platforms is required! The next step would be to add > runtime-pm to clock gating, but I'm refraining from this for now, because > similar patches for SDHCI have still not been committed and it seems, > there are still doubts about the right way to do that. > > Patches apply on top of my previous 2 patches from earlier today. > I'm a bit confused about this series in general. Patch 1 and 5 are both marked RFC but 2/3/4 seem to be unrelated and intended for merging, despite the fact I find the approach itself to be rather suspect. So why exactly are these all lumped together? Please do not create patch series that are intentionally muddled. Since you have two distinct things here with completely different intentions and you've not explicitly stated whether there's any dependencies between the two it simply creates a giant mess. A patch series should be logically structured in some way other than "here's a bunch of random patches I have pending for this particular driver", particularly if only parts of it are intended to be merged. -- 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
Re: [PATCH 2/5] mmc: tmio: add a flag to prohibit access to registers above 0xff
On Mon, Mar 07, 2011 at 07:47:51PM +0100, Guennadi Liakhovetski wrote: > On some implementations there are no registers above 0xff and any > access to them mirrors to registers at addresses with bit 8 masked > out, which leads to malfunction. Add a flag to prevent such accesses. I'm not sure I really see what the point of the flag is, surely you can derive all of this information already from the I/O resource for the register window in question? -- 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
Re: SDHC Read Performance
On Thu, Jan 20, 2011 at 05:28:55PM +0900, Magnus Damm wrote: > On Thu, Jan 20, 2011 at 4:07 PM, Simon Horman wrote: > > As we discussed (offline) yesterday, it ought to be possible > > to change the frequency of the clock source. And in the case of > > the mackerel this can probably be done without disturbing anything > > else as there are per SHDI clock sources. > > Uhm, this is not entirely correct. The sh7372 used by Mackerel is in > this case similar to most older SH processors and shares a clock > between all SDHI hardware blocks. This clock is also shared with a > bunch of other peripherals, so we can't adjust it freely during > runtime. > > The sh73a0 processor has per-SDHI block clock control. > Or at least the driver would need to have some logic for attempting to make the change and being rejected by the clock framework for the shared clock case. It should be pretty trivial to make this behaviour configurable anyways, given that the driver is largely impervious to the clock refcount otherwise. If the blocks in question are optionally capable of driving their own clocks and exposing a wider range of frequencies, then that's something that should be looked in to as well. For older blocks we're likely not going to have a lot of flexibility with regards to the clock source, though. > > I imagine it would be possible to manipulate the frequency > > such that MMC can be run closer to 20Mhz than 12Mhz. > > > > However, I am unsure if this would improve performance in any way. > > It most likely would. Perhaps it's worth adjusting the shared clock a > bit to support 20MHz? > "Most likely" isn't a constructive performance metric. It's worth trying out, and if it helps then of course it makes sense to try and support. It's not really worth going through and adding in additional complexity in order to support every possible frequency just becase we can, however. It would also be good to see what's going on with class 2 and 10 here, given that we still aren't seeing expected class 10 numbers, regardless of frequency. -- 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
Re: [PATCH] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM
On Mon, Jan 10, 2011 at 10:10:19AM +, Pawel Moll wrote: > 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"? > >>Just a thought... ;-) > > > >Thats fine by me except that tools/arm doesn't exist yet. > >It would be good to get some consensus before creating it. > > I think there is consensus regarding "tools" as a place for user-space > tools - eg. perf tools used to live in "Documentation/..." and then were > moved to "tools/perf". > > Now, whether your stuff should be in "tools/SH-Mobile" or > "tools/arm/SH-Mobile", I have no opinion ;-) > I agree that this is a worthwhile direction to move to, but we're a long way from a consensus. x86 has traditionally littered scripts/ and others have sunk to arch//tools hostprogs abuse and so forth. perf is a bit of a special case in that it's fairly architecture agnostic. -- 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
Re: [PATCH 4/6 v3] sh: sh7724 Enable SDIO IRQs
On Tue, Dec 28, 2010 at 11:22:34PM +0100, Arnd Hannemann wrote: > This patch enables the interrupt generation for SDIO IRQs > of the sdhi controllers of the SoC. To make sure interrupt > are handled announce the MMC_CAP_SDIO_IRQ capability > on ecovec, kfr2r09 and se7724. > > Tested with a b43-based SDIO wireless card on ecovec. On Tue, Dec 28, 2010 at 11:22:35PM +0100, Arnd Hannemann wrote: > This patch enables the interrupt generation for SDIO IRQs > of the sdhi controllers of the SoC. To make sure SDIO IRQs > are used, announce the MMC_CAP_SDIO_IRQ capability > on migor. On Tue, Dec 28, 2010 at 11:22:36PM +0100, Arnd Hannemann wrote: > This patch enables the interrupt generation for SDIO IRQs > of the sdhi controllers of the SoC. To make sure SDIO IRQs > are used announce the MMC_CAP_SDIO_IRQ capability > on ap325rxa. All applied to sh/sdio, thanks. -- 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
Re: [PATCH 3/6 v3] ARM: mach-shmobile: sh7372 Enable SDIO IRQs
On Tue, Dec 28, 2010 at 11:22:33PM +0100, Arnd Hannemann wrote: > This patch enables the interrupt generation for SDIO IRQs > of the sdhi controllers of the SoC. To make sure interrupts > are handled announce the MMC_CAP_SDIO_IRQ capability > on AP4EVB. Tested with a b43-based SDIO wireless card. > > Signed-off-by: Arnd Hannemann Applied to rmobile/sdio, thanks. -- 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
Re: outstanding TMIO MMC patches
On Wed, Jan 05, 2011 at 06:57:17PM +, Chris Ball wrote: > On Thu, Jan 06, 2011 at 02:30:30AM +0900, Paul Mundt wrote: > > This is basically where the problem lies. Ian has some version of the > > hardware that we don't, and he likewise doesn't have access to the > > version that we do (of course there would be no problem in making the > > hardware available to whoever decides to step up and look after TMIO in a > > more constructive fashion, though). There are likewise issues with > > regards to who has access to what specifications, and there are cases > > where neither Ian nor any of the people from our side have any specs at > > all. With this sort of a scenario it can be quite difficult to avoid > > stepping on other peoples toes and making sure that things aren't being > > inadvertently broken, and this is something I don't see any specific > > resolution to, other than if you're not around to test and object in a > > timely fashion, you lose. I don't know if other MMC drivers have the same > > problem or not, but I can't imagine that this situation is terribly > > unique when you have both corporations and hobbyists working on the same > > driver from vastly different angles. > > I see. So, if most patches are coming from your side, it seems that the > largest problem for the moment is that no-one except Ian can test your > patches against his hardware. Do we think there's any chance of someone > (I guess ideally you but possibly me) getting hold of hardware with Ian's > MMC block in, for at least occasional testing before releases? > > If not, is there any kind of split in the driver that we could use to try > to isolate changes more? > The biggest difference is that the stuff Ian is working with is a full-blown MFD, while from our side we're simply dealing with an insular MFD cell. At the moment we have a shim single-function MFD driver (sh_mobile_shdi) that simply packages up the insular cell and binds it to tmio-mmc so that we could keep using the same interface on the MMC side without having to hack up the driver irreperably. The behaviour however is not always the same, which you can already see in things like 311f3ac76826bfd8ed6213ded91ec947df164def when DMA support was added. For the most part it's been posible to keep things fairly compartmentalized by layering on top of MFD, but there are plenty of cases where we just have to make assumptions about how the other versions of the block work. Given that we don't have an MFD in any of the blocks we're using, it's not always readily apparent what the best way to split things out is while keeping within the spirit of the MFD layering. How best to handle runtime PM for example remains an outstanding issue. As far as I can tell, all of the other MFD drivers using tmio-mmc are already years old and mostly seem to have come out of the handhelds.org work. Some of them bear recent copyrights but were ported from 2.4 code, and so date from that era of hardware. I expect that for the most part these have all been end of lifed from Toshiba's side already, so it's not entirely obvious how easy they will be to procure. I'll take a look and see what I can dig up though, and of course we're happy to send hardware with our version of the block in it to whoever wishes to do independent testing. -- 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
Re: outstanding TMIO MMC patches
On Wed, Jan 05, 2011 at 10:16:24PM +0100, Arnd Hannemann wrote: > Am 05.01.2011 19:57, schrieb Chris Ball: > > Arnd, can I take just patches 1/2 from your six-part series, and have > > you send the rest through the arch/ maintainers later? > > Sure, should be no problem. > Ah, just saw that you already pushed those two, thanks. > > @Paul: > Maybe it would be best that you ACK those arch patches (if you think > they are ok) and that they also go in via the mmc-next tree? > Otherwise we would need to wait until mmc-next for .38 is merged in your > trees, > right? > If Chris prefers they go through the architecture side then that's not a problem either. I'll be doing at least 2 merges during the merge window, and this stuff is just adding in platform data, so it doesn't really matter when it gets rolled in. Optionally if the MMC tree doesn't rebase I can just set up a topic branch that branches off of that, roll these patches on top of that, and you can just test that directly. -- 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
Re: outstanding TMIO MMC patches
On Wed, Jan 05, 2011 at 04:57:57PM +, Chris Ball wrote: > Wow, how hostile -- insult first, ask questions later? I do review and > merge MMC patches; all it takes is a ping to let me know that the tmio > maintainer is absent and that you'd like me to start picking these up. > I'd seen them being taken into other trees, and no-one's asked me about > merging any of them into the MMC tree before, so I didn't realize there > was a problem. We just need more communication. > Again, this isn't the first time this has happened. Any perceived hostility in this matter is not directed at you directly since you did come in to things rather late and were possibly unaware of the situation. It's more absentee maintainers I have a problem with. In any event, you were Cc'ed on mails that pointed out the problem (at least in summary), you've presumably seen the mails with the patches that went by with pings by people looking for answers, and it still took a strongly worded email to elicit any sort of response. Make of that what you will. In any event, we seem to have shaken out the beginnings of a way forward now, so this is progress! > So, let's come up with a workflow. With Ian absent, it would be good to > have someone with TMIO hardware (I don't have any) who's willing to help > test and review/ACK patches. I don't generally like to take arch code > in through the MMC tree, so it would also be good to break up some of > the patchsets into MMC-only if possible. > This is basically where the problem lies. Ian has some version of the hardware that we don't, and he likewise doesn't have access to the version that we do (of course there would be no problem in making the hardware available to whoever decides to step up and look after TMIO in a more constructive fashion, though). There are likewise issues with regards to who has access to what specifications, and there are cases where neither Ian nor any of the people from our side have any specs at all. With this sort of a scenario it can be quite difficult to avoid stepping on other peoples toes and making sure that things aren't being inadvertently broken, and this is something I don't see any specific resolution to, other than if you're not around to test and object in a timely fashion, you lose. I don't know if other MMC drivers have the same problem or not, but I can't imagine that this situation is terribly unique when you have both corporations and hobbyists working on the same driver from vastly different angles. For the moment Guennadi and Arnd have been doing the work, with the occasional patch from Magnus and others. All of this work however is done on the same set of hardware and roughly by the same set of people with an identical set of interests working for the same company, which makes objective code review a bit problematic. Ian has provided useful feedback in the past, which is why I've generally given him the benefit of the doubt and let patches sit around for a month or two before pushing on people. I note that the driver is 'maintained' for example instead of 'supported', so it's understandable that people do somethings get pulled away by other things from time to time. If one persistently can't even do the bare minimum however, then it should simply be orphaned. As it is now however we are quickly building up an unwieldly patch stack with more future work to be done, and I'm hesitant to have anyone begin any future work when the existing dependencies are wildly out of sync with upstream already. If we can get some sort of process in place that makes this less of a problem, then of course I'm pretty open to anything. The main thing I want to avoid is a feedback loop where things go in to -mm purgatory, get bounced off of Ian once a month or so, and then the process repeats itself. -- 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
Re: [PATCH] mmc: sh_mmcif: make DMA support by the driver unconditional
On Wed, Jan 05, 2011 at 10:45:49AM +0900, Magnus Damm wrote: > On Wed, Dec 29, 2010 at 4:59 PM, Guennadi Liakhovetski > wrote: > > Simplify the driver by removing the possibility to build it without the DMA > > support and remove the respective Kconfig parameter. > > > > Signed-off-by: Guennadi Liakhovetski > > Excellent, this helps against bitrot and makes kernel configuration > easier for newbies. > > Acked-by: Magnus Damm Applied to rmobile/mmcif, thanks. -- 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
Re: outstanding TMIO MMC patches
On Wed, Jan 05, 2011 at 11:10:18AM +0900, Magnus Damm wrote: > mmc: tmio_mmc: allow multi-element scatter-gather lists > mmc: tmio_mmc: fix PIO fallback on DMA descriptor allocation failure > [1/3] mmc: tmio: merge the private header into the driver > [2/3] mmc: tmio: implement a bounce buffer for unaligned DMA > [3/3] mfd: sdhi: require the tmio-mmc driver to bounce unaligned buffers > mmc: tmio_mmc: silence compiler warnings > [1/6] mmc: tmio: implement SDIO IRQ > [2/6] mfd: sh_mobile_sdhi: activate SDIO IRQ for tmio_mmc > [3/6] ARM: mach-shmobile: sh7372 Enable SDIO IRQs > [4/6] sh: sh7724 Enable SDIO IRQs > [5/6] sh: sh7722 Enable SDIO IRQs > [6/6] sh: sh7723 / ap325rxa enable SDIO IRQs > [1/2] tmio_mmc: handle missing HW interrupts > [2/2] tmio_mmc: fix CMD irq handling > > [14 outstanding patches including 2 unlisted from Arnd] > > Guennadi, thanks a lot for this list of outstanding patches. I've > tested most of them myself and I think they are all a welcome addition > to the SDHI hardware block on SH-Mobile / R-Mobile SoCs. I'm not sure > how they affect other platforms though. > > Ian, would it be possible for you to give some feedback? I know it's > holiday season and all, but the first version of most patches were > posted about a month ago. > > If we can't get any feedback then perhaps someone else can maintain > the tmio-mmc driver together with Ian? Or maybe it's easier to just > easier to create a SDHI specific fork of the tmio-mmc driver which can > be modified more easily. > The situation is actually much worse than this, the initial patches are more than 2 months old, and have never been commented on once by the alleged "maintainer" of the TMIO driver. This is not the first time either, and indeed, every single time patches are posted that touch this driver, months pass before anything at all gets done. My expectation was that if the subsystem had a maintainer that claimed to be active they would step up and do something when repeated efforts to engage with an absentee driver maintainer fall short. If neither one of these things are the case, then I really see no reason to bring changes to this driver to the attention of either the author or the subsystem author, and will just start to merge them directly. Having this amount of work backlogged without so much as a single bit of feedback or activity from anyone that pretends to be a maintainer is simply nonsense. It's not acceptable to have progress stalled indefinitely simply because 'real life got in the way' or any other number of baseless excuses. If you can't commit to doing the job you elected to as a maintainer, then set the driver orphaned and get out of the way. The MMC subsystem has been pretty much a disaster in terms of maintenance for as long as I can remember, so this is certainly not a new situation, but I had hoped that the situation had rather improved recently with at least some people stepping up and being a bit more active. For now, -mm is probably the only way for these to make any sort of forward progress, but it's a bit counter-intuitive to have to sideline an allegedly maintained subsystem in order for anything to happen at all. -- 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
Re: [patch v3] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM
On Thu, Dec 09, 2010 at 07:16:53AM +0900, Simon Horman wrote: > This allows a ROM-able zImage to be written to MMC and > for SuperH Mobile ARM to boot directly from the MMCIF > hardware block. > > This is achieved by the MaskROM loading the first portion > of the image into MERAM and then jumping to it. This portion > contains loader code which copies the entire image to SDRAM > and jumps to it. From there the zImage boot code proceeds > as normal, uncompressing the image into its final location > and then jumping to it. > > This patch depends on: > * "ARM: 6514/1: mach-shmobile: Add zboot support for SuperH Mobile ARM" > which has been merged into the devel branch of Russell King's > linux-2.6-arm tree. > * "mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h" > which has been merged into the common/mmcif branch of > Paul Mundt's sh-2.6 tree > * "mmc, sh: Remove sh_mmcif_boot_slurp()" > which has been merged into the common/mmcif branch of > Paul Mundt's sh-2.6 tree This one at least should go through Russell's tree. The dependencies from my side will be sorted out early in the merge window, so you should be able to submit this to Russell's patch tracker after that for a late -rc1 merge, or for -rc2. After that's done, there don't seem to be any more outstanding dependencies, so at that point I'll be able to take care of the remaining patches. -- 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
Re: [PATCH 1/3] sh, mmc: Make mmcif_update_progress static inline
On Sat, Nov 27, 2010 at 08:02:57AM +0900, Simon Horman wrote: > extern inline doesn't make much sense > > Cc: Yusuke Goda > Cc: Magnus Damm > Signed-off-by: Simon Horman On Sat, Nov 27, 2010 at 08:02:58AM +0900, Simon Horman wrote: > This resolves a regression that I introduced in > "mmc, sh: Move constants to sh_mmcif.h". Having > examined the manual and tested the code on an AP4EVB board > it seems that the correct sequence is. > > 1) Write 1 to bit 31 and zeros to all other bits > 2) Write zero to all bits > > Cc: Yusuke Goda > Cc: Magnus Damm > Signed-off-by: Simon Horman On Sat, Nov 27, 2010 at 09:11:55AM +0900, Simon Horman wrote: > The 16-19th bits of CE_CLK_CTRL set the > MMC clock frequency. > > Cc: Yusuke Goda > Cc: Magnus Damm > Signed-off-by: Simon Horman Applied, thanks. -- 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
Re: [PATCH 0/5 v2] MMC: DMA for SH MMCIF
On Wed, Nov 24, 2010 at 11:05:08AM +0100, Guennadi Liakhovetski wrote: > This patch series slightly cleans up the sh_mmcif MMC driver and adds a > DMA capability to it. One of the patches is not directly related, but is > required for a proper DMA functionality. V2 limits the number of request > segments, instead of raising the number of DMA descriptors in shdma.c. > This drops one patch from this series and modifies one further patch, the > rest remain unchanged. > Looks better! All applied, thanks. -- 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
Re: [PATCH v2] mmc, sh: Move constants to sh_mmcif.h
On Tue, Nov 09, 2010 at 05:47:02PM +0900, Simon Horman wrote: > This moves some constants from sh_mmcif.c to sh_mmcif.h > so that they can be used in sh_mmcif_boot_init(). > > It also alters the definition of SOFT_RST_OFF from (0 << 31) to > ~SOFT_RST_ON (= ~(1 << 31)). The former seems bogus. The latter is > consistent with the code in sh_mmcif_boot_init(). > > Cc: Yusuke Goda > Cc: Magnus Damm > Signed-off-by: Simon Horman > --- > drivers/mmc/host/sh_mmcif.c | 23 --- > include/linux/mmc/sh_mmcif.h | 39 ++- > 2 files changed, 34 insertions(+), 28 deletions(-) > As this doesn't appear to introduce any bugfixes or functionality changes I've queued it with the .38 changes. Its on its own topic branch for now, but let me know if you have a dependency on this in future patches aimed at the merge window and I'll make sure it ends up merged wherever its needed. -- 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
Re: [PATCH] mmc, sh: use a consistent pr_ prefix
On Wed, Nov 10, 2010 at 07:27:44PM +0900, Simon Horman wrote:
> Use pr_fmt to set the prefix for pr_ messages.
> I believe this method is common in other
> source files in the kernel tree.
>
pr_fmt() is ok when you have no better options, but in this case you have
the struct device working for you, so you really should be using it.
Consider the case where you have multiple MMCIF blocks, the debug
messages here won't really give you much helpful information if you have
no idea which block you're on.
For example..
> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> index 3f49273..9f37f74 100644
> --- a/drivers/mmc/host/sh_mmcif.c
> +++ b/drivers/mmc/host/sh_mmcif.c
> @@ -221,8 +222,8 @@ static int sh_mmcif_error_manage(struct sh_mmcif_host
> *host)
>
> state1 = sh_mmcif_readl(host->addr, MMCIF_CE_HOST_STS1);
> state2 = sh_mmcif_readl(host->addr, MMCIF_CE_HOST_STS2);
> - pr_debug("%s: ERR HOST_STS1 = %08x\n", DRIVER_NAME, state1);
> - pr_debug("%s: ERR HOST_STS2 = %08x\n", DRIVER_NAME, state2);
> + pr_debug("ERR HOST_STS1 = %08x\n", state1);
> + pr_debug("ERR HOST_STS2 = %08x\n", state2);
>
> if (state1 & STS1_CMDSEQ) {
> sh_mmcif_bitset(host, MMCIF_CE_CMD_CTRL, CMD_CTRL_BREAK);
You can just convert these to:
dev_dbg(&host->pd->dev, ...);
> @@ -230,7 +231,7 @@ static int sh_mmcif_error_manage(struct sh_mmcif_host
> *host)
> while (1) {
> timeout--;
> if (timeout < 0) {
> - pr_err(DRIVER_NAME": Forceed end of " \
> + pr_err("Forceed end of " \
> "command sequence timeout err\n");
> return -EIO;
> }
dev_err(), and so on.
--
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
Re: [PATCH] initialise DMA engine before MMC
On Mon, Jun 07, 2010 at 01:16:36PM +0200, Guennadi Liakhovetski wrote: > To use DMA engine based DMA with MMC in a non-modular build, the DMA > engine has to initialise before MMC. > > Signed-off-by: Guennadi Liakhovetski Dan, any objections to this? -- 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
Re: [PATCH 2/2] sh: Add support MMCIF for ecovec
On Tue, Apr 27, 2010 at 07:15:32PM +0900, Yusuke Goda wrote: > This patch adds MMCIF platform data for the Ecovec board. > > Signed-off-by: Yusuke Goda Applied, thanks. -- 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
Re: [PATCH 9/9 v2] ARM: mach-shmobile: add DMA support to sh7372, enable DMA for SDHI
On Sun, May 23, 2010 at 03:49:47PM +0200, Guennadi Liakhovetski wrote: > This adds DMA support for the sh7372 sh-mobile ARM core, using the shdma > dmaengine driver, and uses DMA for the SDHI SD-card controller on this SoC. > > Signed-off-by: Guennadi Liakhovetski > --- > > v1 -> v2: > > 1. updated to the current genesis tree HEAD > 2. adjusted the topic line to match platform preferences > 3. moved DMA platform devices to the top of the file, so that other > devices can reference them. > > Paul, this should be ready for you to merge now. > Applied, thanks. -- 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
Re: [PATCH 3/3 v2] ARM: mach-shmobile: add support for the second SD-/MMC-card slot on ap4evb
On Sun, May 23, 2010 at 04:12:46PM +0200, Guennadi Liakhovetski wrote: > The ap4evb board is equipped with two card slots: one SD-card slot and one > SD-/MMC-card slot. The latter is connected to the second SDHI interface on > sh7372 (SDHI1). Its power supply can be jumpered either to 1.8 or 3.3V, we fix > it at default 1.8V for now. > > Signed-off-by: Guennadi Liakhovetski Now that all of the dependencies are out of the way, I've applied this too. -- 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
Re: [PATCH 0/3] tmio: let platforms decide upon write-protection availability
On Sat, May 22, 2010 at 04:33:33PM +0900, Paul Mundt wrote: > On Fri, May 21, 2010 at 12:38:27PM -0700, Andrew Morton wrote: > > On Wed, 19 May 2010 20:35:57 +0200 (CEST) > > Guennadi Liakhovetski wrote: > > > > > No changes to patches themselves, just re-sending with an ack added. > > > > > > Applies on top of the > > > > > > "[PATCH 0/10] add DMA support to tmio_mmc, using dmaengine API, use it on > > > SH" > > > > > > patch series. > > > > > > > Paul, are you planning on merging the tem patches in the > > above-mentioned series for 2.6.35-rc1? > > > Yes, they'll be in my next round of updates for -rc1. Since I don't have > much else, I'll send those out today or tomorrow. Since the 0/3 and 0/2 series also had all of the acked-bys and so on I also took those. This at least lets us merge all of the sh platform patches at the same time without any odd dependency ordering. The ARM stuff I'll take care of separately after these have been merged. -- 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
Re: [PATCH 0/3] tmio: let platforms decide upon write-protection availability
On Fri, May 21, 2010 at 12:38:27PM -0700, Andrew Morton wrote: > On Wed, 19 May 2010 20:35:57 +0200 (CEST) > Guennadi Liakhovetski wrote: > > > No changes to patches themselves, just re-sending with an ack added. > > > > Applies on top of the > > > > "[PATCH 0/10] add DMA support to tmio_mmc, using dmaengine API, use it on > > SH" > > > > patch series. > > > > Paul, are you planning on merging the tem patches in the > above-mentioned series for 2.6.35-rc1? > Yes, they'll be in my next round of updates for -rc1. Since I don't have much else, I'll send those out today or tomorrow. -- 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
Re: [PATCH 0/9 v3] add DMA support to tmio_mmc, using dmaengine API, use it on SH
On Thu, May 13, 2010 at 08:42:42AM +0200, Guennadi Liakhovetski wrote: > On Wed, 12 May 2010, Andrew Morton wrote: > > > On Tue, 11 May 2010 12:07:07 +0200 (CEST) > > Guennadi Liakhovetski wrote: > > > > > 2.6.35 release is approaching and Ian hasn't found time yet to review > > > this > > > series, so I was wondering, maybe you could take it into mm at least for > > > now? > > > > Well I did, but I don't know how useful that was. > > > > WHo is the most appropriate tree-maintainer to review and possibly > > merge these? > > Samuel has already acked the MFD patch: > > http://article.gmane.org/gmane.linux.ports.sh.devel/7985 > > (please, add this his ack to the patch too). Most of the patches in the > series are SuperH- or SH-Mobile specific, which makes Paul (added to CC) > the perfect candidate to review them. There is only one tmio-specific > patch, and it is also the most complicated one. You or Paul can certainly > just follow it to verify, that it doesn't introduce any regressions. I can > also confirm it, because I also tested the patched driver without DMA > loaded, and it worked just like before in PIO mode. It would, however, be > great to test the patches on a non-sdhi hardware, of which none of us, > probably, has any. I added Philipp Zabel to CC, who has contributed a few > patches to tmio_mmc in the past, perhaps, he still has access to the > hardware and could test these patches. > I don't have any problems taking all of the SH and SDHI related bits, but since they all depend on the tmio_mmc change I haven't picked them up yet. They'll likely continue to sit in my patch queue until something happens with the tmio_mmc changes. Given the response times we've had with any tmio related changes in the past I'm not exactly betting on a speedy resolution.. -- 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
Re: [PATCH 0/9 v3] add DMA support to tmio_mmc, using dmaengine API, use it on SH
On Tue, May 11, 2010 at 12:07:07PM +0200, Guennadi Liakhovetski wrote: > 2.6.35 release is approaching and Ian hasn't found time yet to review this > series, so I was wondering, maybe you could take it into mm at least for > now? > Note that the tmio_mmc tree has also been dropped from -next due to being unreachable. I'm not sure how this impacts the pending changes, though. -- 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
Re: [PATCH 1/8] SH: constify multiple DMA related objects and references to them
On Wed, Apr 21, 2010 at 05:36:49PM +0200, Guennadi Liakhovetski wrote: > Lists of DMA channels and slaves are not changed, make them constant. Besides, > SH7724 channel and slave configuration of both DMA controllers is identical, > remove the extra copy of the configuration data. I've applied this one, thanks. -- 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
Re: [PATCH 00/07] sh: SuperH Mobile SDHI changes
On Fri, Oct 02, 2009 at 11:21:58AM +0900, Magnus Damm wrote: > sh: SuperH Mobile SDHI changes > > [PATCH 01/07] mfd: Add SuperH Mobile SDHI platform driver > [PATCH 02/07] mmc: Add SuperH to the tmio-mmc Kconfig > [PATCH 03/07] mmc: Remove const from tmio-mmc platform data > [PATCH 04/07] sh: SDHI platform data to the Migo-R board > [PATCH 05/07] sh: SDHI platform data to the AP325RXA board > [PATCH 06/07] sh: SDHI platform data to the SE7724 board > [PATCH 07/07] sh: SDHI platform data to the kfr2r09 board > > These patches contain the SuperH specific changes needed for > the tmio-mmc driver to work with SuperH Mobile SDHI hardware. > > The tmio-mmc patch 0001-MMC-hardware-abstraction-for-CNF-area.patch > by Ian Molton is needed for correct run time behaviour. Without > this patch the tmio-mmc probe() fails gracefully. > > I suggest merging the series in the SuperH tree. Not sure about > the best way to merge the patch by Ian. > > Signed-off-by: Magnus Damm At least patch 3/7 depends on Ian's patch being merged first, so there's little point in merging this series until that hits upstream. So I'll hold off on this for now. -- 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
