Re: New MMC maintainer needed
On Fri, 31 Jul 2009 11:54:07 +0100 Matt Fleming m...@console-pimps.org wrote: On Fri, Jul 31, 2009 at 12:26:23PM +0200, Pierre Ossman wrote: [PATCH 0/32] mmc and omap_hsmmc patches http://marc.info/?t=124722953900010r=1w=2 I haven't looked through these at all. The ones affecting the core probably need some thorough reviews. I did notice the patch to say which cards a controller supports though, and I'm very sceptical about that one. The scanning process should work anyway, and the performance impact should be negligible as it is only on init. So that patch only adds complexity and confusion IMO. How much complexity does it really add? Surely it's better to give the host controller driver writers the ability to not entertain supporting some cards if they cannot be used? If they want to avoid the scanning process for certain cards, why not let them? Let's look at the pros and cons of this: Con: - The scanning code gets less clear as you increase the number of possible paths through it. - Different systems will have different init sequences, possibly provoking bugs in the cards. - Host driver writers now have more capability bits they have to consider. And these might be less than obvious since SD/MMC/SDIO are normally compatible so these bits seem useless. - With the current logic (which was better in the first version), normal drivers will have to explicitly state that they work as intended by setting all bits. Pro: - A slightly reduced scanning time. I simply don't see it as being worth it. Linux patches generally need to provide the answer to Why?, not just be able to avoid Why not?. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature
Re: New MMC maintainer needed
http://marc.info/?t=124722953900010r=1w=2 I haven't looked through these at all. The ones affecting the core probably need some thorough reviews. I did notice the patch to say which cards a controller supports though, and I'm very sceptical about that one. The scanning process should work anyway, and the performance impact should be negligible as it is only on init. So that patch only adds complexity and confusion IMO. I think that's it, but don't be afraid to search the archives for anything else that doesn't seem to have been getting any attention. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature
Re: New MMC maintainer needed
On Wed, 22 Jul 2009 15:17:44 -0700 Andrew Morton a...@linux-foundation.org wrote: Thanks, Pierre. Until and unless someone else steps up I can act as maintainer of last resort for MMC. As I'm presently doing for fbdev, hwmon, rtc, spi, gpio, i2o and about 1000 other identifiable subsystems. I'm not falling of the face of the earth here, so people can still cc me on MMC patches, although I probably cannot answer all of them. I don't want to be the bottle neck that keeps MMC patches and discussions moving at a glacial speed, which is the situation we're in today. Fortunately, MMC doesn't appear to have its own mailing list so I'll actually get to see the patches. I do monitor a couple of subsystem-specific lists (fbdev, hwmon) but the delays can be awful - a month or two. MMC discussions tend to often be very system specific, which makes lists such as the arm kernel list more appropriate. Also, I've always tried to steer people to LKML as it allows others to keep a casual eye on things. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature
Re: New MMC maintainer needed
On Thu, 23 Jul 2009 01:08:08 +0100 Ian Molton i...@mnementh.co.uk wrote: Pierre - do you have a bunch of MMC spec-type docs around? I've lost all but the few sparse datasheets for TMIO that I had, so some docs covering protocol / commands would be useful. Any references / downloads that you know of? I use the public specs from sdcard.org for more or less everything. I also have a MMC 4 spec, which was generously donated to me by Nokia. Unfortunately I am not allowed to pass that on. I can look things up for people if they have specific questions though. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature
Re: New MMC maintainer needed
I'll try to compose a list of outstanding discussions and patches so that people know what needs attention. I'll try to get that done in the next few days. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature
New MMC maintainer needed
I'm afraid the time has come for me to step down as maintainer for the MMC/SD/SDIO subsystem and for someone else to take over the rudder. It is no secret that I haven't been able to give the maintainer role the resources it required, and as a result it has gone from being a fun hobby to a burdensome chore. I was hoping it was a temporary slump, but this has been the norm for over a year now, so it's time for me to throw in the towel. I don't have any clear nominees for a replacement, but if you feel that you are in a position to take over the maintainer role then please raise your hand. I only have a few patches in my queue right now and I can push those off to Linus before I quit. There are however a lot of unhandled messages that need attention. I can provide a list once a successor has been named. I realise that you have put a lot of time and effort into the patches you send me and I am truly sorry that I haven't been able to handle them better. Hopefully me stepping down means that we get someone who can actually take care of everything in a timely manner. I haven't decided what to do with the sdhci maintainership yet. Right now I only know I need a break and freeing myself from the MMC maintainer role is the first step. Hopefully I can return as a developer in the future. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature
Re: [PATCH 1/2] MMC Agressive clocking framework v3
On Sun, 21 Jun 2009 22:05:18 +0200 Linus Walleij linus.ml.wall...@gmail.com wrote: 2009/6/18 Linus Walleij linus.wall...@stericsson.com: diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig (...) + Of unsure, say N. However the rest of the patch is as I intended. I'll send a V4 pronto if you want that for the current merge window. I'm trying to squeeze you in, but time is short so I'm afraid I can't give you any guarantees. :/ Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature
Re: [PATCH 1/2] MMC Agressive clocking framework v2
On Tue, 2 Jun 2009 14:36:28 +0200
Linus Walleij linus.ml.wall...@gmail.com wrote:
This patch modified the MMC core code to optionally call the
set_ios() operation on the driver with the clock frequency set
to 0 to gate the hardware block clock (and thus the MCI clock)
for an MMC host controller after a grace period of at least 8
MCLK cycles. It is inspired by existing clock gating code found
in the OMAP and Atmel drivers and brings this up to the host
abstraction. Gating is performed before and after any MMC request
or IOS operation, the other optional host operations will not
ungate/gate the clock since they do not necessary touch the
actual host controller hardware.
It exemplifies by implementing this for the MMCI/PL180 MMC/SD
host controller, but it should be simple to switch OMAP and
Atmel over to using this instead.
Signed-off-by: Linus Walleij linus.wall...@stericsson.com
---
This looks pretty good. We might want to make it more runtime
configurable in the future, but this lays a nice groundwork. It's also
nicely commented to boot. :)
The only thing that concerns me is the locking and reference counting.
Wouldn't it be sufficient to enable the clock around requests? Or
when the host lock is grabbed? Either version would remove the need for
both clk_users and clk_lock. I think it would also remove a lot of the
special logic you have.
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index ab37a6d..6ae2156 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -14,3 +14,14 @@ config MMC_UNSAFE_RESUME
This option is usually just for embedded systems which use
a MMC/SD card for rootfs. Most people should say N here.
+config MMC_CLKGATE
+ bool MMC host clock gaing (EXPERIMENTAL)
+ depends on EXPERIMENTAL
+ help
+ This will attempt to agressively gate the clock to the MMC host,
+ which typically also will gate the MCI clock to the card. This
+ is done to save power due to gating off the logic and bus noise
+ when MMC is not in use. Your host driver has to support this in
+ order for it to be of any use.
The last sense isn't true anymore, is it?
+
+ Of unsure, say N.
If :)
+/*
+ * Internal work. Work to disable the clock at some later point.
+ */
+static void mmc_clk_disable_work(struct work_struct *work)
+{
+ struct mmc_host *host = container_of(work, struct mmc_host,
+ clk_disable_work);
+
+ mmc_clk_disable_delayed(host);
+}
I think I did a bad job explaining my comments about this the last
time. What I was trying to say was that why have this
mmc_clk_disable_work() when you could give mmc_clk_disable_delayed()
directly to the workqueue?
+/*
+ * mmc_clk_remove - shut down clock gating code
+ * @host: host with potential hardware clock to control
+ */
+static inline void mmc_clk_remove(struct mmc_host *host)
+{
+ if (cancel_work_sync(host-clk_disable_work))
+ mmc_clk_disable_delayed(host);
+ BUG_ON(host-clk_users 0);
+}
I'm not sure why you call mmc_clk_disable_delayed() here. Is the clock
properly enabled again when this function exits? It should be, but the
disable call there has me confused.
@@ -80,6 +235,8 @@ struct mmc_host *mmc_alloc_host(int extra, struct
device *dev)
host-class_dev.class = mmc_host_class;
device_initialize(host-class_dev);
+ mmc_clk_alloc(host);
+
spin_lock_init(host-lock);
init_waitqueue_head(host-wq);
INIT_DELAYED_WORK(host-detect, mmc_rescan);
@@ -156,6 +313,8 @@ void mmc_remove_host(struct mmc_host *host)
device_del(host-class_dev);
led_trigger_unregister_simple(host-led);
+
+ mmc_clk_remove(host);
}
EXPORT_SYMBOL(mmc_remove_host);
alloc and remove don't form a nice pair. I suggest add/remove or
perhaps init/exit.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
signature.asc
Description: PGP signature
Re: [PATCH 1/2] MMC Agressive clocking framework v2
On Sat, 13 Jun 2009 14:45:09 +0200 Linus Walleij linus.ml.wall...@gmail.com wrote: 2009/6/2 Linus Walleij linus.ml.wall...@gmail.com: This patch modified the MMC core code to optionally call the set_ios() operation on the driver with the clock frequency set to 0 to gate the hardware block clock (and thus the MCI clock) have you had a chance to look at this for the current merge window Pierre? Not yet, but I plan to. Sorry about the delay. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org rdesktop, core developer http://www.rdesktop.org TigerVNC, core developer http://www.tigervnc.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature
Re: [PATCH v4 6/6] Atmel MCI: Driver for Atmel on-chip MMC controllers
On Sat, 28 Jun 2008 15:31:44 +0200 Haavard Skinnemoen [EMAIL PROTECTED] wrote: Haavard Skinnemoen [EMAIL PROTECTED] wrote: Tests 7 and 9 are not supported by the card, so I can't do much about it except go through all the cards I have available and see if one of them supports this test. Turns out none of my 12 cards of various brands and models support this test. Do you know some specific model I can try? Of the set I have here, only one supported partial writes. A prototype samsung MMC 4.2 card. It has the markings MM8GH04GNACA-9A on it. A quick google doesn't turn up anything, but some other new Samsung MMC card might have good odds. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature
Re: [PATCH v4 6/6] Atmel MCI: Driver for Atmel on-chip MMC controllers
On Sat, 28 Jun 2008 14:43:13 +0200 Haavard Skinnemoen [EMAIL PROTECTED] wrote: Tests 15 and 17 return -EILSEQ instead of -ETIMEDOUT. The at91_mci driver has the same problem, and I think it's a hardware issue -- the controller wrongly flags a CRC error instead of a data timeout error if the card doesn't respond with any CRC status after a write. I don't know how to work around that problem. If that's how the hardware behaves, then EILSEQ will have to do. The test is more about forcing people to do proper error management in the driver than anything else. Have a check that you don't report a bad bytes_xfered though. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature
