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,
On Wed, Jun 23, 2021 at 3:33 PM Christoph Hellwig <[email protected]> wrote:
> 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
--
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!
On 6/23/21 3:32 PM, Christoph Hellwig wrote:
> 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
> [1] https://lore.kernel.org/patchwork/cover/693910/
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 6/23/21 8:32 AM, Christoph Hellwig wrote:
> 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. :)
> 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.
Understood. Is there an easy "convert to this" I could do to those callers?
Rob
On Wed, 23 Jun 2021 at 22:32, Christoph Hellwig <[email protected]> wrote
> 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
On 6/27/21 5:08 AM, Daniel Palmer wrote:
> On Wed, 23 Jun 2021 at 22:32, Christoph Hellwig <[email protected]> wrote
>> 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
--
.''`. 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,
On Sun, Jun 27, 2021 at 10:48 AM John Paul Adrian Glaubitz
<[email protected]> wrote:
> On 6/27/21 5:08 AM, Daniel Palmer wrote:
> > On Wed, 23 Jun 2021 at 22:32, Christoph Hellwig <[email protected]> wrote
> >> 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
--
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,
On Mon, 28 Jun 2021 at 17:57, Geert Uytterhoeven <[email protected]> wrote:
> > 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.
> 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,
On Mon, Jun 28, 2021 at 11:30 AM Daniel Palmer <[email protected]> wrote:
> On Mon, 28 Jun 2021 at 17:57, Geert Uytterhoeven <[email protected]> wrote:
> > > 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.
> > 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.
> 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.
> 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
--
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
On 6/28/21 8:38 AM, Christoph Hellwig wrote:
> On Sat, Jun 26, 2021 at 05:36:08PM -0500, Rob Landley wrote:
>> On 6/23/21 8:32 AM, Christoph Hellwig wrote:
>> > 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. :)
>>
>> > 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.
>>
>> 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
On 6/28/21 8:49 AM, Christoph Hellwig wrote:
> On Mon, Jun 28, 2021 at 09:04:19AM -0500, Rob Landley wrote:
>> > 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
On Mon, Jun 28, 2021 at 04:29:18PM +0200, Geert Uytterhoeven wrote:
> On Wed, Jun 23, 2021 at 3:33 PM Christoph Hellwig <[email protected]> wrote:
> > 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.
>
> 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.
On Mon, Jun 28, 2021 at 09:29:59AM -0500, Rob Landley wrote:
> > 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?
The part that there is no easy way out without the device tree
conversion.
On Sat, Jun 26, 2021 at 05:36:08PM -0500, Rob Landley wrote:
> On 6/23/21 8:32 AM, Christoph Hellwig wrote:
> > 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. :)
>
> > 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.
>
> 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.
On Mon, Jun 28, 2021 at 09:04:19AM -0500, Rob Landley wrote:
> > 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.
Hi Christoph,
On Wed, Jun 23, 2021 at 3:33 PM Christoph Hellwig <[email protected]> wrote:
> 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.
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
Gr{oetje,eeting}s,
Geert
--
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,
On Mon, Jun 28, 2021 at 6:33 PM Christoph Hellwig <[email protected]> wrote:
> On Mon, Jun 28, 2021 at 09:29:59AM -0500, Rob Landley wrote:
> > > 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?
>
> 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
--
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
On 6/28/21 11:33 AM, Christoph Hellwig wrote:
> On Mon, Jun 28, 2021 at 09:29:59AM -0500, Rob Landley wrote:
> >> 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