Re: [PATCH 9/9] ARM: OMAP2+: Drop legacy platform data for dra7 timers except timer1 to 4

[Tony Lindgren <tony@atomide.com>]

* Tero Kristo <t-kristo@ti.com> [191211 13:00]:
> On 11/12/2019 04:10, Andrew F. Davis wrote:
> > On 12/10/19 6:35 PM, Tony Lindgren wrote:
> > > We can now probe devices with ti-sysc interconnect driver and dts
> > > data. Let's drop the related platform data and custom ti,hwmods
> > > dts property.
> > > 
> > > As we're just dropping data, and the early platform data init
> > > is based on the custom ti,hwmods property, we want to drop both
> > > the platform data and ti,hwmods property in a single patch.
...

> > > @@ -2069,12 +1783,6 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
> > >   	NULL,
> > >   };
> > > -/* GP-only hwmod links */
> > > -static struct omap_hwmod_ocp_if *dra7xx_gp_hwmod_ocp_ifs[] __initdata = {
> > > -	&dra7xx_l4_wkup__timer12,
> > > -	NULL,
> > > -};
> > > -
> > >   /* SoC variant specific hwmod links */
> > >   static struct omap_hwmod_ocp_if *dra76x_hwmod_ocp_ifs[] __initdata = {
> > >   	&dra7xx_l4_per3__usb_otg_ss4,
> > > @@ -2124,8 +1832,5 @@ int __init dra7xx_hwmod_init(void)
> > >   		}
> > >   	}
> > > -	if (!ret && omap_type() == OMAP2_DEVICE_TYPE_GP)
> > > -		ret = omap_hwmod_register_links(dra7xx_gp_hwmod_ocp_ifs);
> > > -
> > 
> > 
> > Maybe I'm missing it but how is this logic getting replicated when using
> > ti,sync? We runtime detect here if we are on an HS device and if so let
> > the secure world manage these device's pm/clocks, without this the
> > non-secure side managment will be unconditional.
> 
> This is handled by the clkctrl driver itself. timer12 is marked as NON-SEC
> device supported only, so it doesn't get registered on HS chips.
> 
> I guess the lack of the clock fails the ti-sysc part of the registration
> logic also. Tony?

Yes it should bail out with a clock error. To avoid an error for that
in dmesg the timer needs to be tagged with status = "disabled" though.

For drivers, we have soc_device_match() to use that should work for
detecting SoCs type on boot. Maybe cat /sys/bus/soc/devices/soc0/type
to confirm this as I don't think we're currently using it for
detecting HS SoCs anywhere.

Regards,

Tony