Re: [PATCH/RFC] dmaengine: sh: Remove R-Mobile APE6 support

[Rob Landley]

On 11/12/18 9:30 AM, Geert Uytterhoeven wrote:
> CC SuperH
> 
> On Mon, Nov 12, 2018 at 4:22 PM Geert Uytterhoeven
>  wrote:
>> Renesas R-Mobile APE6 support is currently unused:
>>   - DMA slaves were never enabled in r8a73a4.dtsi,
>>   - The driver relies on legacy filter matching and describing all
>> slaves and MID/RIDs in a table, unlike modern DMA engine drivers for
>> similar hardware like rcar-dmac,
>>   - The driver doesn't seem to work well.
>>
>> Remove the driver, it can be resurrected from git history when needed.
>>
>> As this was the last user of SH_DMAE_BASE on Renesas ARM SoCs, the
>> sh-dma-engine driver core is now used on SuperH only.

I'm trying to add dma support to smc91x on an sh7760 board:

https://www.spinics.net/lists/linux-sh/msg53400.html

I missed the ship window for the previous iteration so we had to use PIO, but
DMA's a huge speedup and it's cycling back around on my todo list...

Unfortunately due to a flash corruption bug we were stuck at 4.14 for that
release. I'm trying to track that down now, then need to redo this work on top
of 4.20 or 4.21.

Kernel board support patches are at the lawyers being frowned at expensively
before release, but it won't include DMA this time because I only got the first
half of it working. (Board's hooked up and can do memory-to-memory, but the
ethernet card couldn't use it because the smc91x claims of using dmaengine are
lies, it's hardwired to a specific arm chip ("mainstone" I think?), and when I
got QEMU to emulate that ARM board and tried to enable DMA: packet timeouts. I
dunno if it's broken in the kernel or QEMU doesn't emulate the DMA...)

>> Notes:
>>   1. As Renesas ARM SoCs no longer use drivers/dma/sh/shdma-base.c, the
>>  task to remove use of the deprecated dma_slave_config.direction
>>  field gets thrown into the SuperH maintainers' basket ;-)

At least in 4.14 there were two DMA apis, once of which is obsolete and unused,
and the other is modern dmaengine support which at least passes its self-test.

I left off boggling at the "slave API", I think...

>>   3. I tried to get SCIFA DMA to work by:
>>- Applying the DT and driver patches below,
>>- Reverting 219fb0c1436e4893 ("serial: sh-sci: Remove the
>>  platform data dma slave rx/tx channel IDs").

The board I'm using is platform data, never got converted to device tree. (If I
can ever convince them to mail a board to Rich Felker I might try to hire him to
convert it _myself_. Or I could just get him an old board on ebay, current
cheapest one looks like
https://www.ebay.com/p/Johnson-Controls-Ms-nae3511-2-Metasys-Controller-NAE-and-2x-Unt1108/567230953?iid=283254042308
at the moment? Dead battery's fine for a dev/test system...)

But it's not happening this month.

>>  After that, serial console output using DMA seems to work, but the
>>  system locks up when receiving any serial console input.
>>  Probably it is easier to add r8a73a4 support to rcar-dmac.

What _is_ the status of dmaengine? I thought it was the generic dma API the
kernel was moving towards? (The youtube videos suggested such...)

Rob

Re: [PATCH 4/4] serial: sh-sci: Stop RX FIFO timer during port shutdown

[Rob Landley]

On 07/02/2018 04:50 AM, Geert Uytterhoeven wrote:
> Hi Rob,
> 
> On Sun, Jul 1, 2018 at 7:27 PM Rob Landley  wrote:
>> On 06/29/2018 09:25 AM, Geert Uytterhoeven wrote:
>>> The RX FIFO timer may be armed when the port is shut down, hence the
>>> timer function may still be called afterwards.
>>>
>>> Fix this race condition by deleting the timer during port shutdown.
>>
>> Will any of this make the qemu-system-sh4 serial console work again?
> 
> Probably not, as none of these patches touch the qemu source tree.

So we remain well into the second year of each project pointing the finger at
the other on this, and nothing getting fixed. And the workaround remains "run a
kernel from before February 2017 if you want a working serial console under 
qemu.

Good to know,

Rob

Re: [PATCH 4/4] serial: sh-sci: Stop RX FIFO timer during port shutdown

[Rob Landley]

On 06/29/2018 09:25 AM, Geert Uytterhoeven wrote:
> The RX FIFO timer may be armed when the port is shut down, hence the
> timer function may still be called afterwards.
> 
> Fix this race condition by deleting the timer during port shutdown.

Will any of this make the qemu-system-sh4 serial console work again?

Rob

Re: [PATCH/RFC 5/5] ARM: shmobile: defconfig: Disable CONFIG_EMBEDDED

[Rob Landley]

On 12/05/2017 02:28 AM, Simon Horman wrote:
> On Mon, Dec 04, 2017 at 10:46:22AM +0100, Geert Uytterhoeven wrote:
>> Hi Simon,
>>
>> On Fri, Dec 1, 2017 at 9:33 AM, Simon Horman  wrote:
>>> On Thu, Nov 30, 2017 at 02:12:02PM +0100, Geert Uytterhoeven wrote:
 CONFIG_EXPERT exposes too many config options that do not matter for
 development. However, CONFIG_EMBEDDED selects CONFIG_EXPERT, so it
 cannot be disabled.

 Hence disable CONFIG_EMBEDDED, and compensate for the loss of
 CONFIG_DEBUG_KERNEL by enabling the latter.

Didn't I already submit a patch to fix this in 2015?

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=560b8c0ed45a

If it came back, it's a regression.

Rob

Re: [PATCH 9/9] ARM: multi_v7_defconfig: Enable DMA for Renesas serial ports

[Rob Landley]

On 07/11/2017 05:46 AM, Geert Uytterhoeven wrote:
> Hi Rob,
> 
> On Tue, Jul 11, 2017 at 12:37 PM, Rob Landley <r...@landley.net> wrote:
>> On 07/11/2017 03:59 AM, Geert Uytterhoeven wrote:
>>> On Tue, Jul 11, 2017 at 10:42 AM, Arnd Bergmann <a...@arndb.de> wrote:
>>>> On Tue, Jul 11, 2017 at 8:59 AM, Geert Uytterhoeven
>>>> <ge...@linux-m68k.org> wrote:
>>>>> On Tue, Jul 11, 2017 at 5:38 AM, Magnus Damm <magnus.d...@gmail.com> 
>>>>> wrote:
>>>>>> On Mon, Jul 10, 2017 at 10:28 PM, Geert Uytterhoeven
>>>>>> Since enabling DMA Engine still keeps PIO support around I wonder why
>>>>>> we need this Kconfig at all - other drivers seem to get by without
>>>>>> this kind of thing?
>>>>>> So in my opinion it would also be nice to get rid of SERIAL_SH_SCI_DMA
>>>>>> completely and reducing the number of special per-driver Kconfig
>>>>>> entries.
>>>>>
>>>>> In general, I would agree, and remove the option at the blimp of an eye.
>>>>> However, this driver is shared with H8/300 and SuperH.  While both could 
>>>>> use
>>>>> DMA (but it's not supported by Linux yet), I don't know if they are 
>>>>> willing to
>>>>> live with the increased static and dynamic memory footprint of SH_SCI DMA
>>>>> support.
>>>>
>>>> One more thing: enabling the DMA support in the console driver generally
>>>> means you cannot use printk in the DMA driver anywhere that may be called
>>>> during printk(). Not sure if that is a concern here.
>>>
>>> Not anymore, as all of these prints should have been removed/disabled 
>>> already.
>>
>> Last I checked qemu-system-sh4 still doesn't work with current linux
>> serial driver unless you do:
>>
>> --- a/drivers/tty/serial/sh-sci.c
>> +++ b/drivers/tty/serial/sh-sci.c
>> @@ -2193,7 +2193,7 @@ static void sci_reset(struct uart_port *port)
>> setup_timer(>rx_fifo_timer, rx_fifo_timer_fn,
>> (unsigned long)s);
>> } else {
>> -   if (port->type == PORT_SCIFA ||
>> +   if (1 || port->type == PORT_SCIFA ||
>> port->type == PORT_SCIFB)
>> scif_set_rtrg(port, 1);
>> else
>>
>> Does this DMA stuff make that situation worse?
> 
> No, SH-SCI DMA is not used on your platform.
> 
> Gr{oetje,eeting}s,

This issue is still there. QEMU's serial output is borked with the last
year's worth of vanilla superh kernels.

Rob

Re: [PATCH 9/9] ARM: multi_v7_defconfig: Enable DMA for Renesas serial ports

[Rob Landley]

On 07/11/2017 03:59 AM, Geert Uytterhoeven wrote:
> Hi Arnd,
> 
> On Tue, Jul 11, 2017 at 10:42 AM, Arnd Bergmann  wrote:
>> On Tue, Jul 11, 2017 at 8:59 AM, Geert Uytterhoeven
>>  wrote:
>>> On Tue, Jul 11, 2017 at 5:38 AM, Magnus Damm  wrote:
 On Mon, Jul 10, 2017 at 10:28 PM, Geert Uytterhoeven
 Since enabling DMA Engine still keeps PIO support around I wonder why
 we need this Kconfig at all - other drivers seem to get by without
 this kind of thing?
 So in my opinion it would also be nice to get rid of SERIAL_SH_SCI_DMA
 completely and reducing the number of special per-driver Kconfig
 entries.
>>>
>>> In general, I would agree, and remove the option at the blimp of an eye.
>>> However, this driver is shared with H8/300 and SuperH.  While both could use
>>> DMA (but it's not supported by Linux yet), I don't know if they are willing 
>>> to
>>> live with the increased static and dynamic memory footprint of SH_SCI DMA
>>> support.
>>
>> One more thing: enabling the DMA support in the console driver generally
>> means you cannot use printk in the DMA driver anywhere that may be called
>> during printk(). Not sure if that is a concern here.
> 
> Not anymore, as all of these prints should have been removed/disabled already.

Last I checked qemu-system-sh4 still doesn't work with current linux
serial driver unless you do:

--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2193,7 +2193,7 @@ static void sci_reset(struct uart_port *port)
setup_timer(>rx_fifo_timer, rx_fifo_timer_fn,
(unsigned long)s);
} else {
-   if (port->type == PORT_SCIFA ||
+   if (1 || port->type == PORT_SCIFA ||
port->type == PORT_SCIFB)
scif_set_rtrg(port, 1);
else

Does this DMA stuff make that situation worse?

Rob

Re: Commit 18e8cf159177 broke qemu-system-sh4 serial input.

[Rob Landley]

On 04/24/2017 02:23 AM, Ulrich Hecht wrote:
> On Sat, Apr 22, 2017 at 10:49 AM, Rob Landley <r...@landley.net> wrote:
>> On 04/21/2017 02:26 AM, Geert Uytterhoeven wrote:
>>> According to the SH7751R datasheet, SCFCR does have the RTRG1 and RTRG0 
>>> bits.
>>> I assume the problem goes away if you comment out the call to 
>>> scif_set_rtrg()?
>>
>> The current code has been further complicated by two more commits
>> (039403765 and 90afa5255) doing who knows what, but deleting the
>> "scif_set_rtrg(port, s->rx_trigger);" from sci_reset() does appear to
>> fix the problem.
> 
> Most(?) SCIFs have a feature that is always enabled and that asserts
> DR even if the FIFO threshold has not been reached if no data is
> received for 1.5 frames. Exceptions known to me are SCIFA/Bs, which
> require special handling for it to work, and SH7705's SCIF, which does
> not seem to have this at all. According to its datasheet, the
> SH7751R's SCIF has the timeout feature, so I would have expected it to
> work...

QEMU is an emulator. I've run sh4 linux on it for about 10 years now.
Sounds like they never implemented this feature because nothing used it
before now.

My general approach when dealing with this sort of thing is to point
figures at the thing that changed, and caused "it was working" to go to
"it's not working". When qemu broke this same sh4 serial port, I asked
_them_ to fix it:

https://lists.nongnu.org/archive/html/qemu-devel/2012-07/msg03929.html

Asking qemu to change means current kernels will never run on existing
qemu installations again, when they did for a decade now, which seems
like a regression to me?

Rob

Re: Commit 18e8cf159177 broke qemu-system-sh4 serial input.

[Rob Landley]

On 04/21/2017 02:26 AM, Geert Uytterhoeven wrote:
> Hi Rob,
> 
> CC Adrian, linux-serial, linux-renesas-soc
> 
> On Fri, Apr 21, 2017 at 8:21 AM, Rob Landley <r...@landley.net> wrote:
>> In 4.11-rc7 the qemu serial console hangs after the first character you
>> type. To reproduce, configure linux with this mini.config:
>>
>> CONFIG_CPU_SUBTYPE_SH7751R=y
>> CONFIG_MMU=y
>> CONFIG_MEMORY_START=0x0c00
>> CONFIG_VSYSCALL=y
>> CONFIG_SH_FPU=y
>> CONFIG_SH_RTS7751R2D=y
>> CONFIG_RTS7751R2D_PLUS=y
>> CONFIG_SERIAL_SH_SCI=y
>> CONFIG_SERIAL_SH_SCI_CONSOLE=y
>> CONFIG_EARLY_PRINTK=y
>> CONFIG_BLK_DEV_INITRD=y"
>> CONFIG_RD_GZIP=y
>> CONFIG_BINFMT_ELF=y
>> CONFIG_BINFMT_SCRIPT=y
>> CONFIG_MISC_FILESYSTEMS=y
>> CONFIG_DEVTMPFS=y
>>
>> Using "make ARCH=sh allnoconfig KCONFIG_ALLCONFIG=mini.conf", then build
>> the result, then boot under qemu using the following command line:
>>
>> qemu-system-sh4 -M r2d -monitor null -serial null -serial stdio
>> -nographic -no-reboot -append "panic=1 HOST=sh4 console=ttySC1 noiotrap"
>> -kernel zImage -initrd sh4-linux-musl-root.cpio.gz
>>
>> You'll need a simple cpio.gz initramfs (I built one using
>> https://github.com/landley/mkroot and the musl-cross-make cross
>> compiler, the cpio.gz is ~450k or I'd attach it here).
>>
>> I bisected it to commit 18e8cf159177 back in February. If you do this
>> with the revision _before_ that commit, typing "ls -l" and hitting enter
>> works fine. Afterwards you get an "l" and then it hangs. (If type enough
>> it'll eventually deal a burst of characters all at once, and then hang
>> again.)
> 
> SH7751R has both SCI and SCIF ports. ttySC1 is the second (SCIF) port.

Yeah, my qemu invocation for sh4 is a bit eldrich, I got it from the
qemu mailing list. Possibly from:

https://lists.nongnu.org/archive/html/qemu-devel/2007-09/msg00530.html

The really _fun_ thing about this is qemu broke it a couple years back
and now if you hit ctrl-c it kills the _emulator_ rather than passing it
through to the Linux console. (Just sh4, the rest do it right.)

I complained about it on the qemu mailing list in 2014 but nobody there
cared:

http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg0.html

Of course that's actually _useful_ for the testing I'm doing now because
when the kernel tries to shut down qemu it goes:

  / # exit
  reboot: Restarting system
  Unauthorized access

And then hangs eating 100% cpu. (Wheee!)

>  registers a port with type PORT_SCIF,
> so that should become SCIx_SH4_SCIF_REGTYPE. Hence I don't think the issue
> is caused by changing fifosize to 64 for SCIx_SH7705_SCIF_REGTYPE.
> 
> My first guess is that qemu has a bug emulating the triggering.

Very likely given how crappy the rest of its serial emulation is for
this architecture, but ever since qemu added glib support I've stopped
trying to understand their developers' thought processes.

> According to the SH7751R datasheet, SCFCR does have the RTRG1 and RTRG0 bits.
> I assume the problem goes away if you comment out the call to scif_set_rtrg()?

The current code has been further complicated by two more commits
(039403765 and 90afa5255) doing who knows what, but deleting the
"scif_set_rtrg(port, s->rx_trigger);" from sci_reset() does appear to
fix the problem.

Rob