Merge tag 'omap-for-v3.16/l3-noc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/drivers

Merge "ARM: omap l3-noc bus driver changes for v3.16 merge window, resend" from
Tony Lindgren:

Improvments to omap l3-noc bus driver for v3.16 merge window
to add support for am347x and dra7.

* tag 'omap-for-v3.16/l3-noc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: (25 commits)
  bus: omap_l3_noc: Add AM4372 interconnect error data
  bus: omap_l3_noc: Add DRA7 interconnect error data
  bus: omap_l3_noc: introduce concept of submodule
  bus: omap_l3_noc: Add information about the context of operation
  bus: omap_l3_noc: add information about the type of operation
  bus: omap_l3_noc: ignore masked out unclearable targets
  bus: omap_l3_noc: improve readability by using helper for slave event parsing
  bus: omap_l3_noc: make error reporting and handling common
  bus: omap_l3_noc: fix masterid detection
  bus: omap_l3_noc: convert flagmux information into a structure
  bus: omap_l3_noc: use of_match_data to pick up SoC information
  bus: omap_l3_noc: Add support for discountinous flag mux input numbers
  bus: omap_l3_noc: convert target information into a structure
  bus: omap_l3_noc: move L3 master data structure out
  bus: omap_l3_noc: un-obfuscate l3_targ address computation
  bus: omap_l3_noc: switch over to relaxed variants of readl/writel
  bus: omap_l3_noc: populate l3->dev and use it
  bus: omap_l3_noc: remove iclk from omap_l3 struct
  bus: omap_l3_noc: rename functions and data to omap_l3
  bus: omap_l3_noc: Fix copyright information
  ...
Signed-off-by: NOlof Johansson <olof@lixom.net>

The match tables must be zero-terminated, and Kbuild now helpfully
fails to link the kernel if that isn't the case.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

This patch documents the sysfs properties exposed by the Broadcom GISB
bus arbiter hardware.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

This patch adds the Broadcom GISB arbiter Device Tree binding that is
used on all Broadcom Set-top-box System-on-a-chip.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

This patch adds support for the Broadcom GISB arbiter bus timeout/error
handler. GISB is a proprietary bus used by Broadcom Set Top Box
System-on-a-chip devices (BCM7xxx) which allows multiple masters and
clients to be interfaced with each other.

The bus arbiter offers support for generating two interrupts towards the
host CPU, thus allowing us to "catch" clock gated masters, or masters
being volontarily blocked for powersaving purposes, or do general system
troubleshooting.

We also register a hook with the ARM fault exception handling to allow
printing a more informative message than "imprecise external abort at
0x00000000" for instance.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Allwinner drivers changes for 3.16, take 2

Add reset driver for the A31

* tag 'sunxi-drivers-for-3.16-2' of https://github.com/mripard/linux:
  power: reset: Add Allwinner A31 reset code
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Merge tag 'qcom-drivers-for-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom into next/drivers

Qualcomm ARM Based driver Updates for v3.16

* Introduce drivers/soc directory for misc SoC specific code
* Add driver to configure GSBI device

* tag 'qcom-drivers-for-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom:
  soc: qcom: Add GSBI driver
  soc: Introduce drivers/soc place-holder for SOC specific drivers
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The GSBI (General Serial Bus Interface) driver controls the overarching
configuration of the shared serial bus infrastructure on APQ8064, IPQ8064, and
earlier QCOM processors.  The GSBI supports UART, I2C, SPI, and UIM
functionality in various combinations.
Signed-off-by: NAndy Gross <agross@codeaurora.org>
Signed-off-by: NKumar Gala <galak@codeaurora.org>

Based on earlier thread "https://lkml.org/lkml/2013/10/7/662" and
discussion at Kernel Summit'2013, it was agreed to create
'driver/soc' for drivers which are quite SOC specific.

Further discussion on the subject is in response to
the earlier version of the patch is here:
	http://lwn.net/Articles/588942/

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: NSandeep Nair <sandeep_n@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NKumar Gala <galak@codeaurora.org>

That code used to be in the machine code, but it's more fit here with other
restart hooks.

That will allow to cleanup the machine directory, while waiting for a proper
watchdog driver for the A31.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>

Merge tag 'samsung-drivers' of http://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into next/drivers

Merge "Samsung driver update for 3.16" from Kukjin Kim:

exynos_mct update for v3.16

- register sched_clock callback to use clocksource mct-frc

* tag 'samsung-drivers' of http://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
  clocksource: exynos_mct: register sched_clock callback
Signed-off-by: NOlof Johansson <olof@lixom.net>

Merge "Allwinner drivers changes for 3.16" from Maxime Ripard:

Reset drivers for the A31, that have been merged with reset maintainer's
Acked-by.

* 'sunxi/drivers-for-3.16' of https://github.com/mripard/linux:
  reset: sunxi: allow MFD subdevices probe
  reset: sunxi: document sunxi's reset controllers bindings
Signed-off-by: NOlof Johansson <olof@lixom.net>

Merge "ARM: mvebu: driver changes for v3.16" from Jason Cooper:

mvebu driver changes for v3.16

 - mvebu-devbus
    - changes need to add support for the orion5x platform

* tag 'mvebu-drivers-3.16' of git://git.infradead.org/linux-mvebu:
  memory: mvebu-devbus: add a devbus, keep-config property
  memory: mvebu-devbus: add Orion5x support
  memory: mvebu-devbus: split functions
  memory: mvebu-devbus: use _SHIFT suffixes instead of _BIT
  memory: mvebu-devbus: use ARMADA_ prefix in defines
  ARM: orion5x: fix target ID for crypto SRAM window
  memory: mvebu-devbus: fix the conversion of the bus width
Signed-off-by: NOlof Johansson <olof@lixom.net>

The current implementation uses sunxi_reset_init function for both early
init and platform device probe.

The sunxi_reset_init function uses DT to retrieve device resources, which
will be an issue if reset controllers are registered from an MFD device
that define resources from mfd_cell definition.

Moreover, we can make of devm functions when we're in the probe context.
Signed-off-by: NBoris BREZILLON <boris.brezillon@free-electrons.com>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>

Add DT bindings documentation for sunxi's reset controllers.
Signed-off-by: NBoris BREZILLON <boris.brezillon@free-electrons.com>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>

Merge tag 'socfpga-driver-update-for-3.16' of git://git.rocketboards.org/linux-socfpga-next into next/drivers

Merge "drivers: Add reset driver for SOCFPGA" from Dinh Nguyen:

Add a reset driver for the SOCFPGA platform.

* tag 'socfpga-driver-update-for-3.16' of git://git.rocketboards.org/linux-socfpga-next:
  reset: add driver for socfpga
Signed-off-by: NOlof Johansson <olof@lixom.net>

Add AM4372 information to handle L3 error.

AM4372 has two clk domains 100f and 200s. Provide flagmux and data
associated with it.

NOTE: Timeout doesn't have STDERRLOG_MAIN register. And per hardware
team, L3 timeout error cannot be cleared the normal way (by setting
bit 31 in STDERRLOG_MAIN), instead it may be required to do system
reset. L3 error handler can't help in such scenarios.

Hence indicate timeout target offset as L3_TARGET_NOT_SUPPORTED as
done for undocumented bits.
Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

DRA7 is distinctly different from OMAP4 in terms of masters and clock
domain organization. There two main clock domains which is divided as
follows:
     <0x44000000 0x1000000> is clk1 and clk2 is the sub clock domain
     <0x45000000 0x1000> is clk3

Add all the data needed to handle L3 error handling on DRA7 devices
and mark clk2 as subdomain and provide a compatible flag for
functionality. Other than the data difference the hardware blocks
involved are essentially the same.
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
[nm@ti.com: bugfixes and generic improvements, documentation]
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

While OMAP4 and OMAP5 had 3 separate clock domains, DRA7 has only 2
and the first one then is internally divided into 2 sub clock domains.

To better represent this in the driver, we use the concept of submodule.

The address defintions in the devicetree is as per the high level
clock domain(module) base, the sub clockdomain/subdomain which shares
the same register space of a clockdomain is marked in the SoC data as
L3_BASE_IS_SUBMODULE.

L3_BASE_IS_SUBMODULE is used as an indication that it's base address is
the same as the parent module and offsets are considered from the same
base address as they are usually intermingled.

Other than the base address, the submodule is same as a module as it is
functionally so.
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

L3 error may be triggered using Debug interface (example JTAG) or
due to other errors, for example an opcode fetch (due to function
pointer or stack corruption) or a data access (due to some other
failure). NOC registers contain additional information to help aid
debug information.

With this, we can enhance the error information to more detailed form:
"
L3 Custom Error: MASTER MPU TARGET L4PER2 (Read): Data Access in User mode
during Functional access
"
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

Today we get error such as
L3 Custom Error: MASTER MPU TARGET L4PER2

But since the actual instruction triggerring the error Vs the point
at which we report error may not be aligned, it makes sense to try
and provide additional information - example the type of operation
that was attempted to being performed can help narrow the debug down
further.

This helps provide log such as:
L3 Custom Error: MASTER MPU TARGET L4PER2 (Read)
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

Errors that cannot be cleared (determined by reading REGERR register)
are currently handled by masking it. Documentation states that REGERR
"Checks which application/debug error sources are active" - it does not
indicate that this is "interrupt status" - masked out status represented
eventually in the irq line to MPU.
For example:

Lets say module 0 bit 8(0x100) was unclearable, we do the mask it from
generating further errors. However in the following cases:
a) bit 9 of Module 0
OR
b) any bit of Module 1+
occur, the interrupt handler wrongly assumes that the raw interrupt
status of module 0 bit 8 is the root cause of the interrupt, and
returns. This causes unhandled interrupt and resultant infinite
interrupts.

Fix this scenario by storing the events we masked out and masking raw
status with masked ones before identifying and handling the error.
Reported-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Tested-by: NVaibhav Hiremath <hvaibhav@gmail.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

Current interrupt handler does the first level parse to identify the
slave and then handles the slave even identification, reporting and
clearing of event as well. It is hence logical to split the handler
into two where the primary handler just parses the flagmux till it
identifies a slave and the slave handling, reporting and clearing is
done in a helper function.

While at it update the documentation in kerneldoc style.
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

The logic between handling CUSTOM_ERROR and STANDARD_ERROR is just the
reporting style.

So make it generic, simplify and standardize the reporting with both
master and target information printed to log.

Handle the register address difference for master code for standard
error and custom error as well.

While at it, fix a minor indentation error.
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

As per Documentation (OMAP4+), then masterid is infact encoded as
follows:
"L3_TARG_STDERRLOG_MSTADDR[7:0] STDERRLOG_MSTADDR stores the NTTP
master address. The master address is the concatenation of Prefix &
Initiator ConnID. It is defined on 8 bits. The 6 MSBs are used to
distinguish the different initiators."

So, when we matchup currently with the master ID list, we never get a
proper match other than when MPU is the master (thanks to 0).

Now, on other platforms such as AM437x, this tends to be bits[5:0].

Fix this by using the relevant 6MSBits to identify the master ID for
standard and custom errors.
Reported-by: NDarren Etheridge <detheridge@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

This allows us to encompass target information and flag mux offset that
points to the target information into a singular structure. This saves
us the need to look up two different arrays indexed by module ID for
information.

This allows us to reduce the static target information allocation to
just the ones that are documented.
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

DRA7xx SoC has the same l3-noc interconnect ip (as OMAP4 and OMAP5), but
AM437x SoC has just 2 modules instead of 3 which other SoCs have.

So, stop using direct access of array indices and use of->match data and
simplify implementation to benefit future usage.

While at it, rename a few very generic variables to make them omap
specific. This helps us differentiate from DRA7 and AM43xx data in the
future.

NOTE: None of the platforms that use omap_l3_noc are non-device tree
anymore. So, it is safe to assume OF match here.
Signed-off-by: NSricharan R <r.sricharan@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
[nm@ti.com: split, refactor and optimize logic]
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

On DRA7, unlike on OMAP4 and OMAP5, the flag mux input numbers used
to indicate the source of errors are not continous. Have a way in the
driver to catch these and WARN the user of the flag mux input thats
either undocumented or wrong.

In the similar vein, Timeout errors in AM43x can't be cleared per h/w
team, neither does it have a STDERRLOG_MAIN to clear the error.

Further, the mux bit offset might not even be indexed into our array
of known mux input description, in which case we'd have a abort.

So, define a static range check for bit description and any definition
which has target_name set to NULL (the ones that are not populated or
ones that are specifically marked in the case of discontinous input
numbers), can handle the same gracefully. Upon occurance of error from
such sources, mask it. Otherwise, we'd have an infinite interrupt
source without any means to clear it.

NOTE: follow on patch ensures that these masked bits are ignored.

[nm@ti.com: rebase, squash and improve]
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

Currently the target instance information is organized indexed by bit
field offset into multiple arrays.

1. We currently have offsets specific to each target associated with each
clock domains are in seperate arrays:

l3_targ_inst_clk1
l3_targ_inst_clk2
l3_targ_inst_clk3

2. Then they are organized per master index in l3_targ.

3. We have names in l3_targ_inst_name as an array to array of strings
corresponding to the above with offsets.

Simplify the same by defining a structure for information containing
both target offset and name. this is then stored in arrays per domain
and organized into an array indexed off domain.

The array is still indexed based on bit field offset.
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

Move the L3 master structure out of the static definition to enable
reuse for other SoCs.
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

just simplify derefencing that is equivalent.
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

Currently we use __raw_readl and writel in this driver. Considering
there is no specific need for a memory barrier, replacing writel
with endian-neutral writel_relaxed and replacing __raw_readls with
the corresponding endian-neutral readl_relaxed allows us to have a
standard set of register operations for the driver.

While at it, simplify address computation using variables for
register.
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

l3->dev is not populated, so populate it and use it to print information
relevant to the device instead of using a generic pr_*.
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

we do not use iclk directly anymore. And, even if we had to, we
should be using pm_runtime APIs to do the same to be completely SoC
independent.
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

Since omap_l3_noc driver is now being used for OMAP5 and reusable with
DRA7 and AM437x, using omap4 specific naming is misleading.
Signed-off-by: NSricharan R <r.sricharan@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

This is an embarrassing patch :(.

Texas Corporation does not make OMAP. Texas Instruments Inc does.

For that matter I dont seem to be able to find a Texas Corporation on
the internet either.

While at it, update coverage to the current year and update the template
to remove redundant information and use the standard boiler plate
licensing.
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

Use dev_err() which will going to print the driver's name as well and the
KERN_ERR level is sufficient in this case (we also print via dev_err when
there is an error with the mem resources)
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

It is NOP after the devm_* conversion.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

With this we can remove the free_irq() calls from probe and remove.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>

We can then remove the iounmap() calls from probe and remove.
Since the driver requests the resources via index we can do the mem resource
request within a for loop.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>