From: Peter Rosin <peda@axentia.se>
To: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Boris Brezillon <boris.brezillon@bootlin.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Josh Wu <rainyfeeling@outlook.com>,
linux-kernel@vger.kernel.org, Marek Vasut <marek.vasut@gmail.com>,
linux-mtd@lists.infradead.org,
Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>,
Brian Norris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
Date: Wed, 11 Apr 2018 16:44:10 +0200 [thread overview]
Message-ID: <d0afd431-6e51-a9b7-c103-ecf1f6e07c2e@axentia.se> (raw)
In-Reply-To: <20180403091813.5fb5c18c@bbrezillon>
Hi Nicolas,
Boris asked for your input on this (the datasheet difference appears to
have no bearing on the issue) elsewhere in the tree of messages. It's
now been a week or so and I'm starting to wonder if you missed this
altogether or if you are simply out of office or something?
Cheers,
Peter
On 2018-04-03 09:18, Boris Brezillon wrote:
> On Tue, 3 Apr 2018 08:11:30 +0200
> Peter Rosin <peda@axentia.se> wrote:
>
>> On 2018-04-02 22:20, Boris Brezillon wrote:
>>> On Mon, 2 Apr 2018 21:28:43 +0200
>>> Boris Brezillon <boris.brezillon@bootlin.com> wrote:
>>>
>>>> On Mon, 2 Apr 2018 19:59:39 +0200
>>>> Peter Rosin <peda@axentia.se> wrote:
>>>>
>>>>> On 2018-04-02 14:22, Boris Brezillon wrote:
>>>>>> On Thu, 29 Mar 2018 16:27:12 +0200
>>>>>> Peter Rosin <peda@axentia.se> wrote:
>>>>>>
>>>>>>> On 2018-03-29 15:44, Boris Brezillon wrote:
>>>>>>>> On Thu, 29 Mar 2018 15:37:43 +0200
>>>>>>>> Peter Rosin <peda@axentia.se> wrote:
>>>>>>>>
>>>>>>>>> On 2018-03-29 15:33, Boris Brezillon wrote:
>>>>>>>>>> On Thu, 29 Mar 2018 15:10:54 +0200
>>>>>>>>>> Peter Rosin <peda@axentia.se> wrote:
>>>>>>>>>>
>>>>>>>>>>> On a sama5d31 with a Full-HD dual LVDS panel (132MHz pixel clock) NAND
>>>>>>>>>>> flash accesses have a tendency to cause display disturbances. Add a
>>>>>>>>>>> module param to disable DMA from the NAND controller, since that fixes
>>>>>>>>>>> the display problem for me.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Peter Rosin <peda@axentia.se>
>>>>>>>>>>> ---
>>>>>>>>>>> drivers/mtd/nand/raw/atmel/nand-controller.c | 7 ++++++-
>>>>>>>>>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c
>>>>>>>>>>> index b2f00b398490..2ff7a77c7b8e 100644
>>>>>>>>>>> --- a/drivers/mtd/nand/raw/atmel/nand-controller.c
>>>>>>>>>>> +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
>>>>>>>>>>> @@ -129,6 +129,11 @@
>>>>>>>>>>> #define DEFAULT_TIMEOUT_MS 1000
>>>>>>>>>>> #define MIN_DMA_LEN 128
>>>>>>>>>>>
>>>>>>>>>>> +static bool atmel_nand_avoid_dma __read_mostly;
>>>>>>>>>>> +
>>>>>>>>>>> +MODULE_PARM_DESC(avoiddma, "Avoid using DMA");
>>>>>>>>>>> +module_param_named(avoiddma, atmel_nand_avoid_dma, bool, 0400);
>>>>>>>>>>
>>>>>>>>>> I'm not a big fan of those driver specific cmdline parameters. Can't we
>>>>>>>>>> instead give an higher priority to HLCDC master using the bus matrix?
>>>>>>>>>
>>>>>>>>> I don't know if it will be enough, but we sure can try. However, I have
>>>>>>>>> no idea how to do that. I will happily test stuff though...
>>>>>>>>
>>>>>>>> There's no interface to configure that from Linux, but you can try to
>>>>>>>> tweak it with devmem and if that does the trick, maybe we can expose a
>>>>>>>> way to configure that from Linux. For more details, see the "Bus Matrix
>>>>>>>> (MATRIX)" section in Atmel datasheets.
>>>>>>>
>>>>>>> I don't seem to succeed in changing the registers I think I need to change.
>>>>>>> I can poke the "Write Protection Mode Register" by writing MAT0 and MAT1 to
>>>>>>> it.
>>>>>>
>>>>>> You mean 0x4D415400, right? ("MAT0" != 0x4D415400).
>>>>>
>>>>> Bits 1 through 7 do not matter, so even though not equal they are (or
>>>>> should be) equivalent. But I did use 0x4d415400. I simply used the
>>>>> shorter syntax since that was easier to type and conveyed the relevant
>>>>> info.
>>>>
>>>> Ok.
>>>>
>>>>>
>>>>>>> But when I try to write to "Priority Registers B For Slaves" it doesn't
>>>>>>> take, regardless of write protect mode.
>>>>>>
>>>>>> Did you check MATRIX_WPSR after writing to MATRIX_PRXSY?
>>>>>
>>>>> No, but did it again and checked, see transcript below.
>>>>
>>>> I don't use devmem2. Is 'readback' information accurate or is it
>>>> always what's been written? Because when you write 0x33 to 0xFFFFECBC,
>>>> 0x33 is read back, but just after that, when you read it again it's 0.
>>>>
>>>>> BTW, how do I
>>>>> know which master is in use for the LCD controller? 8 or 9? Both?
>>>>
>>>> It's configurable on a per-layer basis through the SIF bit in
>>>> LCDC_<layer>CFG0. The driver tries to dispatch the load on those 2 AHB
>>>> masters [1].
>>>>
>>>>> And
>>>>> which DDR slave is the target? 7, 8, 9 or 10? More than one?
>>>>
>>>> This, I don't know. I guess all of them can be used.
>>>
>>> Looks like I was wrong. According to "Table 15-3. SAMA5D3 Master to
>>> Slave Access", LCDC port 0 can only access DDR port 2 and LCDC port 1
>>> can only access DDR port 3.
>>
>> About that table, someone with HW-knowledge should have a real close
>> look at it! Why?
>>
>> I peeked at all the PRxSy registers and there are a lot of '3' entries
>> for all the MxPR fields. In fact, the '3' entries align very neatly
>> with the checks in this "Master to Slave Access" table. Except they
>> don't, after a while.
>>
>> Here's how the table looks in my datasheet:
>>
>> 0 vv--v--v--vvvv-
>> 1 vv--v--v--vvvv-
>> 2 vv-------------
>> 3 vv--------vvv--
>> 4 vv-------------
>> 5 v--------------
>> 6 vv--vv-vvvvvvvv
>> v--------------
>> 7 v--------------
>> 8 --v-v--v-------
>> 9 -v---v--v--v---
>> 10 ---------vv-vvv
>> 11 v--v-----------
>> 12 v-----v--------
>>
>> And here's the '3' entries when digging in the registers (the extra
>> dash at the end is for the 16th non-existent slave):
>>
>> 0 33--3--3--3333--
>> 1 33--3--3--3333--
>> 2 33--------------
>> 3 -3--------333---
>> 4 33--------------
>> 5 3---------------
>> 6 33--33-33333333-
>> 7 --3-3--3--------
>> 8 -3---3--3--3----
>> 9 --3-3--3-33-333-
>> 10 3--3------------
>> 11 3-----3---------
>> 12 ----------------
>> 13 ----------------
>> 14 ----------------
>> 15 ----------------
>>
>> There's a big mismatch for the four DDR2 lines in the table; they
>> seem to map to only three registers. Other than that, the only tweak
>> or anomaly is that first entry (Cortex A5) for master 3 (Int ROM).
>>
>> *time passes*
>>
>> Arrrgh!! You say "Table 15-3". This is Table 14-3 for me! I believe
>> I'm using the latest datasheet (02-Feb-16). What are you reading???!?
>
> Oops, I was reading an old datasheet (from 2014).
next prev parent reply other threads:[~2018-04-11 14:44 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-29 13:10 [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma Peter Rosin
2018-03-29 13:33 ` Boris Brezillon
2018-03-29 13:37 ` Peter Rosin
2018-03-29 13:44 ` Boris Brezillon
2018-03-29 14:27 ` Peter Rosin
2018-03-30 21:43 ` Peter Rosin
2018-04-02 12:22 ` Boris Brezillon
2018-04-02 17:59 ` Peter Rosin
2018-04-02 19:28 ` Boris Brezillon
2018-04-02 20:20 ` Boris Brezillon
2018-04-02 20:32 ` Boris Brezillon
2018-04-03 6:11 ` Peter Rosin
2018-04-03 7:18 ` Boris Brezillon
2018-04-11 14:44 ` Peter Rosin [this message]
2018-04-11 14:59 ` Boris Brezillon
2018-04-11 15:10 ` Peter Rosin
2018-04-11 15:34 ` Boris Brezillon
2018-04-11 15:34 ` Nicolas Ferre
2018-04-12 7:18 ` Peter Rosin
2018-05-22 18:03 ` Peter Rosin
2018-05-23 10:42 ` Boris Brezillon
2018-05-25 14:51 ` Tudor Ambarus
2018-05-26 17:40 ` Peter Rosin
2018-05-27 9:18 ` Peter Rosin
2018-05-27 22:11 ` Peter Rosin
2018-05-28 10:10 ` Peter Rosin
2018-05-28 14:27 ` Boris Brezillon
2018-05-28 15:52 ` Peter Rosin
2018-05-28 16:09 ` Boris Brezillon
2018-05-28 16:09 ` Nicolas Ferre
2018-05-29 6:30 ` Eugen Hristev
2018-05-29 7:10 ` Peter Rosin
2018-05-29 7:25 ` Eugen Hristev
2018-05-29 14:49 ` Boris Brezillon
2018-05-29 15:01 ` Eugen Hristev
2018-05-29 15:15 ` Boris Brezillon
2018-05-29 15:21 ` Eugen Hristev
2018-05-29 15:46 ` Boris Brezillon
2018-05-29 17:57 ` Boris Brezillon
2018-05-29 21:37 ` Peter Rosin
2018-06-04 15:46 ` Tudor Ambarus
2018-06-04 16:03 ` Boris Brezillon
2018-04-03 6:51 ` Peter Rosin
2018-04-03 7:15 ` Boris Brezillon
2018-04-03 7:32 ` Boris Brezillon
2018-04-03 8:14 ` Peter Rosin
2018-04-03 8:30 ` Boris Brezillon
2018-04-02 20:23 ` Peter Rosin
2018-04-02 20:35 ` Boris Brezillon
2018-04-03 7:18 ` Alexandre Belloni
2018-04-03 8:37 ` Peter Rosin
2018-03-29 14:20 ` Nicolas Ferre
2018-03-29 14:23 ` Peter Rosin
2018-03-29 14:29 ` Boris Brezillon
2018-06-18 8:39 ` Boris Brezillon
2018-06-18 14:00 ` Miquel Raynal
2018-06-25 12:31 ` Miquel Raynal
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=d0afd431-6e51-a9b7-c103-ecf1f6e07c2e@axentia.se \
--to=peda@axentia.se \
--cc=alexandre.belloni@bootlin.com \
--cc=boris.brezillon@bootlin.com \
--cc=computersforpeace@gmail.com \
--cc=cyrille.pitchen@wedev4u.fr \
--cc=dwmw2@infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=nicolas.ferre@microchip.com \
--cc=rainyfeeling@outlook.com \
--cc=richard@nod.at \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).