2011/10/24 Johan RUDHOLM :
>> I think the overlap between your patch and Andrei's
>> mmcblkXbootY/force_ro
>> node is going to be confusing -- one operates purely in the kernel and
>> the other is sent to the card. Do you have any proposal for making the
>> difference clearer?
>
> I concur, the s
2011/10/20 Praveen G K :
>>
>> So you did 10 back-to-back 64k transfers inside the request handling
>> routine, and you noticed that caused a smaller GC delay
>> rather than doing 10 separate multiblock 64k transfers the normal way?
> That's right. Even though the request is supposed to service o
2011/10/19 Praveen G K :
> Also, can somebody please tell me the significance of blk_end_request? Thanks.
> Why do we call this after every block read or write?
Because you want to update the struct request with the amount
written/read. If the entire
requested I/O range has been satiffied, blk_end
2011/10/6 Seungwon Jeon :
> Andrei E. Warkentin wrote:
>> Hi Seungwon,
>>
>> 2011/10/6 Seungwon Jeon :
>> > Adrian Hunter wrote:
>> >> On 08/09/11 10:29, Seungwon Jeon wrote:
>> >> > This patch adds cache feature of eMMC4.5 Spec.
>>
Hi Seungwon,
2011/10/6 Seungwon Jeon :
> Adrian Hunter wrote:
>> On 08/09/11 10:29, Seungwon Jeon wrote:
>> > This patch adds cache feature of eMMC4.5 Spec.
>> > If device supports cache capability, host can utilize some specific
>> > operations.
>> >
>> > Signed-off-by: Seungwon Jeon
>> > ---
I
HI NamJae,
2011/10/5 NamJae Jeon :
>
> How about changing patch like this ?
>
> if (ext_csd[EXT_CSD_BOOT_MULT] && mmc_boot_partition_access(card->host)) {
> for (idx = 0; idx < MMC_NUM_BOOT_PARTITION; idx++) {
> part_size = ext_csd[EXT_CSD_BOOT
Hi James,
2011/10/3 J Freyensee :
>
> The idea is the page cache is too generic for hand-held (i.e. Android)
> workloads. Page cache handles regular files, directories, user-swappable
> processes, etc, and all of that has to contend with the resource available
> for the page cache. This is speci
Hi James,
2011/9/30 J Freyensee :
>
> So I have a question on write behavior.
>
> Say mmc_blk_issue_rw_rq() is called. Say the mmc_queue *mq variable passed
> in is a write.
You mean the struct request?
> Say that write is buffered, delayed into being sent via
> mmc_wait_for_req() for 5 seconds
Hi Namjae,
2011/10/1 Namjae Jeon :
> It allows gerneral purpose partitions in MMC Device.
> And I try to simpliy make mmc_blk_alloc_parts using mmc_part structure
> suggested by Andrei Warkentin.
> After patching, we can see general purpose partitions like this.
>> cat /proc/partitions
>
Hi,
2011/9/28 Barry Song :
> From: Barry Song
>
> now we wait 1ms after every loop, in the worst case, 1ms will be wasted.
> that both decreases sd performance and increases cpu usage.
> This patch shorten the interval to 1us, then in the worst case, only 1us
> is wasted.
>
> Signed-off-by: Barry
Hi Namjae,
Why don't you update card->nr_parts inside mmc_part_add? You're making
this too complicated. There
is also no need for the part_cfg array.
2011/9/30 Namjae Jeon :
> It allows gerneral purpose partitions in MMC Device.
> And I try to simpliy make mmc_blk_alloc_parts using mmc_part struc
Hi James,
2011/9/29 J Freyensee :
> As I've been playing around with with buffering/caching, it seems to me an
> opportunity to simplify things in the MMC space is to eliminate the need for
> a mmc_blk_request struct or mmc_request struct. With looking through the
> mmc_blk_issue_rw_rq(), there i
2011/9/26 Seungwon Jeon :
> Andrei Warkentin wrote:
>> Hi Seungwon,
>>
>> - Original Message -
>> > From: "Seungwon Jeon"
>> > To: linux-mmc@vger.kernel.org
>> > Cc: "Chris Ball" , linux-samsung-...@vger.kernel.org,
>> "kgene kim" , "dh han"
>> > , "Seungwon Jeon"
>> > Sent: Monday, Septe
Hi Adrian,
2011/9/23 Adrian Hunter :
> In the case of a switch error, do not update partition
> config as though the switch succeeded, and ensure
> blk_end_request is called on the failed request.
>
> Signed-off-by: Adrian Hunter
> ---
> drivers/mmc/card/block.c | 16 +---
> 1 file
14 matches
Mail list logo
