On Wed, Apr 20, 2011 at 2:47 AM, Wolfram Sang wrote:
>
>> BTW, Are there reason to omit the sdhci-s3c.c? Maybe Mr. Jung will handle it.
>
> The difference is that sdhci-s3c.c was more like a fork of sdhci-pltfm while
> the others were users of it. With the new interface, s3c can be converted
> us
Hi Tony,
> Add a driver for Elan Digital System's VUB300 chip
> which is a USB connected SDIO/SDmem/MMC host controller.
> A VUB300 chip enables a USB 2.0 or USB 1.1 connected host
> computer to use SDIO/SD/MMC cards without the need for
> a directly connected, for example via PCI, SDIO host
> con
Thanks to all for clarifications. Since everyone is convinced, that that
idle function in mmc bus.c is appropriate, I restored it and managed to
achieve my goals also without it by adjusting the platform runtime pm and
power domain prototype support.
But I still need those "cheating" calls to
Hi Mark,
On Tue, Apr 19 2011, Mark Brown wrote:
> Commit 373e6a (mmc: sdhci: R1B command handling + MMC_CAP_ERASE) moved the
> handling of SDHCI_QUIRK_TIMEOUT_USES_SDCLK from sdhci_calc_timeout() to
> sdhci_add_host(). This causes division by zero errors on at least the S3C
> SDHCI controller as t
On Tue, Apr 19, 2011 at 12:44 PM, Mark Brown
wrote:
> Commit 373e6a (mmc: sdhci: R1B command handling + MMC_CAP_ERASE) moved the
> handling of SDHCI_QUIRK_TIMEOUT_USES_SDCLK from sdhci_calc_timeout() to
> sdhci_add_host(). This causes division by zero errors on at least the S3C
> SDHCI controller
> BTW, Are there reason to omit the sdhci-s3c.c? Maybe Mr. Jung will handle it.
The difference is that sdhci-s3c.c was more like a fork of sdhci-pltfm while
the others were users of it. With the new interface, s3c can be converted using
pltfm more easily. If somebody is willing to do that, this i
Commit 373e6a (mmc: sdhci: R1B command handling + MMC_CAP_ERASE) moved the
handling of SDHCI_QUIRK_TIMEOUT_USES_SDCLK from sdhci_calc_timeout() to
sdhci_add_host(). This causes division by zero errors on at least the S3C
SDHCI controller as the quirk implementation needs host->clock set to work
but
On Tue, Apr 19, 2011 at 2:39 AM, Arnd Bergmann wrote:
> On Tuesday 19 April 2011, Andrei Warkentin wrote:
>
>> So maybe this should be a blacklist for known bad cards. And the
>> entire support should be a "default-N" compile option for MMCs (not
>> SDs). That way someone who just does an "make ol
Hi Per..
2011/4/11 Per Forlin :
> On 9 April 2011 13:55, Jae hoon Chung wrote:
>> Hi Per..
>>
>> I'm applied your patch..and sent the patch about dw_mmc.c.
>> I think good this approach..
>>
> Do you have any test results from the mmc_tests I added?
> I am interested in the results.
I didn't tes
On Tue, 19 Apr 2011, Guennadi Liakhovetski wrote:
> On Tue, 19 Apr 2011, Ohad Ben-Cohen wrote:
>
> > On Tue, Apr 19, 2011 at 1:46 PM, Guennadi Liakhovetski
> > wrote:
> > > MMC bus PM operations implement a .runtime_idle() method, which calls
> > > pm_runtime_suspend(), but this call is not bala
On Tue, Apr 19, 2011 at 4:23 PM, Guennadi Liakhovetski
wrote:
> Seeing a "struct dev_pm_ops" instance with .runtime_suspend(),
> .runtime_resume(), and .runtime_idle() methods I understand, that
> "suspend" and "resume" are two counterparts, that balance each other. Now
> with "idle" I am not sure
On Tue, 19 Apr 2011, Ohad Ben-Cohen wrote:
> On Tue, Apr 19, 2011 at 1:46 PM, Guennadi Liakhovetski
> wrote:
> > MMC bus PM operations implement a .runtime_idle() method, which calls
> > pm_runtime_suspend(), but this call is not balanced by a resume
> > counterpart,
>
> What's the exact flow yo
On Tuesday 19 April 2011, Tony Olech wrote:
> What is wrong in wanting to support non-technical users?
> Especially since there are no backward compatible issues
> involved at all.
It's good to support non-technical users. Things that are
bad about your patch are:
* Have interfaces that work only
Hi,
BTW, Are there reason to omit the sdhci-s3c.c? Maybe Mr. Jung will handle it.
Thank you,
Kyungmin Park
On Tue, Apr 19, 2011 at 7:20 PM, Wolfram Sang wrote:
> Hi Shawn,
>
> On Fri, Mar 25, 2011 at 04:48:46PM +0800, Shawn Guo wrote:
>> Here are what the patch set does.
>>
>> * Remove .probe a
On Tue, Apr 19, 2011 at 1:46 PM, Guennadi Liakhovetski
wrote:
> MMC bus PM operations implement a .runtime_idle() method, which calls
> pm_runtime_suspend(), but this call is not balanced by a resume
> counterpart,
What's the exact flow you refer to ?
> which causes problems with repeated card-p
On Tue, 2011-04-19 at 14:10 +0200, Arnd Bergmann wrote:
> On Tuesday 19 April 2011, Tony Olech wrote:
> > The purpose of this read-only interface is for VUB300 support
> > staff to obtain information from our customers. Our customers
> > are not like the people on this list. If you have ever tried
On Tuesday 19 April 2011, Tony Olech wrote:
> The purpose of this read-only interface is for VUB300 support
> staff to obtain information from our customers. Our customers
> are not like the people on this list. If you have ever tried
> to do telephone support you would appreciate the difficulty
>
Adding support for runtime power-management to the MMCIF driver allows
it to save power as long as no card is present. System-wide power
management has been verified with experimental PM patches on AP4-
based systems.
Signed-off-by: Guennadi Liakhovetski
---
With this patch and with the patch to
MMC bus PM operations implement a .runtime_idle() method, which calls
pm_runtime_suspend(), but this call is not balanced by a resume
counterpart, which causes problems with repeated card-plug and driver-load
cycles. Removing this method fixes the disbalance.
Signed-off-by: Guennadi Liakhovetsk
On Fri, Mar 25, 2011 at 04:48:51PM +0800, Shawn Guo wrote:
> The structure sdhci_pltfm_data is not necessarily to be in a public
> header like include/linux/mmc/sdhci-pltfm.h, so the patch moves it
> into drivers/mmc/host/sdhci-pltfm.h and eliminates the former one.
>
> Signed-off-by: Shawn Guo
> config MMC_SDHCI_ESDHC_IMX
> - bool "SDHCI platform support for the Freescale eSDHC i.MX controller"
> + bool "SDHCI support for the Freescale eSDHC i.MX controller"
> depends on ARCH_MX25 || ARCH_MX35 || ARCH_MX5
> depends on MMC_SDHCI
> - select MMC_SDHCI_PLTFM
> +
> +static int __devinit sdhci_esdhc_probe(struct platform_device *pdev)
> +{
> + struct sdhci_host *host;
> + int ret;
> +
> + host = sdhci_pltfm_init(pdev, &sdhci_esdhc_pdata);
> + if (!host)
> + return -ENOMEM;
Just noticed: Since pltfm_init may fail due to various r
On Fri, Mar 25, 2011 at 04:48:48PM +0800, Shawn Guo wrote:
> The patch is to migrate the use of sdhci_of_host and sdhci_of_data
> to sdhci_pltfm_host and sdhci_pltfm_data, so that the former pair can
> be eliminated.
>
> Signed-off-by: Shawn Guo
> ---
[...]
> diff --git a/drivers/mmc/host/sdhci
On Fri, Mar 25, 2011 at 04:48:47PM +0800, Shawn Guo wrote:
> The patch turns the common stuff in sdhci-pltfm.c into functions, and
> add device drivers their own .probe and .remove which in turn call
> into the common functions, so that those sdhci-pltfm device drivers
> register itself and keep a
Hi Shawn,
On Fri, Mar 25, 2011 at 04:48:46PM +0800, Shawn Guo wrote:
> Here are what the patch set does.
>
> * Remove .probe and .remove hooks from sdhci-pltfm.c and make it be
> a pure common helper function providers.
> * Add .probe and .remove hooks for sdhci pltfm drivers sdhci-cns3xxx,
>
On Tue, 2011-03-15 at 17:23 +0100, Arnd Bergmann wrote:
> On Thursday 10 March 2011, Tony Olech wrote:
...
> > +static ssize_t __show_operating_mode(struct vub300_mmc_host *vub300,
> > + struct mmc_host *mmc, char *buf)
> > +{
> > + int usb_packet_size = vub3
On Tuesday 19 April 2011, Andrei Warkentin wrote:
> So maybe this should be a blacklist for known bad cards. And the
> entire support should be a "default-N" compile option for MMCs (not
> SDs). That way someone who just does an "make oldconfig" will see
> "CONFIG_MMC_BLK_CMD23 - I/O performance i
27 matches
Mail list logo
