On Tue, 3 Apr 2018 10:14:31 +0200
Peter Rosin <p...@axentia.se> wrote:
> On 2018-04-03 09:15, Boris Brezillon wrote:
> > On Tue, 3 Apr 2018 08:51:10 +0200
> > Peter Rosin <p...@axentia.se> wrote:
> >
> >> On 2018-04-02 22:20, Boris Brezillon wrote:
> >>> On Mon, 2 Apr 2018 21:28:43 +0200
> >>> Boris Brezillon <boris.brezil...@bootlin.com> wrote:
> >>>
> >>>> On Mon, 2 Apr 2018 19:59:39 +0200
> >>>> Peter Rosin <p...@axentia.se> wrote:
> >>>>
> >>>>> On 2018-04-02 14:22, Boris Brezillon wrote:
> >>>>>> On Thu, 29 Mar 2018 16:27:12 +0200
> >>>>>> Peter Rosin <p...@axentia.se> wrote:
> >>>>>>
> >>>>>>> On 2018-03-29 15:44, Boris Brezillon wrote:
> >>>>>>>> On Thu, 29 Mar 2018 15:37:43 +0200
> >>>>>>>> Peter Rosin <p...@axentia.se> wrote:
> >>>>>>>>
> >>>>>>>>> On 2018-03-29 15:33, Boris Brezillon wrote:
> >>>>>>>>>> On Thu, 29 Mar 2018 15:10:54 +0200
> >>>>>>>>>> Peter Rosin <p...@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 <p...@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.
> >>>
> >>> Can you try to write 0x3 to 0xFFFFECCC and 0x30 to 0xFFFFECD4?
> >>
> >> Given the matrix dump in the other mail, it is not surprising that I
> >> can't. But if I change the matrix from the default
> >>
> >> 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 ----------------
> >
> > Is it really the default? I thought all entries were set to 0 by
> > default.
>
> Yes, the datasheet claims 0 to be the reset default, but there is
> a note in my datasheet that "Values in the Bus Matrix Priority
> Registers are product dependent". I was referring to what I see
> with devmem2 from the shell directly after boot. I have no idea
> where the threes are coming from; they could be reset default or
> from some loop somewhere that simply tries to write the highest
> priority everywhere, but that the write then only sticks in the
> allowed entries.
>
> BTW, the sanity of everybody screaming "I'm super-important" is
> a bit questionable...
It is indeed.
