Have any other opinion?
On 01/22/2013 09:18 PM, Jaehoon Chung wrote:
> When card removed, then didn't complete the previously data.
> (It didn't wakeup any interrupt.)
> If card is removed, then we can assume to complete the previously data.
> And wakeup the interrupt for wait_event of data.
>
>
On Thu, Jan 31, 2013 at 08:31:20AM +0800, Shawn Guo wrote:
> On Wed, Jan 30, 2013 at 09:11:21PM +0100, Thierry Reding wrote:
> > Commit 3f175a6 (mmc: sdhci-esdhc-imx: remove ESDHC_CD_GPIO handling from
> > IO accessory) removed all the code that was using these variables, so it
> > is safe to drop
Looks good to me.
Reviewed-by: Subhash Jadavani
On 1/30/2013 12:00 PM, Seungwon Jeon wrote:
> Hi Konstantin.
>
> Could you check this patch with [2/2]?
> [PATCH 2/2] mmc: block: don't start new request when the card is removed
>
> mmcqd is often sleeping with acquiring the claim(mmc_claim_host)
On Thu, 31 Jan 2013, Arnd Bergmann wrote:
> On Wednesday 30 January 2013, Guennadi Liakhovetski wrote:
> > On Wed, 30 Jan 2013, Arnd Bergmann wrote:
> >
> > > On Wednesday 30 January 2013, Guennadi Liakhovetski wrote:
> > > > > This means, that a multi-platform driver like, e.g. SDHCI cannot use
commit 4d55c5a1 added preset value support and enable it by default
during sd card init.
below are the enhancements introduced by this patch:
1. In current code, preset value is enabled after setting clock finished,
which means the clock is manually set by driver firstly and
then suddenly switched
On Wed, Jan 30, 2013 at 09:27:18AM +, Arnd Bergmann wrote:
> On Wednesday 30 January 2013, Matt Porter wrote:
> > Adds a dma_request_slave_channel_compat() wrapper which accepts
> > both the arguments from dma_request_channel() and
> > dma_request_slave_channel(). Based on whether the driver is
On Wed, Jan 30, 2013 at 09:24:00AM +, Arnd Bergmann wrote:
> On Wednesday 30 January 2013, Matt Porter wrote:
> > +Optional properties:
> > +- dmas: List of DMA controller phandle and DMA request ordered
> > + pairs. One tx and one rx pair is required for each chip
> > + select.
>
On Wed, Jan 30, 2013 at 09:40:52AM +0200, Andy Shevchenko wrote:
> On Wed, Jan 30, 2013 at 8:41 AM, Matt Porter wrote:
> > On Mon, Jan 28, 2013 at 09:27:24PM +0200, Andy Shevchenko wrote:
> >> On Tue, Jan 15, 2013 at 10:32 PM, Matt Porter wrote:
> >> > Adds support for parsing the TI EDMA DT data
On Wed, Jan 30, 2013 at 09:11:21PM +0100, Thierry Reding wrote:
> Commit 3f175a6 (mmc: sdhci-esdhc-imx: remove ESDHC_CD_GPIO handling from
> IO accessory) removed all the code that was using these variables, so it
> is safe to drop them.
>
> Signed-off-by: Thierry Reding
Thanks for the fixing, T
Hi,
On Wed, Jan 30 2013, Arnd Bergmann wrote:
>> > From the code, I understand that of_get_named_gpio() would return a gpio
>> > line with the polarity already inverted if it's specified that way,
>>
>> Sorry, don't understand. of_get_named_gpio() just returns a GPIO number,
>> not GPIO level. I
On Wednesday 30 January 2013, Guennadi Liakhovetski wrote:
> On Wed, 30 Jan 2013, Arnd Bergmann wrote:
>
> > On Wednesday 30 January 2013, Guennadi Liakhovetski wrote:
> > > > This means, that a multi-platform driver like, e.g. SDHCI cannot use
> > > > the
> > > > gpio "flags" cell and has to fa
Commit 3f175a6 (mmc: sdhci-esdhc-imx: remove ESDHC_CD_GPIO handling from
IO accessory) removed all the code that was using these variables, so it
is safe to drop them.
Signed-off-by: Thierry Reding
---
drivers/mmc/host/sdhci-esdhc-imx.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/dri
Question:
Has any testing been done to determine the maximum data throughput to/from
a MMC device; assuming the MMC device takes zero time to complete tasks?
Put another way - at what level of IOPS does the kernel/driver become the
bottleneck, instead of the storage device?
Sorry if the questi
When irq_of_parse_and_map() returns an error, it does as zero. But in
mmc_spi_get_pdata(), the error return case is compared against NO_IRQ. This
might work where NO_IRQ is zero (defaults to zero when undefined, as on MIPS)
but not where NO_IRQ is sth. different, e.g. on ARM, where it is -1.
This
On Wed, 30 Jan 2013, Arnd Bergmann wrote:
> On Wednesday 30 January 2013, Guennadi Liakhovetski wrote:
> > > This means, that a multi-platform driver like, e.g. SDHCI cannot use the
> > > gpio "flags" cell and has to fall-back to always use "*-inverted"
> > > properties. Same holds for any other
Hi Balaji,
On Wed, Jan 30 2013, Balaji T K wrote:
> I am interested in maintaining omap_hsmmc,
> Please add me as Maintainer and Thanks Venkat for his support
>
> From: Balaji T K
> Subject: [PATCH] mmc: omap_hsmmc: MAINTAINERS: update
>
> Update Maintainer email for omap_hsmmc,
> as Venkatraman
On Tuesday 29 January 2013 03:03 AM, Chris Ball wrote:
Hi,
On Wed, Jan 16 2013, Venkatraman S wrote:
The specified email id is no longer in service.
Update the OMAP HSMMC entry from the MAINTAINERS file as I will
no longer be able to maintain this driver.
Signed-off-by: Venkatraman S
---
MA
On Wednesday 30 January 2013, Guennadi Liakhovetski wrote:
> > This means, that a multi-platform driver like, e.g. SDHCI cannot use the
> > gpio "flags" cell and has to fall-back to always use "*-inverted"
> > properties. Same holds for any other multi-arch driver, using GPIOs. So,
> > we're stu
On Wed, 30 Jan 2013, Guennadi Liakhovetski wrote:
> Hi Arnd
>
> Thanks for your input.
>
> On Wed, 30 Jan 2013, Arnd Bergmann wrote:
>
> > On Monday 28 January 2013, Chris Ball wrote:
> > > On Wed, Jan 23 2013, Guennadi Liakhovetski wrote:
> > > > +cd-inverted and wp-inverted properties are dep
Hi Arnd
Thanks for your input.
On Wed, 30 Jan 2013, Arnd Bergmann wrote:
> On Monday 28 January 2013, Chris Ball wrote:
> > On Wed, Jan 23 2013, Guennadi Liakhovetski wrote:
> > > +cd-inverted and wp-inverted properties are deprecated ans shouldn't be
> > > used,
> > > +instead pleaseuse the OF
On Monday 28 January 2013, Chris Ball wrote:
> On Wed, Jan 23 2013, Guennadi Liakhovetski wrote:
> > +cd-inverted and wp-inverted properties are deprecated ans shouldn't be
> > used,
> > +instead pleaseuse the OF_GPIO_ACTIVE_LOW flag in respective GPIO bindings.
> > Note,
> > +that the default (a
Hi,
On Wed, Jan 30 2013, Guennadi Liakhovetski wrote:
>> On Thu, Jan 24 2013, Guennadi Liakhovetski wrote:
>> > I tried to keep this binding similar to others, that I proposed in "mmc:
>> > add DT bindings for more MMC capability flags." Actually, the above is
>> > indeed wrong, I would call it
Hi Chris
On Thu, 24 Jan 2013, Chris Ball wrote:
> Hi,
>
> On Thu, Jan 24 2013, Guennadi Liakhovetski wrote:
> > I tried to keep this binding similar to others, that I proposed in "mmc:
> > add DT bindings for more MMC capability flags." Actually, the above is
> > indeed wrong, I would call it
On Wed, Jan 30, 2013 at 02:00:27AM -0500, Matt Porter wrote:
> Convert dmaengine channel requests to use
> dma_request_slave_channel_compat(). This supports the DT case of
> platforms requiring channel selection from either the OMAP DMA or
> the EDMA engine. AM33xx only boots from DT and is the onl
On Wednesday 30 January 2013, Matt Porter wrote:
> + dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap);
> + of_dma_controller_register(dev->of_node,
> + of_dma_simple_xlate,
> + &edma_filter
On Wednesday 30 January 2013, Matt Porter wrote:
> Adds a dma_request_slave_channel_compat() wrapper which accepts
> both the arguments from dma_request_channel() and
> dma_request_slave_channel(). Based on whether the driver is
> instantiated via DT, the appropriate channel request call will be
>
On Wednesday 30 January 2013, Matt Porter wrote:
> +Optional properties:
> +- dmas: List of DMA controller phandle and DMA request ordered
> + pairs. One tx and one rx pair is required for each chip
> + select.
The binding looks ok, but the wording is slightly incorrect here:
strictly
If the CD/WP-GPIOs are not provided by the SoC's GPIO controller,
we need to handle the case where omap_hsmmc is probed earlier than
the GPIO controller chosen in the device tree.
Fix this by checking the return value of of_get_named_gpio against
-EPROBE_DEFER and passing it through to the probe f
Signed-off-by: Philip Rakity
Signed-off-by: Kevin Liu
---
drivers/mmc/host/sdhci-pxav3.c |2 ++
include/linux/platform_data/pxa_sdhci.h |2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 3d20c10..3bc86bf 10
Some soc/platform need specific handling for signal voltage
switch. For example, mmp2/mmp3 need to set the AIB IO domain
control register accordingly.
Use regulator notifier to do this.
Signed-off-by: Philip Rakity
Signed-off-by: Kevin Liu
---
drivers/mmc/host/sdhci.c |6 ++
include/li
commit 4d55c5a1 added preset value support and enable it by default
during sd card init.
below are the enhancements introduced by this patch:
1. In current code, preset value is enabled after setting clock finished,
which means the clock is manually set by driver firstly and
then suddenly switched
This patchset aim to do several misc code enhancements for sdhci.c
This patchset based on previous patchset:
[PATCH v10 00/12] mmc: sdhci: fixes and enhancements
Introduction for the patches:
[PATCH 1/7] mmc: sdhci: avoid redundant loops in sdhci_irq for card
[PATCH 3/7] mmc: sdhci: remove redun
If CONFIG_REGULATOR is NOT defined, host->vmmc will be NULL and
regulator_is_supported_voltage will return 0.
so the check can be removed.
Signed-off-by: Kevin Liu
---
drivers/mmc/host/sdhci.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdh
With preset value enabled, SD clock should be reset before enable
both high speed and UHS-I mode. Current code enable them one by one
and do two continuous times of clock disable/enable. The operation
can be combined into once to save time and make code cleaner.
1. disable clock ->
2. enable high
If vqmmc 1.8v check return error, for example vqmmc is a dummy regulator,
UHS-I mode should also be disabled as return 0.
Signed-off-by: Kevin Liu
---
drivers/mmc/host/sdhci.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/s
After cleared the handled irq status, sdhci_irq will check the interrupt
status again at end. And it will loop back to handle the irq if any new
interrupts happened.
But card int will keep active all the time since its status is readonly
and can't be cleared at that time. So in case card int happen
36 matches
Mail list logo
