R-CAR's arch

R-CAR's arch

[Jean Delvare]

Hi Simon and all,

I am in the process of cleaning up dependencies for hardware-specific
linux drivers. I'm looking into R-CAR drivers now and I have to admit I
am confused. Some drivers (drm, gpio) depend on ARM, some (i2c, gen2
pci, thermal, sata) depend on ARCH_SHMOBILE, sound depends on SUPERH ||
ARCH_SHMOBILE, gen2 usb depends on ARCH_R8A7790 || ARCH_R8A7791, while
gen1 usb and video-in have no architecture/platform dependency at all.

Shouldn't all these drivers have the same architecture/platform
dependency? If so, what would the correct one be?

I admit I don't really understand how SHMOBILE relates to ARM and
SUPERH (which so far I thought were two different and totally
independent architectures, but apparently I was wrong?)

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: R-CAR's arch

[Laurent Pinchart]

Hi Jean,

On Thursday 22 May 2014 10:19:38 Jean Delvare wrote:
> Hi Simon and all,
> 
> I am in the process of cleaning up dependencies for hardware-specific
> linux drivers. I'm looking into R-CAR drivers now and I have to admit I
> am confused. Some drivers (drm, gpio) depend on ARM, some (i2c, gen2
> pci, thermal, sata) depend on ARCH_SHMOBILE, sound depends on SUPERH ||
> ARCH_SHMOBILE, gen2 usb depends on ARCH_R8A7790 || ARCH_R8A7791, while
> gen1 usb and video-in have no architecture/platform dependency at all.
> 
> Shouldn't all these drivers have the same architecture/platform
> dependency? If so, what would the correct one be?
> 
> I admit I don't really understand how SHMOBILE relates to ARM and
> SUPERH (which so far I thought were two different and totally
> independent architectures, but apparently I was wrong?)

CONFIG_SUPERH is defined for arch/sh only, and CONFIG_ARCH_SHMOBILE for 
arch/arm/mach-shmobile.

The Kconfig dependencies for Renesas drivers currently model two different 
things, which are what the driver requires in order to compile and which 
architecture(s) the driver can run on.

There's no question regarding the former. If a driver can only be compiled on 
arch/sh it must list CONFIG_SUPERH as a dependency. Ditto for CONFIG_ARM or 
CONFIG_ARCH_SHMOBILE. However, this should be a pretty uncommon case, as most 
drivers should have no compile dependency on a specific architecture (the 
exception here is when a driver uses an API not available on all architectures 
for which no specific Kconfig symbol exists).

The latter is more debatable. We've started by listing platforms on which the 
hardware is known to exist as dependencies to avoid cluttering the kernel 
configuration with useless options. However, this excludes drivers for 
automated builds that can be very useful to report compilation bugs early. 
We've thus started moving to adding a || COMPILE_TEST dependency to enable 
driver compilation even on architectures where the device isn't available 
(only when the driver is expected to compile properly of course).

We've decided to split dependencies on two (or more) lines, one for the 
runtime dependencies and one or more for the compile time dependencies. A good 
example of that is the SPI MSIOF driver.

config SPI_SH_MSIOF
        tristate "SuperH MSIOF SPI controller"
        depends on HAVE_CLK
        depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
        help
          SPI driver for SuperH and SH Mobile MSIOF blocks.

The first "depends on" line states that the driver requires the clock API to 
compile, and the second line states that the device is available on SUPERH and 
ARCH_SHMOBILE only, but can be compiled on other architectures when 
COMPILE_TEST is enabled.

I'd like to generalize this pattern, please feel free to help :-)

-- 
Regards,

Laurent Pinchart

Re: R-CAR's arch

[Simon Horman]

On Fri, May 23, 2014 at 12:55:07AM +0200, Laurent Pinchart wrote:
> Hi Jean,
> 
> On Thursday 22 May 2014 10:19:38 Jean Delvare wrote:
> > Hi Simon and all,
> > 
> > I am in the process of cleaning up dependencies for hardware-specific
> > linux drivers. I'm looking into R-CAR drivers now and I have to admit I
> > am confused. Some drivers (drm, gpio) depend on ARM, some (i2c, gen2
> > pci, thermal, sata) depend on ARCH_SHMOBILE, sound depends on SUPERH ||
> > ARCH_SHMOBILE, gen2 usb depends on ARCH_R8A7790 || ARCH_R8A7791, while
> > gen1 usb and video-in have no architecture/platform dependency at all.
> > 
> > Shouldn't all these drivers have the same architecture/platform
> > dependency? If so, what would the correct one be?
> > 
> > I admit I don't really understand how SHMOBILE relates to ARM and
> > SUPERH (which so far I thought were two different and totally
> > independent architectures, but apparently I was wrong?)
> 
> CONFIG_SUPERH is defined for arch/sh only, and CONFIG_ARCH_SHMOBILE for 
> arch/arm/mach-shmobile.

For Jean's benefit:

SUPERH is an architecture.
SHMOBILE is the in-kernel name for ARM based SoCs from Renesas.

Some IP blocks are shared between both.
Or more to the point SHMOBILE makes use of some (e.g. driver)
code that was originally developed for use with SUPERH.

> The Kconfig dependencies for Renesas drivers currently model two different 
> things, which are what the driver requires in order to compile and which 
> architecture(s) the driver can run on.
> 
> There's no question regarding the former. If a driver can only be compiled on 
> arch/sh it must list CONFIG_SUPERH as a dependency. Ditto for CONFIG_ARM or 
> CONFIG_ARCH_SHMOBILE. However, this should be a pretty uncommon case, as most 
> drivers should have no compile dependency on a specific architecture (the 
> exception here is when a driver uses an API not available on all architectures 
> for which no specific Kconfig symbol exists).
> 
> The latter is more debatable. We've started by listing platforms on which the 
> hardware is known to exist as dependencies to avoid cluttering the kernel 
> configuration with useless options. However, this excludes drivers for 
> automated builds that can be very useful to report compilation bugs early. 
> We've thus started moving to adding a || COMPILE_TEST dependency to enable 
> driver compilation even on architectures where the device isn't available 
> (only when the driver is expected to compile properly of course).
> 
> We've decided to split dependencies on two (or more) lines, one for the 
> runtime dependencies and one or more for the compile time dependencies. A good 
> example of that is the SPI MSIOF driver.
> 
> config SPI_SH_MSIOF
>         tristate "SuperH MSIOF SPI controller"
>         depends on HAVE_CLK
>         depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
>         help
>           SPI driver for SuperH and SH Mobile MSIOF blocks.
> 
> The first "depends on" line states that the driver requires the clock API to 
> compile, and the second line states that the device is available on SUPERH and 
> ARCH_SHMOBILE only, but can be compiled on other architectures when 
> COMPILE_TEST is enabled.
> 
> I'd like to generalize this pattern, please feel free to help :-)
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 

Re: R-CAR's arch

[Jean Delvare]

Hi Simon,

Le Friday 23 May 2014 à 09:37 +0900, Simon Horman a écrit :
> On Fri, May 23, 2014 at 12:55:07AM +0200, Laurent Pinchart wrote:
> > On Thursday 22 May 2014 10:19:38 Jean Delvare wrote:
> > > I admit I don't really understand how SHMOBILE relates to ARM and
> > > SUPERH (which so far I thought were two different and totally
> > > independent architectures, but apparently I was wrong?)
> > 
> > CONFIG_SUPERH is defined for arch/sh only, and CONFIG_ARCH_SHMOBILE for 
> > arch/arm/mach-shmobile.
> 
> For Jean's benefit:
> 
> SUPERH is an architecture.
> SHMOBILE is the in-kernel name for ARM based SoCs from Renesas.
> 
> Some IP blocks are shared between both.
> Or more to the point SHMOBILE makes use of some (e.g. driver)
> code that was originally developed for use with SUPERH.

OK, I thought it was something like that, thanks for the confirmation.

-- 
Jean Delvare
SUSE L3 Support

Re: R-CAR's arch

[Jean Delvare]

Salut Laurent,

Le Friday 23 May 2014 à 00:55 +0200, Laurent Pinchart a écrit :
> Hi Jean,
> 
> On Thursday 22 May 2014 10:19:38 Jean Delvare wrote:
> > Hi Simon and all,
> > 
> > I am in the process of cleaning up dependencies for hardware-specific
> > linux drivers. I'm looking into R-CAR drivers now and I have to admit I
> > am confused. Some drivers (drm, gpio) depend on ARM, some (i2c, gen2
> > pci, thermal, sata) depend on ARCH_SHMOBILE, sound depends on SUPERH ||
> > ARCH_SHMOBILE, gen2 usb depends on ARCH_R8A7790 || ARCH_R8A7791, while
> > gen1 usb and video-in have no architecture/platform dependency at all.
> > 
> > Shouldn't all these drivers have the same architecture/platform
> > dependency? If so, what would the correct one be?
> > 
> > I admit I don't really understand how SHMOBILE relates to ARM and
> > SUPERH (which so far I thought were two different and totally
> > independent architectures, but apparently I was wrong?)
> 
> CONFIG_SUPERH is defined for arch/sh only, and CONFIG_ARCH_SHMOBILE for 
> arch/arm/mach-shmobile.
> 
> The Kconfig dependencies for Renesas drivers currently model two different 
> things, which are what the driver requires in order to compile and which 
> architecture(s) the driver can run on.
> 
> There's no question regarding the former. If a driver can only be compiled on 
> arch/sh it must list CONFIG_SUPERH as a dependency. Ditto for CONFIG_ARM or 
> CONFIG_ARCH_SHMOBILE. However, this should be a pretty uncommon case, as most 
> drivers should have no compile dependency on a specific architecture (the 
> exception here is when a driver uses an API not available on all architectures 
> for which no specific Kconfig symbol exists).

Yes, I am aware of and agree on that.

> The latter is more debatable. We've started by listing platforms on which the 
> hardware is known to exist as dependencies to avoid cluttering the kernel 
> configuration with useless options. However, this excludes drivers for 
> automated builds that can be very useful to report compilation bugs early. 
> We've thus started moving to adding a || COMPILE_TEST dependency to enable 
> driver compilation even on architectures where the device isn't available 
> (only when the driver is expected to compile properly of course).
> 
> We've decided to split dependencies on two (or more) lines, one for the 
> runtime dependencies and one or more for the compile time dependencies. A good 
> example of that is the SPI MSIOF driver.
> 
> config SPI_SH_MSIOF
>         tristate "SuperH MSIOF SPI controller"
>         depends on HAVE_CLK
>         depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
>         help
>           SPI driver for SuperH and SH Mobile MSIOF blocks.
> 
> The first "depends on" line states that the driver requires the clock API to 
> compile, and the second line states that the device is available on SUPERH and 
> ARCH_SHMOBILE only, but can be compiled on other architectures when 
> COMPILE_TEST is enabled.
>
> I'd like to generalize this pattern, please feel free to help :-)

This is an interesting approach, I like it. I'll stick to it for my
future patches, starting with CONFIG_USB_RCAR_PHY and
CONFIG_VIDEO_RCAR_VIN.

For USB PHY the dependencies are clear. For VIN I'm not so sure, does
anybody know? I'd got for ARCH_SHMOBILE || COMPILE_TEST but I don't know
if SUPERH should be listed too.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: R-CAR's arch

[Geert Uytterhoeven]

Hi Jean,

On Fri, May 23, 2014 at 10:23 AM, Jean Delvare <jdelvare@suse.de> wrote:
> For USB PHY the dependencies are clear. For VIN I'm not so sure, does
> anybody know? I'd got for ARCH_SHMOBILE || COMPILE_TEST but I don't know
> if SUPERH should be listed too.

R-Car falls under shmobile (which also covers Emma Mobile and R-Mobile).
I.e. no SUPERH.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Re: R-CAR's arch

[Jean Delvare]

Le Friday 23 May 2014 à 10:39 +0200, Geert Uytterhoeven a écrit :
> Hi Jean,
> 
> On Fri, May 23, 2014 at 10:23 AM, Jean Delvare <jdelvare@suse.de> wrote:
> > For USB PHY the dependencies are clear. For VIN I'm not so sure, does
> > anybody know? I'd got for ARCH_SHMOBILE || COMPILE_TEST but I don't know
> > if SUPERH should be listed too.
> 
> R-Car falls under shmobile (which also covers Emma Mobile and R-Mobile).
> I.e. no SUPERH.

OK. Patch written and sent, thanks!

-- 
Jean Delvare
SUSE L3 Support

Re: R-CAR's arch

[Sergei Shtylyov]

On 05/23/2014 12:23 PM, Jean Delvare wrote:

>> Hi Jean,

>> On Thursday 22 May 2014 10:19:38 Jean Delvare wrote:
>>> Hi Simon and all,

>>> I am in the process of cleaning up dependencies for hardware-specific
>>> linux drivers. I'm looking into R-CAR drivers now and I have to admit I
>>> am confused. Some drivers (drm, gpio) depend on ARM, some (i2c, gen2
>>> pci, thermal, sata) depend on ARCH_SHMOBILE, sound depends on SUPERH ||
>>> ARCH_SHMOBILE, gen2 usb depends on ARCH_R8A7790 || ARCH_R8A7791, while
>>> gen1 usb and video-in have no architecture/platform dependency at all.

>>> Shouldn't all these drivers have the same architecture/platform
>>> dependency? If so, what would the correct one be?

>>> I admit I don't really understand how SHMOBILE relates to ARM and
>>> SUPERH (which so far I thought were two different and totally
>>> independent architectures, but apparently I was wrong?)

>> CONFIG_SUPERH is defined for arch/sh only, and CONFIG_ARCH_SHMOBILE for
>> arch/arm/mach-shmobile.

>> The Kconfig dependencies for Renesas drivers currently model two different
>> things, which are what the driver requires in order to compile and which
>> architecture(s) the driver can run on.

>> There's no question regarding the former. If a driver can only be compiled on
>> arch/sh it must list CONFIG_SUPERH as a dependency. Ditto for CONFIG_ARM or
>> CONFIG_ARCH_SHMOBILE. However, this should be a pretty uncommon case, as most
>> drivers should have no compile dependency on a specific architecture (the
>> exception here is when a driver uses an API not available on all architectures
>> for which no specific Kconfig symbol exists).

> Yes, I am aware of and agree on that.

>> The latter is more debatable. We've started by listing platforms on which the
>> hardware is known to exist as dependencies to avoid cluttering the kernel
>> configuration with useless options. However, this excludes drivers for
>> automated builds that can be very useful to report compilation bugs early.
>> We've thus started moving to adding a || COMPILE_TEST dependency to enable
>> driver compilation even on architectures where the device isn't available
>> (only when the driver is expected to compile properly of course).

>> We've decided to split dependencies on two (or more) lines, one for the
>> runtime dependencies and one or more for the compile time dependencies. A good
>> example of that is the SPI MSIOF driver.

>> config SPI_SH_MSIOF
>>          tristate "SuperH MSIOF SPI controller"
>>          depends on HAVE_CLK
>>          depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
>>          help
>>            SPI driver for SuperH and SH Mobile MSIOF blocks.

>> The first "depends on" line states that the driver requires the clock API to
>> compile, and the second line states that the device is available on SUPERH and
>> ARCH_SHMOBILE only, but can be compiled on other architectures when
>> COMPILE_TEST is enabled.

>> I'd like to generalize this pattern, please feel free to help :-)

> This is an interesting approach, I like it. I'll stick to it for my
> future patches, starting with CONFIG_USB_RCAR_PHY and
> CONFIG_VIDEO_RCAR_VIN.

> For USB PHY the dependencies are clear.

    Do you mean ARCH_MOBILE || COMPILE_TEST? Actually, looking at generation 2 
PHY entry, ARCH_R8A7778 || ARCH_R8A7779 probably makes more sense.

> For VIN I'm not so sure, does
> anybody know? I'd got for ARCH_SHMOBILE || COMPILE_TEST but I don't know
> if SUPERH should be listed too.

    TTBOMK, no. VIN has been first encountered on ARCH_SMOBILE.

> Thanks,

WBR, Sergei

Re: R-CAR's arch

[Jean Delvare]

Hi Sergei,

On Fri, 23 May 2014 15:31:43 +0400, Sergei Shtylyov wrote:
> On 05/23/2014 12:23 PM, Jean Delvare wrote:
> > This is an interesting approach, I like it. I'll stick to it for my
> > future patches, starting with CONFIG_USB_RCAR_PHY and
> > CONFIG_VIDEO_RCAR_VIN.
> 
> > For USB PHY the dependencies are clear.
> 
>     Do you mean ARCH_MOBILE || COMPILE_TEST? Actually, looking at generation 2 
> PHY entry, ARCH_R8A7778 || ARCH_R8A7779 probably makes more sense.

So I got it right :)

http://marc.info/?l=linux-usb&m\x140083419507463&w=2

> > For VIN I'm not so sure, does
> > anybody know? I'd got for ARCH_SHMOBILE || COMPILE_TEST but I don't know
> > if SUPERH should be listed too.
> 
>     TTBOMK, no. VIN has been first encountered on ARCH_SMOBILE.

OK, thanks.

-- 
Jean Delvare
SUSE L3 Support