On 01/10/2015 06:52 PM, Richard Weinberger wrote:
> Convert the driver to blk-mq.
> Beside of moving to the modern block interface this change boosts
> also the performance of the driver.
>
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron NAND 256MiB 3,3V 8-bit
> nand: 256
On 01/26/2015 04:55 PM, Richard Weinberger wrote:
Am 14.01.2015 um 09:39 schrieb Richard Weinberger:
Am 14.01.2015 um 01:23 schrieb Jens Axboe:
Which is as I suspected, you'll do each segment to the length specified,
hence you don't need to track the returned count from blk_rq_map_sg().
Thank
Am 14.01.2015 um 09:39 schrieb Richard Weinberger:
> Am 14.01.2015 um 01:23 schrieb Jens Axboe:
>> Which is as I suspected, you'll do each segment to the length specified,
>> hence you don't need to track the returned count from blk_rq_map_sg().
>
> Thanks a lot for the kind explanation, Jens!
> I
Am 14.01.2015 um 01:23 schrieb Jens Axboe:
> On 01/13/2015 04:36 PM, Richard Weinberger wrote:
>>
>>
>> Am 14.01.2015 um 00:30 schrieb Jens Axboe:
If I understand you correctly it can happen that blk_rq_bytes() returns
more bytes than blk_rq_map_sg() allocated, right?
>>>
>>> No, the numb
On 01/13/2015 04:36 PM, Richard Weinberger wrote:
>
>
> Am 14.01.2015 um 00:30 schrieb Jens Axboe:
>>> If I understand you correctly it can happen that blk_rq_bytes() returns
>>> more bytes than blk_rq_map_sg() allocated, right?
>>
>> No, the number of bytes will be the same, no magic is involved
Am 14.01.2015 um 00:30 schrieb Jens Axboe:
>> If I understand you correctly it can happen that blk_rq_bytes() returns
>> more bytes than blk_rq_map_sg() allocated, right?
>
> No, the number of bytes will be the same, no magic is involved :-)
Good to know. :)
> But lets say the initial request
On 01/13/2015 04:17 PM, Richard Weinberger wrote:
> Am 13.01.2015 um 23:54 schrieb Jens Axboe:
blk_rq_map_sg returns the number of entries actually mapped, which
might be smaller than the number passed in due to merging.
>>>
>>> Yep, but the ubi_sql has a fixed number of scatterlist entri
Am 13.01.2015 um 23:54 schrieb Jens Axboe:
>>> blk_rq_map_sg returns the number of entries actually mapped, which
>>> might be smaller than the number passed in due to merging.
>>
>> Yep, but the ubi_sql has a fixed number of scatterlist entries,
>> UBI_MAX_SG_COUNT.
>> And I limit it also to that
On 01/13/2015 03:51 PM, Richard Weinberger wrote:
> Am 13.01.2015 um 17:25 schrieb Christoph Hellwig:
>>> + struct ubi_sgl usgl;
>>
>> Btw, what's in struct ubi_sgl? Can't find that in my tree.
>
> "[PATCH 1/2] UBI: Add initial support for scatter gather" adds it.
>
> /**
> * struct ubi_sgl -
Am 13.01.2015 um 17:25 schrieb Christoph Hellwig:
>> +struct ubi_sgl usgl;
>
> Btw, what's in struct ubi_sgl? Can't find that in my tree.
"[PATCH 1/2] UBI: Add initial support for scatter gather" adds it.
/**
* struct ubi_sgl - UBI scatter gather list data structure.
* @list_pos: current
> + struct ubi_sgl usgl;
Btw, what's in struct ubi_sgl? Can't find that in my tree.
> +static void ubiblock_do_work(struct work_struct *work)
> +{
> + int ret;
> + struct ubiblock_pdu *pdu = container_of(work, struct ubiblock_pdu,
> work);
> + struct request *req = blk_mq_rq_fro
Convert the driver to blk-mq.
Beside of moving to the modern block interface this change boosts
also the performance of the driver.
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron NAND 256MiB 3,3V 8-bit
nand: 256MiB, SLC, page size: 2048, OOB size: 64
root@debian-armhf:~# dd
12 matches
Mail list logo
