Re: [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections

[Geert Uytterhoeven]

Hi Rich,

On Fri, Jan 8, 2016 at 9:52 PM, Rich Felker <dalias@xxxxxxxx> wrote:
> On Fri, Jan 08, 2016 at 09:35:11PM +0100, Geert Uytterhoeven wrote:
>> On Fri, Jan 8, 2016 at 7:21 PM, Rich Felker <dalias@xxxxxxxx> wrote:
>> > On Fri, Jan 08, 2016 at 10:01:25AM +0100, Geert Uytterhoeven wrote:
>> >> Many old ARM/SH-Mobile SoCs look like SH SoCs with an ARM CPU core bolted on.
>> >> Recent Renesas ARM SoCs still share many IP cores with older SH SoCs; most of
>> >> them even have a secondary SH4 CPU core. Using the SH4 CPU core could be useful
>> >> for doing SH4 work, until J4 becomes mainstream (cfr. old prototype in
>> >> http://www.spinics.net/lists/linux-sh/msg07188.html).
>> >> Probably the Jx series won't share IP cores with SH/ARM, but as arch/sh/
>> >> maintainers you have to care about older Renesas SH platforms, too.
>> >>
>> >> For patchwork, that would mean some more delegation needs to be put in place.
>> >>
>> >> So far my 0.05â...
>> >
>> > Is that actually the case? I can't find any current support in the
>> > kernel for running on these SH4 cores, and I was under the impression
>> > that they were being phased out, if not already gone. And the bulk of
>>
>> There's no in-kernel support for these SH4 cores yet, just the prototype.
>
> OK. Are they presently just running (non-Linux) firmware provided with
> the boards? Or not being used at all? Also, is it correct that they're

I don't know whether they're used in products.

> all SH4, not SH5? I know on the gcc side there's interest in removing
> SH5 support, and I'd probably like to do the same in the kernel if
> it's not being used.

The ones on the boards I have are either SH-4A or SH4AL-DSP.

>> Note that you can find "shmobile" SoCs under both arch/sh/
>> (sh7723/sh7724/sh7343/sh7722/sh7366) and arch/arm/mach-shmobile/.
>> Some of these used to share even more code (e.g. drivers/sh/clk/), until the
>> ARM ones were converted to the Common Clock Framework.
>
> Do you know how much is involved in converting the SH ones over to
> Common Clock Framework? That seems to be one obstacle for full DT
> conversion that supports the old boards.

The clock drivers for SH SoCs with module clocks ("MSTP") look very similar
to e.g. the old non-CCF clock driver for (ARM) SH-Mobile AG5 (sh73a0)
(cfr. arch/arm/mach-shmobile/clock-sh73a0.c in v4.2 and earlier).

With DT/CCF, sh73a0 is handled by clk-sh73a0.c, clk-mstp.c, clk-div6.c under
drivers/clk/shmobile/, and by generic "fixed-clock" and "fixed-factor-clock".
Only the first one is SoC-specific, the other two drivers should be reusable
for SH. This could be a good starting point to get something working.

However, a few years of experience with CCF has taught us that trying to
describe as many clocks as possible in DT has its disadvantages.
Hence for r8a7795 we started moving all clock definitions into the driver
again, cfr. renesas-cpg-mssr.c (core) and r8a7795-cpg-mssr.c in -next.
While I haven't converted sh73a0 yet, I believe a cpg-mssr based clock driver
can easily be written for SH SoCs that are sufficiently similar to sh73a0,
based on the existing SH clock drivers.

Older SH SoCs have even simpler clock drivers.

Disclaimer: I don't have any "pure" SH boards, nor did any (significant)
development for them.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

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