linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Carsten Otte <cotte@de.ibm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Maxim Shchetynin <maxim@de.ibm.com>,
	linuxppc-dev@ozlabs.org, cbe-oss-dev@ozlabs.org
Subject: Re: [Cbe-oss-dev] [patch 3/5] cell: updated driver for DDR2 memory on AXON
Date: Tue, 26 Jun 2007 19:53:10 +0200	[thread overview]
Message-ID: <46815286.1010808@de.ibm.com> (raw)
In-Reply-To: <200706261821.06516.arnd@arndb.de>

Arnd Bergmann wrote:
> What will actually happen if you try to mount an axonram device with ext2?
> I suppose mount should fail with a proper error code if the block size is
> larger than 4kb, but does that happen?
> 
> If you have a 4k block size axonram device, the ext2 really should work
> using XIP as expected, including the mmap() operation.
> 
Absolutely. What's the symptom if you try mount -o xip? I am willing 
to fix any bugs that show in the ext2/xip code in that scenario...

>> We have the direct_access method here only because it is needed for the
>> azfs file-system, which we recommend to use for accessing the Axon's RAM
>> rather then ext2 or any other buffered file-systems.
> 
> I think I've understood what the problem is now. The generic xip code
> assumes that the data to be mapped has a 'struct page' in mem_map,
> and that it's part of the linear kernel mapping. This is actually
> true on s390, where it is currently used, but not for us. The point
> on s390 is that the kernel virtual address is _identical_ to the
> physical address, so it may never have shown up as a problem.
> 
> I'll talk to Carsten about this, he already had plans to remove
> the need for struct page from the filemap_xip infrastructure.
Removing the need for struct page is indeed impossible with current 
memory management because of the fact that VM_PFNMAP vmas have the 
downside that they require a linear physical image of the vma. Ext2 
does not comply to that requriement, a given file may be spread all 
over a media.

  reply	other threads:[~2007-06-26 17:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <OF39A5D2DB.6FC50A30-ONC1257306.0051B925-C1257306.0052040B@de.ibm.com>
2007-06-26 16:21 ` [Cbe-oss-dev] [patch 3/5] cell: updated driver for DDR2 memory on AXON Arnd Bergmann
2007-06-26 17:53   ` Carsten Otte [this message]
2007-06-26 17:38     ` Arnd Bergmann
2007-06-18 22:42 [patch 0/5] cell patches for 2.6.23 Arnd Bergmann
2007-06-18 22:42 ` [patch 3/5] cell: updated driver for DDR2 memory on AXON Arnd Bergmann
     [not found]   ` <20070619154812.GA20347@ps3linux.grid.fixstars.com>
2007-06-19 23:03     ` [Cbe-oss-dev] " Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46815286.1010808@de.ibm.com \
    --to=cotte@de.ibm.com \
    --cc=arnd@arndb.de \
    --cc=carsteno@de.ibm.com \
    --cc=cbe-oss-dev@ozlabs.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=maxim@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).