From: Marek Vasut <marek.vasut@gmail.com>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: "David Woodhouse" <dwmw2@infradead.org>,
"Brian Norris" <computersforpeace@gmail.com>,
"Boris Brezillon" <boris.brezillon@free-electrons.com>,
"Richard Weinberger" <richard@nod.at>,
"Cyrille Pitchen" <cyrille.pitchen@atmel.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"Hauke Mehrtens" <hauke@hauke-m.de>,
"Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH V2] mtd: bcm47xxsflash: support reading flash out of mapping window
Date: Thu, 19 Jan 2017 22:30:21 +0100 [thread overview]
Message-ID: <78f2d03d-e916-c5ea-aea3-c1d860921e7d@gmail.com> (raw)
In-Reply-To: <CACna6ryfrDeYdMmLbOfeZNoA_EifPNKennXVBj3_bZk078c2Tw@mail.gmail.com>
On 01/17/2017 01:04 PM, Rafał Miłecki wrote:
> On 17 January 2017 at 12:49, Marek Vasut <marek.vasut@gmail.com> wrote:
>> On 01/17/2017 12:08 PM, Rafał Miłecki wrote:
>>> On 17 January 2017 at 12:00, Marek Vasut <marek.vasut@gmail.com> wrote:
>>>> On 01/17/2017 11:51 AM, Rafał Miłecki wrote:
>>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>>
>>>>> For reading flash content we use MMIO but it's possible to read only
>>>>> first 16 MiB this way. It's simply an arch design/limitation.
>>>>> To support flash sizes bigger than 16 MiB implement indirect access
>>>>> using ChipCommon registers.
>>>>> This has been tested using MX25L25635F.
>>>>>
>>>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>>>>> ---
>>>>> V2: Simplify line writing to buf
>>>>> Add some trivial comment for OPCODE_ST_READ4B
>>>>> Both requested by Marek
>>>>> ---
>>>>> drivers/mtd/devices/bcm47xxsflash.c | 12 +++++++++++-
>>>>> drivers/mtd/devices/bcm47xxsflash.h | 3 +++
>>>>> 2 files changed, 14 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/mtd/devices/bcm47xxsflash.c b/drivers/mtd/devices/bcm47xxsflash.c
>>>>> index 4decd8c..8d4c1db 100644
>>>>> --- a/drivers/mtd/devices/bcm47xxsflash.c
>>>>> +++ b/drivers/mtd/devices/bcm47xxsflash.c
>>>>> @@ -110,7 +110,17 @@ static int bcm47xxsflash_read(struct mtd_info *mtd, loff_t from, size_t len,
>>>>> if ((from + len) > mtd->size)
>>>>> return -EINVAL;
>>>>>
>>>>> - memcpy_fromio(buf, b47s->window + from, len);
>>>>> + if (from + len <= BCM47XXSFLASH_WINDOW_SIZE) {
>>>>> + memcpy_fromio(buf, b47s->window + from, len);
>>>>
>>>> One last nit, what if the read starts < 16 MiB and ends > 16 MiB ?
>>>> Shouldn't that use partly the windowed mode and partly the other mode?
>>>
>>> You'll lost 10ns*... or not as splitting it into 2 code paths could
>>> take longer, who knows. Most access are block aligned anyway. I don't
>>> think such corner case with doubtful gain is much worth considering &
>>> optimizing.
>>
>> So you can also read the first 16 MiB using the new method , right ?
>
> I could, but this could be noticeable in performance. Reading 16 MiB
> using slower method is different from reading what... a few KiB? Are
> you actually sure mtd does unaligned reads at all?
No, but I'm quite sure the code above can be pushed to misbehave and I'm
trying to confirm/refute that.
> Please let's argue about real problems and not few % performance in
> some corner case on some obsolete hardware with poor design.
OK, real issue:
$ dd if=/dev/mtdX of=/dev/null bs=32M
How will this driver handle it ?
--
Best regards,
Marek Vasut
next prev parent reply other threads:[~2017-01-19 21:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-16 22:09 [PATCH] mtd: bcm47xxsflash: support reading flash out of mapping window Rafał Miłecki
2017-01-17 3:18 ` Marek Vasut
2017-01-17 6:58 ` Rafał Miłecki
2017-01-17 9:49 ` Marek Vasut
2017-01-17 10:39 ` Rafał Miłecki
2017-01-17 10:49 ` Marek Vasut
2017-01-17 10:50 ` Rafał Miłecki
2017-01-17 10:56 ` Marek Vasut
2017-01-17 10:51 ` [PATCH V2] " Rafał Miłecki
2017-01-17 11:00 ` Marek Vasut
2017-01-17 11:08 ` Rafał Miłecki
2017-01-17 11:49 ` Marek Vasut
2017-01-17 12:04 ` Rafał Miłecki
2017-01-17 12:37 ` Rafał Miłecki
2017-01-19 21:31 ` Marek Vasut
2017-01-19 21:30 ` Marek Vasut [this message]
2017-01-23 8:14 ` Rafał Miłecki
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=78f2d03d-e916-c5ea-aea3-c1d860921e7d@gmail.com \
--to=marek.vasut@gmail.com \
--cc=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=cyrille.pitchen@atmel.com \
--cc=dwmw2@infradead.org \
--cc=hauke@hauke-m.de \
--cc=linux-mtd@lists.infradead.org \
--cc=rafal@milecki.pl \
--cc=richard@nod.at \
--cc=zajec5@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.