dma_declare_coherent_memory and SuperH
Hi SuperH maintainers,
I have a vague recollection that you were planning on dropping support for non-devicetree platforms, is that still the case?
The reason I'm asking is because all but one users of dma_declare_coherent_memory are in the sh platform setup code, and I'd really like to move towards killing this function off.
Hi Christoph,
Quoted 2 lines · Christoph Hellwig
I have a vague recollection that you were planning on dropping support for non-devicetree platforms, is that still the case?
There are no devicetree SuperH platforms upstream, only J2, so that means dropping support for all SuperH platforms?
Gr{oetje,eeting}s,
Geert
Signature · 5 lines
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected] In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
John Paul Adrian Glaubitz
maintainerHi Christoph!
Quoted 2 lines · Christoph Hellwig
I have a vague recollection that you were planning on dropping support for non-devicetree platforms, is that still the case?
I guess you are talking about this patch set [1].
Would be great if we could get this rebased and merged. Since Geert has access to SH hardware as well, he might be able to help.
Adrian
Quoted 1 line
Signature · 4 lines
.''`. John Paul Adrian Glaubitz : :' : Debian Developer - [email protected] `. `' Freie Universitaet Berlin - [email protected] `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Quoted 4 lines · Christoph Hellwig
Hi SuperH maintainers,
I have a vague recollection that you were planning on dropping support for non-devicetree platforms, is that still the case?
We'd like to convert them, but have to rustle up test hardware for what _is_ still available. (There was some motion towards this a year or so back, but it petered out because pandemic and everyone got distracted halfway through.)
(We should definitely START by converting the r2d board qemu emulates. :)
Quoted 3 lines
The reason I'm asking is because all but one users of
dma_declare_coherent_memoryare in the sh platform setup code, and I'd really like to move towards killing this function off.
Understood. Is there an easy "convert to this" I could do to those callers?
Rob
Pulling in the debian sh maintainer, who was one of the participants in the earlier discussion...
Quoted 20 lines · Rob Landley
Quoted 4 lines · Christoph Hellwig
Hi SuperH maintainers,
I have a vague recollection that you were planning on dropping support for non-devicetree platforms, is that still the case?
We'd like to convert them, but have to rustle up test hardware for what _is_ still available. (There was some motion towards this a year or so back, but it petered out because pandemic and everyone got distracted halfway through.)
(We should definitely START by converting the r2d board qemu emulates. :)
Quoted 3 lines
The reason I'm asking is because all but one users of
dma_declare_coherent_memoryare in the sh platform setup code, and I'd really like to move towards killing this function off.Understood. Is there an easy "convert to this" I could do to those callers?
Rob
Quoted 10 lines · Rob Landley
Quoted 4 lines · Christoph Hellwig
Hi SuperH maintainers,
I have a vague recollection that you were planning on dropping support for non-devicetree platforms, is that still the case?
We'd like to convert them, but have to rustle up test hardware for what _is_ still available. (There was some motion towards this a year or so back, but it petered out because pandemic and everyone got distracted halfway through.)
Quoted 7 lines
(We should definitely START by converting the r2d board qemu emulates. :)
Quoted 3 lines
The reason I'm asking is because all but one users of
dma_declare_coherent_memoryare in the sh platform setup code, and I'd really like to move towards killing this function off.Understood. Is there an easy "convert to this" I could do to those callers?
Well, the replacement is to declare the device memory carveouts in the Device Tree.
Quoted 13 lines · Christoph Hellwig
Quoted 12 lines · Rob Landley
Quoted 4 lines · Christoph Hellwig
Hi SuperH maintainers,
I have a vague recollection that you were planning on dropping support for non-devicetree platforms, is that still the case?
We'd like to convert them, but have to rustle up test hardware for what _is_ still available. (There was some motion towards this a year or so back, but it petered out because pandemic and everyone got distracted halfway through.)
(We should definitely START by converting the r2d board qemu emulates. :)
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
The reason I'm asking is because all but one users of
dma_declare_coherent_memoryare in the sh platform setup code, and I'd really like to move towards killing this function off.Understood. Is there an easy "convert to this" I could do to those callers?
Well, the replacement is to declare the device memory carveouts in the Device Tree.
Your plan is to eliminate the ability for non-device-tree boards to do DMA?
Rob
Quoted 4 lines · Rob Landley
Quoted 2 lines
Well, the replacement is to declare the device memory carveouts in the Device Tree.
Your plan is to eliminate the ability for non-device-tree boards to do DMA?
No. My hope is to kill dma_declarare_coherent, an API for board support files to declare device-specific regions to be used for coherent DMA.
Quoted 9 lines · Christoph Hellwig
Quoted 4 lines · Rob Landley
Quoted 2 lines
Well, the replacement is to declare the device memory carveouts in the Device Tree.
Your plan is to eliminate the ability for non-device-tree boards to do DMA?
No. My hope is to kill
dma_declarare_coherent, an API for board support files to declare device-specific regions to be used for coherent DMA.
Q) If I haven't got regression test hardware to make sure I properly converted each of these entire boards to device tree, Is there anything else I can do to help you remove this function from common code, such as inlining some portion of this function?
A) You can convert the board to device tree.
Which part of this exchange have I misunderstood?
Rob
Quoted 4 lines · Rob Landley
Quoted 3 lines
No. My hope is to kill
dma_declarare_coherent, an API for board support files to declare device-specific regions to be used for coherent DMA.
Quoted 8 lines
Q) If I haven't got regression test hardware to make sure I properly converted each of these entire boards to device tree, Is there anything else I can do to help you remove this function from common code, such as inlining some portion of this function?
A) You can convert the board to device tree.
Which part of this exchange have I misunderstood?
The part that there is no easy way out without the device tree conversion.
Hi Christoph,
Quoted 10 lines · Christoph Hellwig
Quoted 9 lines · Rob Landley
Quoted 3 lines
No. My hope is to kill
dma_declarare_coherent, an API for board support files to declare device-specific regions to be used for coherent DMA.Q) If I haven't got regression test hardware to make sure I properly converted each of these entire boards to device tree, Is there anything else I can do to help you remove this function from common code, such as inlining some portion of this function?
Quoted 6 lines
Quoted 3 lines
A) You can convert the board to device tree.
Which part of this exchange have I misunderstood?
The part that there is no easy way out without the device tree conversion.
So you keep this functionality around with DT. Which means there's some code to parse the DT, extract a region, and handle it?
I'm just wondering which terrible maintenance burden would be left by making the handling function public, so the SH platform code can still call it?
Gr{oetje,eeting}s,
Geert
Signature · 5 lines
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected] In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Quoted 9 lines · Christoph Hellwig
Quoted 5 lines · Rob Landley
Quoted 3 lines
Your plan is to eliminate the ability for non-device-tree boards to do DMA?
No.
Which part of this exchange have I misunderstood?
The part that there is no easy way out without the device tree conversion.
Interesting use of the word "No".
I didn't ask for easy, I asked what needed to be done. What is the patch you want to apply to kernel/dma so I can see what infrastructure needs to be moved into arch/sh so it's our problem and not yours.
If a wrapper function has to fake up a temporary device tree snippet to lie to new DMA infrastructure that refuses to export non-systemd APIs to handle this, fine. It's still less intrusive than converting EVERY device to a new API on boards I can't easily regression test. (And hey, if you squint that would be a little like a partial incremental device tree conversion.)
Rob
On Wed, 23 Jun 2021 at 22:32, Christoph Hellwig <[email protected]> wrote
Quoted 2 lines
I have a vague recollection that you were planning on dropping support for non-devicetree platforms, is that still the case?
Are there any SH4 boards that actually support DT?
I'm still using an ecovec24 board(SH7724). I'd love to use DT if that's possible.
Cheers,
Daniel
John Paul Adrian Glaubitz
maintainerQuoted 7 lines · Daniel Palmer
On Wed, 23 Jun 2021 at 22:32, Christoph Hellwig <[email protected]> wrote
Quoted 2 lines
I have a vague recollection that you were planning on dropping support for non-devicetree platforms, is that still the case?
Are there any SH4 boards that actually support DT?
I'm still using an ecovec24 board(SH7724). I'd love to use DT if that's possible.
There is an unmerged patch set by Yoshinori Sato that adds device tree support for SH.
Adrian
Signature · 4 lines
.''`. John Paul Adrian Glaubitz : :' : Debian Developer - [email protected] `. `' Freie Universitaet Berlin - [email protected] `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Adrian, Daniel,
Quoted 10 lines · John Paul Adrian Glaubitz
Quoted 7 lines · Daniel Palmer
On Wed, 23 Jun 2021 at 22:32, Christoph Hellwig <[email protected]> wrote
Quoted 2 lines
I have a vague recollection that you were planning on dropping support for non-devicetree platforms, is that still the case?
Are there any SH4 boards that actually support DT?
I'm still using an ecovec24 board(SH7724). I'd love to use DT if that's possible.There is an unmerged patch set by Yoshinori Sato that adds device tree support for SH.
But it does not include support for SH7724 yet, only for SH775[01] (note to myself: still have to try it on my landisk). Fortunately most core devices on SH7724 and Ecovec should already have DT support in their drivers. The main missing pieces are interrupt and clock support.
The SH7750 INTC seems to be a simpler derivative of the SH7724 INTC. The SH7724 clock controller is very similar to those used on later ARM-based SH/R-Mobile and even R-Car SoCs, so adding support for it to the renesas-cpg-mssr.c driver framework shouldn't be that difficult.
Gr{oetje,eeting}s,
Geert
Signature · 5 lines
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected] In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Geert,
Quoted 4 lines · Geert Uytterhoeven
Quoted 1 line
There is an unmerged patch set by Yoshinori Sato that adds device tree support for SH.
But it does not include support for SH7724 yet, only for SH775[01] (note to myself: still have to try it on my landisk).
I have some landisks. Is there a sane u-boot for them? I think mine still have the hacked up lilo thing.
Quoted 3 lines
Fortunately most core devices on SH7724 and Ecovec should already have DT support in their drivers. The main missing pieces are interrupt and clock support.
This sounds like a fun project. I'm not sure if I could manage it without the Hitachi/Renesas debugging dongle though.
Anyhow, it would be a shame to remove the ecovec just because it doesn't have DT as it pretty much fully works with a few small patches to fix some bit rot like ethernet and the LCD not working.
I sent a patch a few years ago for the ethernet and never got a response. :(
Cheers,
Daniel
Hi Daniel,
Quoted 8 lines · Daniel Palmer
Quoted 4 lines · Geert Uytterhoeven
Quoted 1 line
There is an unmerged patch set by Yoshinori Sato that adds device tree support for SH.
But it does not include support for SH7724 yet, only for SH775[01] (note to myself: still have to try it on my landisk).
I have some landisks. Is there a sane u-boot for them? I think mine still have the hacked up lilo thing.
I believe Sato-san has one for the new landisks.
Mine is also using the hacked up lilo, with kexec to boot into a modern kernel. Unfortunately kexec is broken upstream (since ages), so I cannot kexec from a modern kernel to a modern kernel.
Quoted 6 lines
Quoted 3 lines
Fortunately most core devices on SH7724 and Ecovec should already have DT support in their drivers. The main missing pieces are interrupt and clock support.
This sounds like a fun project. I'm not sure if I could manage it without the Hitachi/Renesas debugging dongle though.
Should be doable with earlycon.
Quoted 3 lines
Anyhow, it would be a shame to remove the ecovec just because it doesn't have DT as it pretty much fully works with a few small patches to fix some bit rot like ethernet and the LCD not working.
Yeah, I agree the Ecovec24 (and the SH7722-based Migo-R) should be kept alive.
Quoted 1 line
I sent a patch a few years ago for the ethernet and never got a response. :(
You mean "[PATCH] SH: Add dma mask for sh_eth on ecovec24."[1]? Do you still need that patch? Probably this was fixed in the core core, after the
initial dma_mask breakage.
[1] https://lore.kernel.org/linux-sh/[email protected]/
Gr{oetje,eeting}s,
Geert
Signature · 5 lines
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected] In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Christoph,
Quoted 6 lines · Christoph Hellwig
I have a vague recollection that you were planning on dropping support for non-devicetree platforms, is that still the case?
The reason I'm asking is because all but one users of
dma_declare_coherent_memoryare in the sh platform setup code, and I'd really like to move towards killing this function off.
I guess you mean drivers/remoteproc/remoteproc_virtio.c?
BeagleV Starlight Beta will be adding two more indrivers/nvdla/nvdla_gem.c.
https://github.com/esmil/linux/commit/ce5cffcc8e618604a0d442758321fc5577751c9d
Gr{oetje,eeting}s,
Geert
Signature · 5 lines
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected] In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Quoted 8 lines · Geert Uytterhoeven
Quoted 6 lines · Christoph Hellwig
I have a vague recollection that you were planning on dropping support for non-devicetree platforms, is that still the case?
The reason I'm asking is because all but one users of
dma_declare_coherent_memoryare in the sh platform setup code, and I'd really like to move towards killing this function off.
Quoted 5 lines
I guess you mean
drivers/remoteproc/remoteproc_virtio.c?BeagleV Starlight Beta will be adding two more in
drivers/nvdla/nvdla_gem.c.
https://github.com/esmil/linux/commit/ce5cffcc8e618604a0d442758321fc5577751c9d
As clearly documented adding new callers is not acceptable. But I don't really care about of of tree code anyway.