We have all of mach-omap2 booting in device tree only
mode now, and this data is populated from device tree.

Note that once we have removed support for the omap legacy
DMA, we can also drop struct omap_dma_dev_attr.

Cc: Lokesh Vutla <lokeshvutla@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

With the previous patches removing the need for legacy IRQs
now that all of mach-omap2 is booting in device tree only mode,
we can drop struct omap_hwmod_irq_info.

Note that we can now also finally drop omap4_xlate_irq.

Cc: Lokesh Vutla <lokeshvutla@ti.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

We are now booting all mach-omap2 in device tree only mode.
Any code that is only called in legacy boot mode where
of_have_populated_dt() is not set is safe to remove now.
Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This is not used so let's remove it.
Signed-off-by: NTony Lindgren <tony@atomide.com>

The device node returned by of_find_node_by_name() needs to be released
after it is no longer needed to avoid a device node leak.
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NTony Lindgren <tony@atomide.com>

After commit 0549bde0 ("of: fix of_node leak caused in
of_find_node_opts_by_path"), the following error may be
reported when running omap images.

OF: ERROR: Bad of_node_put() on /ocp@68000000
CPU: 0 PID: 0 Comm: swapper Not tainted 4.10.0-rc7-next-20170210 #1
Hardware name: Generic OMAP3-GP (Flattened Device Tree)
[<c0310604>] (unwind_backtrace) from [<c030bbf4>] (show_stack+0x10/0x14)
[<c030bbf4>] (show_stack) from [<c05add8c>] (dump_stack+0x98/0xac)
[<c05add8c>] (dump_stack) from [<c05af1b0>] (kobject_release+0x48/0x7c)
[<c05af1b0>] (kobject_release)
	from [<c0ad1aa4>] (of_find_node_by_name+0x74/0x94)
[<c0ad1aa4>] (of_find_node_by_name)
	from [<c1215bd4>] (omap3xxx_hwmod_is_hs_ip_block_usable+0x24/0x2c)
[<c1215bd4>] (omap3xxx_hwmod_is_hs_ip_block_usable) from
[<c1215d5c>] (omap3xxx_hwmod_init+0x180/0x274)
[<c1215d5c>] (omap3xxx_hwmod_init)
	from [<c120faa8>] (omap3_init_early+0xa0/0x11c)
[<c120faa8>] (omap3_init_early)
	from [<c120fb2c>] (omap3430_init_early+0x8/0x30)
[<c120fb2c>] (omap3430_init_early)
	from [<c1204710>] (setup_arch+0xc04/0xc34)
[<c1204710>] (setup_arch) from [<c1200948>] (start_kernel+0x68/0x38c)
[<c1200948>] (start_kernel) from [<8020807c>] (0x8020807c)

of_find_node_by_name() drops the reference to the passed device node.
The commit referenced above exposes this problem.

To fix the problem, use of_get_child_by_name() instead of
of_find_node_by_name(); of_get_child_by_name() does not drop
the reference count of passed device nodes. While semantically
different, we only look for immediate children of the passed
device node, so of_get_child_by_name() is a more appropriate
function to use anyway.

Release the reference to the device node obtained with
of_get_child_by_name() after it is no longer needed to avoid
another device node leak.

While at it, clean up the code and change the return type of
omap3xxx_hwmod_is_hs_ip_block_usable() to bool to match its use
and the return type of of_device_is_available().

Cc: Qi Hou <qi.hou@windriver.com>
Cc: Peter Rosin <peda@axentia.se>
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit d9d9cec0 ("ARM: OMAP2+: Remove legacy data from hwmod for
omap3") dropped platform data that should no longer be used as we're
booting with device tree. It turns out that smartreflex is still
using platform data and produces the following errors during probe:

smartreflex smartreflex.0: invalid resource
smartreflex smartreflex.0: omap_sr_probe: ioremap fail
smartreflex: probe of smartreflex.0 failed with error -22
smartreflex smartreflex.1: invalid resource
smartreflex smartreflex.1: omap_sr_probe: ioremap fail
smartreflex: probe of smartreflex.1 failed with error -22

Let's fix the regression by adding back the smartreflex hwmod data.
The long term is to update the smartreflex driver to use device tree
based probing.

Fixes: d9d9cec0 ("ARM: OMAP2+: Remove legacy data from hwmod
for omap3")
Reported-by: NAdam Ford <aford173@gmail.com>
Tested-by: NAdam Ford <aford173@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This data is now coming from device tree so we can remove the
duplicate data. Let's keep the DSS and DMA related things for now
until those have been converted to device tree completely.

While at it, let's also add the trailing commas to data structures
so further processing with scripts will be a bit easier.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add missing sysconfig/sysstatus information
to OMAP3 hwmod. The information has been
checked against OMAP34xx and OMAP36xx TRM.

Without this change DSI block is not reset
during boot, which is required for working
Nokia N950 display.
Signed-off-by: NSebastian Reichel <sre@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: NTony Lindgren <tony@atomide.com>

The McBSPLP's sidetone main clock is the McBSPLP's ICLK, not FCLK as the
sidetone only receives the ICLK from the main McBSP module.
Since the McBSP and sidetone is using the very same clock from PRCM level
the sidetone must not have the prcm section to check the clock status since
the sidetone is only used when McBSP is already configured.
If two separate hwmods looking at the same bit and they would use
pm_runtime in nested way (as it must happen with McBSP and it's ST module)
the hwmod would warn, because the idlest will not match what it is expected
after enable/disable of the clocks.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch enables Synchronous Serial Interface (SSI)
hwmod support for OMAP36xx SoCs (used by Nokia N950/N9).
Signed-off-by: NSebastian Reichel <sre@kernel.org>
Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The legacy-mode device creation logic for IOMMU devices has
been cleaned up, so the device attribute data, irq information
and address data are no longer required. Remove all of these
data for the ISP & IVA IOMMU devices.
Signed-off-by: NSuman Anna <s-anna@ti.com>
[tony@atomide.com: updated to apply for the include]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Remove the mailbox attribute data, irq info and hwmod addr space
data that are used for creating the legacy-style mailbox devices,
there is no need for these as the support for legacy-mode for this
IP is being dropped.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Register crypto hwmod links only if they are not disabled in DT.
If DT information is missing, enable them only for GP devices.

Before this patch crypto hwmod links were always disabled for all HS
devices and it was not possible to use omap-aes and omap-sham linux
drivers.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
[paul@pwsan.com: move the complex IP-block presence heuristics into their
 own function to simplify the code; fix some checkpatch warnings]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

We support decoding the bootloader values if DEBUG is defined.
But we also need to change the struct omap_hwmod flags to have
HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the
boot. Otherwise just the default timings will be displayed
instead of the bootloader configured timings.

This also allows us to clean up the various GPMC related
hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET,
and HWMOD_INIT_NO_IDLE is not needed.

Cc: Brian Hutchinson <b.hutchman@gmail.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Roger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

This is no longer needed now that 3517 is booting in device tree
only mode.
Signed-off-by: NTony Lindgren <tony@atomide.com>

- omap mmc driver supports multiplexing, omap_mmc_hs doesn't
this leads to one of the major confusions in the omap_hsmmc driver

- platform data should be read-only for the driver
most callbacks are not set by the omap3 platform init code while still
required. So they are set from the driver probe function, which is against
the paradigm that platform-data should not be modified by the driver
typical examples are card_detect, read_only callbacks

un-bundling by searching for driver name \"omap_hsmmc in the
arch/arm folder. omap_hsmmc_platform_data is not initialized directly,
but from omap2_hsmmc_info, which is defined in a separate header file
not touched by this patch

hwmod includes platform headers to declare features of the platform. All
the declared features are prefixed OMAP_HSMMC. There is no need to
include platform header from hwmod other except for feature defines
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NAndreas Fenkart <afenkart@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Only a few files really need that platform header. When later splitting
omap_mmc_platform_data into omap_mmc and omap_mmc_hs, those files
declaring an hs mmc platform data will have to change the platform
include, which is a good sanity check.
Also removing omap242x_init_mmc, which is not used anywhere, checked
with grep.
Signed-off-by: NAndreas Fenkart <afenkart@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In sprz318f.pdf "Usage Note 2.7" says that UARTs cannot acknowledge
idle requests in smartidle mode when configured for DMA operations.
This prevents L4 from going idle. So let's use manual idle mode
instead.

Otherwise systems using Sebastian's 8250 patches with DMA will
never enter deeper idle states because of the errata above.

Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit cc824534 ("ARM: OMAP2+: hwmod: Rearm wake-up interrupts
for DT when MUSB is idled") fixed issues with hung UART wake-up
events by calling _reconfigure_io_chain() when MUSB is connected
or disconnected.

As pointed out by Paul Walmsley, we may need to also call
_reconfigure_io_chain() in other cases, so it should be a separate
flag. Let's add HWMOD_RECONFIG_IO_CHAIN as suggested by Paul.
Reviewed-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The fields are not used by the driver and will be removed from platform
data. Don't set them.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

The current entry prevents system from idling if
the hwmod is defined in the .dts file so let's
change the idlemodes.

Note that we probably don't have SYSC_HAS_EMUFREE
or SYSS_HAS_RESET_STATUS either. If we do, those
can be added later on.
Acked-by: NSebastian Reichel <sre@kernel.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

OMAP3 doesn't contain "l3_init_clkdm" clock domain. Use the
proper clock domains for USB Host and USB TLL modules.

Gets rid of the following warnings during boot
 omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm
 omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm
Reported-by: NNishanth Menon <nm@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Fixes: de231388 ("ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3")
Cc: Keshava Munegowda <keshava_mgowda@ti.com>
Cc: Partha Basak <parthab@india.ti.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Use the proper clock name 'usbhost_120m_fck' instead of the
alias 'ehci_logic_fck'

Get rid of the 'ehci_logic_fck' alias from the OMAP3 hwmod data
as well.
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

The IVA MMU is not functional when used through the hwmod and
omap_device layers. Add fixes to clockdomain and hwmod data
to have it functional. The hwmod changes are needed to enable
the clock, and the SWSUP change is needed to wakeup the domain
because the power domain is programmed to be in RET, and there
is no automatic power domain switching to ON.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

CONFIG_OMAP_IOMMU_IVA2 was defined originally to avoid conflicting
usage by tidspbridge and other iommu users. The same can be achieved
by marking the DT node disabled, so remove this obsolete flag and
the corresponding hwmod data can be enabled.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NFlorian Vaussard <florian.vaussard@epfl.ch>
[s-anna@ti.com: revise commit log]
Signed-off-by: NSuman Anna <s-anna@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 7d7e1eba (ARM: OMAP2+: Prepare for irqs.h removal) and commit
ec2c0825 (ARM: OMAP2+: Remove hardcoded IRQs and enable SPARSE_IRQ)
updated the way interrupts for OMAP2/3 devices are defined in the
HWMOD data structures to being an index plus a fixed offset (defined
by OMAP_INTC_START).

Couple of irqs in the OMAP2/3 hwmod data were misconfigured completely
as they were missing this OMAP_INTC_START relative offset. Add this
offset back to fix the incorrect irq data for the following modules:
	OMAP2 - GPMC, RNG
	OMAP3 - GPMC, ISP MMU & IVA MMU
Signed-off-by: NSuman Anna <s-anna@ti.com>
Fixes: 7d7e1eba ("ARM: OMAP2+: Prepare for irqs.h removal")
Fixes: ec2c0825 ("ARM: OMAP2+: Remove hardcoded IRQs and enable SPARSE_IRQ")
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Unlike what the comment states, errata i660 does not state that we
can't RESET the USB host module. Instead it states that RESET is the
only way to recover from a deadlock situation.

RESET ensures that the module is in a known good state irrespective
of what bootloader does with the module, so it must be done at boot.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> # Panda, BeagleXM
Fixes: de231388 ("ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3")
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

This patch adds Synchronous Serial Interface (SSI) hwmod support for
OMAP34xx SoCs.
Signed-off-by: NSebastian Reichel <sre@debian.org>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

With commit '82702ea1' "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: NRajendra Nayak <rnayak@ti.com>
Reported-by: NMark Jackson <mpfj-list@newflow.co.uk>
Reported-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: NMark Jackson <mpfj-list@newflow.co.uk>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

All definitions in arch/arm/mach-omap2/dma.h are removed so it can be
removed now.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Last remaining DMA channel definitions in arch/arm/mach-omap2/dma.h
are used only by omap_hwmod_2xxx_3xxx_ipblock_data.c and
omap_hwmod_3xxx_data.c. Remove them by using directly DMA channel number in
hwmod data and drop definitions with a following script:

egrep '#define [OMAP|AM35XX].*DMA' arch/arm/mach-omap2/dma.h | cut -f 1,3 \
	| while read i; do \
		DEF=`echo $i |cut -d ' ' -f 2`; \
		CH=`echo $i |cut -d ' ' -f 3`; \
		echo "removing" $DEF; \
		sed -i "s/${DEF}/${CH}/" arch/arm/mach-omap2/omap_hwmod_*.c; \
		sed -i "/${DEF}/d" arch/arm/mach-omap2/dma.h; \
	done
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The different generations of OMAP2+ SoCs have almost the same
mailbox IP, but the IP has configurable parameters for number
of users (interrupts it can generate out towards processors)
and number of fifos (the base unidirectional h/w communication
channel). This data cannot be read from any registers, and so
has been added to the platform data.

This data together with the interrupt-type configuration can be
used in properly figuring out the number of registers to save
and restore in the OMAP mailbox driver code.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NSuman Anna <s-anna@ti.com>

The OMAP mailbox platform driver code has been cleaned up to
remove the dependencies with soc.h in preparation for moving
the mailbox code to drivers folder.

The code relied on cpu_is_xxx/soc_is_xxx macros previously to
pick the the right set of mailbox devices and register with the
mailbox driver. This data is now represented in a concise format
and moved to the respective omap_hwmod data files and published
to the driver through the platform data.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NSuman Anna <s-anna@ti.com>

OMAP UART IP needs software control for slave idle modes based on functional
state of the IP. i.e The IP slave idle settings should be set to 'noidle' when
being used and then put back to 'smart_idle' when unused. Currently this is
handled by the driver with function pointers implemented in platform code.
This however breaks in case of device tree because of missing idle handling
APIs.

Previous patches in this series added a flag HWMOD_SWSUP_SIDLE_ACTIVE which
takes care of the mentioned requirement. Hence add the flag for all UART IPs
to take advantage of feature supported by framework.

Subsequent patches removes the slave idle handling from driver code.
Tested-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: NSourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Tested-by: Kevin Hilman <khilman@linaro.org>  # OMAP4/Panda
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Convert the device data for the OMAP3 AES crypto IP
from explicit platform_data to hwmod.

CC: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
[paul@pwsan.com: fixed lines causing sparse warnings]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Convert the device data for the OMAP3 SHAM2 (SHA1/MD5) crypto IP
from explicit platform_data to hwmod.

CC: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
[paul@pwsan.com: updated to use per-SoC registration lists for GP-only hwmods;
 fixed lines causing sparse warnings]
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

For some unknown reason, allowing hwmod to control MIDLEMODE causes
core_pwrdm to not hit idle states for musb in DM3730 at least.
I've verified that setting any MIDLEMODE value other than "force
standby" before enabling the device causes subsequent suspend
attempts to fail with core_pwrdm not entering idle states, even
if the driver is unloaded and "force standby" is restored before
suspend attempt. To recover from this, soft reset can be used, but
that's not suitable solution for suspend.

Keeping the register set at force standby (reset value) makes it work
and device still functions properly, as musb has driver-controlled
OTG_FORCESTDBY register that controls MSTANDBY signal.
Note that TI PSP kernels also have similar workarounds.

This patch also fixes HWMOD_SWSUP_MSTANDBY documentation to match the
actual flag name.
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

According to Mark Greer, on OMAP AM3517/3505 chips, the EMAC is unable
to wake the ARM up from WFI:

    http://www.spinics.net/lists/arm-kernel/msg174734.html

Further troubleshooting was unable to narrow the problem down.  So we
don't have much choice other than to block WFI when the EMAC is active
with the HWMOD_BLOCK_WFI flag.

Based on Mark's original patch.  We're removing the omap_device-based
pm_lats code, so a different approach was needed.

This third version contains some corrections thanks to Mark's review.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Mark A. Greer <mgreer@animalcreek.com>
Acked-by: NMark A. Greer <mgreer@animalcreek.com>

Based on earlier discussions[1] we attempted to find a suitable
location for the omap DMA header in commit 2b6c4e73 (ARM: OMAP:
DMA: Move plat/dma.h to plat-omap/dma-omap.h) until the conversion
to dmaengine is complete.

Unfortunately that was before I was able to try to test compile
of the ARM multiplatform builds for omap2+, and the end result
was not very good.

So I'm creating yet another all over the place patch to cut the
last dependency for building omap2+ for ARM multiplatform. After
this, we have finally removed the driver dependencies to the
arch/arm code, except for few drivers that are being worked on.

The other option was to make the <plat-omap/dma-omap.h> path
to work, but we'd have to add some new header directory to for
multiplatform builds.

Or we would have to manually include arch/arm/plat-omap/include
again from arch/arm/Makefile for omap2+.

Neither of these alternatives sound appealing as they will
likely lead addition of various other headers exposed to the
drivers, which we want to avoid for the multiplatform kernels.

Since we already have a minimal include/linux/omap-dma.h,
let's just use that instead and add a note to it to not
use the custom omap DMA functions any longer where possible.

Note that converting omap DMA to dmaengine depends on
dmaengine supporting automatically incrementing the FIFO
address at the device end, and converting all the remaining
legacy drivers. So it's going to be few more merge windows.

[1] https://patchwork.kernel.org/patch/1519591/#

cc: Russell King <linux@arm.linux.org.uk>
cc: Kevin Hilman <khilman@ti.com>
cc: "Benoît Cousson" <b-cousson@ti.com>
cc: Herbert Xu <herbert@gondor.apana.org.au>
cc: "David S. Miller" <davem@davemloft.net>
cc: Vinod Koul <vinod.koul@intel.com>
cc: Dan Williams <djbw@fb.com>
cc: Mauro Carvalho Chehab <mchehab@infradead.org>
cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
cc: David Woodhouse <dwmw2@infradead.org>
cc: Kyungmin Park <kyungmin.park@samsung.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
cc: Hans Verkuil <hans.verkuil@cisco.com>
cc: Vaibhav Hiremath <hvaibhav@ti.com>
cc: Lokesh Vutla <lokeshvutla@ti.com>
cc: Rusty Russell <rusty@rustcorp.com.au>
cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
cc: Afzal Mohammed <afzal@ti.com>
cc: linux-crypto@vger.kernel.org
cc: linux-media@vger.kernel.org
cc: linux-mtd@lists.infradead.org
cc: linux-usb@vger.kernel.org
cc: linux-fbdev@vger.kernel.org
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>