Otherwise, clk_gpu won't be disabled actually in the runtime.
Change-Id: If1e32061cbffc1564a5cf95fbf01aa91c827550d
Signed-off-by: chenzhen <chenzhen@rock-chips.com>
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/)
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/)
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 260b316436)
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 cdb300a041)
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 0106ef5146)
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>
HardWare limited, the bottom layer not support per-pixel alpha,
Change-Id: I174da1d3d3cfff8d0b6cd6dfab4873438895e56d
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
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>
That is wrong use old crtc mode on atomic check.
Change-Id: Ie37bd842f8bafca04303d641269a84a6016457f4
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
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>
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 9e2c986cb4)
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 651e8b54ab)
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 db57d7460e)
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 4aff7b8546)
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 530cbe100e)
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 75aba7b0e9)
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 5d7ee87708)
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 57d7412395)
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 9e9caa6a49)
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 90381cba64)
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>
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>
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>
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>
