On 19/06/18 11:18, Felipe Balbi wrote:
Hi,
Roger Quadros <rog...@ti.com> writes:
I suggest merging this fix for 4.18-rc, and then Roger can rework the
driver so that it works also on OMAP.
omap has its own glue layer for several reasons. If you're talking about
Keystone devices, then okay, I understand. But in that case, this would
mean Keystone is copying the same arguably broken PM domain design from
OMAP and it would be best not to propagate that idea.
Maybe so. I'm not sure what Roger's use case is, but perhaps the omap
glue driver could be used instead.
unlikely. Keystone devices are very different from OMAP family. But
we'll see what Roger says.
Well, I was considering to use of-simple for the AM654 SoC [1] but now
I'm of the opinion that it might be better to add a new glue layer driver
why isn't dwc3-keystone.c enough?
It is doing too many things than we really need to for AM654.
I'm assuming you meant you really don't need for AM654. That can be made
optional with the use of a different compatible, right?
for that because
- it needs to poke a few registers in the wrapper region
dwc3-keystone.c does that already
- it doesn't really need the driver to enable any clock
Seems to me you're trying to port omap_device to arm64...
It isn't an omap_device but is very similar to how it is done on
keystone.
Fair enough
- it needs a pm_runtime_get_sync() to be done in probe
this really shouldn't be necessary. Keystone doesn't rely on all the
omap_device legacy. At least it didn't use to. Could it be that you're
just missing a struct dev_pm_domain definition for arm64?
I don't think so. If I had missed it it wouldn't enable at all.
arm64 doesn't define own pm_domain.
I haven't seen how you guys implemented your PM for arm64 (is there a
publically accessible version somewhere?), but I'd say you should take
the opportunity to remove this relying on pm_runtime_get_sync() calls
from probe and just do what everybody else does; namely: enable clocks
on probe, pm_runtime_set_active, etc.
This is something Tero can comment on.
TI SoC arm64 PM is done via genpd attached to each domain, which in turn
passes control messages to the PM firmware when transitions happen. See
drivers/soc/ti_sci_pm_domains.c for details.
Not quite sure about the discussion following later, but there is work
ongoing to get rid of both omap_hwmod and omap_device, and replace this
with a proper bus driver for OMAP architectures. It might solve the
issues being talked about, or then not. Tony, any comments on that?
Anyway, main reason that omap devices are actually suspended on HW level
during probe is the aggressive power management applied on the device,
and based on the documentation this is actually a valid thing to do.
This makes sure that all devices get to idle if they are not used (no
driver probed etc.), and will allow the SoC to idle core powerdomain.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
