From: Vignesh Raghavendra <vigneshr@ti.com>
To: Heiko Thiery <heiko.thiery@gmail.com>, <Tudor.Ambarus@microchip.com>
Cc: juliensu@mxic.com.tw, ycllin@mxic.com.tw,
Michael Walle <michael@walle.cc>,
linux-mtd@lists.infradead.org, p.yadav@ti.com,
zhengxunli@mxic.com.tw
Subject: Re: spi-nor: maxronix MX25L12835F support
Date: Mon, 1 Mar 2021 16:22:52 +0530 [thread overview]
Message-ID: <9263ef4d-7944-00bb-8e2f-b7d33e5aab87@ti.com> (raw)
In-Reply-To: <CAEyMn7bY9CisxoWcpF=zR+DYJpW+=EeWLGE_gAB3WK9hvkcuJQ@mail.gmail.com>
Hi,
On 2/28/21 3:22 AM, Heiko Thiery wrote:
[...]
>>>> +#define SPI_NOR_AIM_SFDP BIT(23) /* Try to parse SFDP. Used by flashes
>>>> + * that share the same JEDEC-ID, but
>>>> + * where a flash defines the SFDP tables
>>>> + * and the other doesn't.
>>>> + */
>>>>
>>>> /* Part specific fixup hooks. */
>>>> const struct spi_nor_fixups *fixups;
>>>> diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c
>>>> index 9203abaac229..1ebce775eae4 100644
>>>> --- a/drivers/mtd/spi-nor/macronix.c
>>>> +++ b/drivers/mtd/spi-nor/macronix.c
>>>> @@ -50,7 +50,8 @@ static const struct flash_info macronix_parts[] = {
>>>> { "mx25u4035", INFO(0xc22533, 0, 64 * 1024, 8, SECT_4K) },
>>>> { "mx25u8035", INFO(0xc22534, 0, 64 * 1024, 16, SECT_4K) },
>>>> { "mx25u6435f", INFO(0xc22537, 0, 64 * 1024, 128, SECT_4K) },
>>>> - { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, SECT_4K) },
>>>> + { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256,
>>>> + SECT_4K | SPI_NOR_AIM_SFDP) },
>>>> { "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256, 0) },
>>>> { "mx25r1635f", INFO(0xc22815, 0, 64 * 1024, 32,
>>>> SECT_4K | SPI_NOR_DUAL_READ |
>>>
>>> I tried your patch and it works like expected. I can now read the
>>> whole flash in ~2sec while without that it was ~6sec.
>>>
>>> # time dd if=/dev/mtd0 of=dump.bin
>>> 32768+0 records in
>>> 32768+0 records out
>>> real 0m 2.08s
>>> user 0m 0.01s
>>> sys 0m 2.06s
>>>
>>> vs.
>>>
>>> # time dd if=/dev/mtd0 of=dump.bin
>>> 32768+0 records in
>>> 32768+0 records out
>>> real 0m 6.16s
>>> user 0m 0.05s
>>> sys 0m 6.09s
>>>
>>>
>>
>> Great, thanks!
>>
>>> Should I prepare a patch with that change or will you do?
>>
>> Let's wait for a few days, so others can intervene. I'd like to
>> clarify what's happening on mx66l51235l too.
>
> Since a few days have passed and no one has commented, I would like to
> bring up the subject again.
>
> I can send a patch for the changes you suggested. What do you think?
>
Why not have a single entry for mx66l51235l/mx25l12805d with superset
capabilities declared. And then use info->fixups->post_sfdp() to fixup
capabilities for mx66l51235l based on absence of SFDP tables?
SPI_NOR_AIM_SFDP seems redundant to me. SPI NOR Framework should anyway
be using SFDP for detecting flash capabilities and away from flash_info
based static data.
Regards
Vignesh
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2021-03-01 10:53 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-15 21:53 spi-nor: maxronix MX25L12835F support Heiko Thiery
2021-02-16 9:27 ` Pratyush Yadav
2021-02-16 9:45 ` Heiko Thiery
2021-02-16 9:48 ` Michael Walle
2021-02-16 10:16 ` Pratyush Yadav
2021-02-16 10:20 ` Pratyush Yadav
2021-02-16 10:41 ` Heiko Thiery
2021-02-16 10:48 ` Pratyush Yadav
2021-02-16 10:55 ` Heiko Thiery
2021-02-16 11:05 ` Pratyush Yadav
2021-02-16 11:15 ` Tudor.Ambarus
2021-02-18 5:45 ` zhengxunli
2021-02-18 7:15 ` Heiko Thiery
2021-02-18 7:56 ` Tudor.Ambarus
2021-02-18 8:49 ` Tudor.Ambarus
2021-02-18 7:43 ` Heiko Thiery
2021-02-18 9:27 ` Tudor.Ambarus
2021-02-18 10:15 ` Heiko Thiery
2021-02-18 10:26 ` Tudor.Ambarus
2021-02-18 10:36 ` Heiko Thiery
2021-02-19 2:45 ` zhengxunli
2021-02-27 21:52 ` Heiko Thiery
2021-03-01 10:52 ` Vignesh Raghavendra [this message]
2021-03-01 11:11 ` Tudor.Ambarus
2021-03-01 13:36 ` Pratyush Yadav
2021-03-01 13:50 ` Michael Walle
2021-03-01 14:09 ` Tudor.Ambarus
2021-03-01 14:42 ` Michael Walle
2021-03-01 15:25 ` Tudor.Ambarus
2021-03-02 5:49 ` Vignesh Raghavendra
2021-03-03 13:44 ` Heiko Thiery
2021-03-04 7:02 ` Vignesh Raghavendra
2021-03-04 7:10 ` Heiko Thiery
2021-03-19 14:33 ` Stefan Herbrechtsmeier
2021-03-01 15:40 ` Pratyush Yadav
2021-03-01 14:03 ` Tudor.Ambarus
2021-06-28 7:29 ` Tudor.Ambarus
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=9263ef4d-7944-00bb-8e2f-b7d33e5aab87@ti.com \
--to=vigneshr@ti.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=heiko.thiery@gmail.com \
--cc=juliensu@mxic.com.tw \
--cc=linux-mtd@lists.infradead.org \
--cc=michael@walle.cc \
--cc=p.yadav@ti.com \
--cc=ycllin@mxic.com.tw \
--cc=zhengxunli@mxic.com.tw \
/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.