arm: configs: d3_tda2x: Create defconfig

Squashed commit consisting of the following commits:
    - arm: configs: d3_tda2x: Create defconfig
        Based on omap2plus_defconfig with defconfig patches from PSDK and forced USB
        host mode.
    - arm: configs: D3 TDA2x: Add Amtel I2C TPM support
    - arm: configs: D3 TDA2x: Add at24 eeprom support
    - arm: dts: D3 TDA2x: fpd8ch: Add support for RDACM24-01-A1 OV490 based cameras
    - arm: configs: D3 TDA2x: Update defconfig based on TI DRA7 defaults
        This will contain unrequired drivers and such, but they shouldn't be a problem
        unless the produced image needs to be shrunken down.
    - arm: configs: D3 TDA2x: Update defconfig with patches normally applied at build
    - arm: configs: D3 TDA2X: Added support for QSPI Flash
    - arm: configs: TDA2x_RVP: Updated defconfig to enable USB
    - arm: configs: d3_tda2x: Remake config as a defconfig

arm: dts: Added support for D3 TDA2x 8 Channel Baseboard

Squash commit of the following commits:
    - ARM: DTS: D3 FPD8CH: Added basic device-tree for D3 8-channel baseboard.
        Initial support for the D3 FPDLink3 8-channel baseboard. Ethernet,
        HDMI, and the four GPIO expanders are defined.

        MMC1 & USB1 are inherited from the SOM configuration.
    - ARM: DTS: D3 FPD8CH: Use I2C2 as DDC, instead of dedicated DDC block.
        The HDMI DDC SDA/SCL lines are reversed between HDMI connector and
        processor pins on the 8-channel baseboard.  This enables a fix to
        workaround the issue in software.
    - ARM: DTS: D3 FPD8CH: whitespace cleanup
    - ARM: DTS: D3 FPD8CH: Add lanes property to reverse HDMI lane polarity
        On the 8-channel baseboard, the HDMI controller would not generate output
        in HDMI mode and would output inverted colors in DVI mode.

        Switching lane polarity fixes both issues.
    - ARM: DTS: D3 FPD8CH: Fix comments for I2C5 pinmux
        Minor documentation fix to reflect the actual pad names used for I2C5.
    - ARM: DTS: D3 FPD8CH: Comment out interrupts for all GPIO expanders
        The interrupt functionality is currently unused, and the ignored
        interrupts generate extra I2C bus traffic that interfere with other
        devices on the bus.
    - ARM: DTS: D3 FPD8CH: Add pinmux and configuration for video inputs, SERDES, and cameras
        Add the configuration necessary for the 8-channels of parallel video input
        using the OV10635 as the default imager.
    - ARM: DTS: D3 FPD8CH: Fixed memory mapping issues
        * Fixed incorrect memory binding
        * Added missing CMA pools
        * Added missing memreserve commands
        * Removed unnecessary cmem sections
    - ARM: DTS: D3 FPD8CH: Fixed VIP initialization
        * Left VIP devices "disabled"
        * Moved pinctrl to pinhog
        * Exported camera dev nodes
    - FPD8CH: DTS: Added support for CAN buses.
    - TDA2: 8CH: Correct I2C addresses for rework and pclk polarity
    - FPD8CH: DTS: Added pin muxing for DCAN sleep mode
    - FPD8CH: DTS: Added pin muxing for isolated IO
    - FPD8CH: DTS: Added support for 925 serializer and 926/928 deserializer
        Enables I2C3
        Added alias to the 925 serializer
    - FPD8CH: DTS: Added dummy FPD Output
        Will have to be modified when we get hardware to test on.
    - D3: TDA2: FPD8CH: DTS: Fix reserved memory regions
    - ARM: DTS: TDA2x8CH: Changed I2C bus to run at 100Khz, seems to be more stable
    - arm: dts: D3 TDA2x: fpd8ch: Correct I2C address of BB expander for Rev2
    - arm: dts: D3 TDA2x: fpd8ch: Add support for leds on rev2 baseboard
    - arm: dts: D3 TDA2x: Remove I2C2 in favor of HDMI DDC bus
        The pins were flipped on Rev 1 baseboards, but have been corrected on Rev 2.
    - arm: dts: D3 TDA2x: fpd8ch: Remove ethernet speed limit
        Evidently this was ignored before by the driver.
    - arm: dts: d3 tda2x: fpd8ch: Changes made to allow booting with Linux 4.4.5
    - TDA2x RVP Device Tree: Fixed CMA Allocation regions
    - arm: dts: TDA2X_RVP: Added support for the Ultrasonic board
    - arm: dts: D3 TDA2x: Changes made to support VSDK 3.01
        All peripherals used by the IPU are either disabled or their power down
        functionality is disabled.

arm: dts: TDA2x SOM support

Squash commit of the following patches with changes only for TDA2x SOM
    - TDA2ECO SOM support
    - TDA2ECO: Support TDA2X-ABC variant
    - TDA2ECO: Replace PIN_OFF_NONE with 0
    - TDA2ECO: SOM: GPIO interrupts are part of crossbar_mpu now
    - TDA2ECO: Update mem addresses for cells=2
    - TDA2ECO: Move reserved-memory and cmem to SOM
    - TDA2ECO: Fix cmem block address
    - ARM: DTS: D3 934DES: Removed RTC IRQ causing BUGID 1860
    - ARM: DTS: D3 934DES: Added Onboard RTC
    - ARM: DTS: D3 TDA2ECO SOMs: Moved DCAN nodes to baseboard-specific files.
        The DCAN nodes were specified assuming a particular pinmux in each
        tda2eco-som.

        The pinmux for DCAN changed for the new fpd8ch baseboard, making this
        a baseboard specific configuration.
    - ARM: DTS: D3 TDA2ECO SOMs: Moved Ethernet pinmux to baseboard-specific files.
        The use of RGMII0 and a particular MDIO ioset were assumed in the
        Ethernet pinmux for each TDA2Eco SOM.

        The new FPD8CH baseboard uses RGMII1 instead of RGMII0 and a
        different MDIO ioset making this baseboard-specific configuration.
    - arm: dts: d3 tda2eco som: Fix reserved-memory ranges_format warnings
    - ARM: DTS: D3 TDA2ECO SOM: fix incorrect interrupt refrence
        Also corrects surrounding whitespace
    - ARM: DTS: D3 FPD8CH: Fixed memory mapping issues
        * Fixed incorrect memory binding
        * Added missing CMA pools
        * Added missing memreserve commands
        * Removed unnecessary cmem sections
    - D3: TDA2: FPD8CH: DTS: Fix reserved memory regions
    - TDA2x: SOM: Add debug led to device tree
    - TDA2: Set correct QSPI flash implementation
    - arm: dts: D3 TDA2x: Add TPM entry
    - arm: dts: D3 TDA2x: Remove I2C2 in favor of HDMI DDC bus
        The pins were flipped on Rev 1 baseboards, but have been corrected on Rev 2.
    - arm: dts: d3 tda2x: Changes made to allow booting with Linux 4.4.5
    - TDA2x RVP Device Tree: Fixed CMA Allocation regions
    - TDA2x RVP dtb: removed ipurss cores
    - arm: dts: Added support for QSPI Flash

vdrm: added DT node for visionSDK example usecase

Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>

dra7xx: disable LPAE

Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>

vdrm: remove condition check in v_gem_dmabuf_mmap

This condition is not needed in vdrm. vdrm gem
objects do not have backing shmem files

Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>

vdrm: added get_paddr ioctl for v_gem

Signed-off-by: Kip Broadhurst <kbroadhurst@ti.com>
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>

vdrm : driver implemented

Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>

arm: dts: Update timer entries for remote-cores

VSDK firmwares use the following timers:
IPU-1 -- timer9, timer11
IPU-2 -- timer9, timer11
DSP-1 -- timer5, timer6
DSP-2 -- timer5, timer6

By default on Processor-SDK Linux Automotive IPU-2 binaries use timer3.
Since ipu1 is disabled for all infoadas builds an explicit entry for both
timer9 and timer11 must be specified.
In DRA75x and DRA76x since both DSPs are used no additional changes are needed,
however for DRA72x and DRA71x where only 1 DSP is available, timer5, timer6
entries are specified.

Signed-off-by: Shravan Karthik <shravan.karthik@ti.com>

arm: dts: Board Mux Changes for Enabling VIN2A and VIN3A in TDA2px

Changes to support VIP capture based use-cases for VSDK-Linux / Infoadas

Signed-off-by: Jithin K S <x0272999@bangvideoapps02>

arm: dts: Increase SR memory of dra76x to 330MB

For the 2MP 3D-SRV use-case, current SR-1 size of 250MB doesn't suffice.
Increase the SR-1 region size to 330MB to accomodate buffer requirements for the
use-case.

Signed-off-by: Shravan Karthik <shravan.karthik@ti.com>

arm: dra7: hwmod: Enable SW supervised idle for I2C instances owned by M4

I2C responsible for sensor init (I2C2 on J6, I2C5 on J6+, J6Eco) are
disabled from Linux. Enable software supervised idle state, which ensures hwmod
is responsible for bringing an I2C instance in or out of idle, rather than
depending on the smart-idle module

arm: dra7: powerdomain: Disable power state change for remote-cores

Remote-cores are responsible for changing their power state and needn't
be controlled from Linux. Set the power state to ON for all remote-cores.
This prevents the kernel from changing the state of the core if the core is
in an idle state

arm: dra7: hwmod: remove opt clks enable flag from hwmod

Certain clocks are configured from the remote-core firmware, remove this flag
which enables kernel from disabling all the optional clocks after reset

DSS: Do not disable PLL since DSS is initialized

When DSS is already initialized, disabling the PLL causes a glitch
on the screen. Skip disabling the PLL in this case.

arm: dts: Remove touchscreen from infoadas LCD DTB

Enabling touchscreen causes issues in the kernel boot, and Vision SDK doesn't
need any display related functionality except backlight. Disable touchscreen
from device tree.

Signed-off-by: Shravan Karthik <shravan.karthik@ti.com>

arm: dts: dra72: infoadas: Remove LCD from base infoadas device tree

Remove LCD from the base infoadas DTB
Also fix whitespaces in dra7*-evm-infoadas-lcd-lg.dts
Remove the dra71-evm-vision.dtb from Makefile

Fixes: 0ada510e "arm: dts: HDMI display on dra7-evm-infoadas"
Fixes: 2f225826 "arm: dts: dra7xx: infoadas devicetree based on vision board"
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>

arm: dts: LCD-support for VSDK-linux on J6, J6-Eco

arm: dts: HDMI display on dra7-evm-infoadas

By default VSDK-Linux has display on HDMI, thus remove LCD entries from the dts
file. dra7-evm-infoadas-lcd-lg can be used for LCD display

arm: dts: dra76-evm: Disable HDMI

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>

arm: dts: dra7.dtsi: Add debug subsystem DT nodes

Signed-off-by: Surya <x0246581@ti.com>

gpu: omapdrm: Add support for Display-on-M4

stub out omap_connect_dssdevs if the display is NOT
controlled from A15 (Linux)

This allows to continue Linux without DSS support but still
able to register DRM devices.

Change-Id: Ife396afdc890eecc5b0c000995130a52c9769c54

arm: dts: dra7xx: infoadas devicetree based on vision board

This device tree is needed for informational ADAS use cases.
In that, all instances of VIP, VPE, CAL are managed by remote core.
So linux cannot use them.

Also add the CMA regions for the IPU and DSPs used by Vision SDK.
These values are derived from "mem_segment_definition_1024mb_linux.xs"

Also, I2C camera instance is controlled by M4, remove from Linux DTS

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>

arm: dts: dra7: Re-route PCF interrupts

For DRA72x EVM, the PCF irq gets fired as soon as the driver requests for irq handler.
This causes a NULL pointer crash and backtrace in printed.

Curerntly the IRQ is not used for anything.
Avoid this by removing the inteerupt related properties from PCF node.

Use a dummy-gpio line for tpd12s015 which provide hotplug support instead of
pcf_hdmi as the latter is disabled from linux.
Currently supplying pcf_lcd as the dummy-gpio line for tpd12s015.

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>

arm: dts: dra72: Enable ethernet without board muxes

Select the board mux to enable vin1b instance instead of ethernet
This allows to use one instance of ethernet and camera simultaneously.

Remove board mux dependencies on i2c5 PCF expanders.
This will be setup by u-boot

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>

arm: dts: dra7xx: Remove JAMR3 board.

JAMR3 board cannot be used along side the Vision daughter board.
Removing the JAMR3 dts fragment from the device tree reduces kernel
initialization time by avoiding probing for absent peripherals.

Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>

dma-buf: vmemexp: Exporter driver for virtual memory

Add new virtual memory exporter driver
* Add required Documentation, Makefile and Kconfig options
* Register a simple character driver
* Implement ioctls to export a virtual memory segment
* Implement basic dma_buf operations
* Add multi context support
TODO: Export ioctl header file for publishing to uapi

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>

media: i2c: ov490: Force sensor phy reset by toggling MIPI-TX

commit bdc3389bf8fe ("media: i2c: ov490: Force sensor phy reset by toggling MIPI-TX") branch ti-linux-4.9.y

When shutting down a capture stream (stream_off) make sure the
MIPI TX is put in reset. Similarly when the stream is
started make sure the MIPI TX is taken out of reset.

This make the sensor handshake with the DPHY behave in
a predictable/expected manner.

Change-Id: Ic3ca986acd53045b1670603b425f390a28b22758
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Acked-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

arm: dtsi: dra72x: Update cal nodes to use syscon

commit 9749d346111c ("arm: dtsi: dra72x: Update cal nodes to use syscon") branch ti-linux-4.9.y

Instead of directly mapping the CTRL_CORE_CAMERRX_CONTROL register
we will now use the syscon facility instead.
Updated as per documented bindings.

Change-Id: I82ebfb87ea9841f186b5579c152f2172be65e7de
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

arm: dtsi: dra76x: Update CAL node

commit 5ce75566a586 ("arm: dtsi: dra76x: Update CAL node") branch ti-linux-4.9.y

Add the proper syscon entry as well as correct compatible.

Change-Id: If9db6aa2bdcde46d940147e68f4a199ebbaad3c6
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

media: ti-vpe: cal: Add support DRA76x

commit 4b0c3e4a6b7f ("media: ti-vpe: cal: Add support DRA76x") branch ti-linux-4.9.y

Add the needed control module register bit layout to support
the DRA76x family of devices.

Change-Id: I79552ce90610512a196e50cf4788c1156c026bdc
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

media: ti-vpe: cal: Add per platform data support

commit a16e5cffeb5c ("media: ti-vpe: cal: Add per platform data support") branch ti-linux-4.9.y

First this patch adds a method to access the
CTRL_CORE_CAMERRX_CONTROL register to use the syscon
mechanism. For backward compatibility we also handle
using the existing camerrx_control "reg" entry if a syscon
node is not found.

In addition the register bit layout for the CTRL_CORE_CAMERRX_CONTROL
changes depending on the device. In order to support this we need
to use a register access scheme based on data configuration instead
of using static macro.

In this case we make use of the regmap facility and create
data set based on the various device and phy available.

Finally we update the devicetree binding.

Change-Id: I925386d1ff1417a006c94bc687c36031acf7630d
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

arm: dts: dra76-evm: Add JAMR support

Enable i2c4 and vin1a required for TVP5158 capture

Add device tree nodes which expose the base board devices
through the expansion board for JAMR board.
This includes video port, i2c bus and voltage regulators.

Change-Id: I6e286b3875eb0539cfa5db44d5d6772ddbcab518
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>

arm: dts: dra7: add late attach dts covering all cores of a SOC

This commit adds late attach device tree files for all DRA7x device
variants. For each variant, all the cores in the SOC have the late
attach attribute set.

This is required for automated testing of early boot late attach
feature.

Change-Id: Ib5ce420f9748abc7e8a8a463df76c75d6405404e
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>

arm: dts: dra7: restructure late attach dts

- Extract the common portions of late attach device tree attributes
into dra7x-late.dtsi.

- Enable late attach for a remotecore by defining a corresponding
  macro.

- Use a macro for setting the 3 late attach attributes on each node
  that needs to be modified.

Change-Id: I0a77742a4b7220d1d9542c6af80569e537802ddb
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>

mmc: omap_hsmmc: Workaround errata regarding SDR104/HS200 tuning failures (i929)

commit 8fde69daa390 ("mmc: omap_hsmmc: Workaround errata regarding SDR104/HS200 tuning failures (i929)") branch ti-linux-4.9.y

There is a silicon errata in DRA75x, DRA72x and OMAP5 platforms which
may result in unexpected tuning pattern errors. A small failure band
may be present in the tuning range which may be missed by the curent
algorithm. Furthermore, the failure bands vary with temperature leading
to different optimum tuning values for different temperatures.

As suggested in the silicon errata, tuning should be done in two stages.
In stage 1, assign the optimum tuning ratio in the maximum pass window
for the current temperature. In stage 2, if the chosen value is close
to the small failure band, move away from it in the appropriate direction.

Therefore, modify SDR104/HS200 DLL tuning algorithm as a workaround.

Change-Id: I95769d74cdf1355f3605f31a376ac2b580c81224
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>

remoteproc/omap: consolidate instance-specific pre_shutdown ops

The .pre_shutdown() ops is defined to handle certain pre-shutdown
acvities. This is used by the DSP remoteproc devices on DRA7 SoCs
to recover properly during error recovery when an active EDMA
transaction was happening. These ops are currently defined to be
instance specific, consolidate them into a single instance and
derive the instance-id based on the device string names. This
reduces the duplicity in pdata definitions and handling the
same in remoteproc code.

Change-Id: I648cb13596290dfeed7d79a3d4126a7af493d95a
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Sheng Zhao <shengzhao@ti.com>

remoteproc/omap: Fix DSP recovery issues with EDMA

Resetting the DSP subsystem while there are pending DSP EDMA transfers
or while the DSP EDMA is receiving DMA events from various peripherals
(e.g. McASP) can cause various issues in the recovery process:

- L3 errors which create a complete system lockup
- DSPSS does not reset properly and put TPTCs into an unusable state

Prior to shutdown of a DSP core, two cleanup/checks are required in
order to mitigate these issues:

1. Clear DSP EDMA crossbar routings

  Upon remoteproc reset of the DSP, DMA events may continue to
  arrive to the DSPs EDMA instance after the reset sequence has
  completed.
  Clearing the crossbar ensures that no unexpected events arrive to
  the
  DSP's EDMA after reset

2. Wait for DSP EDMA traffic completion

  After clearing DSP EDMA crossbar routings, we disable all future
  events and poll the various active bits of the TPCC and both
  TPTCs of the DSP's EDMA and wait for any pending transfers to
  complete prior to issuing the reset.

Change-Id: If34e4f361cbccd6eb86476812be0d3b0362a0190
Signed-off-by: Stephen Molfetta <sjmolfetta@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
[s-anna@ti.com: rebase from 3.14 to 4.4]
Signed-off-by: Suman Anna <s-anna@ti.com>
[shengzhao@ti.com: test and port from 3.14 to 4.4]
Signed-off-by: Sheng Zhao <shengzhao@ti.com>

net/rpmsg: fix a potential NULL pointer dereference in bind()

The rpmsg proto driver creates a rpmsg channel device per remote
processor through the socket's bind() interface (a Rx socket) for
receiving messages from remote processors. The rpmsg channel device
is created using a rpmsg_create_channel() API, which creates and
registers a rpmsg device. The endpoint associated for this device
is allocated during the rpmsg bus probe. In the rare case, the rpmsg
bus probe can fail either to create an endpoint or return a failure
from the corresponding rpmsg driver probe, and this failure status
is not returned back to the callers of rpmsg_create_channel()
function with no endpoint associated with the created rpmsg device.
This can result in a potential NULL pointer panic in the
rpmsg_sock_bind() function.

Fix this by adding an additional check for a valid endpoint. The
rpmsg_sock_bind() creates a rpmsg device tied to the rpmsg_proto
driver itself, so the endpoint creation sequence is guaranteed to
be executed in the rpmsg bus probe because of a guaranteed driver
match for the device. The rpmsg device is also unregistered upon
an endpoint allocation failure as part of the cleanup.

Reported-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
[s-anna@ti.com: add the rpmsg_destroy_channel() call for cleanup]
Signed-off-by: Suman Anna <s-anna@ti.com>

net/rpmsg: fix possible kernel crash in callback for deleted sockets

The rpmsg proto driver creates a rpmsg channel device per remote
processor for each MessageQ object through the socket's bind()
call (a Rx socket) for receiving messages. During error recovery,
the virtio core removes the devices created by the Rx sockets,
while the open sockets themselves can be freed up anytime either
by the userspace closing them or through an automatic close when
the process is terminated/closed. Commit e5a9a772354e ("net/rpmsg:
set error status on open sockets after recovery") added the support
for error recovery and handles the race conditions between both the
rpmsg_sock_release() and rpmsg_proto_remove() paths.

The rpmsg_sock_release() clears the end-point's private field for Rx
sockets before destroying the endpoint. This presents a small window
(until before the __rpmsg_destroy_ept() is invoked in virtio rpmsg
core) during which a message can come in for a socket that has already
been deleted, and results in a NULL pointer dereference kernel panic
when the invalid (NULL) sk is accessed. This could happen, for example,
when an application has incorrectly terminated while still communicating
with the remote core. The remote core is unaware of the application's
termination and continues to send messages.

Fix this by adding a check in the rpmsg_proto callback for a NULL
(invalid) sk before accessing the socket, and throw a warning if a
message is received for any invalid socket. Note that this will not
notify the remote processor of the error and it may still be unaware
of the removal of the HOST rpmsg-proto socket unless it has some
other mechanism for checking that the socket is still alive. All
such messages are either dropped in the virtio rpmsg core or in the
rpmsg proto driver's callback.

Fixes: e5a9a772354e ("net/rpmsg: set error status on open sockets after recovery")
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
[s-anna@ti.com: add some more details to commit description]
Signed-off-by: Suman Anna <s-anna@ti.com>
Conflicts:
net/rpmsg/rpmsg_proto.c

Change-Id: I76341ec2da8557db208746f2e1d798e241f890d7

net/rpmsg: fix error status marking of new Rx sockets during recovery

The rpmsg proto driver creates a rpmsg channel device per remote
processor for each MessageQ object through the socket's bind()
call (a Rx socket) for receiving messages. These rpmsg channel
devices do not have a designated dst address upon creation, and
a dst address is automatically assigned the first time a message
is received on the respective channel. An error status is set on
all the bound (Rx) sockets during the auto-removal of the rpmsg
devices during a remote processor recovery, but this logic is
skipped for some devices with a dst address of RPMSG_ADDR_ANY.
This causes some Rx sockets to be not marked properly if an error
recovery happens before they receive a message, and this may result
in a kernel panic during the cleanup of the corresponding socket
upon the termination of the application.

Fix this by adjusting the logic in rpmsg_proto_remove() so that
all Rx sockets are marked properly irrespective of whether they
received a message or not. An additional check is also added
in the bind implementation to check for valid range of socket
addresses since the logic in the probe and remove functions
rely on this range to distinguish userspace created rpmsg
channel devices and those published from the remote processor.

Fixes: e5a9a772354e ("net/rpmsg: set error status on open sockets after recovery")
Reported-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>

net/rpmsg: skip announcement of rpmsg devices created in bind()

The rpmsg proto driver creates a rpmsg channel device per remote
processor (a Rx socket) for each MessageQ object through the
socket's bind() call. These rpmsg channel devices are normally
announced to the remote processor core, as these channels are
treated as rpmsg server channels. The behavior of announcing
the bound endpoints to the remote cores isn't necessary since
binding is for local endpoints. Furthermore, the TI MessageQ
stack doesn't require these devices to be announced as the
object will be looked up using a higher-level protocol logic.

Skip the announcing of these devices by overriding the rpmsg
device's announce field in probe, so that the subsequent
announce is skipped in the virtio rpmsg core. This approach
limits the customization to the rpmsg proto driver leaving
the virtio rpmsg core unchanged. It also has the added benefit
of removing the extra delay of sending the notification to
the remote processor.

Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
[s-anna@ti.com: revise commit description]
Signed-off-by: Suman Anna <s-anna@ti.com>
Conflicts:
net/rpmsg/rpmsg_proto.c

Change-Id: I44c6c969622ff7d00ef4f22e2131cdac08183154

rpmsg: rpc: fix suspicious rcu_dereference_check() usage

The rpmsg rpc code uses fcheck() to verify that the passed-in
dma-buf file descriptors during buffer pre-registration or
unregistration are valid. The caller must hold a rcu though
as part of the lock-free semantics of the file descriptor
management. Add the appropriate rcu locking to fix the following
warning thrown when CONFIG_PROVE_RCU is enabled:

 ===============================
 [ INFO: suspicious RCU usage. ]
 4.4.91-02991-gb242ddd5eda5 #275 Not tainted
 -------------------------------
 include/linux/fdtable.h:93 suspicious rcu_dereference_check() usage!

 other info that might help us debug this:

 rcu_scheduler_active = 1, debug_locks = 1
 no locks held by multiqueue0:src/1104.

 stack backtrace:
 CPU: 0 PID: 1104 Comm: multiqueue0:src Not tainted 4.4.91-02991-gb242ddd5eda5 #275
 Hardware name: Generic DRA74X (Flattened Device Tree)
 [<c0019054>] (unwind_backtrace) from [<c00147d4>] (show_stack+0x10/0x14)
 [<c00147d4>] (show_stack) from [<c02fbd48>] (dump_stack+0x98/0xc4)
 [<c02fbd48>] (dump_stack) from [<bf00d0d4>] (rppc_ioctl+0x3f0/0x6fc [rpmsg_rpc])
 [<bf00d0d4>] (rppc_ioctl [rpmsg_rpc]) from [<c015d57c>] (do_vfs_ioctl+0x47c/0x7a8)
 [<c015d57c>] (do_vfs_ioctl) from [<c015d8dc>] (SyS_ioctl+0x34/0x5c)
 [<c015d8dc>] (SyS_ioctl) from [<c0010540>] (ret_fast_syscall+0x0/0x1c)

The fcheck() calls can perhaps be removed completely and relying on
the implicit checking during the dma_buf_get() calls, but is retained
to provide a preliminary check of the file descriptors.

Fixes: 71711c3509d8 ("rpmsg: rpc: introduce a new rpmsg_rpc driver")
Signed-off-by: Suman Anna <s-anna@ti.com>

rpmsg: check for invalid parameters in couple of public API

There is currently no error-checking for input arguments in couple of
channel and endpoint related public creation API - rpmsg_create_ept()
and rpmsg_create_channel(). Add checks to ensure that any incorrect
usage of these API in rpmsg client drivers is errored out gracefully.
The rpmsg_destroy_ept() API is also enhanced to allow a NULL parameter
like the kernel kfree() function.

Signed-off-by: Suman Anna <s-anna@ti.com>

rpmsg: add input argument sanity checks to rpmsg_send functions

There is currently no error-checking for the rpdev input argument in
all the variants of the rpmsg_send() API. Add checks for the same
to ensure that there are no NULL pointer dereferences of the input
rpdev input argument in these exported functions.

Signed-off-by: Suman Anna <s-anna@ti.com>

ARM: dts: dra76: Allow MCAN to be used upto 5 mbps

commit 743b0ccd383d ("ARM: dts: dra76: Allow MCAN to be used upto 5 mbps") branch ti-linux-4.9.y

Previously the MCAN driver didn't support > 2 mbps due to TDC feature
not being enabled. But now since this feature has been added it is
ok to support upto the transceiver's maximum speed of 5 mbps.

Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

HACK: can: m_can: Support higher speed CAN-FD bitrates

commit cf0c0c01ef43 ("HACK: can: m_can: Support higher speed CAN-FD bitrates") branch ti-linux-4.9.y

During test transmitting using CAN-FD at high bitrates (> 2 Mbps)
would fail. Scoping the signals I noticed that only a single bit
was being transmitted and with a bit more investigation realized the actual
MCAN IP would go back to initialization mode automatically.

It appears this issue is due to the MCAN needing to use the Transmitter
Delay Compensation Mode with the correct value for the transmitter delay
compensation offset (tdco). What impacts the tdco value isn't 100% clear
but to calculate it you use an equation defined in the MCAN User's Guide.

The user guide mentions that this register needs to be set based on clock
values, secondary sample point and the data bitrate. One of the key
variables that can't automatically be determined is the secondary
sample point (ssp). This ssp is similar to the sp but is specific to this
transmitter delay compensation mode. The guidelines for configuring
ssp is rather vague but via some CAN test it appears for DRA76x that a
value of 50% works.

The CAN-CIA's "Bit Time Requirements for CAN FD" paper presented at
the International CAN Conference 2013 indicates that this TDC mode is
only needed for data bit rates above 2.5 Mbps. Therefore, only enable
this mode when the data bit rate is above 2.5 Mbps.

TODO:
Find a solution acceptable in upstream that gives the user the option to
change the SSP either in DT or via userspace. This will handle situations
where a hard coded SSP value fails on a particular board or different CAN
bus configuration.

Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

ARM: dts: dra76x: fix MCAN interrupt parent

commit 2ec15130c91e ("ARM: dts: dra76x: fix MCAN interrupt parent") branch ti-linux-4.9.y

MCAN on DRA76 has very specific IRQ requirements. Unlike most peripherals,
MCAN must use specific irqs or crossbars instances to work. Otherwise
the interrupts won't be properly be triggered. To handle this requirement
MCAN will use MPU_IRQ_67 and MPU_IRQ_68 directly from the GIC. However,
the previous patch that added the MCAN node didn't specify the GIC
as the interrupt parent. This ended up with the crossbar being used and
having MCAN mapped to a crossbar that couldn't be used for its interrupts.

This patch corrects this problem by setting MCAN's interrupt parent to
the GIC.

Fixes: 4695a85a08b0 ("ARM: dts: dra76x: Add MCAN node")
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

ARM: dts: dra71-evm: correct evm_sd regulator max voltage

commit 926d271b5f11 ("ARM: dts: dra71-evm: correct evm_sd regulator max voltage") branch ti-linux-4.9.y

Correct vpo_sd_1v8_3v3 regulator max voltage to 3.3V

Fixes: 9868bc585ae2 ("ARM: dts: Add support for dra718-evm")
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

mmc: host: omap_hsmmc: fix typo in print

commit f3a961903aba ("mmc: host: omap_hsmmc: fix typo in print") branch ti-linux-4.9.y

correct the print to use voltage value instead of bit shift.

Fixes: 54d44bde0a6e5 ("mmc: host: omap_hsmmc: Enable io voltage switch to 3.3V")
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

mmc: host: omap_hsmmc: Fix omap_hsmmc_context_restore()

commit 7656243c0d9c ("mmc: host: omap_hsmmc: Fix omap_hsmmc_context_restore()") branch ti-linux-4.9.y

Use omap_hsmmc_set_capabilties() and omap_hsmmc_conf_bus_power()
to restore HCTL and CAPA register.

This also gets rid of the following compilation warning:
warning: 'capa' may be used uninitialized in this function
[-Wmaybe-uninitialized]

Cc: Ravikumar Kattekola <rk@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

ARM: dts: dra7: Increase max-voltage of pbias regulator

commit 58c6c51409f2 ("ARM: dts: dra7: Increase max-voltage of pbias regulator") branch ti-linux-4.9.y

As per recent TRM, PBIAS cell on dra7 devices supports
3.3V and not 3.0V as documented earlier.

Update PBIAS regulator max voltage to match this.

Document reference:
SPRUI30C – DRA75x, DRA74x Technical reference manual- November 2016

Tested on:
DRA75x PG 2.0 REV H EVM

Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

ARM: dts: omap5: Increase max-voltage of pbias regulator

commit 133bfccab1ff ("ARM: dts: omap5: Increase max-voltage of pbias regulator") branch ti-linux-4.9.y

As per recent TRM, PBIAS cell on omap5 devices supports
3.3V and not 3.0V as documented earlier.

Update PBIAS regulator max voltage to match this.

Document reference:
SWPU249AF - OMAP543x Technical reference manual August 2016

Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

mmc: host: omap_hsmmc: Enable io voltage switch to 3.3V

commit 54d44bde0a6e ("mmc: host: omap_hsmmc: Enable io voltage switch to 3.3V") branch ti-linux-4.9.y

The mmc ip on OMAPx/DRA7x platforms supports io operation at 3.3v but
it has been trimmed to 3.0v in order to align with the PBIAS cell
supported voltage, as documented in the reference manuals.

PBIAS cell is an additional hw component on the chip external
to the mmc ip that provides an internal bias voltage reference
needed for reliable operation of the ios - on dual voltage capable
mmc instances.

Reference manuals of OMAP5x and DRA7x have been updated to reflect
the PBIAS regulator max-voltage as 3.3V instead of 3.0V, while OMAP3x
and OMAP4x are still quoting 3.0V. So, as of now, the mmc driver
needs to support both 3.0V and 3.3V IO voltage based on the max-voltage
supported by the PBIAS regulator.

Document reference:
SWPU249AF - OMAP543x Technical reference manual - August 2016
SPRUI30C – DRA75x, DRA74x Technical reference manual November 2016

Tested on:
DRA75x PG 2.0 REV H EVM

Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

regulator: pbias: Select voltage table based on max-voltage

commit 2d1a3449e55a ("regulator: pbias: Select voltage table based on max-voltage") branch ti-linux-4.9.y

Reference manuals of OMAP5x and DRA7x have been updated to reflect
the PBIAS regulator max-voltage as 3.3V instead of 3.0V, while OMAP3x
and OMAP4x are still quoting 3.0V. So, as of now, the pbias driver
needs to support both 3.0V and 3.3V IO voltage based on the max-voltage
supported by the PBIAS regulator.

Document reference:
SWPU249AF - OMAP543x Technical reference manual - August 2016
SPRUI30C – DRA75x, DRA74x Technical reference manual November 2016

Tested on:
DRA75x PG 2.0 REV H EVM

Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

mmc: host: omap_hsmmc: Clear voltage capabilities before writing

commit 4276f25ae826 ("mmc: host: omap_hsmmc: Clear voltage capabilities before writing") branch ti-linux-4.9.y

Bootloader might have set the voltage capabilities to a certain
value. So, clear it before writing to these bits in kernel driver.

Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

dmaengine: edma: Align the memcpy acnt array size with the transfer

commit fb8ccfae9581 ("dmaengine: edma: Align the memcpy acnt array size with the transfer") branch ti-linux-4.9.y

Memory to Memory transfers does not have any special alignment needs
regarding to acnt array size, but if one of the areas are in memory mapped
regions (like PCIe memory), we need to make sure that the acnt array size
is aligned with the mem copy parameters.

Before "dmaengine: edma: Optimize memcpy operation" change the memcpy was set
up in a different way: acnt == number of bytes in a word based on
__ffs((src | dest | len), bcnt and ccnt for looping the necessary number of
words to comlete the trasnfer.

Instead of reverting the commit we can fix it to make sure that the ACNT size
is aligned to the traswnfer.

Fixes: df6694f80365a (dmaengine: edma: Optimize memcpy operation)
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: stable@vger.kernel.org
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

drm/omap: DMM: Add Read/Write barriers in the i878 workaround code

commit 99840bbbb931 ("drm/omap: DMM: Add Read/Write barriers in the i878 workaround code") branch ti-linux-4.9.y

Since the memory location is updated or read by the DMA we need to make
sure that neither the compiler or the CPU is not moving the readl/writel
commands because of optimization.

With the barriers in place we can make sure these commands are not moved.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

drm/omap: DMM: Check for DMM readiness after successful transaction commit

commit 706c82561bfa ("drm/omap: DMM: Check for DMM readiness after successful transaction commit") branch ti-linux-4.9.y

Check the status of the DMM engine after it is reported that the
transaction was completed as in rare cases the engine might not reached a
working state.

The wait_status() will print information in case the DMM is not reached the
expected state and the dmm_txn_commit() will return with an error code to
make sure that we are not continuing with a broken setup.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

drm/omap: DMM: Print information if we received an error interrupt

commit 34e85fce8f9f ("drm/omap: DMM: Print information if we received an error interrupt") branch ti-linux-4.9.y

To help diagnose DMM errors, print out information if any of the error bits
are set in the interrupt status register.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

drm/omap: DMM: In case of error/timeout in wait_status() print the reason

commit d3991b24e42e ("drm/omap: DMM: In case of error/timeout in wait_status() print the reason") branch ti-linux-4.9.y

If the wait_status() fails either because of an error reported in the
STATUS register or because of a timeout waiting for the wait_mask, print
information which might help diagnose the reason.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

drm/omap: DMM: Fix DMM_IRQSTAT_ERR_MASK definition

commit 47b145a98d17 ("drm/omap: DMM: Fix DMM_IRQSTAT_ERR_MASK definition") branch ti-linux-4.9.y

The error bit definitions are typoed in DMM_IRQSTAT_ERR_MASK which went
unnoticed since the DMM_IRQSTAT_ERR_MASK was not used.

Change the bit definitions to the correct ones.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

ARM: dts: dra7: Correct the compatible string for DMM

commit 7fec4a860745 ("ARM: dts: dra7: Correct the compatible string for DMM") branch ti-linux-4.9.y

On dra7 the DMM needs to be handled differently compared to omap5 due to
errata i878.

Add the "ti,dra7-dmm" to the compatible so the driver can enable the needed
workaround for dra7.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

ti_config_fragments/connectivity.cfg: Enable MCAN

commit a716f2c65891 ("ti_config_fragments/connectivity.cfg: Enable MCAN") branch ti-linux-4.9.y

Enable the MCAN driver which is included in DRA76x

Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

ARM: dts: dra76-evm: Add MCAN node

commit 584d126ffc2e ("ARM: dts: dra76-evm: Add MCAN node") branch ti-linux-4.9.y

Add MCAN node to evm and enable it.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

arm: dts: dra76-evm: Add VIP and OV10633 dts nodes

commit fe742dc5a10b ("arm: dts: dra76-evm: Add VIP and OV10633 dts nodes") branch ti-linux-4.9.y

Add the OV10633 camera and clock nodes, also describe the video
interface via endpoint properties.
Specify the board muxes to route the camera signals to video port.
Also enable vin2a port and add one endpoint linking to the camera.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

arm: dts: dra76-evm: Add CAL and OV490 nodes

commit e37b88697481 ("arm: dts: dra76-evm: Add CAL and OV490 nodes") branch ti-linux-4.9.y

Add device nodes for CSI2 camera board OV490 and the GPIO
expander on the adapter board.

Add board mux entries to set the i2c clk, board muxes, etc.
Also add the endpoint nodes describing the CSI2 PHY configuration.

Add CAL port nodes and link endpoint with the ov490 node.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

ARM: dts: dra7-evm-common: only DRA74x EVM has DCAN

commit 9fefc31539fa ("ARM: dts: dra7-evm-common: only DRA74x EVM has DCAN") branch ti-linux-4.9.y

dra7-evm-common.dtsi serves as common file for both
DRA74x and DRA76x EVMs. But DCAN1 is used only on
DRA74x EVM and should not be enabled on DRA76x EVM.

Move dcan1 node to dra7-evm.dts where it actually belongs.

Also remove duplicated dcan1 pins from dra7-evm-common.dtsi

Acked-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

ARM: dts: dra76x: Add MCAN node

commit 4695a85a08b0 ("ARM: dts: dra76x: Add MCAN node") branch ti-linux-4.9.y

Add support for the MCAN peripheral which supports both classic
CAN messages along with the new CAN-FD message.

Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

can: m_can: Add call to of_can_transceiver

commit 004df7f220ed ("can: m_can: Add call to of_can_transceiver") branch ti-linux-4.9.y

Add call to new generic functions that provides support via a binding
to limit the arbitration rate and/or data rate imposed by the physical
transceiver connected to the MCAN peripheral.

Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

dt-bindings: can: m_can: Document new can transceiver binding

commit d9687b8152a5 ("dt-bindings: can: m_can: Document new can transceiver binding") branch ti-linux-4.9.y

Add information regarding can-transceiver binding. This is especially
important for MCAN since the IP allows CAN FD mode to run significantly
faster than what most transceivers are capable of.

Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

dt-bindings: can: can-transceiver: Document new binding

commit 2bcb595bb96c ("dt-bindings: can: can-transceiver: Document new binding") branch ti-linux-4.9.y

Add documentation to describe usage of the new can-transceiver binding.
This new binding is applicable for any CAN device therefore it exists as
its own document.

Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

ARM: dts: dra762: Add MCAN clock support

commit fb00a55891ad ("ARM: dts: dra762: Add MCAN clock support") branch ti-linux-4.9.y

MCAN is clocked by H14 divider of DPLL_GMAC. Unlike other
DPLL dividers this DPLL_GMAC H14 divider is controlled by
control module. Adding support for these clocks.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

ARM: dra762: hwmod: Add MCAN support

commit d28d665d21d6 ("ARM: dra762: hwmod: Add MCAN support") branch ti-linux-4.9.y

Add MCAN hwmod data and register it for dra762 silicons.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Conflicts:
arch/arm/mach-omap2/omap_hwmod_7xx_data.c

Change-Id: I8243fd02df7793a8703dc0860aa3d368cd2d2df2

can: m_can: Add PM Runtime

commit 81713e6be4c4 ("can: m_can: Add PM Runtime") branch ti-linux-4.9.y

Add support for PM Runtime which is the new way to handle managing clocks.
However, to avoid breaking SoCs not using PM_RUNTIME leave the old clk
management approach in place.

PM_RUNTIME is required by OMAP based devices to handle clock management.
Therefore, this allows future Texas Instruments SoCs that have the MCAN IP
to work with this driver.

Reviewed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
[nsekhar@ti.com: handle pm_runtime_get_sync() failure, fix some bugs]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

can: m_can: fix recovery path on clk enable failure

commit 1e42935ebd1a ("can: m_can: fix recovery path on clk enable failure") branch ti-linux-4.9.y

When hclk enable fails, the recovery path should not
try to disable it. Similarly, when cclk enable fails,
dont try to disable it. Only hclk should be disabled.

Reviewed-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

can: m_can: Update documentation to indicate that hclk may be optional

commit 0368f42d6ea3 ("can: m_can: Update documentation to indicate that hclk may be optional") branch ti-linux-4.9.y

Update the documentation to reflect that hclk is now an optional clock.

Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

can: m_can: Make hclk optional

commit 699334201764 ("can: m_can: Make hclk optional") branch ti-linux-4.9.y

Hclk is the MCAN's interface clock. However, for OMAP based devices such as
DRA7 SoC family the interface clock is handled by hwmod. Therefore, this
interface clock is managed by hwmod driver via pm_runtime_get and
pm_runtime_put calls. Therefore, this interface clock isn't defined in DT
and thus the driver shouldn't fail if this clock isn't found.

Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

can: m_can: add deep Suspend/Resume support

commit d14ccea0e71a55ad02bf4e1cb378bbece282d5cf upstream

This adds Power Management deep Suspend/Resume support for Bosch M_CAN
chip.

When entering deep sleep, the clocks are gated, the interrupts are
disabled. When resuming from deep sleep, the chip needs to be
reinitialized, the clocks ungated and the interrupts enabled.

Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

can: m_can: factorize clock gating and ungating

commit ef7b8aa8ca4acdd0541c622230de93bb3389ef41 upstream

This creates a function to ungate M_CAN clocks and another to gate the
same clocks, then swaps all gating/ungating code with their respective
function.

Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

can: m_can: make m_can_start and m_can_stop symmetric

commit 8a3f3f24a829c80d8d451e75e887912c3905dfd0 upstream

This moves clocks gating outside of the m_can_stop function as the
m_can_start function does not (and cannot, at least in current
implementation) ungate clocks. This way, both functions can now be used
symmetrically.

Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

can: m_can: move Message RAM initialization to function

commit 6a792e8158a2597418a0833c7e350328e209f318 upstream

To avoid possible ECC/parity checksum errors when reading an
uninitialized buffer, the entire Message RAM is initialized when probing
the driver. This initialization is done in the same function reading the
Device Tree properties.

This patch moves the RAM initialization to a separate function so it can
be called separately from device initialization from Device Tree.

Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

can: m_can: Enable TX FIFO Handling for M_CAN IP version >= v3.1.x

commit 10c1c3975a6663375b38e67949722ba029201395 upstream

* Added defines for TX Event FIFO Element
* Adapted ndo_start_xmit function.
  For versions >= v3.1.x it uses the TX FIFO to optimize the data
  throughput. It stores the echo skb at the same index as in the
  M_CAN's TX FIFO. The frame's message marker is set to this index.
  This message marker is received in the TX Event FIFO after
  the message was successfully transmitted. It is used to echo the
  correct echo skb back to the network stack.
* Added m_can_echo_tx_event function. It reads all received
  message markers in the TX Event FIFO and loops back the
  corresponding echo skbs.
* ISR checks for new TX Event Entry interrupt for version >= 3.1.x.

Signed-off-by: Mario Huettel <mario.huettel@gmx.net>
Reviewed-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

can: m_can: Configuration for TX and TX event FIFOs

commit 428479e4714ce786629a009c66b4340a3ba651ce upstream

* TX/TX Event FIFO sizes are configured for version >= v3.1.x

Signed-off-by: Mario Huettel <mario.huettel@gmx.net>
Tested-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

can: m_can: Enable M_CAN version dependent initialization

commit b03cfc5bb0e11f88988e5da2805867e468d03ca1 upstream

This patch adapts the initialization of the M_CAN. So it can be used
with all versions >= 3.0.x.

Changes:
* Added version element to m_can_priv structure to hold M_CAN version.
* Renamed bittiming structs for version 3.0.x
* Added new bittiming structs for version >= 3.1.x
* Function alloc_m_can_dev takes 2 new arguments. The TX FIFO size and the
  base address of the module.
* Chip configuration for CAN_CTRLMODE_LOOPBACK is changed: Enabled
  CCCR_MON bit. In combination with TEST_LBCK it activates the internal
  loopback mode. Leaving CCCR_MON '0' results in external loopback mode.
* Clocks are temporarily enabled by platform_propbe function in order to
  allow read access to the Core Release register and the Control Register.
  Registers are used to detect M_CAN version and optional Non-ISO Feature.

Initialization of M_CAN for version >= 3.1.x:
* TX FIFO of M_CAN is used to transmit frames. The driver does not need to
  stop the tx queue after each frame sent.
* Initialization of TX Event FIFO is added.
* NON-ISO is fixed for all M_CAN versions < 3.2.x. Version 3.2.x _can_ have
  the NISO (Non-ISO) bit which can switch the mode of the M_CAN to Non-ISO
  mode. This bit does not have to be writeable. Therefore it is checked.
  If it is writable Non-ISO support is added to the controllers supported
  CAN modes.

New Functions:
* Function to check the Core Release version. The read value determines the
  behaviour of the driver.
* Function to check if the NISO bit for version >= 3.2.x is implemented.

Signed-off-by: Mario Huettel <mario.huettel@gmx.net>
Reviewed-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

can: m_can: Updated register defines to newest version

commit 5e1bd15a3767b2962595698e849ab59936ce6c33 upstream

* Updated register defines to newest M_CAN version (v3.2.1).
* Changed defines in the whole code.

Signed-off-by: Mario Huettel <mario.huettel@gmx.net>
Reviewed-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

can: m_can: Removed virtual address from print

commit ee8c3f6f75671c9172133636aebabf14dbc80066 upstream

The virtual address of the device was printed. I removed it because it
leaks internal information.

Signed-off-by: Mario Huettel <mario.huettel@gmx.net>
Tested-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

can: m_can: Removed initialization of FIFO water marks

commit 8f265895df44148135ee545f406de76d669dbfd9 upstream

FIFO water marks disabled because the driver doesn't handle water mark
events.

Signed-off-by: Mario Huettel <mario.huettel@gmx.net>
Reviewed-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

can: m_can: Disabled Interrupt Line 1

commit 52973810b54bb569fa3baf14d0ff9bfa3e0f68f9 upstream

* Disabled interrupt line 1. The driver didn't use it.

Signed-off-by: Mario Huettel <mario.huettel@gmx.net>
Tested-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

can: dev: Add support for limiting configured bitrate

commit a56dd37c7ee1 ("can: dev: Add support for limiting configured bitrate") branch ti-linux-4.9.y

Various CAN or CAN-FD IP may be able to run at a faster rate than
what the transceiver the CAN node is connected to. This can lead to
unexpected errors. However, CAN transceivers typically have fixed
limitations and provide no means to discover these limitations at
runtime. Therefore, add support for a can-transceiver node that
can be reused by other CAN peripheral drivers to determine for both
CAN and CAN-FD what the max bitrate that can be used. If the user
tries to configure CAN to pass these maximum bitrates it will throw
an error.

Reviewed-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
[nsekhar@ti.com: fix build error with !CONFIG_OF]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

drivers: net: generalize napi_complete_done()

commit 6ad20165d376fa07919a70e4f43dfae564601829 upstream

napi_complete_done() allows to opt-in for gro_flush_timeout,
added back in linux-3.19, commit 3b47d30396ba
("net: gro: add a per device gro flush timer")

This allows for more efficient GRO aggregation without
sacrifying latencies.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

clk: ti: divider: Update context save and restore

commit 215354cddb07 ("clk: ti: divider: Update context save and restore") branch ti-linux-4.9.y

Commit 5c420dac7d46 ("clk: ti: divider: convert TI divider clock to use
its own data representation") changed how divider clocks are represented
in the driver, but because this was an upstream patch it did not update
the context save and restore functions needed for RTC+DDR mode.

This patch converts clk_divider_save_context and
clk_divider_restore_context to use the new struct clk_omap_divider
representation of divider clocks and adds the necessary "context" member
to store the context.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

clk: ti: omap4: cleanup unnecessary clock aliases

commit b6312da57f4dfaff083e31e3aa61faa9e20d9ad5 upstream.

Cleanup any unnecessary DT_CLK() alias entries from the OMAP4 clock file.
Most of these are now handled dynamically by the driver code.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

clk: ti: move omap2_init_clk_clkdm under TI clock driver

commit 2e1a294c0f2273a6d3537c91965ca46a6483bd8c upstream.

This is not needed outside the driver, so move it inside it and remove
the prototype from the public header also.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

clk: ti: add clkdm_lookup to the exported functions

commit b6f27b2db2df395d65b02a758861c7fc54edbec1 upstream.

This will be needed to move some additional clockdomain functionality
under clock driver.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

clk: ti: use automatic clock alias generation framework

commit 1ae79c46cf195ea39407bd5a2b234304d537980f upstream.

Generate clock aliases automatically for all TI clock drivers.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

clk: ti: fix building without legacy omap3

commit fc04f27dfc4280ef35540ab40fa14c24ff8cc799 upstream.

When CONFIG_ATAGS or CONFIG_OMAP3 is disabled, we get a build error:

In file included from include/linux/clk-provider.h:15:0,
                 from drivers/clk/ti/clk.c:19:
drivers/clk/ti/clk.c: In function 'ti_clk_add_aliases':
drivers/clk/ti/clk.c:438:29: error: 'simple_clk_match_table' undeclared (first use in this function); did you mean 'simple_attr_write'?

Moving the match table down fixes it.

Fixes: c17435c56bb1 ("clk: ti: add API for creating aliases automatically for simple clock types")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

clk: ti: fix linker error with !SOC_OMAP4

commit 2158a09395b3751db99663b2efdcce0ae09ca133 upstream.

When none of the OMAP4-generation SoCs are enabled, we run into a link
error for am43xx/am43xx:

drivers/clk/ti/dpll.o: In function `of_ti_am3_dpll_x2_setup':
dpll.c:(.init.text+0xd8): undefined reference to `clkhwops_omap4_dpllmx'

This is easily fixed by adding another #ifdef.

While looking at the code, I also spotted another problem with the
assignment of hw_ops variable that is not used again later. I'm
changing this to setting clk_hw->ops instead, which I guess is what
was intended here.

Fixes: 473adbf4e028 ("clk: ti: dpll44xx: fix clksel register initialization")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tero Kristo <t-kristo@ti.com>
[sboyd@codeaurora.org: Replaced fixes tag with correct one]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

clk: ti: add API for creating aliases automatically for simple clock types

commit c17435c56bb1feb7365ebffcfbe98baae50a0fb4 upstream.

This API generates clock aliases automatically for simple clock types
(fixed-clock, fixed-factor-clock), so that we don't need to add the data
for these statically into tables. Shall be called from the SoC specific
clock init.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

clk: ti: add support for automatic clock alias generation

commit 21f0bf2d3dcc7b18cebe2fa3da700e3263c3a3ce upstream.

Large portions of the OMAP framework still depend on the support of
having clock aliases in place, so add support functions for generating
these automatically.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>