The RK3328 has two video IP sharing the same mmu,
but only the VDPU is available in this platform.

Change-Id: I24d73cd5ab2c3d32da6ef29661061c7fda9186f2
Signed-off-by: Randy Li <randy.li@rock-chips.com>

This commit would enable the VDPU and RKVDEC devices. The VDPU works in the non combo mode.

Change-Id: I643350d5a2ac17759984fda2e95fb2b82701e7cf
Signed-off-by: Randy Li <randy.li@rock-chips.com>
Signed-off-by: Hans Yang <yhx@rock-chips.com>

Conflicts:
	arch/arm64/boot/dts/rockchip/rk3328-evb.dts

Change-Id: Idf5691c7b0c7da75579be410c2fb5e1a346ab012

Change-Id: I4d0b01491f4183c7e700fdb8ba7025871a162951

This reverts commit 1f58bcd.

Change-Id: I2c01055569640e8238f48ec069ec4a58300dccd8

This reverts commit bf512ba.

Change-Id: I02e7ab0bed3166cf98483f35b3f4da6113baacd6

Add helper to allow users to retrieve the speaker allocations without
knowledge of the ELD structure.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

During probe, DAIs can need to perform some actions that requests
the knowledge of the pcm runtime handle.
The callback is called during DAIs linking, after PCM device creation.
For instance this can be used to add relationship between a DAI pcm
control and the pcm device.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Add user interface to provide channel mapping.
In a first step this control is read only.

As TLV type, the control provides all configuration available for
HDMI sink(ELD), and provides current channel mapping selected by codec
based on ELD and number of channels specified by user on open.
When control is called before the number of the channel is specified
(i.e. hw_params is set), it returns all channels set to UNKNOWN.

Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

DRM legacy doesn't allow that, will be only available with drm atomic.
Although, when running 4K modes, it's preferable to get a 1080p frambuffer that can be handlded properly by GPU and then use VOP to upscale that to 4K.

Revert "Squashfs: optimize reading uncompressed data"

This reverts commit 0c2f831.

Revert "Squashfs: implement .readpages()"

This reverts commit 9c6d9ab.

Revert "Squashfs: replace buffer_head with BIO"

This reverts commit 8327714.

Revert "Squashfs: refactor page_actor"

This reverts commit 4bc7d97.

Revert "Squashfs: remove the FILE_CACHE option"

This reverts commit 3de0af4.

Support internal ephy currently.

Change-Id: I8d85e7f98d152dc74ac2036de384625d0d228f2b
Signed-off-by: David Wu <david.wu@rock-chips.com>

Change-Id: I7b596d97bc76dd9fd969fd7c22d6a04a5504a073
Signed-off-by: David Wu <david.wu@rock-chips.com>

Change-Id: If2c0e5b6d50ba4326f6ca7d2ee4a1c87e7682959
Signed-off-by: David Wu <david.wu@rock-chips.com>

Change-Id: I57c0efd009b4f443eda9b3da8e397e5c19e4e40e

Change-Id: Ia108663f0c30b4d28d775738a62669c3e4f2a14a

Change-Id: Idf130dbf2f9e0f8d00519a320263fe9771d7e2de

…d modules for USB wifi hardware (#1)

* Add support for mtd devices, generic SPI NOR flash and the GD25Q128 NOR flash on the Rock64

* Delete SPI DMA properties via board dts, fix kernel config.

* Disable SPI debug.

Change-Id: Ia3c5339eadaa95d72b142b2f44f30df43075c791

commit b556c9a
Author: Kamil Trzcinski <ayufan@ayufan.eu>
Date:   Mon Jul 3 23:44:11 2017 +0200

    Check address valideness and save use vendor mtd partition

    Change-Id: I35f5ade707470dbfe2c7d62697802f40019bd58d

commit c07592e
Author: Kamil Trzcinski <ayufan@ayufan.eu>
Date:   Mon Jul 3 21:49:12 2017 +0200

    Use vendor from MTD

    Change-Id: I9f977a541a715256b7cae4d7b59000d7aa5b9055

Change-Id: Ie96ba984aa67c43b5a540d6efd9cd7d7d5817b02

Change-Id: Id57301eab1212b8d5f3435cf560773978a5c93f9

- include additional cgroups for mem, pids and block,
- disable CONFIG_RK_PARTITION as it clashes with GPT when boot over eMMC,
- enable NBD and AOE

Change-Id: Ifad46b1eaaede1186c52472e313b13f64a619d57

Change-Id: Ibab4744b5cb660385ca2d6fade356ee51fc83414

* Since the 'clock-freq-min-max' is deprecated, we use max-frequency.

* dts: fix emmc clocks, enable HS-200 mode

)

* dts: enable 1.4Ghz / 1.35V operating point for testing.

* Disable energy aware scheduling, we have currently no model.

…10)"

This reverts commit 328ae88.

Change-Id: Ifa0196660c78be99b654f22e02f8d5dbebf991d9

Change-Id: I4ceb2f351afcc37e4a4c34c9305b8e96511a35a2

Change-Id: Id89bcc3547920f3c58f7ce04c3a08dafd3c8bb38

Change-Id: I65713e622c46ed2028166cd54ce56794ae00d766

Change-Id: I05fd4132f04235d4464d29496b090f75d9352836

…se-4.4"

This reverts commit 3b7ef43, reversing
changes made to 17cebdb.

Change-Id: I6eca20102609dd5b4d111e84da71b64b79d8598a

Change-Id: I0ca083128af53409c97c6c5900af887a06955201

Change-Id: I59580d1828dba31df39720be9832593e4b9c8bdd

Change-Id: Ie35667d264963952c4ff5311199db9a7f6c91a27

Change-Id: I85efbe0bec06c450fe43d8a8b59da71ee388dd20

Change-Id: Ic618bada2e8a158f107192b056630cc08b42188c

Change-Id: I88695d123e4b2fa0261c5bd30e365da06be99c8b

This reverts commit 13dbe2c.

This reverts commit 5f63878.

…tervention"

This reverts commit e8a6e50.

…urst len * burst size)"

This reverts commit c66ecf1.

This reverts commit 8e770f3.

dmaengine device should explicitly call devm_free_irq() when using
devm_request_irq().

The irq is still ON when devices remove is executed and irq should be
quiesced before remove is completed.

Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 46cf94d)

…tors

Only one descriptor in the work list should be running at
any given time, but it's possible to have an enqueued BUSY
descriptor that has not yet transferred any data, or for
a BUSY descriptor to linger briefly before transitioning
to DONE. These cases should be handled to keep residual
calculations consistent even with the non-running BUSY
descriptors in the work list.

Signed-off-by: Stephen Barber <smbarber@chromium.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
(cherry picked from commit d64e9a2)

There is a racing when accessing dmac thread in pl330_tx_status that
the pl330_update is handling active request at the same time and
changing the status of descriptors. This could cause an invalid
transferred count from BUSY descriptor added up to the residual number.
Fix the bug by using the dmac's spinlock in pl330_tx_status to protect
thread resources from changing.
Note that the nested order of holding dmac's and dma_chan's spinlock is
consistent with the rest of the driver: dma_chan first and then dmac,
so it is safe from deadlock scenario.

Signed-off-by: Hsin-Yu Chao <hychao@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
(cherry picked from commit a40235a)

…ished

After executing DMAGO it's possible that a request can come in for the
current xferred count, but if that happens too soon then DMAMOV SAR/DAR
may not have yet completed. If that happens, we should explicitly return 0
since nothing has been transferred yet.

Signed-off-by: Stephen Barber <smbarber@chromium.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
(cherry picked from commit c44da03)

When PL330 is used with !MMU the following fault is seen:

Unhandled fault: alignment exception (0x801) at 0x8f26a002
Internal error: : 801 [#1] ARM
Modules linked in:
CPU: 0 PID: 640 Comm: dma0chan0-copy0 Not tainted 4.8.0-6a82063-clean+ #1600
Hardware name: ARM-Versatile Express
task: 8f1baa80 task.stack: 8e6fe000
PC is at _setup_req+0x4c/0x350
LR is at 0x8f2cbc00
pc : [<801ea538>]    lr : [<8f2cbc00>]    psr: 60000093
sp : 8e6ffdc0  ip : 00000000  fp : 00000000
r10: 00000000  r9 : 8f2cba10  r8 : 8f2cbc00
r7 : 80000013  r6 : 8f21a050  r5 : 8f21a000  r4 : 8f2ac800
r3 : 8e6ffe18  r2 : 00944251  r1 : ffffffbc  r0 : 8f26a000
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 00c5387c
Process dma0chan0-copy0 (pid: 640, stack limit = 0x8e6fe210)
Stack: (0x8e6ffdc0 to 0x8e700000)
fdc0: 00000001 60000093 00000000 8f2cba10 8f26a000 00000004 8f0ae000 8f2cbc00
fde0: 8f0ae000 8f2ac800 8f21a000 8f21a050 80000013 8f2cbc00 8f2cba10 00000000
fe00: 60000093 801ebca0 8e6ffe18 000013ff 40000093 00000000 00944251 8f2ac800
fe20: a0000013 8f2b1320 00001986 00000000 00000001 000013ff 8f1e4f00 8f2cba10
fe40: 8e6fff6c 801e9044 00000003 00000000 fef98c80 002faf07 8e6ffe7c 00000000
fe60: 00000002 00000000 00001986 8f1f158d 8f1e4f00 80568de4 00000002 00000000
fe80: 00001986 8f1f53ff 40000001 80580500 8f1f158d 8001e00c 00000000 cfdfdfdf
fea0: fdae2a25 00000001 00000004 8e6fe000 00000008 00000010 00000000 00000005
fec0: 8f2b1330 8f2b1334 8e6ffe80 8e6ffe8c 00001986 00000000 8f21a014 00000001
fee0: 8e6ffe60 8e6ffe78 00000002 00000000 000013ff 00000001 80568de4 8f1e8018
ff00: 0000158d 8055ec30 00000001 803f6b00 00001986 8f2cba10 fdae2a25 00000001
ff20: 8f1baca8 8e6fff24 8e6fff24 00000000 8e6fff24 ac6f3037 00000000 00000000
ff40: 00000000 8e6fe000 8f1e4f40 00000000 8f1e4f40 8f1e4f00 801e84ec 00000000
ff60: 00000000 00000000 00000000 80031714 dfdfdfcf 00000000 dfdfdfcf 8f1e4f00
ff80: 00000000 8e6fff84 8e6fff84 00000000 8e6fff90 8e6fff90 8e6fffac 8f1e4f40
ffa0: 80031640 00000000 00000000 8000f548 00000000 00000000 00000000 00000000
ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 dfdfdfcf cfdfdfdf
[<801ea538>] (_setup_req) from [<801ebca0>] (pl330_tasklet+0x41c/0x490)
[<801ebca0>] (pl330_tasklet) from [<801e9044>] (dmatest_func+0xb58/0x149c)
[<801e9044>] (dmatest_func) from [<80031714>] (kthread+0xd4/0xec)
[<80031714>] (kthread) from [<8000f548>] (ret_from_fork+0x14/0x2c)
Code: e3a03001 e3e01043 e5c03001 e59d3048 (e5802002)

This happens because _emit_{ADDH,MOV,GO) accessing to unaligned data
while writing to buffer. Fix it with writing to buffer byte by byte.

Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
(cherry picked from commit d07c9e1)

In pl330_add(), variable ‘regs’ is initialized but never used, which
leads to warning with W=1.

drivers/dma/pl330.c: In function 'pl330_add':
drivers/dma/pl330.c:1891:16: warning: variable 'regs' set but not used [-Wunused-but-set-variable]

So remove it.

Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
(cherry picked from commit 920e00d)

The static bug finder EBA (http://www.iagoabal.eu/eba/) reported the
following double-lock bug:

    Double lock:
    1. spin_lock_irqsave(pch->lock, flags) at pl330_free_chan_resources:2236;
    2. call to function `pl330_release_channel' immediately after;
    3. call to function `dma_pl330_rqcb' in line 1753;
    4. spin_lock_irqsave(pch->lock, flags) at dma_pl330_rqcb:1505.

I have fixed it as suggested by Marek Szyprowski.

First, I have replaced `pch->lock' with `pl330->lock' in functions
`pl330_alloc_chan_resources' and `pl330_free_chan_resources'. This avoids
the double-lock by acquiring a different lock than `dma_pl330_rqcb'.

NOTE that, as a result, `pl330_free_chan_resources' executes
`list_splice_tail_init' on `pch->work_list' under lock `pl330->lock',
whereas in the rest of the code `pch->work_list' is protected by
`pch->lock'. I don't know if this may cause race conditions. Similarly
`pch->cyclic' is written by `pl330_alloc_chan_resources' under
`pl330->lock' but read by `pl330_tx_submit' under `pch->lock'.

Second, I have removed locking from `pl330_request_channel' and
`pl330_release_channel' functions. Function `pl330_request_channel' is
only called from `pl330_alloc_chan_resources', so the lock is already
held. Function `pl330_release_channel' is called from
`pl330_free_chan_resources', which already holds the lock, and from
`pl330_del'. Function `pl330_del' is called in an error path of
`pl330_probe' and at the end of `pl330_remove', but I assume that there
cannot be concurrent accesses to the protected data at those points.

Signed-off-by: Iago Abal <mail@iagoabal.eu>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
(cherry picked from commit 91539eb)

When removing a device with less than 9 IRQs (AMBA_NR_IRQS), we'll get a
big WARN_ON from devres.c because pl330_remove calls devm_free_irqs for
unallocated irqs. Similarly to pl330_probe, check that IRQ number is
present before calling devm_free_irq.

Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
(cherry picked from commit ebcdaee)

This driver is now used only on platforms which support device tree, so
it is safe to remove legacy platform data based initialization code.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
For plat-samsung:
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
(cherry picked from commit e8bb467)

The functions _queue_empty(), _emit_ADDH(), _emit_NOP(), _emit_STZ()
and _emit_WFE() are not used. Delete them.

Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
(cherry picked from commit d43674e)

Change-Id: I266376a272ba0efd0b488c496dbcad3247df656b

…hubusercontent.com/moby/moby/master/contrib/check-config.sh

Change-Id: I03270c3466077b0a9fc2ef476117c652a3678730

The kernel headers package (linux-headers) doesn't include
header files from other architectures required to build
out-of-tree modules.

For e.g. on ARM64, opcodes.h includes the same file from ARM
which causes the following error:
./arch/arm64/include/asm/opcodes.h:1:43: fatal error:
../../arm/include/asm/opcodes.h: No such file or directory
compilation terminated.

Signed-off-by: Azriel Samson <asamson@codeaurora.org>

Change-Id: I27a9d962f778e39323e8ff70177379360f589de7

CONFIG_KEYS_COMPAT is defined in arch-specific Kconfigs and is missing for
several 64-bit architectures : mips, parisc, tile.

At the moment and for those architectures, calling in 32-bit userspace the
keyctl syscall would return an ENOSYS error.

This patch moves the CONFIG_KEYS_COMPAT option to security/keys/Kconfig, to
make sure the compatibility wrapper is registered by default for any 64-bit
architecture as long as it is configured with CONFIG_COMPAT.

[DH: Modified to remove arm64 compat enablement also as requested by Eric
 Biggers]

Signed-off-by: Bilal Amarni <bilal.amarni@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
cc: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>

…act-cert

Change-Id: I5a1df1068dc4a77b84b9a6e3107eb5f73930b0c0

Some special SoCs (e.g. rk322xh) USB3 PHY have problem to detect
disconnection, they lose the ability to detect an absence of Rx
termination specified in USB3 spec Table 6-21, fortunately, the
USB3 PHY can detect port link state change when USB3 device is
unplugged, so we can do soft disconnect according to the PLC.

Change-Id: I2cbd62fddc8a1f9c5a264d705db43fb0cf3e035c
Signed-off-by: William Wu <wulf@rock-chips.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>

According to xHCI spec v1.1 section 6.4.5 TRB Completion Codes,
the standard XHCI controller provide a TRB Completion Status
'USB Transaction Error' to asserted in the case where the host
did not receive a valid response from the device, it's useful
to handle pending URBs on the endpoint when the USB device is
plugged out.

Unfortunately, some SOCs USB 3.0 modules lose the ability to
assert the 'USB Transaction Error' status when USB 3.0 device
disconnect. This may cause the pending URBs unhandled, even
lead to USB class driver stalled in waiting for URBs complete.

This patch flush pending URBs in usb_disable_device() when
USB 3.0 device disconnect, it will call xhci_urb_dequeue()
-> xhci_queue_stop_endpoint() to cancel pending URBs and
giveback URB status immediately.

Change-Id: If8acac59bc1f2c10a41ee390ccbeb84b2e7743c1
Signed-off-by: Feng Mingli <fml@rock-chips.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>