The skeleton.dtsi file was removed in ARM64 for different reasons as
explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi").

These also applies to ARM and it will also allow to get rid of the
following DTC warnings in the future:

"Node /memory has a reg or ranges property, but no unit name"

The disassembled DTB are almost the same besides an empty chosen
node being removed and nodes reordered, so it should not have
functional changes.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The skeleton.dtsi file was removed in ARM64 for different reasons as
explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi").

These also applies to ARM and it will also allow to get rid of the
following DTC warnings in the future:

"Node /memory has a reg or ranges property, but no unit name"

The disassembled DTB are almost the same besides an empty chosen
node being removed and nodes reordered, so it should not have
functional changes.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The skeleton.dtsi file was removed in ARM64 for different reasons as
explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi").

These also applies to ARM and it will also allow to get rid of the
following DTC warnings in the future:

"Node /memory has a reg or ranges property, but no unit name"

The disassembled DTB are almost the same besides an empty chosen
node being removed and nodes reordered, so it should not have
functional changes.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The skeleton.dtsi file was removed in ARM64 for different reasons as
explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi").

These also applies to ARM and it will also allow to get rid of the
following DTC warnings in the future:

"Node /memory has a reg or ranges property, but no unit name"

The disassembled DTB are almost the same besides an empty chosen
node being removed and nodes reordered, so it should not have
functional changes.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The skeleton.dtsi file was removed in ARM64 for different reasons as
explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi").

These also applies to ARM and it will also allow to get rid of the
following DTC warnings in the future:

"Node /memory has a reg or ranges property, but no unit name"

The disassembled DTB are almost the same besides an empty chosen
node being removed and nodes reordered, so it should not have
functional changes.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The skeleton.dtsi file was removed in ARM64 for different reasons as
explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi").

These also applies to ARM and it will also allow to get rid of the
following DTC warnings in the future:

"Node /memory has a reg or ranges property, but no unit name"

But these boards don't have a memory node defined, so removing the
skeleton.dtsi inclusion from omap3.dtsi will cause a change in the
compiled DTB. Add a dummy memory node so the compiled DTB doesn't
change if the skeleton.dtsi is removed from omap3.dtsi.

Eventually the correct starting addresses and sizes should be used
but I didn't find that information.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The skeleton.dtsi file was removed in ARM64 for different reasons as
explained in commit ("3ebee5a2 arm64: dts: kill skeleton.dtsi").

These also applies to ARM and it will also allow to get rid of the
following DTC warnings in the future:

"Node /memory has a reg or ranges property, but no unit name"

But the sl50 board doesn't have a, so removing the  skeleton.dtsi
inclusion from am33xx.dtsi will cause a change in the compiled DTB.

The board has 512 MiB of RAM and its starting address is 0x80000000,
so add a proper memory device node in the DTS.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Current clocks tree definition for CPSW/CPTS doesn't
correspond TRM for dra7/am57 SoCs.

CPTS: has to be sourced from gmac_rft_clk_mux clock
CPSW: DPLL_GMAC -> CLKOUT_M2 -> GMAC_250M_CLK -> 1/2 ->
      -> GMAC_MAIN_CLK (125 MHZ)

Hence, correct clock tree for GMAC_MAIN_CLK and use proper
clock for CPTS. This also require updating of CPTS clock
multiplier.
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: NMugunthan V N <mugunthanvnm@ti.com>
Acked-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This commit fixes the clock data inside the DRA7xx clocks device tree
structure for the gmac_gmii_ref_clk_div clock. This clock is actually
the GMAC_MAIN_CLK and has nothing to do with the register at address
0x4a0093d0. If CLKSEL_REF bit 24 inside of CM_GMAC_GMAC_CLKCTRL, is
set to 1 in order to use the GMAC_RMII_CLK instead of the
GMAC_RMII_HS_CLK, the kernel generates a clock divider warning:
    WARNING: CPU: 0 PID: 0 at drivers/clk/clk-divider.c:129 clk_divider_recalc_rate+0xa8/0xe0()
    gmac_gmii_ref_clk_div: Zero divisor and CLK_DIVIDER_ALLOW_ZERO not set

By properly configuring the gmac_gmii_ref_clk_div (GMAC_MAIN_CLK) to
have the parent of dpll_gmac_m2_ck always divided by 2 the warning is
resolved and the clock tree is fixed up.

Additionally, a new clock called rmii_50mhz_clk_mux is defined that
does utilize CM_GMAC_GMAC_CLKCTRL[24] CLKSEL_REF to configure the
source clock for the RMII_50MHZ_CLK.

Cc: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NJ.D. Schroeder <jay.schroeder@garmin.com>
Reviewed-by: NTrenton Andres <trenton.andres@garmin.com>
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Acked-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Since DRA7 has multiple PCIe Rootcomplex, add "linux,pci-domain"
property to assign a PCI domain number to each of the host
bridges.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

AM335x ICE board has a rotary-switch connected to PCA9536 I2C GPIO
expander. The position of the rotary-switch is reflected by status of
GPIO lines. Add gpio-decoder node to read these GPIO line status via
gpio-decoder driver and report it as an input event to the system.
Signed-off-by: NVignesh R <vigneshr@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Support is in the device tree, but they are not mentioned here.
Signed-off-by: NAdam Ford <aford173@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Silicon limitation i845 documents how to cope with false
disconnection condition on USB2 PHY. Reference: AM572x
silicon errata document SPRZ429H, revised January 2016.

Using compatible "ti,dra7x-usb2" enables the recommended
software workaround for this issue. Use it for USB1 PHY.

The workaround is already in place for USB2 PHY.
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The wega board has a TLV320AIC3007 connected via McASP0. In the default
configuration, no external crystal is mounted. We run a system clock of
25 MHz, so we use the audio codec PLL for audio clock generation.
Signed-off-by: NStefan Müller-Klieser <s.mueller-klieser@phytec.de>
Reviewed-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

AM572x IDK has a Spansion s25fl256s1 QSPI flash on the EVM connected to
TI QSPI IP over CS0. Hence, add QSPI and flash slave DT nodes.
Signed-off-by: NVignesh R <vigneshr@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

According to AM572x DM SPRS953A, QSPI maximum bus speed can be 76.8MHz.
Therefore, increase the spi-max-frequency value of QSPI node to 76.8MHz
for DRA74 and DRA72 evm. This improves flash raw read speed by ~2MB/s.
Signed-off-by: NVignesh R <vigneshr@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

With the device tree parsing using the regulator framework
there is a no longer a need for separate compatibles for
individual regulator nodes. Hence removing them all.
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

With the device tree parsing using the regulator framework
there is a no longer a need for separate compatibles for
individual regulator nodes. Hence removing them all.
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

With the device tree parsing using the regulator framework
there is a no longer a need for separate compatibles for
individual regulator nodes. Hence removing them all.
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

With the device tree parsing using the regulator framework
there is a no longer a need for separate compatibles for
individual regulator nodes. Hence removing them all.
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Without this, the memory will remain active during poweroff consuming
extra power. Please note revision 2.1 PMIC seems to fail when DCDC3
disable is attempted, so this is not done on that PMIC revision. The
PMIC revision checks in the regulator patches make sure of this.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Without this, the memory will remain active during poweroff consuming
extra power.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

dcdc3, dcdc5, dcdc6 supply ddr and rtc respectively. These
are required to be on during suspend. Hence set the state accordingly.
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch fixes the following DTC warnings for many boards:

"Node /leds/led@1 has a unit name, but no reg property"
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch fixes the following DTC warnings for many boards:

"Node /leds/led@1 has a unit name, but no reg property"
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch fixes the following DTC warnings for many boards:

"Node /gpio_keys/button0@10 has a unit name, but no reg property"
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch fixes the following DTC warnings for many boards:

"Node /gpio_keys/button0@10 has a unit name, but no reg property"
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch fixes the following DTC warnings for many boards:

"Node /fixedregulator@0 has a unit name, but no reg property"
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch fixes the following DTC warnings for many boards:

"Node /fixedregulator@0 has a unit name, but no reg property"
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch fixes the following DTC warnings for many boards:

"Node /fixedregulator@0 has a unit name, but no reg property"
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch fixes the following DTC warnings for many boards:

"Node /matrix_keypad@0 has a unit name, but no reg property"
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit b8d368ca ("ARM: dts: omap3: overo: remove unneded unit names
in display nodes") removed the unit names for all Overo display nodes
that didn't have a reg property.

But the display in arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi does
have a reg property so the correct fix was to make the unit name match
the value of the reg property, instead of removing it.

This patch fixes the following DTC warning for boards using this dtsi:

"ocp/spi@48098000/display has a reg or ranges property, but no unit name"

Fixes: b8d368ca ("ARM: dts: omap3: overo: remove unneded unit names in display nodes")
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch fixes the following DTC warnings for many boards:

"Node /ocp has a reg or ranges property, but no unit name"
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This fix was applied to a bunch of omap3 devices including LogicPD
Torpedo, but this got missed since it was new around the same times
the patches were applied.  This makes the GPMC parameters match the
Torpedo since they have the same processor PoP memory.
Signed-off-by: NAdam Ford <aford173@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This was applied to a variety of omap3 boards, so it should
probably be applied here.  I did not test NAND performance, but
I tested this with UBI to confirm read/write didn't break.
Signed-off-by: NAdam Ford <aford173@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The gpmc ranges property for NAND at CS0 was being overridden by later
includes that defined gpmc ethernet nodes, effectively breaking NAND on
these systems:

	omap-gpmc 6e000000.gpmc: /ocp/gpmc@6e000000/nand@0,0 has
	malformed 'reg' property

Instead of redefining the NAND range in every such dtsi, define all
currently used ranges in omap3-overo-base.dtsi.

Fixes: 98ce6007 ("ARM: dts: overo: Support PoP NAND")
Cc: stable <stable@vger.kernel.org> # 4.3
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The gpmc ranges property for NAND at CS0 has been broken since it was
first added.

This currently prevents the nand gpmc child node from being probed:

	omap-gpmc 6e000000.gpmc: /ocp/gpmc@6e000000/nand@0,0 has
	malformed 'reg' property

and consequently the NAND device from being registered.

Fixes: 98ce6007 ("ARM: dts: overo: Support PoP NAND")
Cc: stable <stable@vger.kernel.org>	# 4.3
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The check for the "elm_id" binding had been removed.
This causes nand boot to fail on boards still using
the old binding. Update the bindings on those boards.
Signed-off-by: NTeresa Remmet <t.remmet@phytec.de>
Acked-by: NBrian Norris <computersforpeace@gmail.com>
Acked-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Pull more block fixes from Jens Axboe:
 "As mentioned in the pull the other day, a few more fixes for this
  round, all related to the bio op changes in this series.

  Two fixes, and then a cleanup, renaming bio->bi_rw to bio->bi_opf.  I
  wanted to do that change right after or right before -rc1, so that
  risk of conflict was reduced.  I just rebased the series on top of
  current master, and no new ->bi_rw usage has snuck in"

* 'for-linus' of git://git.kernel.dk/linux-block:
  block: rename bio bi_rw to bi_opf
  target: iblock_execute_sync_cache() should use bio_set_op_attrs()
  mm: make __swap_writepage() use bio_set_op_attrs()
  block/mm: make bdev_ops->rw_page() take a bool for read/write