| Age | Commit message (Collapse) | Author |
|---|
|
This patch adds support for FIMD variant found on S5PV210 SoC.
Except CLKSEL bit availability, it is identical to Exynos4210.
Tested-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
Use new return type vm_fault_t for fault handler
in struct vm_operations_struct.
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into exynos-drm-next
Fixup pagefault issue of mixer driver
- it makes sure to check shadow register for interlace scan.
- it corrects chroma_addr[1], height and vertical position values.
And trivial cleanup
- it just removes duplicated drm_bridge_attach.
|
|
drm_bridge_attach takes care of these assignments, so there is no need
to open-code them a second time.
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
CI noticed
<4>[ 23.430701] ============================================
<4>[ 23.430706] WARNING: possible recursive locking detected
<4>[ 23.430713] 4.17.0-rc4-CI-CI_DRM_4156+ #1 Not tainted
<4>[ 23.430720] --------------------------------------------
<4>[ 23.430725] systemd-udevd/169 is trying to acquire lock:
<4>[ 23.430732] (ptrval) (&(&timeline->lock)->rlock){....}, at: move_to_timeline+0x48/0x12c [i915]
<4>[ 23.430888]
but task is already holding lock:
<4>[ 23.430894] (ptrval) (&(&timeline->lock)->rlock){....}, at: i915_request_submit+0x1a/0x40 [i915]
<4>[ 23.430995]
other info that might help us debug this:
<4>[ 23.431002] Possible unsafe locking scenario:
<4>[ 23.431007] CPU0
<4>[ 23.431010] ----
<4>[ 23.431013] lock(&(&timeline->lock)->rlock);
<4>[ 23.431021] lock(&(&timeline->lock)->rlock);
<4>[ 23.431028]
*** DEADLOCK ***
<4>[ 23.431036] May be due to missing lock nesting notation
<4>[ 23.431044] 5 locks held by systemd-udevd/169:
<4>[ 23.431049] #0: (ptrval) (&dev->mutex){....}, at: __driver_attach+0x42/0xe0
<4>[ 23.431065] #1: (ptrval) (&dev->mutex){....}, at: __driver_attach+0x50/0xe0
<4>[ 23.431078] #2: (ptrval) (&dev->struct_mutex){+.+.}, at: i915_gem_init+0xca/0x630 [i915]
<4>[ 23.431174] #3: (ptrval) (rcu_read_lock){....}, at: submit_notify+0x35/0x124 [i915]
<4>[ 23.431271] #4: (ptrval) (&(&timeline->lock)->rlock){....}, at: i915_request_submit+0x1a/0x40 [i915]
<4>[ 23.431369]
stack backtrace:
<4>[ 23.431377] CPU: 0 PID: 169 Comm: systemd-udevd Not tainted 4.17.0-rc4-CI-CI_DRM_4156+ #1
<4>[ 23.431385] Hardware name: Dell Inc. OptiPlex GX280 /0G8310, BIOS A04 02/09/2005
<4>[ 23.431394] Call Trace:
<4>[ 23.431403] dump_stack+0x67/0x9b
<4>[ 23.431411] __lock_acquire+0xc67/0x1b50
<4>[ 23.431421] ? ring_buffer_lock_reserve+0x154/0x3f0
<4>[ 23.431429] ? lock_acquire+0xa6/0x210
<4>[ 23.431435] lock_acquire+0xa6/0x210
<4>[ 23.431530] ? move_to_timeline+0x48/0x12c [i915]
<4>[ 23.431540] _raw_spin_lock+0x2a/0x40
<4>[ 23.431634] ? move_to_timeline+0x48/0x12c [i915]
<4>[ 23.431730] move_to_timeline+0x48/0x12c [i915]
<4>[ 23.431826] __i915_request_submit+0xfa/0x280 [i915]
<4>[ 23.431923] i915_request_submit+0x25/0x40 [i915]
<4>[ 23.432024] i9xx_submit_request+0x11/0x140 [i915]
<4>[ 23.432120] submit_notify+0x8d/0x124 [i915]
<4>[ 23.432202] __i915_sw_fence_complete+0x81/0x250 [i915]
<4>[ 23.432300] __i915_request_add+0x31c/0x7c0 [i915]
<4>[ 23.432395] i915_gem_init+0x621/0x630 [i915]
<4>[ 23.432476] i915_driver_load+0xbee/0x10b0 [i915]
<4>[ 23.432485] ? trace_hardirqs_on_caller+0xe0/0x1b0
<4>[ 23.432566] i915_pci_probe+0x29/0x90 [i915]
<4>[ 23.432574] pci_device_probe+0xa1/0x130
<4>[ 23.432582] driver_probe_device+0x306/0x480
<4>[ 23.432589] __driver_attach+0xb7/0xe0
<4>[ 23.432596] ? driver_probe_device+0x480/0x480
<4>[ 23.432602] ? driver_probe_device+0x480/0x480
<4>[ 23.432609] bus_for_each_dev+0x74/0xc0
<4>[ 23.432616] bus_add_driver+0x15f/0x250
<4>[ 23.432623] ? 0xffffffffa02d7000
<4>[ 23.432629] driver_register+0x52/0xc0
<4>[ 23.432635] ? 0xffffffffa02d7000
<4>[ 23.432642] do_one_initcall+0x58/0x370
<4>[ 23.432653] ? do_init_module+0x1d/0x1ea
<4>[ 23.432660] ? rcu_read_lock_sched_held+0x6f/0x80
<4>[ 23.432667] ? kmem_cache_alloc_trace+0x282/0x2e0
<4>[ 23.432675] do_init_module+0x56/0x1ea
<4>[ 23.432682] load_module+0x2435/0x2b20
<4>[ 23.432694] ? __se_sys_finit_module+0xd3/0xf0
<4>[ 23.432701] __se_sys_finit_module+0xd3/0xf0
<4>[ 23.432710] do_syscall_64+0x55/0x190
<4>[ 23.432717] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 23.432724] RIP: 0033:0x7fa780782839
<4>[ 23.432729] RSP: 002b:00007ffcea73e668 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
<4>[ 23.432738] RAX: ffffffffffffffda RBX: 0000561a472a4b30 RCX: 00007fa780782839
<4>[ 23.432745] RDX: 0000000000000000 RSI: 00007fa7804610e5 RDI: 000000000000000e
<4>[ 23.432752] RBP: 00007fa7804610e5 R08: 0000000000000000 R09: 00007ffcea73e780
<4>[ 23.432758] R10: 000000000000000e R11: 0000000000000246 R12: 0000000000000000
<4>[ 23.432765] R13: 0000561a47296450 R14: 0000000000020000 R15: 0000561a472a4b30
but did not report it as an issue as it only occurred during the first
module on boot. This is due to the removal of the distinct global
timeline, and its separate lock class. So instead mark up the expected
nesting. An alternative would be to define a separate lock class for the
engine, but since we only expect to have a single point of nesting, we
can avoid having multiple lock classes for the struct.
Fixes: a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual timelines")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Tested-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508153514.20251-1-chris@chris-wilson.co.uk
|
|
The i915_flip* tracepoints are no longer in use since the removal of CS
flip in commit 8b5d27b911d7 ("drm/i915: Remove intel_flip_work
infrastructure")
References: 8b5d27b911d7 ("drm/i915: Remove intel_flip_work infrastructure")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508151552.31024-1-chris@chris-wilson.co.uk
|
|
DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address 0000eh.
With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
To avoid breaking panels that are not spec compiant we now warn on
invalid values.
V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.
V4: style changes
V5: typo
V6: print statement revisions, DP_REV to DPCD_REV, comment correction
V7: typo
V8: Style
V9: Strip out DPCD_REV_XX into seperate patch
v10: DPCD_REV_XX to DP_DPCD_REV_XX
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180504221800.17830-2-matthew.s.atwood@intel.com
|
|
As more differentation occurs between DP spec. Its useful to have these
as macros in a drm_dp_helper.
v2: DPCD_REV_XX to DP_DPCD_REV_XX
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180504221800.17830-1-matthew.s.atwood@intel.com
|
|
During request submission, we call the engine->schedule() function so
that we may reorder the active requests as required for inheriting the
new request's priority. This may schedule several tasklets to run on the
local CPU, but we will need to schedule the tasklets again for the new
request. Delay all the local tasklets until the end, so that we only
have to process the queue just once.
v2: Beware PREEMPT_RCU, as then local_bh_disable() is then not a
superset of rcu_read_lock().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180507135731.10587-2-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
When called from process context tasklet_schedule() defers itself to
ksoftirqd. From experience this may cause unacceptable latencies of over
200ms in executing the submission tasklet, our goal is to reprioritise
the HW execution queue and trigger HW preemption immediately, so disable
bh over the call to schedule and force the tasklet to run afterwards if
scheduled.
v2: Keep rcu_read_lock() around for PREEMPT_RCU
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180507135731.10587-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
As we flush each test and wait for idle before the next, also switch
back to the kernel context. This helps limit the amount of collateral
damage a test may cause by resetting to the default state each time (and
also helps clean up temporaries used by the test).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508115312.12628-1-chris@chris-wilson.co.uk
|
|
Add some onion to populate_lr_context.
v2: prefer err_unpin_ctx
drop the fixes tag, worst case we just spew a warn before everything
is cleaned up and balance is restored
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180301114639.510-1-matthew.auld@intel.com
|
|
igt_ctx_exec() expects that we retire all active requests/objects before
completing, so that when we clean up the files afterwards they are ready
to be freed. Before we do so, it is then prudent to ensure that we have
indeed retired the GPU activity, raising an error if it fails. If we do
not, we run the risk of triggering an assertion when freeing the object:
__i915_gem_free_objects:4793 GEM_BUG_ON(i915_gem_object_is_active(obj))
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180505091014.26126-2-chris@chris-wilson.co.uk
|
|
Pull igt_flush_test() out into its own library before copying and
pasting the code for a third time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180505091014.26126-1-chris@chris-wilson.co.uk
|
|
Operating on a zero sized GEM userptr object will lead to explosions.
Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl")
Testcase: igt/gem_userptr_blits/input-checking
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180502195021.30900-1-matthew.auld@intel.com
|
|
If the loop times out then we want to exit with "to" set to zero, but in
the current code it's set to -1.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508092829.GC661@mwanda
|
|
The xen_drm_front_shbuf_alloc() function was returning a mix of error
pointers and NULL and the the caller wasn't checking correctly. I've
changed it to always return error pointer consistently.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508092739.GB661@mwanda
|
|
drm_dev_alloc() returns error pointers, it never returns NULL.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508092650.GA661@mwanda
|
|
When rescheduling a change of dependencies, they all need to be added to
the same priolist (at least the ones on the same engine!). Since we
likely want to move a batch of requests, keep the priolist around.
v2: Throw in an assert to catch trivial errors quickly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508003046.2633-2-chris@chris-wilson.co.uk
|
|
lookup_priolist() no longer attaches the request into the priolist, it
just returns the priolist for the given priority instead. Drop the
unused parameter.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508003046.2633-1-chris@chris-wilson.co.uk
|
|
Unsafe module parameters are just that, unsafe. If the user is foolish
enough to try them and the kernel breaks, they get to keep both pieces.
Don't ask them to file a bug report if they broke it themselves.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106423
Fixes: d15d7538c6d2 ("drm/i915: Tune down init error message due to failure injection")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180506183147.2690-1-chris@chris-wilson.co.uk
|
|
This implements the "MG PLL Programming" sequence from our spec. The
biggest problem was that the spec assumes real numbers, so we had to
adjust some numbers and calculations due to the fact that the Kernel
prefers to deal with integers.
I recommend grabbing some coffee, a pen and paper before reviewing
this patch.
v2:
- Correctly identify DP encoders after upstream change.
- Small checkpatch issues.
- Rebase.
v3:
- Try to impove the comment on the tdc_targetcnt calculation based on
Manasi's feedback (Manasi).
- Rebase.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180328215803.13835-7-paulo.r.zanoni@intel.com
|
|
Just use the hardcoded tables provided by our spec.
v2: Rebase.
v3: Clarify that 38.4 uses the 19.2 table (James).
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180328215803.13835-6-paulo.r.zanoni@intel.com
|
|
HDMI mode DPLL programming on ICL is the same as CNL, so just reuse
the CNL code.
v2:
- Properly detect HDMI crtcs.
- Rebase after changes to the cnl function (clock * 1000).
v3:
- Add a comment to clarify why we treat 38.4 as 19.2 (James).
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180328215803.13835-5-paulo.r.zanoni@intel.com
|
|
This commit introduces the definitions for the ICL clocks and adds the
basic functions to the shared DPLL framework. It adds code for the
Enable and Disable sequences for some PLLs, but it does not have the
code to compute the actual PLL values, which are marked as TODO
comments and should be introduced as separate commits.
Special thanks to James Ausmus for investigating and fixing a bug with
the placement of icl_unmap_plls_to_ports() function.
v2:
- Rebase around dpll_lock changes.
v3:
- The spec now says what the timeouts should be.
- Touch DPCLKA_CFGCR0_ICL at the appropriate time so we don't freeze
the machine.
- Checkpatch found a white space problem.
- Small adjustments before upstreaming.
v4:
- Move the ICL checks out of the *map_plls_to_ports() functions
(James)
- Add extra encoder check (James)
- Call icl_unmap_plls_to_ports() later (James)
v5:
- Rebase after the pll struct changes.
v6:
- Properly make the unmap function based on encoders_post_disable()
with regarding to checks and iterators.
- Address checkpatch comment on "min = max = x()".
Cc: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180427231436.9353-1-paulo.r.zanoni@intel.com
|
|
Add documentation to gen9_set_dc_state() on what enabling a given DC
state means and at what point HW/DMC actually enters/exits these states.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180417113147.25120-1-imre.deak@intel.com
|
|
The sync_debug.h header is internal, and only used by
sw_sync.c. Therefore, SW_SYNC is always defined and there
is no need for the stubs. Remove them and make the code
simpler.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180504180037.10661-1-ezequiel@collabora.com
|
|
We have to check dma-buf reservation objects of our framebuffers before
we use them. Otherwise, another driver might be writing on the same
buffer which we are using. This would cause visible tearing effects
on display.
We can use existing atomic helper functions to solve this problem.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
|
The R8A77965 (M3-N) SoC provides RGB, HDMI and LVDS output.
This platform is unusual in that the RGB is connected to DU3 leaving DU2
unpopulated. This is reflected by the channels_mask accordingly.
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
|
The group objects assume linear indexing, and more so always assume that
channel 0 of any active group is used.
Now that the CRTC objects support non-linear indexing, adapt the groups
to remove assumptions that channel 0 is utilised in each group by using
the channel mask provided in the device structures.
Finally ensure that the RGB routing is determined from the index of the
CRTC object (which represents the hardware DU channel index).
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
|
The DU CRTC driver does not support distinguishing between a hardware
index, and a software (CRTC) index in the event that a DU channel might
not be populated by the hardware.
Support this by adapting the rcar_du_device_info structure to store a
bitmask of available channels rather than a count of CRTCs. The count
can then be obtained by determining the hamming weight of the bitmask.
This allows the rcar_du_crtc_create() function to distinguish between
both index types, and non-populated DU channels will be skipped without
leaving a gap in the software CRTC indexes.
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
|
The M3-N HDMI TX controller is compatible with the M3-W and H3. No
extension to the DT bindings are needed.
Add an SoC-specific compatible string in case differences between the IP
versions are found later and require model-specific handling.
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
|
The naming of the fields for the ODPM signals in the DU extensional
function control register 6 (DEFR6) is incorrect against the data sheets
for both R-Car Gen2 and R-Car Gen3.
Rename the fields to match the datasheet.
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
|
Document the M3-N (r8a77965) SoC in the R-Car DU bindings.
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
|
The DU output table lists the port combinations for each supported DU
type. Newer models of R-Car Gen3 platforms have an increased string
length.
Increase the table indentation in preparation for supporting new target
types.
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
|
Replace the initialisation of the vsps table with a NULL specifier.
Fixes the following warning:
linux/drivers/gpu/drm/rcar-du/rcar_du_kms.c:483:40:
warning: Using plain integer as NULL pointer
CC drivers/gpu/drm/rcar-du/rcar_du_kms.o
Fixes: 3e81374e2014 ("drm: rcar-du: Support multiple sources from the same VSP")
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Vaishali Thakkar <vthakkar@vaishalithakkar.in>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
|
The symbol 'rcar_du_of_init' is defined by the rcar_du_of module header,
but it is not included by the C implementation.
Include the header to correctly define the function prototypes.
Fixes the following warning:
linux/drivers/gpu/drm/rcar-du/rcar_du_of.c:319:13:
warning: symbol 'rcar_du_of_init' was not declared. Should it be static?
CC drivers/gpu/drm/rcar-du/rcar_du_of.o
Fixes: 81c0e3dd8292 ("drm: rcar-du: Fix legacy DT to create LVDS encoder nodes")
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Vaishali Thakkar <vthakkar@vaishalithakkar.in>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
|
Ignore the tests looking at the innards of execlists and its submission
tasklets on machines that don't support execlists!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180504124202.24894-1-chris@chris-wilson.co.uk
|
|
Fix `[drm:intel_enable_lvds] *ERROR* timed out waiting for panel to
power on` in kernel log at boot time.
Toshiba Satellite Z930 laptops needs between 1 and 2 seconds to power
on its screen during Intel i915 DRM initialization. This currently
results in a `[drm:intel_enable_lvds] *ERROR* timed out waiting for
panel to power on` message appearing in the kernel log during boot
time and when stopping the machine.
This change increases the timeout of the `intel_enable_lvds` function
from 1 to 5 seconds, letting enough time for the Satellite 930 LCD
screen to power on, and suppressing the error message from the kernel
log.
This patch has been successfully tested on Linux 4.14 running on a
Toshiba Satellite Z930.
[vsyrjala: bump the timeout from 2 to 5 seconds to match the DP
code and properly cover the max hw timeout of ~4 seconds, and
drop the comment about the specific machine since this is not
a particulary surprising issue, nor specific to that one machine]
Signed-off-by: Florent Flament <contact@florentflament.com>
Cc: stable@vger.kernel.org
Cc: Pavel Petrovic <ppetrovic@acm.org>
Cc: Sérgio M. Basto <sergio@serjux.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103414
References: https://bugzilla.kernel.org/show_bug.cgi?id=57591
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180419160700.19828-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
It is useful to see the priority as requests are coming in and completed
status as requests are coming out of the GPU.
To achieve this in a more readable way we need to abandon the common
request_hw tracepoint class.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180504115643.22437-1-tvrtko.ursulin@linux.intel.com
|
|
"An outstanding request must still be on an active ring somewhere" is
only true if we haven't just been interrupted by the shrinker in the
middle of allocating the request itself. (At the start of
i915_request_alloc() we pin the context and prepare the GT for activity,
marking it as active, and then try to allocate the request. If this
allocation invokes the shrinker, we try to reclaim some space by calling
i915_retire_requests() which may then be confused by the pre-reservation
of active_requests.)
<3>[ 125.472695] i915_retire_requests:1429 GEM_BUG_ON(list_empty(&i915->gt.active_rings))
<2>[ 125.472792] kernel BUG at drivers/gpu/drm/i915/i915_request.c:1429!
<4>[ 125.472822] invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
<4>[ 125.498764] Modules linked in: snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel btusb btrtl btbcm btintel cdc_ether snd_hda_codec_realtek bluetooth i915 snd_hda_codec_generic usbnet r8152 mii ecdh_generic lpc_ich mei_me snd_hda_intel snd_hda_codec mei snd_hwdep snd_hda_core snd_pcm prime_numbers
<4>[ 125.498923] CPU: 0 PID: 1115 Comm: gem_exec_create Tainted: G U 4.17.0-rc3-gc49cbe0d1eb8-kasan_32+ #1
<4>[ 125.498955] Hardware name: GOOGLE Peppy/Peppy, BIOS MrChromebox 02/04/2018
<4>[ 125.499074] RIP: 0010:i915_retire_requests+0x3f2/0x590 [i915]
<4>[ 125.499095] RSP: 0018:ffff88004e5dec40 EFLAGS: 00010282
<4>[ 125.499117] RAX: 0000000000000010 RBX: ffff8800458f0000 RCX: 0000000000000000
<4>[ 125.499140] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff880060c2f6f0
<4>[ 125.499164] RBP: ffff88004e5dee30 R08: ffffed000c185ee6 R09: ffffed000c185ee6
<4>[ 125.499187] R10: 0000000000000001 R11: ffffed000c185ee5 R12: ffff8800553da160
<4>[ 125.499210] R13: dffffc0000000000 R14: 0000000000000000 R15: ffff8800458faed0
<4>[ 125.499235] FS: 00007fe18f052980(0000) GS:ffff880065400000(0000) knlGS:0000000000000000
<4>[ 125.499262] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[ 125.499282] CR2: 00007f01df11efb8 CR3: 00000000518d4001 CR4: 00000000000606f0
<4>[ 125.499304] Call Trace:
<4>[ 125.499417] i915_gem_shrink+0x576/0xb50 [i915]
<4>[ 125.499532] ? i915_gem_shrinker_count+0x2f0/0x2f0 [i915]
<4>[ 125.499561] ? trace_hardirqs_on_thunk+0x1a/0x1c
<4>[ 125.499671] ? i915_gem_shrinker_count+0x1d6/0x2f0 [i915]
<4>[ 125.499782] ? i915_gem_shrinker_scan+0xc4/0x320 [i915]
<4>[ 125.499889] i915_gem_shrinker_scan+0xc4/0x320 [i915]
<4>[ 125.499997] ? i915_gem_shrinker_vmap+0x3a0/0x3a0 [i915]
<4>[ 125.500021] ? do_raw_spin_unlock+0x4f/0x240
<4>[ 125.500042] ? _raw_spin_unlock+0x29/0x40
<4>[ 125.500149] ? i915_gem_shrinker_count+0x1d6/0x2f0 [i915]
<4>[ 125.500177] shrink_slab.part.18+0x23e/0x8f0
<4>[ 125.500202] ? unregister_shrinker+0x1f0/0x1f0
<4>[ 125.500226] ? mem_cgroup_iter+0x379/0xcc0
<4>[ 125.500249] shrink_node+0xa7e/0x1180
<4>[ 125.500276] ? shrink_node_memcg+0x11f0/0x11f0
<4>[ 125.500297] ? __delayacct_freepages_start+0x38/0x80
<4>[ 125.500319] ? __is_insn_slot_addr+0xe3/0x1a0
<4>[ 125.500342] ? recalibrate_cpu_khz+0x10/0x10
<4>[ 125.500361] ? ktime_get+0xb2/0x140
<4>[ 125.500382] do_try_to_free_pages+0x2d3/0xe40
<4>[ 125.500407] ? allow_direct_reclaim.part.23+0x1e0/0x1e0
<4>[ 125.500429] ? shrink_node+0x1180/0x1180
<4>[ 125.500450] ? __read_once_size_nocheck.constprop.4+0x10/0x10
<4>[ 125.500476] try_to_free_pages+0x1af/0x560
<4>[ 125.500497] ? do_try_to_free_pages+0xe40/0xe40
<4>[ 125.500525] __alloc_pages_nodemask+0xadc/0x2130
<4>[ 125.500553] ? gfp_pfmemalloc_allowed+0x150/0x150
<4>[ 125.500654] ? i915_gem_do_execbuffer+0x219d/0x32e0 [i915]
<4>[ 125.500678] ? debug_check_no_locks_freed+0x2a0/0x2a0
<4>[ 125.500701] ? __debug_object_init+0x322/0xd90
<4>[ 125.500722] ? debug_check_no_locks_freed+0x2a0/0x2a0
<4>[ 125.500827] ? i915_gem_do_execbuffer+0xdc2/0x32e0 [i915]
<4>[ 125.500942] ? i915_request_alloc+0x5b5/0x13f0 [i915]
<4>[ 125.500964] ? page_frag_free+0x170/0x170
<4>[ 125.500984] ? debug_check_no_locks_freed+0x2a0/0x2a0
<4>[ 125.501008] new_slab+0x21d/0x5c0
<4>[ 125.501029] ___slab_alloc.constprop.35+0x322/0x3e0
<4>[ 125.501052] ? reservation_object_reserve_shared+0x10b/0x250
<4>[ 125.501074] ? __ww_mutex_lock.constprop.3+0x1104/0x2cf0
<4>[ 125.501097] ? _raw_spin_unlock_irqrestore+0x39/0x60
<4>[ 125.501120] ? fs_reclaim_acquire+0x10/0x10
<4>[ 125.501138] ? lock_acquire+0x138/0x3c0
<4>[ 125.501156] ? lock_acquire+0x3c0/0x3c0
<4>[ 125.501176] ? reservation_object_reserve_shared+0x10b/0x250
<4>[ 125.501198] ? __slab_alloc.isra.27.constprop.34+0x3d/0x70
<4>[ 125.501219] __slab_alloc.isra.27.constprop.34+0x3d/0x70
<4>[ 125.501243] ? reservation_object_reserve_shared+0x10b/0x250
<4>[ 125.501265] __kmalloc_track_caller+0x313/0x350
<4>[ 125.501287] krealloc+0x62/0xb0
<4>[ 125.501305] reservation_object_reserve_shared+0x10b/0x250
<4>[ 125.501411] i915_gem_do_execbuffer+0x2040/0x32e0 [i915]
<4>[ 125.501522] ? eb_relocate_slow+0xad0/0xad0 [i915]
<4>[ 125.501544] ? debug_check_no_locks_freed+0x2a0/0x2a0
<4>[ 125.501646] ? i915_gem_execbuffer2_ioctl+0x108/0x770 [i915]
<4>[ 125.501755] ? i915_gem_execbuffer2_ioctl+0x108/0x770 [i915]
<4>[ 125.501779] ? drm_dev_get+0x20/0x20
<4>[ 125.501803] ? __might_fault+0xea/0x1a0
<4>[ 125.501902] ? i915_gem_execbuffer2_ioctl+0x108/0x770 [i915]
<4>[ 125.502012] ? i915_gem_execbuffer_ioctl+0xb90/0xb90 [i915]
<4>[ 125.502116] ? i915_gem_execbuffer_ioctl+0xb90/0xb90 [i915]
<4>[ 125.502218] i915_gem_execbuffer2_ioctl+0x3c5/0x770 [i915]
<4>[ 125.502243] ? drm_dev_enter+0xe0/0xe0
<4>[ 125.502260] ? lock_acquire+0x138/0x3c0
<4>[ 125.502362] ? i915_gem_execbuffer_ioctl+0xb90/0xb90 [i915]
<4>[ 125.502470] ? i915_gem_object_create.part.28+0x570/0x570 [i915]
<4>[ 125.502575] ? i915_gem_execbuffer_ioctl+0xb90/0xb90 [i915]
<4>[ 125.502680] ? i915_gem_execbuffer_ioctl+0xb90/0xb90 [i915]
<4>[ 125.502702] drm_ioctl_kernel+0x151/0x200
<4>[ 125.502721] ? drm_ioctl_permit+0x2a0/0x2a0
<4>[ 125.502746] drm_ioctl+0x63a/0x920
<4>[ 125.502844] ? i915_gem_execbuffer_ioctl+0xb90/0xb90 [i915]
<4>[ 125.502868] ? drm_getstats+0x20/0x20
<4>[ 125.502886] ? trace_hardirqs_on_thunk+0x1a/0x1c
<4>[ 125.502919] do_vfs_ioctl+0x173/0xe90
<4>[ 125.502936] ? trace_hardirqs_on_thunk+0x1a/0x1c
<4>[ 125.502957] ? ioctl_preallocate+0x170/0x170
<4>[ 125.502978] ? trace_hardirqs_on_thunk+0x1a/0x1c
<4>[ 125.503002] ? retint_kernel+0x2d/0x2d
<4>[ 125.503024] ksys_ioctl+0x35/0x60
<4>[ 125.503043] __x64_sys_ioctl+0x6a/0xb0
<4>[ 125.503061] do_syscall_64+0x97/0x400
<4>[ 125.503081] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 125.503101] RIP: 0033:0x7fe18e4f65d7
<4>[ 125.503116] RSP: 002b:00007ffe2ffc06a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
<4>[ 125.503145] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe18e4f65d7
<4>[ 125.503168] RDX: 00007ffe2ffc07f0 RSI: 0000000040406469 RDI: 0000000000000003
<4>[ 125.503191] RBP: 00007ffe2ffc07f0 R08: 0000000000000004 R09: 00007ffe2ffcf080
<4>[ 125.503215] R10: 000000000002c7de R11: 0000000000000246 R12: 0000000040406469
<4>[ 125.503238] R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
<4>[ 125.503268] Code: e8 18 a0 c9 da 48 8b 35 25 3a 47 00 49 c7 c0 a0 3b 88 c0 b9 95 05 00 00 48 c7 c2 e0 49 88 c0 48 c7 c7 8d 3b 5d c0 e8 ee 7e db da <0f> 0b 48 89 ef e8 a4 26 f5 da e9 51 fe ff ff e8 8a 26 f5 da e9
<1>[ 125.503548] RIP: i915_retire_requests+0x3f2/0x590 [i915] RSP: ffff88004e5dec40
Fixes: 643b450a594e ("drm/i915: Only track live rings for retiring")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180504101147.26286-1-chris@chris-wilson.co.uk
|
|
Following commit f773568b6ff8 ("drm/i915: nuke the duplicated stolen
discovery"), the if-else-chain for determining the GTT size is redundant
with the !chv branches all being the same.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
References: f773568b6ff8 ("drm/i915: nuke the duplicated stolen discovery")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180503212956.3948-1-chris@chris-wilson.co.uk
|
|
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180503112217.37292-6-maarten.lankhorst@linux.intel.com
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
We want to add more DRM selftests, and there's not much point in
having a Kconfig option for every single one of them, so make
a generic one.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180503112217.37292-5-maarten.lankhorst@linux.intel.com
[mlankhorst: Fix i915/Kconfig.debug (ickle)]
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
With the previous patch drm_atomic_helper_check_plane_state correctly
calculates clipping and the xf86-video-intel ddx is fixed to fall back
to GPU correctly when SetPlane fails, we can remove the hack where
we try to pan/zoom when out of min/max scaling range. This was already
poor behavior where the screen didn't show what was requested, and now
instead we reject it outright. This simplifies check_sprite_plane a lot.
Changes since v1:
- Set crtc_h to the height correctly.
- Reject < 3x3 rectangles instead of making them invisible for <gen9.
For gen9+ skl_update_scaler_plane will reject them.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180503112217.37292-4-maarten.lankhorst@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
|
|
Instead of relying on a scale which may increase rounding errors,
clip src by doing: src * (dst - clip) / dst and rounding the result
away from 1, so the new coordinates get closer to 1. We won't need
to fix up with a magic macro afterwards, because our scaling factor
will never go to the other side of 1.
Changes since v1:
- Adjust dst immediately, else drm_rect_width/height on dst gives bogus
results.
Change since v2:
- Get rid of macros and use 64-bits math.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
[mlankhorst: Add Villes comment, and rename newsrc to tmp. (Ville)]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180503112217.37292-3-maarten.lankhorst@linux.intel.com
|
|
When calculating limits we want to be as pessimistic as possible,
so we have to explicitly say whether we want to round up or down
to accurately calculate whether we are below min_scale or above
max_scale.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
[mlankhorst: Fix wording in documentation. (Ville)]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180503112217.37292-2-maarten.lankhorst@linux.intel.com
|
|
The new helper returns index of the matching string in an array.
We are going to use it here.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180503181706.22120-1-andriy.shevchenko@linux.intel.com
|
|
Limit the arbitration (where preemption may occur) to inside the batch,
and prevent it from happening on the pipecontrols/flushes we use to
write the breadcrumb seqno. Once the user batch is complete, we have
nothing left to do but serialise and emit the breadcrumb; switching
contexts at this point is futile so don't.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180503195416.22498-1-chris@chris-wilson.co.uk
|
|
Don't pre-emptively retire the oldest request in our ring's list if it
is the only request. We keep various bits of state alive using the
active reference from the request and would rather transfer that state
over to a new request rather than the more involved process of retiring
and reacquiring it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180503195115.22309-2-chris@chris-wilson.co.uk
|
