Re: [PATCH 13/14] Pramfs: Write Protection
2009/6/18 Paul Mundt let...@linux-sh.org: On Wed, Jun 17, 2009 at 06:58:00PM +0200, Marco wrote: Jared Hulbert wrote: Why not just fix flush_tlb_range()? If an arch has a flush_tlb_kernel_page() that works then it stands to reason that the flush_tlb_kernel_range() shouldn't work with minimal effort, no? flush_tlb_kernel_page() is a new one to me, it doesn't have any mention in Documentation/cachetlb.txt anyways. Many of the flush_tlb_kernel_range() implementations do ranged checks with tunables to determine whether it is more expensive to selectively flush vs just blowing the entire TLB away. Likewise, there is no reason why those 4 architectures can not just shove that if (end = start + PAGE_SIZE) check in the beginning of their flush_tlb_kernel_range() and fall back on flush_tlb_kernel_page() for those cases. Hiding this in generic code is definitely not the way to go. Ok I'll change that function at arch level and I'll remove the ifdef, I'll call only flush_tlb_kernel_page(), but I'd like to know what is the opinion of the arch maintainers to do that. (Who is the maintainer of H8300 arch?) No, you should call flush_tlb_kernel_range() and just fix up the flush_tlb_kernel_range() calls to wrap in to flush_tlb_kernel_page(). As far as the kernel is concerned, flush_tlb_kernel_page() is not a standard interface, as it has no mention in Documentation/cachetlb.txt. flush_tlb_page() and flush_tlb_kernel_range() on the other hand are both standard interfaces. Oops, my fault. I meant flush_tlb_kernel_range not the page version, sorry. I agree with you. H8300 is a nommu platform, so it has no TLB to flush. Yoshinori Sato is the maintainer. Consult the MAINTAINERS file, that's what it is there for. I know the MAINTAINERS file but for h8300 there isn't an exactly indication (/arch/h8300 as for the other archs). 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
2009/6/17 Chris Friesen cfrie...@nortel.com: Marco wrote: This is a second attempt at mainlining Pramfs. The first attempt was back in early 2004 by MontaVista. Since then the kernel code has almost been completely rewritten. So my first item on the list was porting the code on a recent kernel version. After that I added the XIP support. Now some FAQs: What is the goal of this filesystem? Many embedded systems have a block of non-volatile RAM separate from normal system memory, i.e. of which the kernel maintains no memory page descriptors. For such systems it would be beneficial to mount a fast read/write filesystem over this I/O memory, for storing frequently accessed data that must survive system reboots and power cycles. An example usage might be system logs under /var/log, or a user address book in a cell phone or PDA. Nice to see something like this submitted to mainline. We use something similar to provide persistent storage for crash recovery debug data for boards which don't have local storage. In many cases kdump can provide good information, but it's not sufficient for flight recorder type data if the kernel gets rebooted by a hardware mechanism (watchdog, for instance) that doesn't give a pre-interrupt. I'm very happy that this fs has the approval of the kernel community. :) I'm a bit concerned about your PTE modifications on every write though...we do things like log every exception and scheduler operation to persistent memory, and I think the overhead of changing the protection on every write would be a killer. Instead, we make extensive use of checksums at various different levels so that the recovery app can determine which data is valid. It's a trade-off between security and performance. Checksum it's a good way to understand if a data is valid or not (indeed it's used in this fs), but with this schema you can prevent the system to do something wrong. This option, however, can be enabled/disabled via kconfig. Also, I'd like to ensure that direct memory access to the memory area would be available. What do you exactly mean with this? Can you explain to me a bit deeper? There are some things (like the sched/exception logging mentioned above) where we want to make accesses as fast as possible. Chris 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
[PATCH 2/2] Modify MMCI/PL180 to handle agressive clocking v3
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
Re: Representing Embedded Architectures at the Kernel Summit
On Jun 17, 2009, at 9:51 PM, Paul Mundt wrote: On Wed, Jun 17, 2009 at 09:31:48AM -0500, Kumar Gala wrote: One topic that was partially touched on was dealing with various memories on embedded systems. We have several sram based allocators in the kernel for various different arch's: - Blackfin sram allocator arch/blackfin/mm/sram-alloc.c - Lite5200(b) sram allocator arch/powerpc/sysdev/bestcomm/sram.c - AVR32 sram allocator arch/avr32/mach-at32ap/at32ap700x.c and arch/ avr32/mach-at32ap/include/mach/sram.h - Potential davinci sram allocator There maybe others. SH does this through NUMA on SRAM blocks that are anywhere from 128kB to 64MB. Some of our SMP configurations have upwards of a dozen of these blocks. Do you really have that much on chip memory? - k -- 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: Representing Embedded Architectures at the Kernel Summit
On Thu, Jun 18, 2009 at 09:59:20PM -0500, Kumar Gala wrote: On Jun 17, 2009, at 9:51 PM, Paul Mundt wrote: On Wed, Jun 17, 2009 at 09:31:48AM -0500, Kumar Gala wrote: One topic that was partially touched on was dealing with various memories on embedded systems. We have several sram based allocators in the kernel for various different arch's: - Blackfin sram allocator arch/blackfin/mm/sram-alloc.c - Lite5200(b) sram allocator arch/powerpc/sysdev/bestcomm/sram.c - AVR32 sram allocator arch/avr32/mach-at32ap/at32ap700x.c and arch/ avr32/mach-at32ap/include/mach/sram.h - Potential davinci sram allocator There maybe others. SH does this through NUMA on SRAM blocks that are anywhere from 128kB to 64MB. Some of our SMP configurations have upwards of a dozen of these blocks. Do you really have that much on chip memory? Is this really a serious question? If we didn't, I would not have mentioned it. -- 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
