Re: [patch 0/6] ps3vram driver patches

Re: [patch 0/6] ps3vram driver patches

[Arnd Bergmann]

On Tuesday 06 January 2009, Geoff Levand wrote:
> Patches 3-6 are minor cleanups suggested by Arnd Bergmann.  I have left two
> of Arnd's sugestions, implementing the driver as a block device, similar to
> the axonram driver, and eliminating the need to ioremap.  These will require
> a significant re-work.

My complaint about the ioremap was just about the type of the mapping,
not something fundamental. Please just replace ioremap(addr, size) with
ioremap_flags(addr, size, _PAGE_NO_CACHE) in order to get a mapping without
the guarded bit.

If everyone else thinks that doing the ps3vram driver as an MTD rather than
a block device is acceptable, I have no further objections. Thanks for
following up on my other comments.

Acked-by: Arnd Bergmann <arnd@arndb.de>

	Arnd <><

Re: [patch 0/6] ps3vram driver patches

[Geoff Levand]

Arnd Bergmann wrote:
> On Tuesday 06 January 2009, Geoff Levand wrote:
>> Patches 3-6 are minor cleanups suggested by Arnd Bergmann.  I have left two
>> of Arnd's sugestions, implementing the driver as a block device, similar to
>> the axonram driver, and eliminating the need to ioremap.  These will require
>> a significant re-work.
> 
> My complaint about the ioremap was just about the type of the mapping,
> not something fundamental. Please just replace ioremap(addr, size) with
> ioremap_flags(addr, size, _PAGE_NO_CACHE) in order to get a mapping without
> the guarded bit.

OK, I see.  I'll post a patch.

Geert and I were discussing actually removing the direct write to the XDR
memory, and so the need for that ioremap, as the mapping is just used in
ps3vram_erase(), which seems could be removed.

> If everyone else thinks that doing the ps3vram driver as an MTD rather than
> a block device is acceptable, I have no further objections. Thanks for
> following up on my other comments.

I want to get it converted to a block device, and I will work towards
that, but it will take some time.  As it is, it is very useful for typical
systems that are running full desktops like gmome or KDE and do a lot of
swapping.  Many of the distros now use it, and users want it.

-Geoff

Re: [patch 0/6] ps3vram driver patches

[Arnd Bergmann]

On Wednesday 07 January 2009, Geoff Levand wrote:

> Geert and I were discussing actually removing the direct write to the XDR
> memory, and so the need for that ioremap, as the mapping is just used in
> ps3vram_erase(), which seems could be removed.

Ah, I see. I also forgot to mention that the ioremap_flags change should
only be done for actual memory regions, but *not* for memory mapped I/O
registers.

> I want to get it converted to a block device, and I will work towards
> that, but it will take some time.  As it is, it is very useful for typical
> systems that are running full desktops like gmome or KDE and do a lot of
> swapping.  Many of the distros now use it, and users want it.

Yes, fine by me.

	Arnd <><

Re: [patch 0/6] ps3vram driver patches

[Geert Uytterhoeven]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 1577 bytes --]

On Wed, 7 Jan 2009, Arnd Bergmann wrote:
> On Wednesday 07 January 2009, Geoff Levand wrote:
> > Geert and I were discussing actually removing the direct write to the XDR
> > memory, and so the need for that ioremap, as the mapping is just used in
> > ps3vram_erase(), which seems could be removed.

ps3vram_erase() writes all ones to the memory, as that's what done when
erasing real FLASH. I do not know if the MTD layer can handle it if we don't
"erase" it to ones.

David?

> Ah, I see. I also forgot to mention that the ioremap_flags change should
> only be done for actual memory regions, but *not* for memory mapped I/O
> registers.

This is DDR memory for the RSX.

> > I want to get it converted to a block device, and I will work towards
> > that, but it will take some time.  As it is, it is very useful for typical
> > systems that are running full desktops like gmome or KDE and do a lot of
> > swapping.  Many of the distros now use it, and users want it.
> 
> Yes, fine by me.

One disadvantage of this approach is that it makes life more difficult for
distro maintainers: their userland has to support both the MTD and the block
version.

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010