ISP mmu can't support reset operation, it won't get the
expected result when reset, but rest functions work normally.
Add this patch as a WA for this issue.
Signed-off-by: Simon Xue <xxm@rock-chips.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
RK3368 vpu mmu have two irqs, this patch support multi irqs
Signed-off-by: Simon Xue <xxm@rock-chips.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
sa1100 provides its own variant of the clk API rather than using the
generic COMMON_CLK API. This generally works, but it causes some link
errors with drivers using the clk_set_rate, clk_get_parent, clk_set_parent
or clk_round_rate functions when a platform lacks those interfaces.
This adds trivial stub implementations for each of them, based on
the behavior of the COMMON_CLK implementation:
- set_rate() and set_parent() report success without doing anything
- round_rate() returns the clk rate
- get_parent() returns NULL.
This adds the minimal bloat and should do the right thing for
the simple clock hardware in this SoC.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
davinci still has its own clk implementation, but lacks
a clk_get_parent() helper, which can lead to link errors
in randconfig builds.
This adds the usual implementation.
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
In commit 3169663ac5 "ARM: sa11x0/pxa: convert OS timer registers
to IOMEM", the definition of the OSCR macro was changed to be an
__iomem pointer, but the same register is also used by the XIP
code. This patch does the corresponding change here as well.
On PXA, the IRQ register definitions were removed even earlier, in
commit 5d284e353e ("ARM: pxa: avoid accessing interrupt registers
directly"). This patch unfortunately brings some of that back. An
earlier version of my patch moved the code into an external function,
which could not work for CONFIG_XIP_KERNEL+CONFIG_MTD_XIP, so this
restores something close to the original code.
Link: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/241716.html
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A change to the platform data definitions caused a warning in the board code:
arch/arm/mach-davinci/board-da850-evm.c:1221:13: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
arch/arm/mach-davinci/board-da850-evm.c:1231:13: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
This is a bit unfortunate, since we generally like structure definitions to
be const, but as this is legacy code, the easiest way out is still to
remove the 'const' annotation here.
Fixes: 4a5f8ae50b ("[media] davinci: vpif_capture: get subdevs from DT when available")
Fixes: 231ce279e6 ("ARM: davinci: fix const warnings")
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The ZTE SoC drivers are only useful when building for a ZTE ZX platform.
Fixes: 4c2c2e3971 ("soc: zte: pm_domains: Prepare for supporting ARMv8 zx2967 family")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Baoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Due to a bugfix in wireless tree and the commit mentioned below a merge
was needed which went haywire. So the submitted change resulted in the
function brcmf_sdiod_sgtable_alloc() being called twice during the probe
thus leaking the memory of the first call.
Cc: stable@vger.kernel.org # 4.6.x
Fixes: 4d79289598 ("brcmfmac: switch to new platform data")
Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The commit to rework the headroom check in start_xmit() now calls
pxskb_expand_head() unconditionally if the header is CoW. Unfortunately,
it does so with the delta between the extant headroom and the header
length, which may be negative if there is already sufficient headroom.
pskb_expand_head() does allow for size being 0, in which case it just
copies, so clamp the header delta to zero.
Opening Chrome (and all my tabs) on a PCIE device was enough to reliably
hit this.
Fixes: 270a6c1f65 ("brcmfmac: rework headroom check in .start_xmit()")
Signed-off-by: Daniel Stone <daniels@collabora.com>
Cc: Arend Van Spriel <arend.vanspriel@broadcom.com>
Cc: James Hughes <james.hughes@raspberrypi.org>
Cc: Hante Meuleman <hante.meuleman@broadcom.com>
Cc: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Cc: Franky Lin <franky.lin@broadcom.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Drop the unused endpoints. They should only be used when there is an
actual remote-endpoint connected.
Cc: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Drop the unused endpoints. They should only be used when there is
an actual remote-endpoint connected.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Broadcom BCM53573 SoCs actually have 32 GPIOs, and not 16.
Fixes: 3f37ec79dd ("bcma: support BCM53573 series of wireless SoCs")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The current code kfree's entry and then dereferences it by accessing
entry->bssid. Avoid the dereference-after-free by moving the kfree
after the access to entry->bssid.
Detected by CoverityScan, CID#1448600 ("Read from pointer after free")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Pull "mvebu fixes for 4.13 (part 1)" from Gregory CLEMENT:
- Fix wrong irq type for gpio expeander on Armada 388 GP
- Use __pa_symbol instead of virt_to_phys in the mv98dx3236 platform
SMP code
* tag 'mvebu-fixes-4.13-1' of git://git.infradead.org/linux-mvebu:
ARM: dts: armada-38x: Fix irq type for pca955
ARM: mvebu: use __pa_symbol in the mv98dx3236 platform SMP code
Add necessary parent clocks for audss (Audio SubSystem, MAUDIO) clock
controller block.
This allows driver to keep EPLL enabled before accessing any MAUDIO
registers thus fixing silent hang. This silent hang appeared with
commit 6edfa11cb3 ("clk: samsung: Add enable/disable operation for
PLL36XX clocks"), e.g. on Odroid U3 usually with last (but unrelated)
messages:
[ 2.382741] input: gpio_keys as /devices/platform/gpio_keys/input/input0
[ 2.405686] usb 1-3: new high-speed USB device number 3 using exynos-ehci
[ 2.419843] max77686-rtc max77686-rtc: setting system clock to 2017-06-21 17:04:13 UTC (1498064653)
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Pull "Second Round of Renesas ARM Based SoC Fixes for v4.13" from Simon Horman:
Correct order of sound clock frequencies for ULCB boards
used by r8a7795 and r8a7796 SoCs.
These sounds clock frequencies are used as the ADG clock (output clocks
for audio module) initial setting and sound codec's initial system clock
which needs the maximum clock frequency. Thus, descending order is
required.
* tag 'renesas-fixes2-for-v4.13' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
arm64: dts: renesas: ulcb: sound clock-frequency needs descending order
Pull "Few fixes for omaps for issues found recently" from Tony Lindgren:
- Fix disable_irq related shared IRQ warnings for omap3 PRM
- Fix omap4 legacy code regression that accidentally removed code that
we still need for PRM interrupts
- Fix dm8168-evm NAND pins and MMC write protect pin direction
- Fix dra71-evm mdio impedance values
* tag 'omap-for-v4.13/fixes-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: dra71-evm: mdio: Fix impedance values
ARM: dts: dm816x: Correct the state of the write protect pin
ARM: dts: dm816x: Correct NAND support nodes
ARM: OMAP4: Fix legacy code clean-up regression
ARM: OMAP2+: Fix omap3 prm shared irq
Pull "Renesas ARM Based SoC Fixes for v4.13" from Simon Horman:
Correct order of sound clock frequencies for Salvator boards
used by r8a7795 and r8a7796 SoCs.
These sounds clock frequencies are used as the ADG clock (output clocks
for audio module) initial setting and sound codec's initial system clock
which needs the maximum clock frequency. Thus, descending order is
required.
* tag 'renesas-fixes-for-v4.13' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
arm64: renesas: salvator-common: sound clock-frequency needs descending order
mwifiex records information about various channels as it receives scan
information. It does this by appending to a buffer that was sized
to the max number of supported channels on any band, but there are
numerous problems:
(a) scans can return info from more than one band (e.g., both 2.4 and 5
GHz), so the determined "max" is not large enough
(b) some firmware appears to return multiple results for a given
channel, so the max *really* isn't large enough
(c) there is no bounds checking when stashing these stats, so problems
(a) and (b) can easily lead to buffer overflows
Let's patch this by setting a slightly-more-correct max (that accounts
for a combination of both 2.4G and 5G bands) and adding a bounds check
when writing to our statistics buffer.
Due to problem (b), we still might not properly report all known survey
information (e.g., with "iw <dev> survey dump"), since duplicate results
(or otherwise "larger than expected" results) will cause some
truncation. But that's a problem for a future bugfix.
(And because of this known deficiency, only log the excess at the WARN
level, since that isn't visible by default in this driver and would
otherwise be a bit too noisy.)
Fixes: bf35443314 ("mwifiex: channel statistics support for mwifiex")
Cc: <stable@vger.kernel.org>
Cc: Avinash Patil <patila@marvell.com>
Cc: Xinming Hu <huxm@marvell.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Turns out that just writing CURPOS isn't sufficient to move the cursor
on some platforms. My 830 works just fine, but eg. 945 and PNV don't.
On those platforms we need to arm even the CURPOS update with a
CURBASE write.
Even worse, a write to any of the cursor register apart from CURBASE
will cancel an already pending cursor update. So if we have armed a
CURCNTR/CURBASE update, a subsequent CURPOS write prior to vblank
would cancel that armed update. Thus we're left with a cursor that
doesn't appear to move, or even change shape.
Fix the problem by always performing the CURBASE write after a
CURPOS write. Bspec is somewhat unclear which platforms actually
require this CURBASE write and which don't. So to keep it simple
and to make sure we really fix the problem across all supported
devices, let's just perform the CURBASE write unconditionally.
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101790
Fixes: 75343a44c9 ("drm/i915: Drop useless posting reads from cursor commit")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20170714155227.6089-1-ville.syrjala@linux.intel.com
(cherry picked from commit 8753d2bc5e)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The hdmi bits simply don't exist, so nerf them. I think audio doesn't
work on gen3 at all, and for the limited color range we should
probably use the colorimetry sdvo paramater instead of the bit in the
port.
But fixing sdvo isn't my goal, I just want to get the backtrace out of
the way, and this takes care of that.
Still, while at it fix the missing read-out of the gen4 audio bit,
maybe that part even works ...
v2: Instead of trying to plug the damage in ->compute_config() make
sure we never set intel_sdvo->is_hdmi, which stops the bad state at
the source. Suggested by Chris Wilson. Also make sure we don't break
this by accident by putting a WARN_ON in place.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170726193251.25393-1-daniel.vetter@ffwll.ch
lockdep complaints about a locking recursion for the i2c bus lock
because both the sdvo ddc proxy bus and the gmbus nested within use
the same locking class. It's not really a deadlock since we never nest
the other way round, but it's annoying.
Fix it by pulling the gmbus locking into the i2c lock_ops for both
i2c_adapater and making sure that the ddc_proxy_xfer function is
entirely lockless.
Re-layouting the extracted function resulted in some whitespace
cleanups, I figured we might as well keep them.
v2: Review from Chris:
- s/locked/unlocked/ since I got the naming backwards
- Use the vfuncs of the proxied adatper instead of re-rolling copies.
That's more consistent with the other proxying we're doing.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170726132647.31833-1-daniel.vetter@ffwll.ch
Reduce acquisition of struct_mutex to the critical regions that must
hold it; for KMS, we need struct_mutex currently only for the purpose of
pinning/unpinning the framebuffer's VMA into the global GTT. This allows
us to avoid taking the struct_mutex when disabling the CRTC (i.e. NULL
framebuffer objects) before a reset. (Not yet achieving the full goal of
avoiding the strut_mutex nesting, but good enough to break the first
half of the reset deadlock.)
v2: Keep pages pinning inside struct_mutex for the moment.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170726160038.29487-1-chris@chris-wilson.co.uk
[danvet: Drop another case of grabbing dev->struct_mutex around
cleanup_planes, which popped up because I had to redo the drm-next
backmerge for entirely different reasons. Acked by Chris on irc.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When reading the i915_energy_uJ debugfs file, it tries to fetch
MSR_RAPL_POWER_UNIT, which might not be available, like in a vm
environment, causing the exception shown below.
We can easily prevent it by doing a rdmsrl_safe read instead, which will
handle the exception, allowing us to abort the debugfs file read.
This was caught by the new igt@debugfs_test@read_all_entries testcase in
the CI.
unchecked MSR access error: RDMSR from 0x606 at rIP:0xffffffffa0078f66
(i915_energy_uJ+0x36/0xb0 [i915])
Call Trace:
seq_read+0xdc/0x3a0
full_proxy_read+0x4f/0x70
__vfs_read+0x23/0x120
? putname+0x4f/0x60
? rcu_read_lock_sched_held+0x75/0x80
? entry_SYSCALL_64_fastpath+0x5/0xb1
vfs_read+0xa0/0x150
SyS_read+0x44/0xb0
entry_SYSCALL_64_fastpath+0x1c/0xb1
RIP: 0033:0x7f1f5e9f4500
RSP: 002b:00007ffc77e65cf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
RAX: ffffffffffffffda RBX: ffffffff8146e003 RCX: 00007f1f5e9f4500
RDX: 0000000000000200 RSI: 00007ffc77e65d10 RDI: 0000000000000006
RBP: ffffc900007abf88 R08: 0000000001eaff20 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000006 R14: 0000000000000005 R15: 0000000001eb94db
? __this_cpu_preempt_check+0x13/0x20
v2:
- Drop unsigned long long cast and improve calculation (Chris)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101901
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/87o9s7zrx3.fsf@dilma.collabora.co.uk
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The goal here was to minimise doing any thing or any check inside the
kernel that was not strictly required. For a userspace that assumes
complete control over the cache domains, the kernel is usually using
outdated information and may trigger clflushes where none were
required.
However, swapping is a situation where userspace has no knowledge of the
domain transfer, and will leave the object in the CPU cache. The kernel
must flush this out to the backing storage prior to use with the GPU. As
we use an asynchronous task tracked by an implicit fence for this, we
also need to cancel the ASYNC flag on the object so that the object will
wait for the clflush to complete before being executed. This also absolves
userspace of the responsibility imposed by commit 77ae995789 ("drm/i915:
Enable userspace to opt-out of implicit fencing") that its needed to ensure
that the object was out of the CPU cache prior to use on the GPU.
Fixes: 77ae995789 ("drm/i915: Enable userspace to opt-out of implicit fencing")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101571
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20170721145037.25105-5-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I was being overly paranoid in not updating the execobject.offset after
performing the fallback copy where we set reloc.presumed_offset to -1.
The thinking was to ensure that a subsequent NORELOC execbuf would be
forced to process the invalid relocations. However this is overkill so
long as we *only* update the execobject.offset following a successful
update of the relocation value witin the batch. If we have to repeat the
execbuf due to a later interruption, then we may skip the relocations on
the second pass (honouring NORELOC) since the execobject.offset match
the actual offsets (even though reloc.presumed_offset is garbage).
Subsequent calls to execbuf with NORELOC should themselves ensure that
the reloc.presumed_offset have been corrected in case of future
migration.
Reporting back the actual execobject.offset, even when
reloc.presumed_offset is garbage, ensures that reuse of those objects
use the latest information to avoid relocations.
Fixes: 2889caa923 ("drm/i915: Eliminate lots of iterations over the execobjects array")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101635
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170721145037.25105-4-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To support ycbcr output, we need a pipe CSC block to do
RGB->YCBCR conversion.
Current Intel platforms have only one pipe CSC unit, so
we can either do color correction using it, or we can perform
RGB->YCBCR conversion.
This function adds a csc handler, which uses recommended bspec
values to perform RGB->YCBCR conversion (target color space BT709)
V2: Rebase
V3: Rebase
V4: Rebase
V5: Addressed review comments from Ander
- Remove extra line added in the patch
- Add the spec details in the commit message
- Combine two if(cond) while calling intel_crtc_compute_config
V6: Handle YCBCR420 outputs only (Ville)
V7: Addressed review comments from Ville:
- Add description about target colorspace
- Remove the comments from CSC function
- DRM_DEBUG->DEBUG_KMS for atomic failure due to CSC unit busy
- Remove unnecessary debug message about YCBCR420 possibe
V8: Addressed review comments from Ville:
- Remove extra comment, not required.
- Do not add extra variable for CTM, reuse pipe_config
Added r-b from Ville
V9: Remove extra whitespace (Imre)
V10: Added r-b from Imre
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1500650709-14447-5-git-send-email-shashank.sharma@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in full
blend mode to use the scaler in 5x3 ratio (bits 26 and 27)
This patch:
- Adds definition of these bits.
- Programs PIPEMISC for YCBCR420 outputs.
- Adds readouts to compare HW and SW states.
V2: rebase
V3: rebase
V4: rebase
V5: added r-b from Ander
V6: Handle only YCBCR420 outputs (ville)
V7: rebase
V8: Addressed review comments from Ville
- Add readouts for state->ycbcr420 and 420 pixel_clock.
- Handle warning due to mismatch in clock for ycbcr420 clock.
- Rename PIPEMISC macros to match the Bspec.
- Add a debug print stating if YCBCR 4:2:0 output enabled.
Added r-b from Ville
V9: Addressed review comments from Imre:
- Add 420 mode clock adjustment in intel_hdmi_mode_valid to
prevent 420_only modes getting rejected for high clock.
- Add port clock adjustment for ycbcr420 modes in ddi_get_clock
- Rename macros as per Ville's suggestion.
- Remove unnecessary wl changes.
V10: Added r-b from Imre
V11: Fixed faulty dotclock handling, and addressed missing comment
from previous set of review comments (Imre)
V12: Fixed dotclock for 12bpc too, removed 420 check for GEN < 10
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1500904172-31717-1-git-send-email-shashank.sharma@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To get a YCBCR420 output from intel platforms, we need one
scaler to scale down YCBCR444 samples to YCBCR420 samples.
This patch:
- Does scaler allocation for HDMI ycbcr420 outputs.
- Programs PIPE_MISC register for ycbcr420 output.
V2: rebase
V3: rebase
V4: rebase
V5: addressed review comments from Ander:
- No need to check both scaler_user && hdmi_output.
Check for scaler_user is enough.
V6: rebase
V7: Do not create a new scaler user, use existing pipe scaler user.
V8: rebase
V9: Addressed review comments from Ville:
- Remove leftover comment for HDMI scaler user.
- Remove unnecessary blank line.
- Make scaler alocation failure a DEBUG log instead of ERROR.
Added r-b from Ville
V10: Update commit message as per latest code (Imre)
Added r-b from Imre
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Ander Conselvan De Oliveira <conselvan2@gmail.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1500650709-14447-3-git-send-email-shashank.sharma@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch checks encoder level support for YCBCR420 outputs.
The logic goes as simple as this:
If the input mode is YCBCR420-only mode: prepare HDMI for
YCBCR420 output, else continue with RGB output mode.
It checks if the mode is YCBCR420 and source can support this
output then it marks the ycbcr_420 output indicator into crtc
state, for further staging in driver.
V2: Split the patch into two, kept helper functions in DRM layer.
V3: Changed the compute_config function based on new DRM API.
V4: Rebase
V5: Rebase
V6: Check and handle YCBCR420-only modes, discard the property
based approach (Ville)
V7: Addressed review comments from Ville
- add else case in 12BPC check.
- extract ycbcr420 state inside hdmi_12bpc_possible function.
V8: Addressed review comments from Ville
- Remove extra blank lines.
- Remove "HDMI" from the description of ycbcr420 state variable.
- Remove local variable, use crtc_state->ycbcr420 instead.
Added r-b from Ville.
V9: Rebase
V10: Added r-b from Imre
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1500650709-14447-2-git-send-email-shashank.sharma@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
