After converting am335x to probe devices with simple-pm-bus I noticed
that we are not passing auxdata for of_platform_populate() like we do
with simple-bus.

While device tree using SoCs should no longer need platform data, there
are still quite a few drivers that still need it as can be seen with
git grep OF_DEV_AUXDATA. We want to have simple-pm-bus be usable as a
replacement for simple-bus also for cases where OF_DEV_AUXDATA is still
needed.

Let's fix the issue by passing auxdata as platform data to simple-pm-bus.
That way the SoCs needing this can pass the auxdata with OF_DEV_AUXDATA.
And let's pass the auxdata for omaps to fix the issue for am335x.

As an alternative solution, adding simple-pm-bus handling directly to
drivers/of/platform.c was considered, but we would still need simple-pm-bus
device driver. So passing auxdata as platform data seems like the simplest
solution.

Fixes: 5a230524 ("ARM: dts: Use simple-pm-bus for genpd for am3 l4_wkup")
Acked-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NTony Lindgren <tony@atomide.com>

With commit df6c2ec8 ("ARM: OMAP2+: Drop legacy remaining legacy
platform data for am4") we moved am4 to boot with simple-pm-bus using
genpd and devicetree based data. But I forgot to test am4 only build
that still has few references to the old platform data left, and cause
undefined reference errors with omap_hwmod_set_postsetup_state and
omap_hwmod_for_each. We can just drop the related calls for am4 now,
and also drop the references to unused struct wkup_m3_platform_data.
Reported-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

If we have only am3 selected, there's no need to build the
hwmod related code as we are probing devices with device tree
data.
Signed-off-by: NTony Lindgren <tony@atomide.com>

In preparation for probing the interconnects with simple-pm-bus to
make use of genpd, we need to probe the always-on PRCM first for the
clocks needed by l4_wkup instance.
Signed-off-by: NTony Lindgren <tony@atomide.com>

We need to know SoC type and features for cases where the same SoC
may be installed in various versions on the same board and would need
a separate dts file otherwise for the different variants.

For example, am3703 is pin compatible with omap3630, but has sgx and
iva accelerators disabled. We must not try to access the sgx or iva
module registers on am3703, and need to set the unavailable devices
disabled early.

Let's also detect omap3430 as that is needed for display subsystem
(DSS) reset later on, and GP vs EMU or HS devices. Further SoC
specific disabled device detection can be added as needed, such as
dra71x vs dra76x rtc and usb4.

Cc: Adam Ford <aford173@gmail.com>
Cc: André Hentschel <nerv@dawncrow.de>
Cc: H. Nikolaus Schaller <hns@goldelico.com>
Cc: Keerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

We can now start passing sdma auxdata to the dmaengine driver to start
removing the platform based sdma init.

Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Vinod Koul <vkoul@kernel.org>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NVinod Koul <vkoul@kernel.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The IPU1 MMU has been using common IOMMU pdata quirks defined and
used by all IPU IOMMU devices on OMAP4 and beyond. Separate out the
pdata for IPU1 MMU with the additional .set_pwrdm_constraint ops
plugged in, so that the IPU1 power domain can be restricted to ON
state during the boot and active period of the IPU1 remote processor.
This eliminates the pre-conditions for the IPU1 boot issue as
described in commit afe518400bdb ("iommu/omap: fix boot issue on
remoteprocs with AMMU/Unicache").

NOTE:
1. RET is not a valid target power domain state on DRA7 platforms,
   and IPU power domain is normally programmed for OFF. The IPU1
   still fails to boot though, and an unclearable l3_noc error is
   thrown currently on 4.14 kernel without this fix. This behavior
   is slightly different from previous 4.9 LTS kernel.
2. The fix is currently applied only to IPU1 on DRA7xx SoC, as the
   other affected processors on OMAP4/OMAP5/DRA7 are in domains
   that are not entering RET. IPU2 on DRA7 is in CORE power domain
   which is only programmed for ON power state. The fix can be easily
   scaled if these domains do hit RET in the future.
3. The issue was not seen on current DRA7 platforms if any of the
   DSP remote processors were booted and using one of the GPTimers
   5, 6, 7 or 8 on previous 4.9 LTS kernel. This was due to the
   errata fix for i874 implemented in commit 1cbabcb9 ("ARM:
   DRA7: clockdomain: Implement timer workaround for errata i874")
   which keeps the IPU1 power domain from entering RET when the
   timers are active. But the timer workaround did not make any
   difference on 4.14 kernel, and an l3_noc error was seen still
   without this fix.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

IOMMU driver will be using ti-sysc bus driver for power management control
going forward, and the pdata quirks are not needed for anything anymore.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The parent clockdomain for reset must be in force wakeup mode, otherwise
the reset may never complete. Add pdata quirks for this purpose for PRM
driver.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

We must bail out early if the clock is not hw_omap. Otherwise we will
try to access invalid address with hwclk->clkdm_name:

Unable to handle kernel paging request at virtual address ffffffff
Internal error: Oops: 27 [#1] ARM
...
(strcmp) from [<c011b348>] (clkdm_lookup+0x40/0x60)
[<c011b348>] (clkdm_lookup) from [<c011cb84>] (ti_sysc_clkdm_init+0x5c/0x64)
[<c011cb84>] (ti_sysc_clkdm_init) from [<c03680a8>] (sysc_probe+0x948/0x117c)
[<c03680a8>] (sysc_probe) from [<c03d0af4>] (platform_drv_probe+0x48/0x98)
...

Fixes: 2b2f7def ("bus: ti-sysc: Add support for missing clockdomain handling")
Signed-off-by: NTony Lindgren <tony@atomide.com>

There is a new driver in drivers/mmc/host/omap_hsmmc.c
configured by CONFIG_MMC_OMAP_HS and the last user
was the pdata-quirks for pandora.
Suggested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NH. Nikolaus Schaller <hns@goldelico.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

With a wl1251 child node of mmc3 in the device tree decoded
in omap_hsmmc.c to handle special wl1251 initialization, we do
no longer need to instantiate the mmc3 through pdata quirks.

We also can remove the wlan regulator and reset/interrupt definitions
and do them through device tree.

Fixes: 81eef6ca ("mmc: omap_hsmmc: Use dma_request_chan() for requesting DMA channel")
Signed-off-by: NH. Nikolaus Schaller <hns@goldelico.com>
Cc: <stable@vger.kernel.org> # v4.7+
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This partly reverts the commit efdfeb07 ("regulator: fixed: Convert to
use GPIO descriptor only").

We must remove this from mainline first, so that the following patch
to remove the openpandora quirks for mmc3 and wl1251 cleanly applies
to stable v4.9, v4.14, v4.19 where the above mentioned patch is not yet
present.

Since the code affected is removed (no pandora gpios in pdata-quirks
and more), there will be no matching revert-of-the-revert.
Signed-off-by: NH. Nikolaus Schaller <hns@goldelico.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

All TI_ST users have been migrated to the new serdev based HCILL
bluetooth driver. That driver is initialized from DT and does not
need any platform quirks.
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The OMAP3 ISP IOMMU does not have any reset lines, so it didn't
need any pdata previously. The OMAP IOMMU driver now requires the
platform data ops for device_enable/idle on all the IOMMU devices
after commit db8918f6 ("iommu/omap: streamline enable/disable
through runtime pm callbacks") to enable/disable the clocks properly
and maintain the reference count and the omap_hwmod state machine.
So, add these callbacks through iommu pdata quirks for the OMAP3
ISP IOMMU.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The OMAP IOMMU driver requires the device_enable/idle platform
data ops on all the IOMMU devices to be able to enable and disable
the clocks after commit db8918f6 ("iommu/omap: streamline
enable/disable through runtime pm callbacks"). Plug in these
pdata ops for all the existing IOMMUs through pdata quirks to
maintain functionality.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 0ed266d7 ("clk: ti: omap3: cleanup unnecessary clock aliases")
removed old omap3 clock framework aliases but caused omap3-rom-rng to
stop working with clock not found error.

Based on discussions on the mailing list it was requested by Tero Kristo
that it would be best to fix this issue by probing omap3-rom-rng using
device tree to provide a proper clk property. The other option would be
to add back the missing clock alias, but that does not help moving things
forward with removing old legacy platform_data.

Let's also add a proper device tree binding and keep it together with
the fix.

Cc: devicetree@vger.kernel.org
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Adam Ford <aford173@gmail.com>
Cc: Pali Rohár <pali.rohar@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Tero Kristo <t-kristo@ti.com>
Fixes: 0ed266d7 ("clk: ti: omap3: cleanup unnecessary clock aliases")
Reported-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

In general we should check for GP device instead of HS device unless
the other options such as EMU are also checked. Otherwise omap3-rom-rng
won't probe on few of the old n900 macro boards still in service in
automated build and boot test systems.

Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Adam Ford <aford173@gmail.com>
Cc: Pali Rohár <pali.rohar@gmail.com>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

We can currently get "Unable to handle kernel paging request at
virtual address" for invalid clocks with dts node but no driver:

(__clk_get_hw) from [<c0138ebc>] (ti_sysc_find_one_clockdomain+0x18/0x34)
(ti_sysc_find_one_clockdomain) from [<c0138f0c>] (ti_sysc_clkdm_init+0x34/0xdc)
(ti_sysc_clkdm_init) from [<c0584660>] (sysc_probe+0xa50/0x10e8)
(sysc_probe) from [<c065c6ac>] (platform_drv_probe+0x58/0xa8)

Let's add IS_ERR checks to ti_sysc_clkdm_init() as And let's start treating
clk_get() with -ENOENT as a proper error. If the clock name is specified
in device tree we must succeed with clk_get() to continue. For modules with
no clock names specified in device tree we will just ignore the clocks.

Fixes: 2b2f7def ("bus: ti-sysc: Add support for missing clockdomain handling")
Acked-by: NRoger Quadros <rogerq@ti.com>
Tested-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Based on 2 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NEnrico Weigelt <info@metux.net>
Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: NAllison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We need to let ti-sysc driver manage clockdomain autoidle for the
duration of of reset, enable and idle. And we need to do it before we
enable the clock and after we disable it. Currently we are still
relying on platform callbacks indirectly managing clockdomain autoidle.
But I noticed that for device tree only probed drivers it now happens
only after we enabling the clocks and before we disable the clocks,
while it should be the other way around. So far I have not noticed
any issues with this though.

Let's add new ti_sysc_clkdm_deny_idle() and ti_sysc_clkdm_allow_idle()
functions for ti-sysc driver to use to manage clockdomains directly via
platform data callbacks. Note that we can implement the clockdomain
functions in pdata-quirks.c as for probing devices without "ti,hwmods"
custom property we don't need to use the other platform data callbacks.

Let's do this in one patch as there's is still an unlikely chance we
may need to apply this as a fix for v5.2 for dropping legacy platform
data for some devices. We also do have the option of adding back the
platform data if needed in case of trouble.
Tested-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This pushes the handling of inversion semantics and open drain
settings to the GPIO descriptor and gpiolib. All affected board
files are also augmented.

This is especially nice since we don't have to have any
confusing flags passed around to the left and right littering
the fixed and GPIO regulator drivers and the regulator core.
It is all just very straight-forward: the core asks the GPIO
line to be asserted or deasserted and gpiolib deals with the
rest depending on how the platform is configured: if the line
is active low, it deals with that, if the line is open drain,
it deals with that too.

Cc: Alexander Shiyan <shc_work@mail.ru> # i.MX boards user
Cc: Haojian Zhuang <haojian.zhuang@gmail.com> # MMP2 maintainer
Cc: Aaro Koskinen <aaro.koskinen@iki.fi> # OMAP1 maintainer
Cc: Tony Lindgren <tony@atomide.com> # OMAP1,2,3 maintainer
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com> # EM-X270 maintainer
Cc: Robert Jarzmik <robert.jarzmik@free.fr> # EZX maintainer
Cc: Philipp Zabel <philipp.zabel@gmail.com> # Magician maintainer
Cc: Petr Cvek <petr.cvek@tul.cz> # Magician
Cc: Robert Jarzmik <robert.jarzmik@free.fr> # PXA
Cc: Paul Parsons <lost.distance@yahoo.com> # hx4700
Cc: Daniel Mack <zonque@gmail.com> # Raumfeld maintainer
Cc: Marc Zyngier <marc.zyngier@arm.com> # Zeus maintainer
Cc: Geert Uytterhoeven <geert+renesas@glider.be> # SuperH pinctrl/GPIO maintainer
Cc: Russell King <rmk+kernel@armlinux.org.uk> # SA1100
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> #OMAP1 Amstrad Delta
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The MCBSP config option has been changed.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The OMAP HSMMC driver has some elaborate and hairy handling for
passing GPIO card detect and write protect lines from a boardfile
into the driver: the machine defines a struct omap2_hsmmc_info
that is copied into struct omap_hsmmc_platform_data by
omap_hsmmc_pdata_init() in arch/arm/mach-omap2/hsmmc.c.

However the .gpio_cd and .gpio_wp fields are not copied from
omap2_hsmmc_info to omap_hsmmc_platform_data by
omap_hsmmc_pdata_init() so they remain unused. The only platform
defining omap2_hsmmc_info also define both to -1, unused.

It turn out there are no boardfiles passing any valid GPIO
lines into the OMAP HSMMC driver at all. And since we are not
going to add any more OMAP2 boardfiles, we can delete this
card detect and write protect handling altogether.

This seems to also fix a bug: the card detect callback
mmc_gpio_get_cd() in the slot GPIO core needs to be called
by drivers utilizing slot GPIO. It appears the the boardfile
quirks were not doing this right, so this would only get
called for boardfiles, i.e. since no boardfile was using it,
never.

Just assign mmc_gpio_get_cd() unconditionally to omap_hsmmc_ops
.get_cd() so card detects from the device tree works.
AFAICT card detect with GPIO lines assigned from
mmc_of_parse() are not working at the moment, but that is
no regression since it probably never worked.

Cc: Tony Lindgren <tony@atomide.com>
Cc: linux-omap@vger.kernel.org
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

As we augmented the regulator core to accept a GPIO descriptor instead
of a GPIO number, we can augment the fixed GPIO regulator to look up
and pass that descriptor directly from device tree or board GPIO
descriptor look up tables.

Some boards just auto-enumerate their fixed regulator platform devices
and I have assumed they get names like "fixed-regulator.0" but it's
pretty hard to guess this. I need some testing from board maintainers to
be sure. Other boards are straight forward, using just plain
"fixed-regulator" (ID -1) or "fixed-regulator.1" hammering down the
device ID.

It seems the da9055 and da9211 has never got around to actually passing
any enable gpio into its platform data (not the in-tree code anyway) so we
can just decide to simply pass a descriptor instead.

The fixed GPIO-controlled regulator in mach-pxa/ezx.c was confusingly named
"*_dummy_supply_device" while it is a very real device backed by a GPIO
line. There is nothing dummy about it at all, so I renamed it with the
infix *_regulator_* as part of this patch set.

Intel MID portions tested by Andy.

Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Check the x86 BCM stuff
Acked-by: Tony Lindgren <tony@atomide.com> # OMAP1,2,3 maintainer
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Reviewed-by: NMike Rapoport <rppt@linux.vnet.ibm.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

regulator: fixed/gpio: Revert GPIO descriptor changes due to platform breakage

Commit 6059577c "regulator: fixed: Convert to use GPIO descriptor
only" broke at least the ams-delta platform since the lookup tables
added to the board files use the function name "enable" while the driver
uses NULL causing the regulator to not acquire and control the enable
GPIOs.  Revert that and a couple of other commits that are caught up
with it to fix the issue:

2b6c00c1 "ARM: pxa, regulator: fix building ezx e680"
6059577c "regulator: fixed: Convert to use GPIO descriptor only"
37bed97f "regulator: gpio: Get enable GPIO using GPIO descriptor"
Reported-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

As we augmented the regulator core to accept a GPIO descriptor instead
of a GPIO number, we can augment the fixed GPIO regulator to look up
and pass that descriptor directly from device tree or board GPIO
descriptor look up tables.

Some boards just auto-enumerate their fixed regulator platform devices
and I have assumed they get names like "fixed-regulator.0" but it's
pretty hard to guess this. I need some testing from board maintainers to
be sure. Other boards are straight forward, using just plain
"fixed-regulator" (ID -1) or "fixed-regulator.1" hammering down the
device ID.

The OMAP didn't have proper label names on its GPIO chips so I have fixed
this with a separate patch to the GPIO tree, see
commit 088413bc
"gpio: omap: Give unique labels to each GPIO bank/chip"

It seems the da9055 and da9211 has never got around to actually passing
any enable gpio into its platform data (not the in-tree code anyway) so we
can just decide to simply pass a descriptor instead.

The fixed GPIO-controlled regulator in mach-pxa/ezx.c was confusingly named
"*_dummy_supply_device" while it is a very real device backed by a GPIO
line. There is nothing dummy about it at all, so I renamed it with the
infix *_regulator_* as part of this patch set.

For the patch hunk hitting arch/blackfin I would say I do not expect
testing, review or ACKs anymore so if it works, it works.

The hunk hitting the x86 BCM43xx driver is especially tricky as the number
comes out of SFI which is a mystery to me. I definately need someone to
look at this. (Hi Andy.)

Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Check the x86 BCM stuff
Cc: Alexander Shiyan <shc_work@mail.ru> # i.MX boards user
Cc: Haojian Zhuang <haojian.zhuang@gmail.com> # MMP2 maintainer
Cc: Aaro Koskinen <aaro.koskinen@iki.fi> # OMAP1 maintainer
Cc: Tony Lindgren <tony@atomide.com> # OMAP1,2,3 maintainer
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com> # EM-X270 maintainer
Cc: Robert Jarzmik <robert.jarzmik@free.fr> # EZX maintainer
Cc: Philipp Zabel <philipp.zabel@gmail.com> # Magician maintainer
Cc: Daniel Mack <zonque@gmail.com> # Raumfeld maintainer
Cc: Marc Zyngier <marc.zyngier@arm.com> # Zeus maintainer
Cc: Geert Uytterhoeven <geert+renesas@glider.be> # SuperH pinctrl/GPIO maintainer
Cc: Russell King <rmk+kernel@armlinux.org.uk> # SA1100
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Looks like these functions don't do anything in the mainline kernel so
we can just drop it.

Note that we must now also remove ir-rx51 pdata as it relies on the dummy
platform data that does not do anything. And ir-rx51 is calling a pdata
callback that doesn't do anything without checking if it exists first.

For configuring device specific minimal latencies, the interface to use
is pm_qos_add_request(). For an example, see what was done in commit
9834ffd1 ("ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent
glitches"). I've added some comments to ir-rx51 so people using it can
add pm_qos support and test it.

Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Cc: Kevin Hilman <khilman@kernel.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Let's enable ti-sysc probing of child devices. So far we have only used
ti-sysc to probe interconnect target modules to idle them for cases where
the SoC does not have any child devices configured for the module, such
as smartreflex on dra7.

As we have smartreflex driver configured in the device tree for some SoCs,
we need to flip things on with a single patch to prevent both omap_device
and ti-sysc to probe smartreflex. So let's stop probing smartreflex with
omap_device and probe it with ti-sysc by enabling passing the auxdata.
Signed-off-by: NTony Lindgren <tony@atomide.com>

We want to pass the device tree configuration for interconnect target
modules from ti-sysc driver to the existing platform hwmod code.

This allows us to first validate the dts data against the existing
platform data before we start dropping the platform data in favor of
device tree data.

To do this, let's add platform data callbacks for PM runtime functions
to call for the interconnect target modules if platform data is
available.

Note that as ti-sysc driver can rebind, omap_auxdata_lookup and related
functions can no longer be __init.
Signed-off-by: NTony Lindgren <tony@atomide.com>

We are still initializing smartreflex with platform data using
omap_device_build(). We can instead pass the platform data in
with auxdata in pdata-quirks.c and make the driver use that
in later patches.

Note that we cannot enable the auxdata use yet, this is done
in the last patch of the series.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Remove unused timer pdata.
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Tested-by: NLadislav Michl <ladis@linux-mips.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The header file is currently under plat-omap directory
under arch/omap. Move this out to an accessible place.

No Code changes done to the header file and renamed to timer-ti-dm.h.
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Tested-by: NLadislav Michl <ladis@linux-mips.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

DRA74x EVM Rev H EVM comes with revision 2.0 silicon.
However, earlier versions of EVM can come with either
revision 1.1 or revision 1.0 of silicon.

The device-tree file is written to support rev 2.0 of
silicon. pdata quirks are used to then override the
settings needed for PG 1.1 silicon.

PG 1.1 silicon has limitations w.r.t frequencies at
which MMC1/2/3 can operate as well as different IOdelay
numbers.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

As reported by kernel build test:

   In file included from arch/arm/mach-omap2/pdata-quirks.c:15:0:
>> arch/arm/mach-omap2/pdata-quirks.c:536:49: error: 'rx51_lirc_data' undeclared here (not in a function)
     OF_DEV_AUXDATA("nokia,n900-ir", 0, "n900-ir", &rx51_lirc_data),
                                                    ^
   include/linux/of_platform.h:52:21: note: in definition of macro 'OF_DEV_AUXDATA'
       .platform_data = _pdata }
                        ^~~~~~

Since "a92def1b [media] ir-rx51: port to rc-core" the build fails on
some arm configurations.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

This driver was written using lirc since rc-core did not support
transmitter-only hardware at that time. Now that it does, port
this driver.

Compile tested only.
Signed-off-by: NSean Young <sean@mess.org>
Cc: Timo Kokkonen <timo.t.kokkonen@iki.fi>
Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

It's possible that there are multiple quirks that need to be initialized
for the same SoC. Fix the issue by not returning on the first match.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 485fa126 ("ARM: OMAP2+: LogicPD Torpedo + Wireless: Add Bluetooth")
set the wrong baud rate for the UART. The Baud rate was 300,000 and it should
be 3,000,000 for WL1283.
Signed-off-by: NAdam Ford <aford173@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Drop dmtimer usage for pulse timer in favor of hrtimer. That allows
removing PWM dmitimer platform data usage.
Signed-off-by: NIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Acked-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>