Re: [PATCH] mmc: agressive clocking framework v9

2010-11-09 Thread Linus Walleij
2010/11/9 Jaehoon Chung : > i tested the clocking framework v8...at samsung SOC > just this patch worked S/W enable/disable..not H/W clock.. Yes that is the intention. It only handles soft clock gating. > So i agreed the philip's opinion.. > i also think that need some approach about H/W clock g

Re: [PATCH 2.6.35]: Add new device IDs and registers for MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) cards.

2010-11-09 Thread Chris Ball
Hi Jennifer, On Tue, Nov 09, 2010 at 02:28:00PM +0800, Jennifer Li (TP) wrote: > Hi, > > This can make MMC/SD driver work on O2 chip. > > Best regards, > Jennifer Thanks for the patch submission. There are some changes that need to be made before this can be accepted into the kernel -- you can

[PATCH] sdhci: Fix crash on boot with C0 stepping Moorestown platforms

2010-11-09 Thread Alan Cox
Try again with the header fixed properly this time (thought I'd fixed it the last time - sorry) From: Jacob Pan SDHC2 is newly added in C0 stepping of Langwell. Without the Moorestown specific quirk, the default pci_probe will be called and crash the kernel. This patch unblocks the crash proble

Re: [PATCH 1/1]sdhci-pxa: support tune_timming for various cards

2010-11-09 Thread Eric Miao
On Tue, Nov 9, 2010 at 10:17 PM, zhangfei gao wrote: > Haojian, > > Would you help review, since arch/arm/plat-pxa/include/plat/sdhci.h is > updated, thanks > > From 6619812b749aa12ebf0efbe057366c2f99051bfe Mon Sep 17 00:00:00 2001 > From: Zhangfei Gao > Date: Tue, 2 Nov 2010 07:37:44 -0400 > Sub

[PATCH 1/1]sdhci-pxa: support tune_timming for various cards

2010-11-09 Thread zhangfei gao
Haojian, Would you help review, since arch/arm/plat-pxa/include/plat/sdhci.h is updated, thanks >From 6619812b749aa12ebf0efbe057366c2f99051bfe Mon Sep 17 00:00:00 2001 From: Zhangfei Gao Date: Tue, 2 Nov 2010 07:37:44 -0400 Subject: [PATCH] sdhci-pxa: support tune_timming for various cards

Re: [PATCH 1/1]sdhci-pxa: support tune_timming for various cards

2010-11-09 Thread Chris Ball
Hi, Here are some obvious changes: On Tue, Nov 09, 2010 at 09:17:21AM -0500, zhangfei gao wrote: > Haojian, > > Would you help review, since arch/arm/plat-pxa/include/plat/sdhci.h is > updated, thanks > > >From 6619812b749aa12ebf0efbe057366c2f99051bfe Mon Sep 17 00:00:00 2001 > From: Zhangfei G

Re: [PATCH] sdhci: Fix crash on boot with C0 stepping Moorestown platforms

2010-11-09 Thread Chris Ball
Hi Alan, On Tue, Nov 09, 2010 at 01:57:29PM +, Alan Cox wrote: > Try again with the header fixed properly this time (thought I'd fixed it > the last time - sorry) > > From: Jacob Pan > > SDHC2 is newly added in C0 stepping of Langwell. Without the Moorestown > specific quirk, the default pc

Re: [PATCH] SDHC2 is newly added in C0 stepping of Langwell. Without the Moorestown

2010-11-09 Thread Chris Ball
Hi Alan, On Tue, Nov 09, 2010 at 11:27:19AM +, Alan Cox wrote: > From: Jacob Pan > > specific quirk, the default pci_probe will be called and crash the kernel. > > This patch unblocks the crash problem on C0 by using the same probing > function as HC1, which limits the number of slots to on

Re: [patch] sdhci: remove SDHCI_QUIRK_FORCE_1_BIT_DATA

2010-11-09 Thread Philip Rakity
On Nov 9, 2010, at 4:27 AM, Anton Vorontsov wrote: > Hi, > > On Tue, Nov 09, 2010 at 06:37:58AM -0500, zhangfei gao wrote: >> Here is patch to remove SDHCI_QUIRK_FORCE_1_BIT_DATA, which only used >> in drivers/mmc/host/sdhci-of-core.c. >> The reason is quirk is too valuable resource, the type is

Re: can we remove the quirk SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN ?

2010-11-09 Thread Wolfram Sang
Hi Philip, > Doesn't the platform data hold the specific board specific quirks ? If we agree on not calling it "quirks" but "configuration", then we may in deed be talking about the very same thing :) > Can you provide an example of how you see the platform data being > used. Sad thing is that

[PATCH] SDHC2 is newly added in C0 stepping of Langwell. Without the Moorestown

2010-11-09 Thread Alan Cox
From: Jacob Pan specific quirk, the default pci_probe will be called and crash the kernel. This patch unblocks the crash problem on C0 by using the same probing function as HC1, which limits the number of slots to one. Signed-off-by: Jacob Pan Signed-off-by: Alan Cox --- drivers/mmc/host/sd

Re: Fwd: can we remove the quirk SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN ?

2010-11-09 Thread Wolfram Sang
On Tue, Nov 09, 2010 at 03:45:15AM -0800, Philip Rakity wrote: > > reposting since we are discussing removing quirks. > > We could partition the quirks into one set for controller quirks and one set > for platform quirks. That would give us another 32 quirks. IMHO we need less quirks, not

Fwd: can we remove the quirk SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN ?

2010-11-09 Thread Philip Rakity
reposting since we are discussing removing quirks. We could partition the quirks into one set for controller quirks and one set for platform quirks. That would give us another 32 quirks. Philip Begin forwarded message: > From: Philip Rakity > Date: September 24, 2010 2:31:25 AM PDT > To

[patch] sdhci: remove SDHCI_QUIRK_FORCE_1_BIT_DATA

2010-11-09 Thread zhangfei gao
Hi, Xiaobo & Anton Here is patch to remove SDHCI_QUIRK_FORCE_1_BIT_DATA, which only used in drivers/mmc/host/sdhci-of-core.c. The reason is quirk is too valuable resource, the type is u32, while the highest is (1<<29) now. 1. MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA is opened by default in sdhci.

Re: [PATCH] sdhci: 8 bit widths - allow new QUIRK for 8 bit and v3 sd controller

2010-11-09 Thread Philip Rakity
If we support the idea of adding quirks after sdhc_add_host() is called then I support this patch. see below for minor change Philip On Nov 8, 2010, at 3:48 AM, zhangfei gao wrote: > On Mon, Nov 8, 2010 at 4:17 AM, Wolfram Sang wrote: This isn't a quirk, this is platform_data, no? >>>

Re: can we remove the quirk SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN ?

2010-11-09 Thread Philip Rakity
Doesn't the platform data hold the specific board specific quirks ? Can you provide an example of how you see the platform data being used. I think we are saying the same thing using different words but a code snippet would clarify this. Philip On Nov 9, 2010, at 3:55 AM, Wolfram Sang wrote:

Re: can we remove the quirk SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN ?

2010-11-09 Thread Alan Cox
I think I agree with Wolfram. Perhaps a much better model would be "Anyone who adds a quirk will have to figure out how to remove one" Several are trivial to remove and generalise into a couple of function overrides. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in

Re: can we remove the quirk SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN ?

2010-11-09 Thread Wolfram Sang
On Tue, Nov 09, 2010 at 12:08:35PM +, Alan Cox wrote: > I think I agree with Wolfram. Perhaps a much better model would be > > "Anyone who adds a quirk will have to figure out how to remove one" > > Several are trivial to remove and generalise into a couple of function > overrides. My favour

Re: [patch] sdhci: remove SDHCI_QUIRK_FORCE_1_BIT_DATA

2010-11-09 Thread Anton Vorontsov
Hi, On Tue, Nov 09, 2010 at 06:37:58AM -0500, zhangfei gao wrote: > Here is patch to remove SDHCI_QUIRK_FORCE_1_BIT_DATA, which only used > in drivers/mmc/host/sdhci-of-core.c. > The reason is quirk is too valuable resource, the type is u32, while > the highest is (1<<29) now. FYI, initially that

[PATCH v2] mxcmmc: update the regulator support code to the latest API

2010-11-09 Thread Alberto Panizzo
This fix also the build problem introduced by my previous patch due to not handled API changes introduced by commit: 99fc513 (mmc: Move regulator handling closer to core) Signed-off-by: Alberto Panizzo --- This patch apply to the current mmc-next branch drivers/mmc/host/mxcmmc.c | 20 ++

Re: [PATCH] mxcmmc: update the regulator support code to the latest API

2010-11-09 Thread Alberto Panizzo
On mar, 2010-11-09 at 11:14 +0100, Uwe Kleine-König wrote: > On Tue, Nov 09, 2010 at 11:09:50AM +0100, Alberto Panizzo wrote: > > > > This fix also the build problem introduced by my previous patch > > due to unhanded API changes introduced by > s/handed/handled/ ? > > > commit:99fc5131018cbdc3cf

Re: [PATCH] mmc: agressive clocking framework v9

2010-11-09 Thread Jaehoon Chung
Hi Linus.. i tested the clocking framework v8...at samsung SOC just this patch worked S/W enable/disable..not H/W clock.. So i agreed the philip's opinion.. i also think that need some approach about H/W clock gating.. Linus Walleij wrote: > Philip Rakity wrote: > >> I am concerned that having

Re: [PATCH 1/2] mmc: agressive clocking framework v8

2010-11-09 Thread Linus Walleij
Chris Ball wrote: > Done -- thanks very much for doing this! I fixed up a compile error > when CONFIG_MMC_CLKGATE=n: Thanks for the cleanup Chris, let's see if this one holds now then... :-) Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a m

Re: [PATCH] mxcmmc: update the regulator support code to the latest API

2010-11-09 Thread Uwe Kleine-König
On Tue, Nov 09, 2010 at 11:09:50AM +0100, Alberto Panizzo wrote: > > This fix also the build problem introduced by my previous patch > due to unhanded API changes introduced by s/handed/handled/ ? > commit:99fc5131018cbdc3cf42ce09fb394a4e8b053c74 Linus wants to have the commit shortlog for refere

[PATCH] mxcmmc: update the regulator support code to the latest API

2010-11-09 Thread Alberto Panizzo
This fix also the build problem introduced by my previous patch due to unhanded API changes introduced by commit:99fc5131018cbdc3cf42ce09fb394a4e8b053c74 Signed-off-by: Alberto Panizzo --- This patch apply to the current mmc-next branch drivers/mmc/host/mxcmmc.c | 20 1

Re: [PATCH] mxcmmc: Add the ability to bind a regulator to manage the MMC card voltage

2010-11-09 Thread Alberto Panizzo
On lun, 2010-11-08 at 23:12 +0100, Linus Walleij wrote: > 2010/11/2 Alberto Panizzo : > > > +static inline void mxcmci_init_ocr(struct mxcmci_host *host) > > +{ > > +#ifdef CONFIG_REGULATOR > > + host->vcc = regulator_get(mmc_dev(host->mmc), "vmmc"); > > + > > + if (IS_ERR(host->vcc))

[PATCH v2] mmc, sh: Move constants to sh_mmcif.h

2010-11-09 Thread Simon Horman
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: Yusuk

[PATCH] mmc, sh: Move constants to sh_mmcif.h

2010-11-09 Thread Simon Horman
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: Yusuk