>-----Original Message-----
>From: Mike Frysinger [mailto:[email protected]]
>Sent: Friday, January 15, 2010 3:07 PM
>To: Song, Barry
>Cc: [email protected];
>[email protected]
>Subject: Re: [Linux-kernel-commits] [8168] trunk: mtd-physmap:
>add support users can assign the probe type in board files
>
>On Fri, Jan 15, 2010 at 01:11, Song, Barry wrote:
>>From: Mike Frysinger [mailto:[email protected]]
>>>On Thu, Jan 14, 2010 at 23:35, Song, Barry wrote:
>>>> I don't think ram driver is not a right choice for a real
>>>>flash. Its write and erase is fake.
>>>
>>>i mean when we're doing a ROM kernel. the plat-ram driver lets you
>>>specify a specific probe type (mtd-rom) which lets you disable
>>>write/erase funcs. a flash doing kernel XIP shouldnt be allowed to
>>>write/erase any sector.
>>
>> Even though plat-ram supports assigning probe, physmap needs
>this support too.
>>
>> For xip kernel to suppot writable flash, how about one of
>the following two ways:
>
>with parallel flashes, it is my understanding that most commands put
>the flash into an unreadable state until the command has been
>completed. any transition to an unreadable state is unacceptable for
>a XIP kernel since we're executing out of it.
>
>> 1. let user assign cfi (or other interfaces) in board files
>directly, and let cfi ignore the detection.
>
>i dont think that would fly with mainline. their answer would be
>"stop complicating correct common code to account for dumb users".
>
>> 2. relocation detection codes into RAM?
>
>i think there's way too many async events that can occur and be
>implicitly called by the handlers for this to be feasible.
Basically, I agree with you about the writing issue of flash. I will send a
email to mtd to get some feedback.
>-mike
>
_______________________________________________
Linux-kernel-commits mailing list
[email protected]
https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits
