Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
Why is an entire filesystem needed, instead of simply a block driver if the ramdisk driver cannot be used? From documentation: A relatively straight-forward solution is to write a simple block driver for the non-volatile RAM, and mount over it any disk-based filesystem such as ext2/ext3, reiserfs, etc. But the disk-based fs over non-volatile RAM block driver approach has some drawbacks: 1. Disk-based filesystems such as ext2/ext3 were designed for optimum performance on spinning disk media, so they implement features such as block groups, which attempts to group inode data into a contiguous set of data blocks to minimize disk seeking when accessing files. For RAM there is no such concern; a file's data blocks can be scattered throughout the media with no access speed penalty at all. So block groups in a filesystem mounted over RAM just adds unnecessary complexity. A better approach is to use a filesystem specifically tailored to RAM media which does away with these disk-based features. This increases the efficient use of space on the media, i.e. more space is dedicated to actual file data storage and less to meta-data needed to maintain that file data. So... what is the performance difference between ext2 and your new filesystem? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/14] Pramfs: Include files
Arnd Bergmann wrote:
On Saturday 13 June 2009, Sam Ravnborg wrote:
+ union {
+ struct {
+ /*
+ * ptr to row block of 2D block pointer array,
+ * file block #'s 0 to (blocksize/4)^2 - 1.
+ */
+ off_t row_block;
It is my understanding that we shall use: __kernel_off_t
in exported headers.
That is a correct understanding in general, however this case is
different, because it describes an on-disk data structure,
not a kernel to user space interface. Here, __kernel_off_t is just
as wrong as off_t, because it will differ between 32 and 64 bit
architectures, making the fs layout incompatible. I'd suggest
simply defining this as __u64.
Moreover, file system layout should be described in terms of
big-endian or little-endian types (e.g. __be64 or __le64),
together with the right accessor functions.
Arnd
I was thinking about your comment and I think I'll use __kernel_off_t
for the exported headers. I know that it will differ between 32 and 64
bit architectures, but for this kind of fs there isn't any compatibility
problem at layout level. You cannot remove a chip of RAM from a board
32bit little endian and attach it to a board with a cpu 64bit big
endian, the memory isn't a disk. Indeed, I see that tmpfs uses simply
unsigned long in the exported header file without any problems to
little or big endian.
Regards,
Marco
--
To unsubscribe from this list: send the line unsubscribe linux-embedded 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/14] Pramfs: Persistent and protected ram filesystem
Pavel Machek wrote: Why is an entire filesystem needed, instead of simply a block driver if the ramdisk driver cannot be used? From documentation: A relatively straight-forward solution is to write a simple block driver for the non-volatile RAM, and mount over it any disk-based filesystem such as ext2/ext3, reiserfs, etc. But the disk-based fs over non-volatile RAM block driver approach has some drawbacks: 1. Disk-based filesystems such as ext2/ext3 were designed for optimum performance on spinning disk media, so they implement features such as block groups, which attempts to group inode data into a contiguous set of data blocks to minimize disk seeking when accessing files. For RAM there is no such concern; a file's data blocks can be scattered throughout the media with no access speed penalty at all. So block groups in a filesystem mounted over RAM just adds unnecessary complexity. A better approach is to use a filesystem specifically tailored to RAM media which does away with these disk-based features. This increases the efficient use of space on the media, i.e. more space is dedicated to actual file data storage and less to meta-data needed to maintain that file data. So... what is the performance difference between ext2 and your new filesystem? About the space you can read a detailed documentation on the site: http://pramfs.sourceforge.net/pramfs-spec.html In addition I can do an example of compact information: ext2 uses directory entry objects (dentries) to associate file names to inodes, and these dentries are located in data blocks owned by the parent directory. In pramfs, directory inode's do not need to own any data blocks, because all dentry information is contained within the inode's themselves. From performance point of view: Sometimes ago I uploaded here (http://elinux.org/Pram_Fs) some benchmark results to compare the performance with and without XIP in a real embedded environment with bonnie++. You could use it as reference point. I hope I've answered to your question. Regards, Marco -- To unsubscribe from this list: send the line unsubscribe linux-embedded 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] MMC Agressive clocking framework v3
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. Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-embedded 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] 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 00/14] Pramfs: Persistent and protected ram filesystem
1. Disk-based filesystems such as ext2/ext3 were designed for optimum performance on spinning disk media, so they implement features such as block groups, which attempts to group inode data into a contiguous set of data blocks to minimize disk seeking when accessing files. For RAM there is no such concern; a file's data blocks can be scattered throughout the media with no access speed penalty at all. So block groups in a filesystem mounted over RAM just adds unnecessary complexity. A better approach is to use a filesystem specifically tailored to RAM media which does away with these disk-based features. This increases the efficient use of space on the media, i.e. more space is dedicated to actual file data storage and less to meta-data needed to maintain that file data. So... what is the performance difference between ext2 and your new filesystem? About the space you can read a detailed documentation on the site: http://pramfs.sourceforge.net/pramfs-spec.html I do not see any numbers there. Do you think you can save significant memory when storing for example kernel source trees? In addition I can do an example of compact information: ext2 uses directory entry objects (dentries) to associate file names to inodes, I'm not sure that on-disk directory entry == dentry. and these dentries are located in data blocks owned by the parent directory. In pramfs, directory inode's do not need to own any data blocks, because all dentry information is contained within the inode's themselves. How do you handle hard-links, then? From performance point of view: Sometimes ago I uploaded here (http://elinux.org/Pram_Fs) some benchmark results to compare the performance with and without XIP in a real embedded environment with bonnie++. You could use it as reference point. Well, so XIP helps. ext2 can do XIP too, IIRC. Is your performance better than ext2? Wait... those numbers you pointed me... claim to be as slow as 13MB/sec. That's very very bad. My harddrive is faster than that. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Modify MMCI/PL180 to handle agressive clocking v4
This adds a few clk_enable()/clk_disable() calls to the MMCI
driver so as to handle an set_ios() request with clock
frequency set to 0 as an instruction to gate the block clock.
This also breaks out the clock setting code into its own
function to simplify the set_ios() function a bit.
Signed-off-by: Linus Walleij linus.wall...@stericsson.com
---
drivers/mmc/host/mmci.c | 78 ++
1 files changed, 57 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 36875dc..d9f5c9a 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -37,8 +37,34 @@
static unsigned int fmax = 515633;
+/*
+ * This must be called with host-lock held
+ */
+static void mmci_set_clkreg(struct mmci_host *host, unsigned int desired)
+{
+ u32 clk = 0;
+
+ if (desired) {
+ if (desired = host-mclk) {
+ clk = MCI_CLK_BYPASS;
+ host-cclk = host-mclk;
+ DBG(host, MMCI: bypass clock divider, cclk = %u Hz\n,
host-cclk);
+ } else {
+ clk = host-mclk / (2 * desired) - 1;
+ if (clk = 256)
+ clk = 255;
+ host-cclk = host-mclk / (2 * (clk + 1));
+ DBG(host, MMCI: divide cclk to %u Hz (divide %u by
%u)\n, host-cclk, host-mclk, clk);
+ }
+ if (host-hw_designer == 0x80)
+ clk |= MCI_FCEN; /* Bug fix in ST IP block */
+ clk |= MCI_CLK_ENABLE;
+ }
+ writel(clk, host-base + MMCICLOCK);
+}
+
static void
-mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
+ mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
{
writel(0, host-base + MMCICOMMAND);
@@ -418,22 +444,7 @@ static void mmci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
{
struct mmci_host *host = mmc_priv(mmc);
- u32 clk = 0, pwr = 0;
-
- if (ios-clock) {
- if (ios-clock = host-mclk) {
- clk = MCI_CLK_BYPASS;
- host-cclk = host-mclk;
- } else {
- clk = host-mclk / (2 * ios-clock) - 1;
- if (clk = 256)
- clk = 255;
- host-cclk = host-mclk / (2 * (clk + 1));
- }
- if (host-hw_designer == 0x80)
- clk |= MCI_FCEN; /* Bug fix in ST IP block */
- clk |= MCI_CLK_ENABLE;
- }
+ u32 pwr = 0;
if (host-plat-translate_vdd)
pwr |= host-plat-translate_vdd(mmc_dev(mmc), ios-vdd);
@@ -464,12 +475,23 @@ static void mmci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
}
}
- writel(clk, host-base + MMCICLOCK);
+ spin_lock(host-lock);
+
+ if (ios-clock == 0) {
+ clk_disable(host-clk);
+ } else {
+ clk_enable(host-clk);
+ mmci_set_clkreg(host, ios-clock);
+ }
if (host-pwr != pwr) {
host-pwr = pwr;
+ clk_enable(host-clk);
writel(pwr, host-base + MMCIPOWER);
+ clk_disable(host-clk);
}
+
+ spin_unlock(host-lock);
}
static const struct mmc_host_ops mmci_ops = {
@@ -615,6 +637,8 @@ static int __devinit mmci_probe(struct amba_device *dev,
void *id)
host-timer.expires = jiffies + HZ;
add_timer(host-timer);
+ /* The first IOS will turn the clock on again */
+ clk_disable(host-clk);
return 0;
irq0_free:
@@ -646,17 +670,22 @@ static int __devexit mmci_remove(struct amba_device *dev)
mmc_remove_host(mmc);
+ /* framework may have gated the block clock */
+ clk_enable(host-clk);
+
writel(0, host-base + MMCIMASK0);
writel(0, host-base + MMCIMASK1);
writel(0, host-base + MMCICOMMAND);
writel(0, host-base + MMCIDATACTRL);
+ clk_disable(host-clk);
+
free_irq(dev-irq[0], host);
free_irq(dev-irq[1], host);
iounmap(host-base);
- clk_disable(host-clk);
+
clk_put(host-clk);
mmc_free_host(mmc);
@@ -677,8 +706,11 @@ static int mmci_suspend(struct amba_device *dev,
pm_message_t state)
struct mmci_host *host = mmc_priv(mmc);
ret = mmc_suspend_host(mmc, state);
- if (ret == 0)
+ if (ret == 0) {
+ clk_enable(host-clk);
writel(0, host-base + MMCIMASK0);
+ clk_disable(host-clk);
+ }
}
return ret;
@@ -692,7 +724,11 @@ static int
[PATCH 1/2] MMC Agressive clocking framework v4
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.
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
ChangeLog v3-v4:
Fixed a single spelling error.
---
drivers/mmc/core/Kconfig | 11 +++
drivers/mmc/core/core.c| 35 +
drivers/mmc/core/core.h|2 +
drivers/mmc/core/debugfs.c | 10 ++-
drivers/mmc/core/host.c| 165 +++-
drivers/mmc/core/host.h|3 +
include/linux/mmc/host.h |9 +++
7 files changed, 232 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index ab37a6d..5372fc9 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.
+
+ If unsure, say N.
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 2649117..e9093b6 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -113,6 +113,8 @@ void mmc_request_done(struct mmc_host *host, struct
mmc_request *mrq)
if (mrq-done)
mrq-done(mrq);
+
+ mmc_clk_disable(host);
}
}
@@ -173,6 +175,7 @@ mmc_start_request(struct mmc_host *host, struct mmc_request
*mrq)
mrq-stop-mrq = mrq;
}
}
+ mmc_clk_enable(host);
host-ops-request(host, mrq);
}
@@ -447,6 +450,38 @@ void mmc_set_clock(struct mmc_host *host, unsigned int hz)
mmc_set_ios(host);
}
+#ifdef CONFIG_MMC_CLKGATE
+/*
+ * This gates the clock by setting it to 0 Hz.
+ */
+void mmc_gate_clock(struct mmc_host *host)
+{
+ host-clk_old = host-ios.clock;
+ host-ios.clock = 0;
+ mmc_set_ios(host);
+}
+
+/*
+ * This restores the clock from gating by using the cached
+ * clock value.
+ */
+void mmc_ungate_clock(struct mmc_host *host)
+{
+ /*
+* We should previously have gated the clock, so the clock
+* shall be 0 here!
+* The clock may however be 0 during intialization,
+* when some request operations are performed before setting
+* the frequency. When ungate is requested in that situation
+* we just ignore the call.
+*/
+ if (host-clk_old) {
+ BUG_ON(host-ios.clock);
+ mmc_set_clock(host, host-clk_old);
+ }
+}
+#endif
+
/*
* Change the bus mode (open drain/push-pull) of a host.
*/
diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index c819eff..ee27f81 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -27,6 +27,8 @@ void mmc_detach_bus(struct mmc_host *host);
void mmc_set_chip_select(struct mmc_host *host, int mode);
void mmc_set_clock(struct mmc_host *host, unsigned int hz);
+void mmc_gate_clock(struct mmc_host *host);
+void mmc_ungate_clock(struct mmc_host *host);
void mmc_set_bus_mode(struct mmc_host *host, unsigned int mode);
void mmc_set_bus_width(struct mmc_host *host, unsigned int width);
u32 mmc_select_voltage(struct mmc_host *host, u32 ocr);
diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
index 610dbd1..1a969bd 100644
--- a/drivers/mmc/core/debugfs.c
+++ b/drivers/mmc/core/debugfs.c
@@ -149,11 +149,17 @@ void mmc_add_host_debugfs(struct mmc_host *host)
host-debugfs_root = root;
if (!debugfs_create_file(ios, S_IRUSR, root, host, mmc_ios_fops))
- goto err_ios;
+ goto err_remove_files;
+
+#ifdef CONFIG_MMC_CLKGATE
+ if (!debugfs_create_u32(clk_delay, (S_IRUSR | S_IWUSR),
+ root, host-clk_delay))
+ goto err_remove_files;
+#endif
return;
-err_ios:
+err_remove_files:
debugfs_remove_recursive(root);
host-debugfs_root = NULL;
err_root:
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 5e945e6..792bbfe
