* Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> [170508 04:36]:
> The next step is to remove the omapdss platform driver (for the virtual
> omapdss platform device, also known as core code, not to be confused with the
> omapdss_dss driver for the DSS hardware device). Patches 21/28 to 23/28 move
> the useful features of the core to the omapdss_dss driver. Patch 24/28 adds
> omapdrm platform device registration to the omapdss_dss driver to replace
> board code, and patch 25/28 finally removes the omapdss platform driver.
>
> Note that registering the omapdrm platform device from within the omapdss_dss
> driver is a hack, but isn't worse than the current situation. Quite the
> contrary, given that the omapdrm device exists for the sole purpose of
> supporting the omapdrm/omapdss driver architecture, moving it out of platform
> code can be considered as (slightly) cleaner. In any case, it will be easier
> to refactor the code as everything is now isolated on the driver side.
Good to see this happening. While at it, can you please also check that
the struct device entries follow what's in the hardware to avoid more
headaches later on.
The rule of thumb for struct device use here should be that each
interconnect target module is a separate device. If a single interconnect
target module has multiple IP blocks within it, then you need to have a
minimal wrapper driver to deal with the shared hardware resources like
the clkctrl clock ("ti,hwmods") along the lines of what we're doing in
drivers/usb/musb/musb_am335x.c to wrap two musb instances and cppi41 dma
all in a single interconnect target module.
You can detect the interconnect target module with SYSCONFIG and
SYSSTATUS entries listed for it in the TRM. It might be already set
up that way if we're lucky.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
