UPSTREAM: stmmac: do not sleep in atomic context for mdio_reset

stmmac_mdio_reset() has been updated to use msleep rather udelay
(as some PHY requires a one second delay there).
It called from stmmac_resume() within the spin_lock_irqsave block
atomic context triggering 'scheduling while atomic'.

The stmmac_priv lock usage is not fully documented, but it seems
to protect the access to the MAC registers / DMA structures rather
than the MDIO bus or the PHY (which have separate locking),
so we can push the spin_lock after the stmmac_mdio_reset call.

Change-Id: I0e8a0f7e798f89678d59eefdfd251f217c00787e
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit f55d84b07c4e7340473a25dc82b462607578402c)

MALI: midgard: rockchip: add .shutdown of GPU platform_driver

Change-Id: I5af2a464db88b08530b063d90b3a7ce61e26f201
Signed-off-by: chenzhen <chenzhen@rock-chips.com>

MALI: midgard: rockchip: not to enable clk_gpu when probing

Otherwise, clk_gpu won't be disabled actually in the runtime.

Change-Id: If1e32061cbffc1564a5cf95fbf01aa91c827550d
Signed-off-by: chenzhen <chenzhen@rock-chips.com>

video: rockchip: vop: 3399: fix layer index for disp info error

Change-Id: I2c45b204d9fafa01b3b05dbb0378bb1b05bd0642
Signed-off-by: Huang Jiachai <hjc@rock-chips.com>

drm/rockchip: vop: correct the source size of uv scale factor setting

When the input color format is YUV, we need to do some external scale
for CBCR. Like,
 * In YUV420 data format:
     cbcr_xscale = dst_w / src_w * 2;
     cbcr_yscale = dst_h / src_h * 2;
 * In YUV422 data format:
     cbcr_xscale = dst_w / src_w * 2;
     cbcr_yscale = dst_h / src_h;
 * In YUV444 data format
     cbcr_xscale = dst_w / src_w;
     cbcr_yscale = dst_h / src_h;

Change-Id: I08678fdcc13a5c4055fcc46f20b378ad7fa16761
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9157353/)

FROMLIST: drm/rockchip: vop: add uv_vir register field for RK3036 VOP

The WIN0 of RK3036 VOP could support YUV data format, but driver
forget to add the uv_vir register field for it.

Change-Id: I1fd6be43308468cf0718b113be74d2170f71eebe
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9157349/)

UPSTREAM: mmc: dw_mmc: use resource_size_t to store physical address

The dw_mmc driver stores the physical address of the MMIO registers
in a pointer, which requires the use of type casts, and is actually
broken if anyone ever has this device on a 32-bit SoC in registers
above 4GB. Gcc warns about this possibility when the driver is built
with ARM LPAE enabled:

mmc/host/dw_mmc.c: In function 'dw_mci_edmac_start_dma':
mmc/host/dw_mmc.c:702:17: warning: cast from pointer to integer of different size
  cfg.dst_addr = (dma_addr_t)(host->phy_regs + fifo_offset);
                 ^
mmc/host/dw_mmc-pltfm.c: In function 'dw_mci_pltfm_register':
mmc/host/dw_mmc-pltfm.c:63:19: warning: cast to pointer from integer of different size
  host->phy_regs = (void *)(regs->start);

This changes the code to use resource_size_t, which gets rid of the
warning, the bug and the useless casts.

Change-Id: I894c49cede8f0626efb80a9a3181a5385bbb2bcd
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 260b31643691e8a58683a4ccc3bdf7abfd86f54a)

UPSTREAM: ARM: dts: rockchip: add support rk3229 evb board

Initial release for rk3229 evb board, and turn the GMAC on.

Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
v4.8-armsoc/dts32 commit 241eff3c198492b2d63e75723b774f2836fee8a3)

Conflicts:

Documentation/devicetree/bindings/arm/rockchip.txt
[zx: RK3399 FPGA conflicts with RK3399 evb board, fix it.]

Change-Id: I95cfe430aa0975a748aa203c1f78ba7fceedf9af
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>

UPSTREAM: PM / Domains: Fix potential deadlock while adding/removing subdomains

We must preserve the same order of how we acquire and release the lock for
genpd, as otherwise we may encounter deadlocks.

The power on phase of a genpd starts by acquiring its lock. Then it walks
the hierarchy of its parent domains to be able to power on these first, as
per design of genpd.

From a locking perspective this means the locks of the parents becomes
acquired after the lock of the subdomain.

Let's fix pm_genpd_add|remove_subdomain() to maintain the same order of
acquiring/releasing the genpd lock as being applied in the power on/off
sequence.

Change-Id: I7f56875b7620eee6247efecd502a3ada4bfa4e24
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from commit cdb300a041f5df1dfbde1367f95109b6449d1371)

UPSTREAM: PM / domains: fix lockdep issue for all subdomains

During genpd_poweron, genpd->lock is acquired recursively for each
parent (master) domain, which are separate objects. This confuses
lockdep, which considers every operation on genpd->lock as being done on
the same lock class. This leads to the following false positive warning:

=============================================
[ INFO: possible recursive locking detected ]
4.4.0-rc4-xu3s #32 Not tainted
---------------------------------------------
swapper/0/1 is trying to acquire lock:
 (&genpd->lock){+.+...}, at: [<c0361550>] __genpd_poweron+0x64/0x108

but task is already holding lock:
 (&genpd->lock){+.+...}, at: [<c0361af8>] genpd_dev_pm_attach+0x168/0x1b8

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&genpd->lock);
  lock(&genpd->lock);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

3 locks held by swapper/0/1:
 #0:  (&dev->mutex){......}, at: [<c0350910>] __driver_attach+0x48/0x98
 #1:  (&dev->mutex){......}, at: [<c0350920>] __driver_attach+0x58/0x98
 #2:  (&genpd->lock){+.+...}, at: [<c0361af8>] genpd_dev_pm_attach+0x168/0x1b8

stack backtrace:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s #32
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[<c0016c98>] (unwind_backtrace) from [<c00139c4>] (show_stack+0x10/0x14)
[<c00139c4>] (show_stack) from [<c0270df0>] (dump_stack+0x84/0xc4)
[<c0270df0>] (dump_stack) from [<c00780b8>] (__lock_acquire+0x1f88/0x215c)
[<c00780b8>] (__lock_acquire) from [<c007886c>] (lock_acquire+0xa4/0xd0)
[<c007886c>] (lock_acquire) from [<c0641f2c>] (mutex_lock_nested+0x70/0x4d4)
[<c0641f2c>] (mutex_lock_nested) from [<c0361550>] (__genpd_poweron+0x64/0x108)
[<c0361550>] (__genpd_poweron) from [<c0361b00>] (genpd_dev_pm_attach+0x170/0x1b8)
[<c0361b00>] (genpd_dev_pm_attach) from [<c03520a8>] (platform_drv_probe+0x2c/0xac)
[<c03520a8>] (platform_drv_probe) from [<c03507d4>] (driver_probe_device+0x208/0x2fc)
[<c03507d4>] (driver_probe_device) from [<c035095c>] (__driver_attach+0x94/0x98)
[<c035095c>] (__driver_attach) from [<c034ec14>] (bus_for_each_dev+0x68/0x9c)
[<c034ec14>] (bus_for_each_dev) from [<c034fec8>] (bus_add_driver+0x1a0/0x218)
[<c034fec8>] (bus_add_driver) from [<c035115c>] (driver_register+0x78/0xf8)
[<c035115c>] (driver_register) from [<c0338488>] (exynos_drm_register_drivers+0x28/0x74)
[<c0338488>] (exynos_drm_register_drivers) from [<c0338594>] (exynos_drm_init+0x6c/0xc4)
[<c0338594>] (exynos_drm_init) from [<c00097f4>] (do_one_initcall+0x90/0x1dc)
[<c00097f4>] (do_one_initcall) from [<c0895e08>] (kernel_init_freeable+0x158/0x1f8)
[<c0895e08>] (kernel_init_freeable) from [<c063ecac>] (kernel_init+0x8/0xe8)
[<c063ecac>] (kernel_init) from [<c000f7d0>] (ret_from_fork+0x14/0x24)

This patch replaces mutex_lock with mutex_lock_nested() and uses
recursion depth to annotate each genpd->lock operation with separate
lockdep subclass.

Change-Id: I9b94b2a571f906ea9e5300abc6f40db343af49e3
Reported-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from commit 0106ef5146f9e89e4dc9354f308ecaddb9617310)

arm64: dts: rockchip: add a power-domain node for mipi dsi on rk3399

Change-Id: I48ef7a7b209b0766a4277c3d9db0d74deee19c50
Signed-off-by: Chris Zhong <zyw@rock-chips.com>

drm/rockchip: mipi: return probe defer if attach panel failed

Return -EINVAL would cause mipi dsi bad behavior, probe defer
to ensure mipi find the correct mode,

Change-Id: I0bb8e97dd6bd19f66052b4e985e95d8d82faf29b
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

drm/rockchip: disabled the plane alpha if it's bottom layer

HardWare limited, the bottom layer not support per-pixel alpha,

Change-Id: I174da1d3d3cfff8d0b6cd6dfab4873438895e56d
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

drm/rockchip: set unused layer with top zpos

Hardware limited, we should keep all unused layer same
with the same zpos, otherwise, would get display abnormal.

Change-Id: I417a6a14731148a89f0372cc028e43a94b56e4d3
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

drm/rockchip: fix vop value mask

Change-Id: Iedfb871f2909a427ca97f3014f4b0e0b565d06f0
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

drm/rockchip: add DRM_RENDER_ALLOW

Change-Id: Ia0159b877f7d8b2bb5cecf3b352b67d9c76c7c97
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

drm/rockchip: vop: use new crtc state on atomic check

That is wrong use old crtc mode on atomic check.

Change-Id: Ie37bd842f8bafca04303d641269a84a6016457f4
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

drm/rockchip: move rockchip drm core compile to the last one

All rockchip drm modules are module_init, so the probe sequence
is judged by compile sequence.

We want the rockchip drm core probe on the last one, so if components
call probe defer on bind, would use rockchip drm core to do probe defer.

Change-Id: Ibda12998545a93327bdf35bc1b8386034189ba6a
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>

ARM64: dts: rk3399-box-808-android: modify pinctrl for spdif

Change-Id: I0e9dd45820900463c7c144b8eff4e89c64618061
Signed-off-by: Zhangbin Tong <zebulun.tong@rock-chips.com>

MALI: rockchip: add utgard(mali400) src dir

Change-Id: I519dfc05fa762e9145404a9f12b4c0092364c4a8
Signed-off-by: chenzhen <chenzhen@rock-chips.com>

MALI: rockchip: upgrade utgard DDK to r6p0-01rel1

Change-Id: I0c88698a29855905da05b45c54f37beddcb6fcd6
Signed-off-by: chenzhen <chenzhen@rock-chips.com>

MALI: utgard: rockchip: tidy the files to track

Change-Id: I8629720bc63eae8b2c309d89d2370623ef614948
Signed-off-by: chenzhen <chenzhen@rock-chips.com>

MALI: rockchip: upgrade utgard DDK to r6p0-01rel0

Conflicts:

drivers/gpu/arm/mali400/mali/common/mali_control_timer.c
drivers/gpu/arm/mali400/mali/include/linux/mali/mali_utgard_uk_types.h
drivers/gpu/arm/mali400/mali/linux/mali_osk_mali.c
drivers/gpu/arm/mali400/mali/linux/mali_ukk_wrappers.h

Change-Id: I13d02e836efcebd0dd2367ce138aac258dacda24
Signed-off-by: chenzhen <chenzhen@rock-chips.com>

UPSTREAM: DT/arm,gic-v3: Documment PPI partition support

Add a decription of the PPI partitioning support.

Change-Id: I11bb88c45556630207fb3ff534fa5645b73cb3f0
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Will Deacon <will.deacon@arm.com>
Link: http://lkml.kernel.org/r/1460365075-7316-6-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from commit 287e9357abcc0ef079bf4e439e098a3bd6246a05)

UPSTREAM: irqchip/gic-v3: Add support for partitioned PPIs

Plug the partitioning layer into the GICv3 PPI code, parsing the
DT and building the partition affinities and providing the generic
code with partition data and callbacks.

Change-Id: I1f9049d48388b899e99bcadd6be729729d0fe6bb
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Rob Herring <robh+dt@kernel.org>
Link: http://lkml.kernel.org/r/1460365075-7316-5-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from commit e3825ba1af3a27d7522c9f5f929f5a13b8b138ae)

UPSTREAM: irqchip: Add per-cpu interrupt partitioning library

We've unfortunately started seeing a situation where percpu interrupts
are partitioned in the system: one arbitrary set of CPUs has an
interrupt connected to a type of device, while another disjoint
set of CPUs has the same interrupt connected to another type of device.

This makes it impossible to have a device driver requesting this interrupt
using the current percpu-interrupt abstraction, as the same interrupt number
is now potentially claimed by at least two drivers, and we forbid interrupt
sharing on per-cpu interrupt.

A solution to this is to turn things upside down. Let's assume that our
system describes all the possible partitions for a given interrupt, and
give each of them a unique identifier. It is then possible to create
a namespace where the affinity identifier itself is a form of interrupt
number. At this point, it becomes easy to implement a set of partitions
as a cascaded irqchip, each affinity identifier being the HW irq.

This allows us to keep a number of nice properties:
- Each partition results in a separate percpu-interrupt (with a restrictied
  affinity), which keeps drivers happy.
- Because the underlying interrupt is still per-cpu, the overhead of
  the indirection can be kept pretty minimal.
- The core code can ignore most of that crap.

For that purpose, we implement a small library that deals with some of
the boilerplate code, relying on platform-specific drivers to provide
a description of the affinity sets and a set of callbacks.

Conflicts:
drivers/irqchip/Kconfig
drivers/irqchip/Makefile

Change-Id: Ie6b2bc8c4c152f0dcd3fbcab8950fae781338322
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Rob Herring <robh+dt@kernel.org>
Link: http://lkml.kernel.org/r/1460365075-7316-4-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from commit 9e2c986cb460bf97154f18e85aa833739a1e8dc7)

UPSTREAM: genirq: Allow the affinity of a percpu interrupt to be set/retrieved

In order to prepare the genirq layer for the concept of partitionned
percpu interrupts, let's allow an affinity to be associated with
such an interrupt. We introduce:

- irq_set_percpu_devid_partition: flag an interrupt as a percpu-devid
  interrupt, and associate it with an affinity
- irq_get_percpu_devid_partition: allow the affinity of that interrupt
  to be retrieved.

This will allow a driver to discover which CPUs the per-cpu interrupt
can actually fire on.

Change-Id: I251774db34d1f0145d6c051265886c22f41d941e
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Rob Herring <robh+dt@kernel.org>
Link: http://lkml.kernel.org/r/1460365075-7316-3-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from commit 222df54fd8b7641dcc81476f157806bb3144ee1d)

UPSTREAM: irqdomain: Allow domain matching on irq_fwspec

When iterating over the irq domain list, we try to match a domain
either by calling a match() function or by comparing a number
of fields passed as parameters.

Both approaches are a bit restrictive:
- match() is DT specific and only takes a device node
- the fallback case only deals with the fwnode_handle

It would be useful if we had a per-domain function that would
actually perform the matching check on the whole of the
irq_fwspec structure. This would allow for a domain to triage
matching attempts that need to extend beyond the fwnode.

Let's introduce irq_find_matching_fwspec(), which takes a full
blown irq_fwspec structure, and call into a select() function
implemented by the irqdomain. irq_find_matching_fwnode() is
made a wrapper around irq_find_matching_fwspec in order to
preserve compatibility.

Change-Id: I07df9af068d114c80cd97b9cb987a70c0e24afda
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Rob Herring <robh+dt@kernel.org>
Link: http://lkml.kernel.org/r/1460365075-7316-2-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from commit 651e8b54abdeeaa36f5f54ffa05c18707a3cc1d0)

UPSTREAM: irqchip/gic-v3: Refactor gic_of_init() for GICv3 driver

Isolate hardware abstraction (FDT) code to gic_of_init().
Rest of the logic goes to gic_init_bases() and expects well
defined data to initialize GIC properly. The same solution
is used for GICv2 driver.

This is needed for ACPI initialization later.

Change-Id: I61fcbd96ecd2dc8130cdd2d6ce79841eb184e87b
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from commit db57d7460ea74de2204ddc303520753f256ea67d)

UPSTREAM: dt-bindings: arm, gic-v3: require that reserved cells are always 0

The arm,gic-v3 binding was written with good intentions and doesn't
enforce interrupt-cells to be 3, therefore making it easy to extend
the irq description in future if necessary:

  > Cells 4 and beyond are reserved for future use.

Unfortunately, this sentence is immediately followed up with:

  > When the 1st cell has a value of 0 or 1, cells 4 and beyond act as
  > padding, and may be ignored. It is recommended that padding cells
  > have a value of 0.

Consequently, any extensions to the PPI or SPI interrupt specifiers must
be able to work with random crap from legacy DTs, effectively
necessitating a new interrupt type in the first cell. Sigh.

This patch fixes the text so that additional, reserved cells are
required to be zero. This looks like a reasonable thing to require and
is already satisifed by the .dts files in-tree.

Change-Id: Ia5b07ab4243c0a4492b7c4516af95b86974c42a0
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from commit 4aff7b854611d91c5fefb1553eb4c328123095ae)

UPSTREAM: irqdomain: Allow domain lookup with DOMAIN_BUS_WIRED token

Let's take the (outlandish) example of an interrupt controller
capable of handling both wired interrupts and PCI MSIs.

With the current code, the PCI MSI domain is going to be tagged
with DOMAIN_BUS_PCI_MSI, and the wired domain with DOMAIN_BUS_ANY.

Things get hairy when we start looking up the domain for a wired
interrupt (typically when creating it based on some firmware
information - DT or ACPI).

In irq_create_fwspec_mapping(), we perform the lookup using
DOMAIN_BUS_ANY, which is actually used as a wildcard. This gives
us one chance out of two to end up with the wrong domain, and
we try to configure a wired interrupt with the MSI domain.
Everything grinds to a halt pretty quickly.

What we really need to do is to start looking for a domain that
would uniquely identify a wired interrupt domain, and only use
DOMAIN_BUS_ANY as a fallback.

In order to solve this, let's introduce a new DOMAIN_BUS_WIRED
token, which is going to be used exactly as described above.
Of course, this depends on the irqchip to setup the domain
bus_token, and nobody had to implement this so far.

Only so far.

Change-Id: Ia71c7475354eb38ab9b15423560aa3d28ae16381
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Link: http://lkml.kernel.org/r/1453816347-32720-2-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from commit 530cbe100ef7587aa5b5ac3a4b670cda4d50e598)

UPSTREAM: irqdomain: Introduce is_fwnode_irqchip helper

Since there will be several places checking if fwnode.type
is equal FWNODE_IRQCHIP, this patch adds a convenient function
for this purpose.

Change-Id: I65ab9e1350428de18864ba493256b959efc01f45
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from commit 75aba7b0e9ac416ca53c0c97680b8e9aedf09284)

UPSTREAM: arm64: perf: add support for Cortex-A72

Cortex-A72 has a PMUv3 implementation that is compatible with the PMU
implemented by Cortex-A57.

This patch hooks up the new compatible string so that the Cortex-A57
event mappings are used.

Change-Id: I06b39699fa019d61be81a1a275f7eb6eed17808a
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 5d7ee87708d4d86fcc32afc9552d05f7625d303d)

UPSTREAM: arm64: perf: add format entry to describe event -> config mapping

It's all very well providing an events directory to userspace that
details our events in terms of "event=0xNN", but if we don't define how
to encode the "event" field in the perf attr.config, then it's a waste
of time.

This patch adds a single format entry to describe that the event field
occupies the bottom 10 bits of our config field on ARMv8 (PMUv3).

Change-Id: I71f9ebf92cd2f7083c10f20a8707a91d4517cbcb
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 57d74123954dfe70fad12724d19f743ed14cec90)

UPSTREAM: arm64: perf: Correct Cortex-A53/A57 compatible values

Use commas instead of periods.

Change-Id: I6762decd0390c9f8914e4f314a5212875d200ed5
Acked-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Dirk Behme <dirk.behme@gmail.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit aae881ad73460e1b2aea01f079a0541bd5a9136c)

UPSTREAM: arm64: perf: Add event descriptions

Add additional information about the ARM architected hardware events
to make counters self describing. This makes the hardware PMUs easier
to use as perf list contains possible events instead of users having
to refer to documentation like the ARM TRMs.

Change-Id: Idb004bb6d9889f8e63f518d105e238d43956b561
Signed-off-by: Drew Richardson <drew.richardson@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 9e9caa6a496174e53d7753baa4779717771da4a7)

UPSTREAM: arm64: perf: Convert event enums to #defines

The enums are not necessary and this allows the event values to be
used to construct static strings at compile time.

Change-Id: I01049434e5ddc5c51b7ae914e9c55a0ef6bf66d9
Signed-off-by: Drew Richardson <drew.richardson@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 90381cba64591e27d0e8bbfe71bf8a98bd2a3db3)

video: rockchip: fb: update format define

Change-Id: Ief308474bfdbacadcc85e5a662d2f0a070c0c5cf
Signed-off-by: Huang Jiachai <hjc@rock-chips.com>

video: rockchip: rk fb: disable all layer and update vop state when switch screen

Change-Id: Ibdd82c477b2fdd2f21b5cbb708048bebbf1dfc7b
Signed-off-by: Huang Jiachai <hjc@rock-chips.com>

video: rockchip: vop: 3399: close vop when hdmi unplug

Change-Id: Ia75972e95aa738a4da5e766f9363250a63154cc3
Signed-off-by: Huang Jiachai <hjc@rock-chips.com>

[media] rockchip-vpu: change V4L2_CTRL_ID2CLASS to V4L2_CTRL_ID2WHICH

Change-Id: I700e8564caa08eb3239d4801cef9c1e04699fe6f
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rockchip-vpu: reconstructs for futher chips

Change-Id: Ia88f45b37a1af829723e6b8cb9d8ff3cb5f54530
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rockchip-vpu: reconstructs hw codes for futher chips

Change-Id: I3ad3a5220d5dc5b952d9e0e11f7142bc30a144f9
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rockchip-vpu: rename rk3288-vpu to rockchip-vpu

Note: dec/enc dev name change to rockchip-vpu-dec/rockchip-vpu-enc

Change-Id: I35d168fa7ccf6df4465affd01f6c3c5456182897
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rockchip-vpu: rename rk3288-vpu sources to rockchip-vpu

Change-Id: I66ba2cde8984e56ffa3a27515e4e6380af8544d8
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rockchip-vpu: add dma-iommu support on arm64

Change-Id: Ieeaed0320202a6d056b6c248d5b72df2419bf29c
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rockchip-vpu: fix compile errors

Adjust to new v4l2 APIs and fix some debug logs.

Change-Id: Iafba102fa326c669efcbb0baeb8897fe660dcdd4
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rk3288-vpu: move rk3288-vpu to rockchip-vpu

Change-Id: I4c884307550b0782c29a482d5df6793132c3a9ff
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

FROMLIST: common: DMA-mapping: add DMA_ATTR_ALLOC_SINGLE_PAGES attribute

This patch adds the DMA_ATTR_ALLOC_SINGLE_PAGES attribute to the
DMA-mapping subsystem.

This attribute can be used as a hint to the DMA-mapping subsystem that
it's likely not worth it to try to allocate large pages behind the
scenes.  Large pages are likely to make an IOMMU TLB work more
efficiently but may not be worth it.  See the Documentation contained in
this patch for more details about this attribute and when to use it.

Note that the name of the hint (DMA_ATTR_ALLOC_SINGLE_PAGES) is loosely
based on the name MADV_NOHUGEPAGE.  Just as there is MADV_NOHUGEPAGE
vs. MADV_HUGEPAGE we could also add an "opposite" attribute to
DMA_ATTR_ALLOC_SINGLE_PAGES.  Without having the "opposite" attribute
the lack of DMA_ATTR_ALLOC_SINGLE_PAGES means "use your best judgement
about whether to use small pages or large pages".

BUG=chromium:570532
TEST=Stress memory and watch cat videos.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
(am from https://patchwork.kernel.org/patch/8007151/)
Reviewed-on: https://chromium-review.googlesource.com/322334
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Change-Id: I9d0af41446b5c41d6f39a2b77e711179d0b40eca
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: vb2: Add a new "use_dma_bidirectional" queue flag.

When set to 1 for CAPTURE queues by the driver on calling vb2_queue_init(),
forces the buffers on the queue to be allocated/mapped with
DMA_BIDIRECTIONAL DMA direction flag, instead of DMA_FROM_DEVICE. This
allows the device not only to write to the buffers, but also read out from
them. This may be useful e.g. for codec hardware, which may be using
CAPTURE buffers as reference to decode other buffers.

This flag is ignored for OUTPUT queues, as we don't want to allow HW to
be able to write to OUTPUT buffers.

Signed-off-by: Pawel Osciak <posciak@chromium.org>
BUG=chrome-os-partner:45346
TEST=video playback

Reviewed-on: https://chromium-review.googlesource.com/300726
Commit-Ready: Pawel Osciak <posciak@chromium.org>
Tested-by: Pawel Osciak <posciak@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Change-Id: Ifba955eef75ac23c9a13edab04bc1fe7f5375c70
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: vb2: Store dma_dir in vb2_queue.

Store dma_dir in struct vb2_queue and reuse it, instead of recalculating
it each time.

Signed-off-by: Pawel Osciak <posciak@chromium.org>
BUG=chrome-os-partner:45346
TEST=video playback

Reviewed-on: https://chromium-review.googlesource.com/300725
Commit-Ready: Pawel Osciak <posciak@chromium.org>
Tested-by: Pawel Osciak <posciak@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Owen Lin <owenlin@chromium.org>
Conflicts:
drivers/media/v4l2-core/videobuf2-core.c

Change-Id: Ia5405cd758ffef0b0319d184a2f32699ebc805ea
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

UPSTREAM: v4l: add V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME.

Some drivers also need a control like
V4L2_CID_MPEG_MFC51_VIDEO_FORCE_FRAME_TYPE to force an encoder
key frame. Add a general V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME
so the new drivers and applications can use it.

Signed-off-by: Wu-Cheng Li <wuchengli@chromium.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
(cherry picked from commit 0c8485ca3f2aaf7842d45ba24c667a9492c9900f)
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
BUG=chromium:572825
TEST=Build and boot oak-rev5 to UI
TEST=emerge-smaug chromeos-kernel-3_18

Reviewed-on: https://chromium-review.googlesource.com/328870
Commit-Ready: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Change-Id: I45de3048d41edbe443b3d202c17e79f2d448213b
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rk3288-vpu: Add V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME

Also remove unused V4L2_CID_MPEG_MFC51_VIDEO_FORCE_FRAME_TYPE.

BUG=chrome-os-partner:53551
TEST=Passed vea test cases.
CQ-DEPEND=CL:346361

Signed-off-by: Heng-Ruey Hsu <henryhsu@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346390
Commit-Ready: Heng-ruey Hsu <henryhsu@chromium.org>
Tested-by: Heng-ruey Hsu <henryhsu@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Reviewed-by: Wu-cheng Li <wuchengli@chromium.org>
Change-Id: I6ad197191e57de9233d201d8196b3edb4df7e560
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: rk3288-vpu: Set DMA_ATTR_ALLOC_SINGLE_PAGES

We do video allocation all the time and we need it to be fast.  Plus TLB
efficiency isn't terribly important for video.

That means we want to set DMA_ATTR_ALLOC_SINGLE_PAGES

See also the previous change ("ARM: dma-mapping: Use
DMA_ATTR_ALLOC_SINGLE_PAGES hint to optimize alloc")

BUG=chromium:570532
TEST=Memory pressure + cat videos is even smoother!

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/322336
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Change-Id: I8bda3d9655daaa893c7bead7108b863607d1614f
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: rk3288-vpu: Set use_dma_bidirectional=1 for decoder CAPTURE queue

This allows us to read out from decoded buffers to use them for reference
for decoding other frames.

Signed-off-by: Pawel Osciak <posciak@chromium.org>
BUG=chrome-os-partner:45346
TEST=video playback

Reviewed-on: https://chromium-review.googlesource.com/300727
Commit-Ready: Pawel Osciak <posciak@chromium.org>
Tested-by: Pawel Osciak <posciak@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Owen Lin <owenlin@chromium.org>
Change-Id: I454916b0862e541d1362413b29bfd3e51c8e3e6d
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: rk3288-vpu: Add DMABUF to io_modes.

To support gralloc buffers.

BUG=chrome-os-partner:45346
TEST=Play a video on minnie.

Signed-off-by: Owen Lin <owenlin@google.com>
Reviewed-on: https://chromium-review.googlesource.com/299613
Commit-Ready: Owen Lin <owenlin@chromium.org>
Tested-by: Owen Lin <owenlin@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Change-Id: I7ba9c7a0640fa822c43f2442ddbdc257609bc09a
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rk3288-vpu: Workaround for encode after decode

On RK3288 there is an issue with certain hardware state being corrupted
while decoding certain streams, which affects encoding task run directly
after that decoding task. To reinitialize the state properly, a dummy
encoding of a single 64x64 pixels keyframe must be performed before the
real encoding is run.

This patch adds necessary workaround code to the driver, which makes it
execute an encoding task using dummy buffers with static parameters
manually selected for lowest performance overhead and to assure that
aforementioned hardware state is reinitialized.

BUG=chrome-os-partner:41585
TEST=AppRTC loopback

Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/286284
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Change-Id: I019d1983633ec2cf2818956a7bf988314d853cdf
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rk3288-vpu: Add helper for encode plane sizes calculation

Currently plane sizes calculation on encoder side is happening only in
vidioc_s_fmt() function, howerver as a prerequisite for further patch
adding further code which needs this operation, this patch adds a common
helper function, which performs this operation.

BUG=chrome-os-partner:41585
TEST=AppRTC loopback

Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/289047
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Change-Id: I6e5769667ae40b3fb5758ce9471b4ddd6866183f
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rk3288-vpu: Add helper to get context operating mode

Currently there is only one place in the code checking whether given
context is decoding or encoding. However as a prerequisite for further
patch adding more such checks, this patch adds a common helper function
which returns appropriate enum value depending on operating mode of
given context.

BUG=chrome-os-partner:41585
TEST=AppRTC loopback

Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/288661
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Change-Id: Ide145770ca77897ada3cb878c4b9c9787824a827
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rk3288-vpu: vp8e: increase frame hdr size

Currently, FRAME_HEADER_SIZE is 256, but i've saw
the hdr be larger then 256 when doing screen share.
so we should increase it.

This needs change the define in v4lplugin too.
(change id: Ia6c2271b727218692c4e0b1603d243f32d2f1d77)

BUG=chromium:497324
TEST=screen share through Hangouts

Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/277398
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Change-Id: I06e7712420404c43661774e176a7b9333ddc3def
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rk3288-vpu: Implement VIDIOC_ENUM_FRAMESIZES

This patch adds implementations of VIDIOC_ENUM_FRAMESIZES for rk3288-vpu
encoder and decoder devices. This IOCTL lets the userspace learn about
frame size limits of the hardware.

BUG=chromium:485409
TEST=vda/veatests, Chrome with crrev.com/1097913002.

Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/269867
Reviewed-by: Heng-ruey Hsu <henryhsu@google.com>
Change-Id: Ia23a89c2f380b16cc7ef8338d33946d62f8a68fe
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rk3288-vpu: Make find_format() use fourcc directly

As a prerequisite for using find_format() helpers from contexts in which
a v4l2_format struct is not available, this patch makes it take u32 fourcc
as its argument instead, since it was the only member of that struct it
actually used anyway.

BUG=chromium:485409
TEST=vda/veatests, Chrome with crrev.com/1097913002.

Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/269866
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Trybot-Ready: Pawel Osciak <posciak@chromium.org>

Change-Id: Ifa9c4e3e378fbeafb6453a01b9e4f7c11606025b
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rk3288-vpu: Use macros for frame size limits

As a prerequisite for reusing those values in new code, this patch
creates appropriate macros for them and updates current code to use
them.

BUG=chromium:485409
TEST=vda/veatests, Chrome with crrev.com/1097913002.

Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/269865
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Trybot-Ready: Pawel Osciak <posciak@chromium.org>

Change-Id: I95b1afbeff91aeb71d1748bf05895e769385f76e
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rk3288-vpu: Require kernel mapping only for encoder output

For rk3288-vpu, kernel mapping of video buffers is required only for
encoder bitstream output buffers for additional bistream formatting. Any
other buffers can be allocated without kernel mapping, greatly
conserving the limited pool of vmalloc memory.

This patch modifies the rk3288-vpu driver to use the newly added vb2-dc
interface to create two separate allocation contexts, one for
allocations with kernel mapping and one without.

BUG=chrome-os-partner:38873
TEST=vda/vea unit tests

Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/265364
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Change-Id: I4154802dda2329934dea675a242d67e80b925db0
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rk3288-vpu: Add suspend/resume handlers

Currently the driver does not implement suspend and resume PM ops.
However when system is entering suspend, the driver should prevent
submitting further runs to the hardware and wait for current run to be
finished. To resume playback after leaving sleep state, next run, if
available, must be submitted to the hardware.

This patch adds proper suspend and resume callbacks to handle this.

BUG=chrome-os-partner:38565
TEST=suspend and resume veyron_jerry several times with video playing

Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/263662
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Change-Id: Id07b7d681ef78655879ce77c9705b1c25231df9d
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rk3288-vpu: Preserve picture positions in H264 DPB lists

Even though H264 standard allows arbitrary order of DPB entries, the
hardware requires picture with given POC to use the same DPB entry for
its whole lifetime. This means that the driver needs to reorder DPB
array to suit this requirement.

This patch modifies the driver to reorder H264 DPB and should fix
corruption issues when DPB array received from userspace does not meet
hardware requirements.

BUG=chrome-os-partner:38416
TEST=http://www.youtube.com/embed/YE7VzlLtp-4

Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/263370
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Tested-by: Caesar Wang <wxt@rock-chips.com>
Change-Id: Ibbd0e2bc4e527aadd21ef08ec68866678bf8a659
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rk3288-vpu: Fix image size clamping

Current code always assumed the maximum supported resolution to be
1920x1088, and minimum 8x4 however the real limits are 48x48 and 3840x2160
for decoder and 96x96 and 1920x1088 for encoder. This patch modifies the
driver to use correct limits and also fixes incorrect log message.

BUG=chrome-os-partner:38232,chromium:464920
TEST=Screen sharing of a window bigger than 1920x1088 to Jerry

Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/261851
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Change-Id: I0c51e5a9ad235716ee447e052455b97ed0c295de
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rk3288-vpu: Fix hangout corruption

If segmentation_enable flag is zero, no matter what
segmentation_update_flag is, we cannot set it to HW.
Before this patch, incorrect segmentation_update_flag
might be set to HW which caused hangout corruption.

BUG=chrome-os-partner:35531
TEST=make a video chat by hangout with other device.

Signed-off-by: ZhiChao Yu <zhichao.yu@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/242732
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Commit-Queue: Tomasz Figa <tfiga@chromium.org>

Change-Id: I86c00c27d3c97854db8c4164289fa434b29819ff
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rk3288-vpu: Fix VP8 decode corruption

The QP value wasn't correctly clamped by calling function clamp()
with wrong order of arguments. Fix this by passing the arguments
correctly.

BUG=chrome-os-partner:35606
TEST=Open Chrome and navigate to:
http://video.webmfiles.org/elephants-dream.webm

Signed-off-by: ZhiChao Yu <zhichao.yu@rock-chips.com>
[tfiga: Moved back to clamp(), but fixed argument order.]
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242171
Reviewed-by: Kuang-che Wu <kcwu@chromium.org>
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Change-Id: I415e19e6cdfb125b281d205bcdf93ae9911655f4
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rk3288-vpu: Bump ACLK frequency to 400 MHz

According to RK3288 TRM, the maximum worst case operating frequency of
VPU is 400 MHz, but by default it is set to 200 MHz. To fix (or work
around) performance issues with VP8 encoder, this patch bumps the
frequency to maximum possible value.

BUG=chrome-os-partner:35405
TEST=./video_encode_accelerator_unittest
--test_stream_data=tulip2-1280x720-1b95123232922fe0067869c74e19cd09.yuv:1280:720:11:out1280x720.ivf:1200000
--v

Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240644
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Change-Id: I397139fe1195b74b8ebd516eae0968bccff7ef4b
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rk3288_vpu: implement vp8d hw config part

This patch adds code implementing rk3288_vpu_codec_ops
for VP8 decoder.

BUG=chrome-os-partner:33728
TEST=video_encode_accelerator_unittest;video_decode_accelerator_unittest

Signed-off-by: ZhiChao Yu <zhichao.yu@rock-chips.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238311
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Change-Id: I7875c3c6e53ed00ea74035778651b6b676298ee8
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rk3288-vpu: Add VP8 decoder to V4L2 API implementation

This patch extends existing implementation of required V4L2 API calls
with code required for VP8 decoder.

BUG=chrome-os-partner:33728
TEST=video_encode_accelerator_unittest;video_decode_accelerator_unittest

Signed-off-by: ZhiChao Yu <zhichao.yu@rock-chips.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/239814
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Change-Id: I633687b7223c25f46d2373b964ceb1fe29f02b2f
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rk3288_vpu: implement h264d hardware config part

This patch adds code implementing rk3288_vpu_codec_ops for H264 decoder.

BUG=chrome-os-partner:33728
TEST=compile

Signed-off-by: Hertz Wong <hertz.wong@rock-chips.com>
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237618
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Change-Id: I17e9828008946d370f6fb7b52ce02b412e73c6e9
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] rk3288-vpu: Implement basic V4L2 APIs for decoder

This patch adds implementation of basic V4L2 APIs for decoder part of
the driver. It is still missing the hardware specific part, including
the hardware specific controls containing certain data precalculated
in userspace.

BUG=chrome-os-partner:33728
TEST=compile

Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237617
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Change-Id: I3cad74aad3c6c4ac5e6b2123b5d93e3173b74c7a
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] Add rk3288-vpu driver (vp8-encoder only)

Currently it consists of implementations of a platform driver and a V4L2
mem-to-mem encoder device. Only VP8 encoding is implemented currently.

BUG=chrome-os-partner:33728
TEST=video_encode_acceleator_unittest

Signed-off-by: Alpha Lin <Alpha.Lin@rock-chips.com>
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237614
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Conflicts:
drivers/media/platform/Makefile

Change-Id: I6e2c44ff378c68af4f1db071c7909a0870d9171a
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] v4l2-ioctl: add vp8 frame & h264 slice to VIDIOC_ENUM_FMT

Change-Id: Idcfa80d3c838e3b2da1107800b178dc6e8d82dc1
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] videobuf2-dc: Let drivers specify DMA attrs

DMA allocations might be subject to certain reqiurements specific to the
hardware using the buffers, such as availability of kernel mapping (for
contents fix-ups in the driver). The only entity that knows them is the
driver, so it must share this knowledge with vb2-dc.

This patch extends the alloc_ctx initialization interface to let the
driver specify DMA attrs, which are then stored inside the allocation
context and will be used for all allocations with that context.

As a side effect, all dma_*_coherent() calls are turned into
dma_*_attrs() calls, because the attributes need to be carried over
through all DMA operations.

BUG=chrome-os-partner:38873
TEST=compile

Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/265363
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Change-Id: I0e6c040cf820c194b6ca6f3e6355217496bd1532
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: v4l: Add VP8 low-level decoder API controls.

These controls are to be used with the new low-level decoder API for VP8
to provide additional parameters for the hardware that cannot parse the
input stream.

BUG=chrome-os-partner:33728
TEST=compile

Signed-off-by: Pawel Osciak <posciak@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237670
Reviewed-by: Wu-cheng Li <wuchengli@chromium.org>
Commit-Queue: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Change-Id: I32b45e07cfe02b25ea5202d0c839699103e3b800
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: v4l: Add H264 low-level decoder API compound controls.

Signed-off-by: Pawel Osciak <posciak@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237616
Reviewed-by: Wu-cheng Li <wuchengli@chromium.org>
Commit-Queue: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
[rebase44(groeck): include linux/types.h in v4l2-controls.h]
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Change-Id: Iee08205ff3b9a54c6561e385acae8182acc73393
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: [media] v4l: Add private compound control type.

V4L2_CTRL_TYPE_PRIVATE is to be used for private driver compound
controls that use the "ptr" member of struct v4l2_ext_control.

BUG=chrome-os-partner:33728
TEST=build

Signed-off-by: Pawel Osciak <posciak@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228988
Trybot-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Wu-cheng Li <wuchengli@chromium.org>
Commit-Queue: Tomasz Figa <tfiga@chromium.org>

Change-Id: I44083b0216ef32629d12f0910e972a3e827a599a
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: v4l2-ctrls: add function to apply a configuration store.

Drivers need to be able to select a specific store. Add a new function that can
be used to apply a given store.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
BUG=chrome-os-partner:33728
TEST=build

Signed-off-by: Pawel Osciak <posciak@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232585
Trybot-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Wu-cheng Li <wuchengli@chromium.org>
Commit-Queue: Tomasz Figa <tfiga@chromium.org>

Change-Id: I3b80a31681765836a134812ebc56686324ca5194
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: Add config store support

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
BUG=chrome-os-partner:33728
TEST=build

Signed-off-by: Pawel Osciak <posciak@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232584
Trybot-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Wu-cheng Li <wuchengli@chromium.org>
Commit-Queue: Tomasz Figa <tfiga@chromium.org>

Conflicts:
drivers/media/v4l2-core/v4l2-ctrls.c
include/media/v4l2-ctrls.h

[rebase44(groeck): Resolved conflicts]
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Conflicts:
drivers/media/v4l2-core/v4l2-ctrls.c

Change-Id: I0b2e66f3331cab91d209868f5d5f67f795a0e72c
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: videodev2.h: rename reserved2 to config_store in v4l2_buffer.

When queuing buffers allow for passing the configuration store ID that
should be associated with this buffer. Use the 'reserved2' field for this.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
BUG=chrome-os-partner:33728
TEST=build

Signed-off-by: Pawel Osciak <posciak@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232583
Trybot-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Wu-cheng Li <wuchengli@chromium.org>
Commit-Queue: Tomasz Figa <tfiga@chromium.org>

Conflicts:
drivers/media/v4l2-core/videobuf2-core.c

[rebase44(groeck): fixed conflicts; structural changes to match v4.4]
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Conflicts:
drivers/media/v4l2-core/v4l2-compat-ioctl32.c

Change-Id: Ibb823e9369bec79645e09651b0dda006ed53ecc5
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: videodev2.h: add config_store to v4l2_ext_controls

The ctrl_class is fairly pointless when used with drivers that use the control
framework: you can just fill in 0 and it will just work fine. There are still
some old unconverted drivers that do not support 0 and instead want the control
class there. The idea being that all controls in the list all belong to that
class. This was done to simplify drivers in the absence of the control framework.

When using the control framework the framework itself is smart enough to allow
controls of any class to be included in the control list.

Since configuration store IDs are in the range 1..255 (or so, in any case a relatively
small non-zero positive integer) it makes sense to effectively rename ctrl_class
to config_store. Set it to 0 and you get the normal behavior (you change the current
control value), set it to a configuration store ID and you get/set the control for
that store.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
BUG=chrome-os-partner:33728
TEST=build

Signed-off-by: Pawel Osciak <posciak@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232582
Trybot-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Wu-cheng Li <wuchengli@chromium.org>
Commit-Queue: Tomasz Figa <tfiga@chromium.org>

Conflicts:
include/uapi/linux/videodev2.h

Change-Id: I862bb5796e27bcbbd055e22202ac9a1ed0cc6f7d
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

CHROMIUM: ARM: dts: rockchip: assigned parents for vop dclks

The VOP DCLK is used to generate panel clocks.

For veyron, we have decided to permanently assign vop0 for
use with HDMI and vop1 for use with eDP.

Furthermore, to allow us to generate a wide range of precise pixel clocks,
we will be dedicating the NPLL exclusively for use as the parent clock
for VOP0/HDMI.

To implement the exclusive assignment of NPLL in the kernel, we remove
the NPLL entry from all clock muxes that would otherwise be able to select
it (such as vop1).  For vop0, we remove all choices *except* NPLL.

Before booting the kernel, the bios will configure vop0 and vop1 as it
sees fit - potentially assigning NPLL to vop1 and some other PLL to vop0.

Thus, at boot it is possible that from the kernel's perspective, these
clocks are orphans.  To fix this, we explicitly assign their clock parents
to ensure that they are properly parented no matter what state they are
when the kernel boots.

Change-Id: Iafe301abcbf211246fda66519cea5fc946af97ee
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>

CHROMIUM: videodev2.h: add V4L2_CTRL_FLAG_CAN_STORE

Controls that have a configuration store will set this flag.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
BUG=chrome-os-partner:33728
TEST=build

Signed-off-by: Pawel Osciak <posciak@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232581
Trybot-Ready: Tomasz Figa <tfiga@chromium.org>
Tested-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Wu-cheng Li <wuchengli@chromium.org>
Commit-Queue: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Conflicts:
include/uapi/linux/videodev2.h

[rebase44(groeck): Resolved conflicts]
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Change-Id: I88ccf65a5c6f11381cfacb4c328b589194f249ec
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

FROMLIST: ARM: dts: rockchip: add the panel power supply for rk3288-evb board with rk808 pmu

Panel regulator is controller by a normal GPIO, so we need to
write a regulator-fixed node for it.

Change-Id: I24a0f2787ef3bb93422296e8a97c076040460ccc
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9201801/)

FROMLIST: ARM: dts: rockchip: add the panel power supply for rk3288-evb board with act8846 pmu

Panel regulator is controller by a normal GPIO, so we need to
write a regulator-fixed node for it.

Change-Id: I4368b16bf49ef04a539aad154f7c16b094bfc382
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9201803/)

FROMLIST: ARM: dts: rockchip: add eDP/panel display device nodes for rk3288-evb

The default eDP panel on RK3288 EVB board is LG LP079QX1-SP0V TFT LCD,
we haven't declared the panel regulator in the 'panel-simple' device
node here, so the specific board like ACT8846 / RK8080 need to support
the panel power supply.

Change-Id: Ibf4a6457d606027eaa91cacf6fde2241376afd13
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9201815/)

dt-bindings: Add support for AUO B101EW05 1280x800 panel

The AUO B101EW05 panel is a 10.1" 1280(RGB)x800 WXGA TFT-LCD panel,
connected using LVDS interfaces.

Change-Id: Ic80369353f5e1726d2ea2ace6d53bb2bcdae6fc2
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

drm/panel: simple: Add support for AUO B101EW05 1280x800 panel

The AUO B101EW05 panel is a 10.1" 1280(RGB)x800 WXGA TFT-LCD panel,
connected using LVDS interfaces

Change-Id: Ic67fe5793a975b585cecfb8da02e81cd9fa6346f
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

dt-bindings: add support Chunghwa CLAA070WP03 800x1280 panel

Chunghwa CLAA070WP03 is 7” color TFT-LCD module composed of LCD
panel, LVDS driver ICs, control circuit and backlight. This module
supports 800x1280 mode.

Change-Id: I7f71464a80725d648802918740e64a0368f5c480
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

drm/panel: simple: add support Chunghwa CLAA070WP03 800x1280 panel

Chunghwa CLAA070WP03 is 7” color TFT-LCD module composed of LCD panel,
LVDS driver ICs, control circuit and backlight. This module supports
800x1280 mode.

Change-Id: I6a6339ad25664e2e47fc0e0de5c079db3494bd25
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

ARM: dts: rockchip: enable GPU support on RK3288 EVB board with act8846 pmu

Change-Id: I92e43f6dd5563a9b8f423cf03f17dad60b4497ab
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

ARM: dts: rockchip: add GPU device node for RK3288

RK3288 have integrated the Mali-T760

Change-Id: Id5f98f8c236049c7936c44290e93dfef9dee0c3b
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

UPSTREAM: ARM: dts: rockchip: add 2 regulators for rk3288-evb-act8846

vcc_wl and vcc_lcd are 2 gpio switches for rk3288-evb-act8846 board.

Change-Id: I49fc20665adf4176d672fdd3e4030ee472f558a8
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(cherry pick from commit 662513a14c9dd1ba2b4d5928d6eae443744edefc)

video: rockchip: vop: 3399: fix layer0 perpixel alpha error

Change-Id: I5d4947ab131d39ebc611ba78100e05aa95c4b3e9
Signed-off-by: Huang Jiachai <hjc@rock-chips.com>

ARM64: kernel: dump kernel addresses larger than VA_START

The arm64 virtual addresses of kernel are like:
VA_START < MODULES_VADDR < KIMAGE_VADDR < PAGE_OFFSET.
PAGE_OFFSET is the virtual address of the start of the linear map.
And the vmalloc, kernel code and so on are between VA_START and
PAGE_OFFSET, so it is necessary to expand dump addresses to VA_START,
instead of PAGE_OFFSET.

Change-Id: I810ed216862de4c6e68b92d483de4aa68da532b8
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>

ARM: dts: rockchip: add the supports-emmc for rk3288 emmc property

I don't need send for upstream since the rockchip inside kernel
need it for tuning. At least the upstream can work it with dwmmc.

Change-Id: I73c12b455c7dc5320d6c06f9e29ddec5c4a6def5
Signed-off-by: Yakir Yang <ykk@rock-chips.com>

UPSTREAM: ARM: dts: rockchip: add GMAC nodes for RK322x SoCs

This patch add the GMAC dt nodes for rk322x SoCs.

Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
v4.8-armsoc/dts32 commit 5d3d7c72b920f9aa44f9b64cdd8a1c5bf5cbea07)

Change-Id: I85467b7253fda16c242d91bcdd207d0175ee0db3
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>