commit d0243693fbf6fbd48b4efb2ba7210765983b03e3 upstream.

Commit 83a86fbb ("irqchip/gic: Loudly complain about the use of
IRQ_TYPE_NONE") started warning about incorrect dts usage for irqs.
ARM GIC only supports active-high interrupts for SPI (Shared Peripheral
Interrupts), and the Palmas PMIC by default is active-low.

Palmas PMIC allows changing the interrupt polarity using register
PALMAS_POLARITY_CTRL_INT_POLARITY, but configuring sys_nirq1 with
a pull-down and setting PALMAS_POLARITY_CTRL_INT_POLARITY made the
Palmas RTC interrupts stop working. This can be easily tested with
kernel tools rtctest.c.

Turns out the SoC inverts the sys_nirq pins for GIC as they do not go
through a peripheral device but go directly to the MPUSS wakeupgen.
I've verified this by muxing the interrupt line temporarily to gpio_wk16
instead of sys_nirq1. with a gpio, the interrupt works fine both
active-low and active-high with the SoC internal pull configured and
palmas polarity configured. But as sys_nirq1, the interrupt only works
when configured ACTIVE_LOW for palmas, and ACTIVE_HIGH for GIC.

Note that there was a similar issue earlier with tegra114 and palmas
interrupt polarity that got fixed by commit df545d1c ("mfd: palmas:
Provide irq flags through DT/platform data"). However, the difference
between omap5 and tegra114 is that tegra inverts the palmas interrupt
twice, once when entering tegra PMC, and again when exiting tegra PMC
to GIC.

Let's fix the issue by adding a custom wakeupgen_irq_set_type() for
wakeupgen and invert any interrupts with wrong polarity. Let's also
warn about any non-sysnirq pins using wrong polarity. Note that we
also need to update the dts for the level as IRQ_TYPE_NONE never
has irq_set_type() called, and let's add some comments and use proper
pin nameing to avoid more confusion later on.

Cc: Belisko Marek <marek.belisko@gmail.com>
Cc: Dmitry Lifshitz <lifshitz@compulab.co.il>
Cc: "Dr. H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Jon Hunter <jonathanh@nvidia.com>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
Cc: Santosh Shilimkar <ssantosh@kernel.org>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Thierry Reding <treding@nvidia.com>
Cc: stable@vger.kernel.org # v4.17+
Reported-by: NBelisko Marek <marek.belisko@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The wl1835mod.pdf data sheet says this pretty clearly for WL_IRQ line:

"WLAN SDIO out-of-band interrupt line. Set to rising edge (active high)
by default."

And it seems this interrupt can be optionally configured to use falling
edge too since commit bd763482 ("wl18xx: wlan_irq: support platform
dependent interrupt types").

On omap4, if the wlcore interrupt is configured as level instead of edge,
L4PER will stop doing hardware based idling after ifconfig wlan0 down is
done and the WL_EN line is pulled down.

The symptoms show up with L4PER status registers no longer showing the
IDLEST bits as 2 but as 0 for all the active GPIO banks and for
L4PER_CLKCTRL. Also the l4per_pwrdm RET count stops increasing in
the /sys/kernel/debug/pm_debug/count.

While there is also probably a GPIO related issue that needs to be
still fixed, this change gets us to the point where we can have L4PER
idling.

I'm guessing wlcore was at some point configured to use level interrupts
because of edge handling issues in gpio-omap. However, with the recent
fixes to gpio-omap the edge interrupts seem to be working just fine.

Let's change it for all omap boards with wlcore interrupt set as level.

Cc: Dave Gerlach <d-gerlach@ti.com>
Cc: Eyal Reizer <eyalr@ti.com>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: Nishanth Menon <nm@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
[tony@atomide.com updated comments a bit for gpio issue]
Signed-off-by: NTony Lindgren <tony@atomide.com>

The xref_xtal clock is used by twl6040 as mclk. It is needed for the HPPLL
internally.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

"usb-nop-xceiv" is using the phy binding, but is missing #phy-cells
property. This is probably because the binding was the precursor to the phy
binding.

Fixes the following warning in OMAP dts files:

Warning (phys_property): Missing property '#phy-cells' in node ...
Signed-off-by: NRob Herring <robh@kernel.org>
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Enric Balletbo i Serra <eballetbo@gmail.com>
Cc: Javier Martinez Canillas <javier@dowhile0.org>
Cc: linux-omap@vger.kernel.org
Signed-off-by: NTony Lindgren <tony@atomide.com>

With commit 8dd6666f ("ARM: OMAP2+: omap_hwmod: Add support for
earlycon") we can now get debug information early if something goes
wrong as long as kernel command line has earlycon in it. Let's enable
it for omap5-common as all these have debug uart at uart3.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Devices using an external encoder, ESD protection and level shifter
such as tpd12s015 or ip4791cz12 have the CEC pull in the encoder
chip. And on var-som-om44, there is external pull up resistor R30.

So the internal CEC pull-up resistor needs to be disabled as otherwise
the external and internal pull are parallel making the pull value
much smaller than intended. This leads into the CEC not working as
reported by Hans Verkuil <hverkuil@xs4all.nl>.
Reported-by: NHans Verkuil <hverkuil@xs4all.nl>
Cc: Dmitry Lifshitz <lifshitz@compulab.co.il>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

DDR3L is usually specified as

	JEDEC standard 1.35V(1.28V~1.45V) & 1.5V(1.425V~1.575V)

Therefore setting smps6 regulator to 1.2V is definitively below
minimum. It appears that real world chips are more forgiving than
data sheets indicate, but let's set the regulator right.

Note: a board that uses other voltages (DDR with 1.5V) can
overwrite by referencing &smps6_reg.
Signed-off-by: NH. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Signed-off-by: NH. Nikolaus Schaller <hns@goldelico.com>
Reviewed-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Will be needed for iio based drivers.
Signed-off-by: NH. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The LEDs on igepv5 are on the GPIO expander unlike on omap5-uevm.

Configuration copied from git.isee.biz git tree except fixed for
red and blue mapping.
Signed-off-by: NTony Lindgren <tony@atomide.com>

The ID pin GPIO comes from the PMIC. Let's configure it as a GPIO
for the driver to use, and also make sure the PMIC GPIO pin muxing
is correct. The PMIC pad1 and 2 values for omap5-uevm and igepv5 are
0x5a and 0x1b, we only need to clear bit 2 in pad1 register to make
the ID pin GPIO work.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Few changes to fix issues I've noticed while debugging omap5-uevm
wl18xx issues:

1. Move wlcore irq pin muxing under wlcore. This irq could be
   different from gpio_wk14 on some board variants

2. Don't configure pull on wlcore irq pin. There is a 10k
   pull up resistor R105 on the device to VDDS_1v8_MAIN

3. The padconf register for wlsdio_data1 is wrong, it's really
   at 0x1a8 + 2 - 0x40 = 0x16a offset, not at 0x168 as that's
   for wlsdio_data0

4. Mark the omap5-uevm wlan as compatible with ti,wl1837 as
   that's what the TDK R078 part seems to be

5. The MMC interrupt for WLAN musb be wakeupgen, not gic

Looks like omap5-uevm WLAN behaves better now, but I still seem
to have issues with some access points.
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 omap5-igep0050.dtb,
omap5-sbc-t54.dtb and omap5-uevm.dtb:

"connector@0 has a unit name, but no reg property"
"endpoint@0 has a unit name, but no reg property"
"encoder@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>

The twl6040 codec is generating the pdmclk, which is used by the McPDM as
functional clock.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The padconf register WAKEUP_EN is now handled in a generic way using
Linux wakeirqs where pinctrl-single toggles the WAKEUP_EN bit when
a wakeirq is enabled or disabled.

At least omap5 gets confused if the WAKEUP_EN bit is set and the pin
is not claimed as a wakeirq. The end result is that wakeirqs don't
work properly as there is nothing handling the wakeirq.

So let's just remove the WAKEUP_EN usage from dts files.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Playing audio works on omap5-uevm, but produces an "Unhandled fault:
imprecise external abort (0x1406) at 0x00000000" error on igepv5.

Looks like the twl6040 audpwron GPIO pin is different for these
boards. Let's fix the issue by configuring the audpwron in the
board specific dts file.

Cc: Agustí Fontquerni <af@iseebcn.com>
Cc: Eduard Gavin <egavin@iseebcn.com>
Cc: Enric Balletbo i Serra <eballetbo@gmail.com>
Acked-by: Peter Ujfalusi <peter.ujflausi@ti com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

OMAP5uEVM based platforms share a similar voltage rail map. This
should be properly described in device tree, without this regulator core
will be unable to determine the source voltage of LDOs such as LDO9 and
SMPS10 which could be configured for bypass depending on the voltage
requested of them. This results in conditions such as:

ldo9: bypassed regulator has no supply!
ldo9: failed to get the current voltage(-517)
palmas-pmic 48070000.i2c:palmas@48:palmas_pmic: failed to register
48070000.i2c:palmas@48:palmas_pmic regulator

Cc: Agustí Fontquerni <af@iseebcn.com>
Cc: Eduard Gavin <egavin@iseebcn.com>
Cc: Enric Balletbo i Serra <eballetbo@iseebcn.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
[tony@atomide.com: fixed to use palmas style in-supply]
Signed-off-by: NTony Lindgren <tony@atomide.com>

tested on OMP5432 EVM
Signed-off-by: NH. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

ldo4_reg is connected to DSS, and should always be 1.8V. However the
The dts defines a range of 1.5V-1.8V, which requires somethings to set
the actual voltage at runtime. Currently we set the voltage in omapdss
driver.

As the voltage must always be 1.8V, let's just define the range to 1.8V
so that the driver doesn't need to deal with the voltage. In fact, the
driver should not touch the voltage, except in the cases where the
voltage needs to be changed at runtime.

I presume the situation is the same for ldo1_reg, used for CSI, although
I think it is not currently used in the mainline.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NTony Lindgren <tony@atomide.com>

tested on OMP5432 EVM

Cc: stable@vger.kernel.org # v4.4
Signed-off-by: NH. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The palmas PMIC has two control lines that need to be muxed properly
for things to work. The sys_nirq pin is used for interrupts, and msecure
pin is used for enabling writes to some PMIC registers.

Without these pins configured properly things can fail in mysterious
ways. For example, we can't update the RTC registers on palmas PMIC
unless the msecure pin is configured. And this is probably the reason
why we had RTC missing from the omap5 dts file.

According to "OMAP5430 ES2.0 Data Manual [Public] VErsion A (Rev. F)"
swps052f.pdf, mux mode 1 is for sys_drm_msecure so in theory there's
should be no need to configure it as a GPIO pin.

However, it seems there are some reliability issues using the msecure
mux mode. And the TI trees configure the msecure pin as GPIO out high
instead.

As the PMIC only cares that the msecure line is high to allow access
to the RTC registers, let's use a GPIO hog as suggested by Nishanth
Menon <nm@ti.com>. Also the use of the internal pull was considered
but supposedly that may not be capable of keeping the line high in
a noisy environment.

If we ever see high security omap5 products in the mainline tree,
those need to skip the msecure pin muxing and ignore setting the GPIO
hog. Chances are the related pin mux registers are locked in that case
and the msecure pin is managed by whatever software may be running in
the ARM TrustZone.

Who knows what the original intention of the msecure pin was. Maybe
it was supposed to prevent the system time to be set back for some
game demo modes to time out? Anyways, it seems that later PMICs like
tps659037 have recycled this pin for "powerhold" and devices like
beagle-x15 do not need changes to the msecure pin configuration.

To avoid further confusion with TWL variant PMICs, beagle-x15 does
not have a back-up battery for RTC palmas. Instead the mcp79410 RTC
is used with rtc-ds1307 driver. There is a "powerhold" jumper j5
holes near the palmas PMIC, and shorting it seems to power up
beagle-x15 automatically. It is unknown if it also has other side
effects to the beagle-x15 power up sequence.

Cc: stable@vger.kernel.org # v4.4
Signed-off-by: NTony Lindgren <tony@atomide.com>

Use the pinmux IOPAD macros to define the register as an offset from
the padconf physical address instead of the offset from padconf base.
This makes the DTS easier to read since matches the addresses listed
in the Technical Reference Manual.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Looks like thevarious omap5-uevm models and igepv5 are very similar. So let's
create omap5-board-common.dtsi to allow fixing up things properly for mainline
kernel to support all these.

Even if we eventually end up having only PMIC + MMC + eMMC + SDIO WLAN + SATA +
USB + HDMI configuration in the omap5-board-common.dtsi, this is the easiest
way to add support for other boards rather than diffing various versions of
out of tree dts files.

My guess is that also omap5-sbc-t54.dts can use this, but I don't have that
board so that will need to be dealt with later on.
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 99f84cae ("ARM: dts: add wl12xx/wl18xx bindings") added
device tree bindings for the TI WLAN SDIO on many omap variants.

I recall wondering how come omap5-uevm did not have the WLAN
added and this issue has been bugging me for a while now, and
I finally tracked it down to a bad pinmux regression, and a missing
deferred probe handling for the 32k clock from palmas that's
requested by twl6040.

Basically 392adaf7 ("ARM: dts: omap5-evm: Add mcspi data")
added pin muxing for mcspi4 that conflicts with the onboard
WLAN. While some omap5-uevm don't have WLAN populated, the
pins are not reused for other devices. And as the SDIO bus
should be probed, let's try to enable WLAN by default.

Let's fix the regression and add the WLAN configuration as
done for the other boards in 99f84cae ("ARM: dts: add
wl12xx/wl18xx bindings"). And let's use the new MMC pwrseq for
the 32k clock as suggested by Javier Martinez Canillas
<javier@dowhile0.org>.

Note that without a related deferred probe fix for twl6040,
the 32k clock is not initialized if palmas-clk is a module
and twl6040 is built-in.

Let's also use the generic "non-removable" instead of the
legacy "ti,non-removable" property while at it.

And finally, note that omap5 seems to require WAKEUP_EN for
the WLAN GPIO interrupt.

Fixes: 392adaf7 ("ARM: dts: omap5-evm: Add mcspi data")
Cc: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Many OMAP2+ DTS are not using the defined constants to express
the GPIO polarity. Replace these so the DTS are easier to read.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The i2c5 pinctrl offsets are wrong. If the bootloader doesn't set the
pins up, communication with tca6424a doesn't work (controller timeouts)
and it is not possible to enable HDMI.

Fixes: 9be495c4 ("ARM: dts: omap5-evm: Add I2c pinctrl data")
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Palmas on OMAP5uevm has support for power button, so enable it.
Signed-off-by: NAparna Balasubramanian <aparnab@ti.com>
Acked-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

UART3 wakeup takes place with iodaisy chain. enable the wakeup pin.
Reported-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
[tony@atomide.com: tabify uart pins properly while at it]
Signed-off-by: NTony Lindgren <tony@atomide.com>

OMAP4/5 has been (ab)using the gic_arch_extn to provide
wakeup from suspend, and it makes a lot of sense to convert
this code to use stacked domains instead.

This patch does just this, updating the DT files to actually
reflect what the HW provides.

BIG FAT WARNING: because the DTs were so far lying by not
exposing the WUGEN HW block, kernels with this patch applied
won't have any suspend-resume facility when booted with old DTs,
and old kernels with updated DTs won't even boot.

On a platform with this patch applied, the system looks like
this:

root@bacon-fat:~# cat /proc/interrupts
            CPU0       CPU1
 16:          0          0     WUGEN  37  gp_timer
 19:     233799     155916       GIC  27  arch_timer
 23:          0          0     WUGEN   9  l3-dbg-irq
 24:          1          0     WUGEN  10  l3-app-irq
 27:        282          0     WUGEN  13  omap-dma-engine
 44:          0          0  4ae10000.gpio  13  DMA
294:          0          0     WUGEN  20  gpmc
297:        506          0     WUGEN  56  48070000.i2c
298:          0          0     WUGEN  57  48072000.i2c
299:          0          0     WUGEN  61  48060000.i2c
300:          0          0     WUGEN  62  4807a000.i2c
301:          8          0     WUGEN  60  4807c000.i2c
308:       2439          0     WUGEN  74  OMAP UART2
312:        362          0     WUGEN  83  mmc2
313:        502          0     WUGEN  86  mmc0
314:         13          0     WUGEN  94  mmc1
350:          0          0      PRCM  pinctrl, pinctrl
406:   35155709          0       GIC 109  ehci_hcd:usb1
407:          0          0     WUGEN   7  palmas
409:          0          0     WUGEN 119  twl6040
410:          0          0   twl6040   5  twl6040_irq_ready
411:          0          0   twl6040   0  twl6040_irq_th
IPI0:          0          1  CPU wakeup interrupts
IPI1:          0          0  Timer broadcast interrupts
IPI2:      95334     902334  Rescheduling interrupts
IPI3:          0          0  Function call interrupts
IPI4:        479        648  Single function call interrupts
IPI5:          0          0  CPU stop interrupts
IPI6:          0          0  IRQ work interrupts
IPI7:          0          0  completion interrupts
Err:          0
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Link: https://lkml.kernel.org/r/1426088629-15377-8-git-send-email-marc.zyngier@arm.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>

The board uses twl6040 codec connected via McPDM link. McBSP1 and McBSP2 can
be used for FM/BT.
At the same time move the pinctrl handling to the correct place - under the
corresponding nodes.
Audio connectors on the board:
Headset in/out
Stereo Line out
Stereo Line in.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The board uses twl6040 as audio codec. Move the corresponding  pinctrl as
well under the node.
twl6040 needs 32k clock from palams.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

clk32kg-audio clock is needed for twl6040 codec.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

omap5-uevm has a single HDMI output. Add the necessary display
information, including pinmuxing.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

omap5-uevm has a tca6424a I/O expander. Add it to the .dts file.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

The necessary clock phandle for the EHCI clock is now provided
via device tree so we no longer need this legacy method.

Update the omap4-panda and omap5-uevm board DTS to provide the
necessary EHCI PHY clock information.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

When the omap5-evm.dts file has been renamed to omap5-uevm.dts and the sEVM
support got deprecated in favor of uEVM (or Panda5) the content was not
validated.
Panda5 does not have support for digital microphones so remove the pinmux
section for it.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

When the omap5-evm.dts file has been renamed to omap5-uevm.dts and the sEVM
support got deprecated in favor of uEVM (or Panda5) the content was not
validated.
On uEVM the twl6040 reset GPIO is from gpio5_141 and not via gpio5_145, which
was the case in sEVM.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>

regulator smps123 supply from Palmas PMIC powers CPU0 on OMAP5uEVM.

Based on a patch by J Keerthy <j-keerthy@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NBenoit Cousson <bcousson@baylibre.com>