ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL

With commit '82702ea11ddfe0e43382e1fa5b66d807d8114916' "ARM: OMAP2+:
Fix serial init for device tree based booting" stubbing out omap_serial_early_init()
for Device tree based booting, there was a crash observed on AM335x based devices
when hwmod does a _setup_reset() early at boot.

This was rootcaused to hwmod trying to reset console uart while earlycon was using it.
The way to tell hwmod not to do this is to specify the HWMOD_INIT_NO_RESET flag,
which were infact set by the omap_serial_early_init() function by parsing the
cmdline to identify the console device.

Parsing the cmdline to identify the uart used by earlycon itself seems broken
as there is nothing preventing earlycon to use a different one.

This patch, instead, attempts to populate the requiste flags for hwmod based on
the CONFIG_DEBUG_OMAPxUARTy FLAGS. This gets rid of the need for cmdline parsing
in the DT as well as non-DT cases to identify the uart used by earlycon.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Reported-by: Mark Jackson <mpfj-list@newflow.co.uk>
Reported-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
serial: omap: enable PM runtime only when its fully configured

If earlyprintk is enabled and current UART is console port the platform
code can mark it as RPM_ACTIVE to sync real IP state with PM Runtime and
avoid resuming of already active device, but now, driver initialization
will be performed in the wrong way:

	pm_runtime_enable(&pdev->dev);
    <-- PM runtime alowed (device state RPM_ACTIVE)
	if (omap_up_info->autosuspend_timeout == 0)
		omap_up_info->autosuspend_timeout = -1;
	device_init_wakeup(up->dev, true);
	pm_runtime_use_autosuspend(&pdev->dev);
	<-- update_autosuspend() will be called and it will disable device
        (device state RPM_SUSPENDED)
	pm_runtime_set_autosuspend_delay(&pdev->dev,
			omap_up_info->autosuspend_timeout);
	<-- update_autosuspend() will be called which will re-enable device
        (device state RPM_ACTIVE), because autosuspend_timeout < 0

	pm_runtime_irq_safe(&pdev->dev);
	pm_runtime_get_sync(&pdev->dev);
	<-- will do nothing

Such behavior isn't expected by OMAP serial drivers and causes
unpredictable calls of serial_omap_runtime_suspend() and
serial_omap_runtime_resume().

Hence, fix it by allowing PM runtime only after all its parameters are
configured.

CC: Tony Lindgren <tony@atomide.com>
CC: Rajendra Nayak <rnayak@ti.com>
CC: Felipe Balbi <balbi@ti.com>
CC: Kevin Hilman <khilman@linaro.org>

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
ARM: OMAP2+: Avoid idling memory controllers with no drivers

Memory controllers in OMAP (like GPMC and EMIF) have the hwmods marked with
HWMOD_INIT_NO_IDLE and are left in enabled state post initial setup.

Even if they have drivers missing, avoid idling them as part of
omap_device_late_idle()

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
ARM: OMAP2+: Sync hwmod state with the pm_runtime and omap_device state

Some hwmods which are marked with HWMOD_INIT_NO_IDLE are left in enabled
state post setup(). When a omap_device gets created for such hwmods
make sure the omap_device and pm_runtime states are also in sync for such
hwmods by doing a omap_device_enable() and pm_runtime_set_active() for the
device.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
ARM: DRA: hwmod: enable debug_ll flag for uart1

Enabling debug flag of DEBUG_LL is enabled.
For more info please refer to the commit:
"397983f ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with
DEBUG_LL"

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>