The other advantage of staging is the I don't think syzbot enables it.
I guess it's easier to persuade Dmitry to ignore STAGING than it was to
get him to disable FBDEV. :P
The memory corruption in fbdev was a real headache for everyone because
the stack traces ended up all over the kernel.
regar
On Wed, 26 Jan 2022, Lucas De Marchi wrote:
> Remove the trailing semicolon, as correctly warned by checkpatch:
>
> -:1189: WARNING:TRAILING_SEMICOLON: macros should not use a trailing
> semicolon
> #1189: FILE: drivers/gpu/drm/i915/intel_device_info.c:119:
> +#define PRINT_FLAG
On Wed, 26 Jan 2022, Lucas De Marchi wrote:
> Sort includes alphabetically so it's easier to add/remove includes and
> know when that is needed.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_gem.c | 20 ++--
> 1 file changed, 10 insert
The rk3568 HDMI has an additional clock that needs to be enabled for the
HDMI controller to work. The purpose of that clock is not clear. It is
named "hclk" in the downstream driver, so use the same name.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 18 ++
Add a device node to drm_encoder which corresponds with the port node
in the DT description of the encoder. This allows drivers to find the
of_graph link between a crtc and an encoder.
Signed-off-by: Sascha Hauer
---
include/drm/drm_encoder.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a
The driver returns an error when devm_phy_optional_get() fails leaving
the previously enabled clock turned on. Change order and enable the
clock only after the phy has been acquired.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 +++---
1 file changed,
Add a new dw_hdmi_plat_data struct and new compatible for rk3568.
Signed-off-by: Benjamin Gaignard
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 31 +
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
To fix that, this patch renames the vpll clock to ref clock. The clock
name "vpll" is left for compatibility to old
This is v4 of adding RK356x VOP2 support. Due to popular demand I added
a changelog to each patch, at least starting with changes to v3, I
didn't care to add the older changes as well. I hopefully integrated all
feedback I received to v3. Additionally I added some patches to the HDMI
driver to supp
The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs needed
for the HDMI port. add support for these to the driver for boards which
have them supplied by switchable regulators.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 41 +++--
1
On Wed, 26 Jan 2022, Lucas De Marchi wrote:
> linux/string_helpers.h provides a helper to return "yes"/"no" strings.
> Replace the open coded versions with str_yes_no(). The places were
> identified with the following semantic patch:
>
> @@
> expression b;
> @@
>
> - b ? "y
From: Douglas Anderson
Jitter was improved by lowering the MPLL bandwidth to account for high
frequency noise in the rk3288 PLL. In each case MPLL bandwidth was
lowered only enough to get us a comfortable margin. We believe that
lowering the bandwidth like this is safe given sufficient testing.
The driver checks if the pixel clock of the given mode matches an entry
in the mpll config table. The frequencies in the mpll table are meant as
a frequency range up to which the entry works, not as a frequency that
must match the pixel clock. The downstream Kernel also does not have
this check, so
With upcoming VOP2 support VOP won't be the only choice anymore, so make
the VOP driver optional.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/Kconfig| 8
drivers/gpu/drm/rockchip/Makefile | 3 ++-
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
3 f
None of the upstream device tree files has a "unwedge" pinctrl
specified. Make it optional.
Signed-off-by: Sascha Hauer
---
.../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/roc
This adds a few more PLL settings needed for some standard resolutions:
297MHz3840x2160-30.00
241.5MHz 2560x1440-59.95
135MHz1280x1024-75.02
119MHz1680x1050-59.88
108MHz1280x1024-60.02
78.75MHz 1024x768-75.03
Changes since v3:
- new patch
Signed-off-by: Sascha Hauer
---
drive
From: Andy Yan
The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
It replaces the VOP unit found in the older Rockchip SoCs.
This driver has been derived from the downstream Rockchip Kernel and
heavily modified:
- All nonstandard DRM properties have been removed
- dropped str
The VOP2 is the display output controller on the RK3568. Add the node
for it to the dtsi file along with the required display-subsystem node
and the iommu node.
changes since v3:
- Bring back gamma_lut regs
- Drop redundant _vop suffix from clock names
Signed-off-by: Sascha Hauer
---
arch/arm64
The binding specifies the clock order to "cec", "grf", "vpll". Reorder
the clocks accordingly.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64
Add support for the HDMI port found on RK3568.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 37 +++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
b/arch/arm64/boot/dts/rockchip/rk356x.dts
The pixel clocks dclk_vop[012] can be clocked from hpll, vpll, gpll or
cpll. gpll and cpll also drive many other clocks, so changing the
dclk_vop[012] clocks could change these other clocks as well. Drop
CLK_SET_RATE_PARENT to fix that. With this change the VOP2 driver can
only adjust the pixel clo
The reference clock for the HDMI controller has been renamed to 'ref',
the previous 'vpll' name is only left for compatibility in the driver.
Rename the clock to the new name.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 delet
The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566.
The binding differs slightly from the existing VOP binding, so add a new
binding file for it.
Changes since v3:
- drop redundant _vop suffix from clock names
Signed-off-by: Sascha Hauer
---
.../display/rockchip/rockchip-vop
The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs
needed for the HDMI port. Add the binding for these supplies.
Signed-off-by: Sascha Hauer
---
.../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 11 +++
1 file changed, 11 insertions(+)
diff --git
a/Documentation/de
"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
This patch adds "ref" as a new alternative clock name for "vpll"
Changes since v3:
- Keep old clock name for compat
This enabled the VOP2 display controller along with hdmi and the
required port routes which is enough to get a picture out of the
hdmi port of the board.
Changes since v3:
- Fix HDMI connector type
Signed-off-by: Sascha Hauer
---
.../boot/dts/rockchip/rk3568-evb1-v10.dts | 48 ++
From: Nickey Yang
add 594Mhz configuration parameters in rockchip_phy_config
Changes since v3:
- new patch
Change-Id: Iaa335cdd90059817fd9892877e574f8b84f2b5dc
Signed-off-by: Nickey Yang
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 +
1 file changed, 1 inse
On the rk3568 we have this (simplified) situation:
.. .-..-.
-| hpll |--.--| /n ||dclk_vop0|-
`´ | `-´`-´
| .-..-.
`--| /m ||dclk_vop1|-
| `-´`-´
From: Michael Riesch
Enable the RK356x Video Output Processor (VOP) 2 on the Pine64
Quartz64 Model A.
Changes since v3:
- Fix HDMI connector type
Signed-off-by: Michael Riesch
Signed-off-by: Sascha Hauer
---
.../boot/dts/rockchip/rk3566-quartz64-a.dts | 48 +++
1 file chang
From: Benjamin Gaignard
Define a new compatible for rk3568 HDMI.
This version of HDMI hardware block needs two new clocks hclk_vio and hclk
to provide phy reference clocks.
Signed-off-by: Benjamin Gaignard
Reviewed-by: Rob Herring
Link:
https://lore.kernel.org/r/20210707120323.401785-2-benjam
The rk3568 HDMI has an additional clock that needs to be enabled for the
HDMI controller to work. The purpose of that clock is not clear. It is
named "hclk" in the downstream driver, so use the same name.
Signed-off-by: Sascha Hauer
---
.../bindings/display/rockchip/rockchip,dw-hdmi.yaml
From: Douglas Anderson
The previous tables for mpll_cfg and curr_ctrl were created using the
20-pages of example settings provided by the PHY vendor. Those
example settings weren't particularly dense, so there were places
where we were guessing what the settings would be for 10-bit and
12-bit (n
Hi
Am 26.01.22 um 14:32 schrieb Andy Shevchenko:
On Wed, Jan 26, 2022 at 12:41:41PM +0100, Thomas Zimmermann wrote:
Am 26.01.22 um 11:59 schrieb Helge Deller:
...
It's always for the same reason: the hw is old and devs have moved on.
It's pity to have a working system with an old hardwar
Hi
> Gesendet: Mittwoch, 26. Januar 2022 um 15:55 Uhr
> Von: "Sascha Hauer"
> Betreff: [PATCH 01/27] drm/encoder: Add of_graph port to struct drm_encoder
Please use "git format-patch -vX ..." when creating your patches to make sure
the version is set in every patch and not only the coverletter.
Fix the following warning from "make htmldocs":
drivers/gpu/drm/drm_privacy_screen.c:270:
WARNING: Inline emphasis start-string without end-string.
Fixes: 8a12b170558a ("drm/privacy-screen: Add notifier support (v2)")
Reported-by: Stephen Rothwell
Signed-off-by: Hans de Goede
---
drivers/gpu/
Starting from DG2 we will have resizable BAR support for device local-memory,
but in some cases the final BAR size might still be smaller than the total
local-memory size. In such cases only part of local-memory will be CPU
accessible, while the remainder is only accessible via the GPU. This series
With small LMEM-BAR we need to be able to differentiate between the
total size of LMEM, and how much of it is CPU mappable. The end goal is
to be able to utilize the entire range, even if part of is it not CPU
accessible.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915
From: Arunpravin
Implemented a function which walk through the order list,
compares the offset and returns the maximum offset block,
this method is unpredictable in obtaining the high range
address blocks which depends on allocation and deallocation.
for instance, if driver requests address at a
From: Arunpravin
On contiguous allocation, we round up the size
to the *next* power of 2, implement a function
to free the unused pages after the newly allocate block.
v2(Matthew Auld):
- replace function name 'drm_buddy_free_unused_pages' with
drm_buddy_block_trim
- replace input argume
From: Arunpravin
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands
- Implemented a new function alloc_range() which allocates
the requested power-of-two block comply with range limitations
- Moved order computation and memory alignment logi
On devices with non-mappable LMEM ensure we always allocate the pages
within the mappable portion. For now we assume that all LMEM buffers
will require CPU access, which is also inline with pretty much all
current kernel internal users. In the next patch we will introduce a new
flag to override thi
If the user doesn't require CPU access for the buffer, then
ALLOC_TOPDOWN should be used, in order to prioritise allocating in the
non-mappable portion of LMEM.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 15 +++
drivers/gp
Differentiate between mappable vs non-mappable resources, also if this
is an actual range allocation ensure we set res->start as the starting
pfn. Later when we need to do non-mappable -> mappable moves then we
want TTM to see that the current placement is not compatible, which
should result in an
Otherwise we get -EINVAL, instead of the more useful -E2BIG if the
allocation doesn't fit within the pfn range, like with mappable lmem.
The hugepages selftest, for example, needs this to know if a smaller
size is needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915
Track the total amount of available visible memory, and also track
per-resource the amount of used visible memory. For now this is useful
for our debug output, and deciding if it is even worth calling into the
buddy allocator. In the future tracking the per-resource visible usage
will be useful for
For some reason we are selecting PRIO_HAS_PAGES when we don't have
mm.pages, and vice versa. Perhaps something else is going on here.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --
The end goal is to have userspace tell the kernel what buffers will
require CPU access, however if we ever reach the CPU fault handler, and
the current resource is not mappable, then we should attempt to migrate
the buffer to the mappable portion of LMEM, or even system memory, if the
allowable pla
Starting from DG2+, when dealing with LMEM, we assume that by default
all userspace allocations should be placed in the non-mappable portion
of LMEM. Note that dumb buffers are not included here, since these are
not "GPU accelerated" and likely need CPU access.
In a later patch userspace will be
If we need to make room for some some mappable object, then we should
only victimize objects that have one or pages that occupy the visible
portion of LMEM. Let's also create a new priority hint for objects that
are placed in mappable memory, where we know that CPU access was
requested, that way we
If we have to contend with non-mappable LMEM, then we need to ensure the
object fits within the mappable portion, like in the selftests, where we
later try to CPU access the pages. However if it can't then we need to
gracefully handle this, without throwing an error.
Also it looks like TTM will re
Exercise each of the migration scenarios, verifying that the final
placement and buffer contents match our expectations.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
.../drm/i915/gem/selftests/i915_gem_mman.c| 306 ++
1 file changed, 306 insertions(+)
diff --git a/d
Check that mappable vs non-mappable matches our expectations.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
.../drm/i915/selftests/intel_memory_region.c | 143 ++
1 file changed, 143 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
b/driv
If set, force the allocation to be placed in the mappable portion of
LMEM. One big restriction here is that system memory must be given as a
potential placement for the object, that way we can always spill the
object into system memory if we can't make space.
XXX: Still very much WIP and needs IGT
Just pass along the probed io_size. The backend should be able to
utilize the entire range here, even if some of it is non-mappable.
It does leave open with what to do with stolen local-memory.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 6
On platforms where there might be non-mappable LMEM, force userspace to
mark the buffers with the correct hint. When dumping the BO contents
during capture we need CPU access. Note this only applies to buffers
that can be placed in LMEM, and also doesn't impact DG1.
Signed-off-by: Matthew Auld
Cc
Just for CI.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 5 ++---
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_c
On Wed, Jan 26, 2022 at 04:02:23PM +0100, Thomas Zimmermann wrote:
> Am 26.01.22 um 14:32 schrieb Andy Shevchenko:
> > On Wed, Jan 26, 2022 at 12:41:41PM +0100, Thomas Zimmermann wrote:
> > > Am 26.01.22 um 11:59 schrieb Helge Deller:
> > > It's always for the same reason: the hw is old and devs h
Hi,
On Wed, Jan 26, 2022 at 6:58 AM Sascha Hauer wrote:
>
> From: Douglas Anderson
>
> Jitter was improved by lowering the MPLL bandwidth to account for high
> frequency noise in the rk3288 PLL. In each case MPLL bandwidth was
> lowered only enough to get us a comfortable margin. We believe th
On 1/25/22 20:35, Robert Beckett wrote:
From: Matthew Auld
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update
On 2022-01-26 07:07, Christian König wrote:
Am 25.01.22 um 23:37 schrieb Andrey Grodzovsky:
Defined a reset_domain struct such that
all the entities that go through reset
together will be serialized one against
another. Do it for both single device and
XGMI hive cases.
Signed-off-by: Andrey G
JingWen - could you maybe give those patches a try on SRIOV XGMI system
? If you see issues maybe you could let me connect and debug. My SRIOV
XGMI system which Shayun kindly arranged for me is not loading the
driver with my drm-misc-next branch even without my patches.
Andrey
On 2022-01-17 1
On Wed, Jan 26, 2022 at 2:47 PM Hans de Goede wrote:
>
> Hi All,
>
> On 1/23/22 10:10, Tong Zhang wrote:
> > when acpi=off is provided in bootarg, kernel crash with
> >
> > [1.252739] BUG: kernel NULL pointer dereference, address:
> > 0018
> > [1.258308] Call Trace:
> > [1
Hi,
On Wed, Jan 26, 2022 at 6:58 AM Sascha Hauer wrote:
>
> From: Douglas Anderson
>
> The previous tables for mpll_cfg and curr_ctrl were created using the
> 20-pages of example settings provided by the PHY vendor. Those
> example settings weren't particularly dense, so there were places
> whe
On 1/26/22 16:02, Thomas Zimmermann wrote:
> Hi
>
> Am 26.01.22 um 14:32 schrieb Andy Shevchenko:
>> On Wed, Jan 26, 2022 at 12:41:41PM +0100, Thomas Zimmermann wrote:
>>> Am 26.01.22 um 11:59 schrieb Helge Deller:
>>
>> ...
>>
>>
>>> It's always for the same reason: the hw is old and devs have mov
On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer wrote:
>
> Add support for the HDMI port found on RK3568.
>
> Signed-off-by: Sascha Hauer
> ---
> arch/arm64/boot/dts/rockchip/rk356x.dtsi | 37 +++-
> 1 file changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boo
Hi,
On Thu, Jan 20, 2022 at 8:26 AM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Jan 19, 2022 at 10:45 PM Grace Mi
> wrote:
> >
> > From: Yunlong Jia
> >
> > We have added corresponding information:
> > [BOE]NV116WHM-N45 use delay_200_500_e50
> > [KDB]116N29-30NK-C007 use delay_200_500_e80_
Hi,
On 1/26/22 16:54, Rafael J. Wysocki wrote:
> On Wed, Jan 26, 2022 at 2:47 PM Hans de Goede wrote:
>>
>> Hi All,
>>
>> On 1/23/22 10:10, Tong Zhang wrote:
>>> when acpi=off is provided in bootarg, kernel crash with
>>>
>>> [1.252739] BUG: kernel NULL pointer dereference, address:
>>>
Hi Sascha
tested full series on Bananapi r2 Pro V0 prototype (rk3568)
4K@60Hz
1080p@60Hz
both look good
Tested-By: Frank Wunderlich
regards Frank
On Wed, Jan 26, 2022 at 5:41 PM Hans de Goede wrote:
>
> Hi,
>
> On 1/26/22 16:54, Rafael J. Wysocki wrote:
> > On Wed, Jan 26, 2022 at 2:47 PM Hans de Goede wrote:
> >>
> >> Hi All,
> >>
> >> On 1/23/22 10:10, Tong Zhang wrote:
> >>> when acpi=off is provided in bootarg, kernel crash with
> >>>
On 26/01/2022 13:49, Thomas Hellström (Intel) wrote:
On 1/25/22 20:35, Robert Beckett wrote:
From: Ramalingam C
Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.
With this flag has_64k_pages will only in
On 26/01/2022 15:45, Thomas Hellström (Intel) wrote:
On 1/25/22 20:35, Robert Beckett wrote:
From: Matthew Auld
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm->min_alignment > 4K, depending
on the vm itself and the ty
On 26/01/2022 14:05, Thomas Hellström (Intel) wrote:
On 1/25/22 20:35, Robert Beckett wrote:
add test to check handling of misaligned offsets and sizes
v4:
* remove spurious blank lines
* explicitly cast intel_region_id to intel_memory_type in
misaligned_pin
Reported-by: kernel te
On Wed, 26 Jan 2022, Andy Shevchenko wrote:
> And basically create a MIPI based driver for I2C.
What does that even mean?
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
On 2022-01-26 16:04, Peter Geis wrote:
On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer wrote:
Add support for the HDMI port found on RK3568.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 37 +++-
1 file changed, 36 insertions(+), 1 deletion(-)
On Wed, 26 Jan 2022, Matthew Auld wrote:
> From: Arunpravin
>
> - Make drm_buddy_alloc a single function to handle
> range allocation and non-range allocation demands
>
> - Implemented a new function alloc_range() which allocates
> the requested power-of-two block comply with range limitation
On Tue, 25 Jan 2022, Lucas De Marchi wrote:
> Only x86 and in some cases PPC have support added in drm_cache.c for the
> clflush class of functions. However warning once is sufficient to taint
> the log instead of spamming it with "Architecture has no drm_cache.c
> support" every few millisecond.
On 26/01/2022 15:21, Matthew Auld wrote:
From: Arunpravin
Implemented a function which walk through the order list,
compares the offset and returns the maximum offset block,
this method is unpredictable in obtaining the high range
address blocks which depends on allocation and deallocation.
On Wed, Jan 26, 2022 at 12:56 PM Robin Murphy wrote:
>
> On 2022-01-26 16:04, Peter Geis wrote:
> > On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer wrote:
> >>
> >> Add support for the HDMI port found on RK3568.
> >>
> >> Signed-off-by: Sascha Hauer
> >> ---
> >> arch/arm64/boot/dts/rockchip/rk35
On 1/24/2022 07:01, Matthew Brost wrote:
Change the preemption timeout to the smallest possible value (1 us) when
disabling scheduling to cancel a request and restore it after
cancellation. This not only cancels the request as fast as possible, it
fixes a bug where the preemption timeout is 0 whi
On 1/24/2022 07:01, Matthew Brost wrote:
More than 1 request can be submitted to a single ELSP at a time if
multiple requests are ready run to on the same context. When a request
is canceled it is marked bad, an idle pulse is triggered to the engine
(high priority kernel request), the execlists s
On 2022-01-26 18:44, Peter Geis wrote:
On Wed, Jan 26, 2022 at 12:56 PM Robin Murphy wrote:
On 2022-01-26 16:04, Peter Geis wrote:
On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer wrote:
Add support for the HDMI port found on RK3568.
Signed-off-by: Sascha Hauer
---
arch/arm64/boot/dts/roc
to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Matthew-Auld/Initial-support-for-small-BAR-recovery/20220126-232640
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-a002-202201
On Wed, Jan 26, 2022 at 2:25 PM Robin Murphy wrote:
>
> On 2022-01-26 18:44, Peter Geis wrote:
> > On Wed, Jan 26, 2022 at 12:56 PM Robin Murphy wrote:
> >>
> >> On 2022-01-26 16:04, Peter Geis wrote:
> >>> On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer
> >>> wrote:
>
> Add support for
to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Matthew-Auld/Initial-support-for-small-BAR-recovery/20220126-232640
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-a013-202201
On Wed, Jan 26, 2022 at 08:24:54PM +0200, Jani Nikula wrote:
On Tue, 25 Jan 2022, Lucas De Marchi wrote:
Only x86 and in some cases PPC have support added in drm_cache.c for the
clflush class of functions. However warning once is sufficient to taint
the log instead of spamming it with "Architec
On Wed, Jan 26, 2022 at 11:03:24AM -0800, John Harrison wrote:
> On 1/24/2022 07:01, Matthew Brost wrote:
> > More than 1 request can be submitted to a single ELSP at a time if
> > multiple requests are ready run to on the same context. When a request
> > is canceled it is marked bad, an idle pulse
On Wed, Jan 26, 2022 at 10:58:46AM -0800, John Harrison wrote:
> On 1/24/2022 07:01, Matthew Brost wrote:
> > Change the preemption timeout to the smallest possible value (1 us) when
> > disabling scheduling to cancel a request and restore it after
> > cancellation. This not only cancels the reques
The hdmi-cec clock must be 32khz in order for cec to work correctly.
Ensure after enabling the clock we set it in order for the hardware to
work as expected.
Warn on failure, in case this is a static clock that is slighty off.
Fixes hdmi-cec support on Rockchip devices.
Fixes: ebe32c3e282a ("drm/b
The rcar-du driver goes to great lengths to preserve device tree
backward compatibility for the LVDS encoders by patching old device
trees at runtime.
The last R-Car Gen2 platform was converted to the new bindings commit
edb0c3affe5214a2 ("ARM: dts: r8a7793: Convert to new LVDS DT bindings"),
in v
On Wed, Jan 26, 2022 at 5:25 PM Peter Geis wrote:
> +
> + ret = clk_set_rate(hdmi->cec_clk, HDMI_CEC_CLK_RATE);
> + if (ret)
> + dev_warn(hdmi->dev, "Cannot set HDMI cec clock rate:
> %d\n", ret);
You are setting the cec clock rate after it has
While porting i915 to arm64 we noticed some issues accessing lmem.
Some writes were getting corrupted and the final state of the buffer
didn't have exactly what we wrote. This became evident when enabling
GuC submission: depending on the number of engines the ADS struct was
being corrupted and GuC
Add a variant of shmem_read() that takes a dma_buf_map pointer rather
than a plain pointer as argument. It's mostly a copy __shmem_rw() but
adapting the api and removing the write support since there's currently
only need to use dma_buf_map as destination.
Reworking __shmem_rw() to share the imple
In certain situations it's useful to be able to read or write to an
offset that is calculated by having the memory layout given by a struct
declaration. Usually we are going to read/write a u8, u16, u32 or u64.
Add a pair of macros dma_buf_map_read_field()/dma_buf_map_write_field()
to calculate th
Add helpers on top of dma_buf_map_read_field() /
dma_buf_map_write_field() functions so they always use the right
arguments and make code easier to read.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas
Use dma_buf_map_memset() to zero the private data as ADS may be either
on system or IO memory.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
Now the map is saved during creation, so use it to initialize the
golden context, reading from shmem and writing to either system or IO
memory.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
Use dma_buf_map to write the fields ads.capture_*.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 10 +-
1 file changed, 5 insertion
Use dma_buf_map to write the policies update so access to IO and system
memory is abstracted away.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ad
Use dma_buf_map to write the fields system_info.mapping_table[][].
Since we already have the info_map around where needed, just use it
instead of going through guc->ads_map.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
S
Convert intel_guc_ads_create() and initialization to use dma_buf_map
rather than plain pointer and save it in the guc struct. This will help
with additional updates to the ads_blob after the
creation/initialization by abstracting the IO vs system memory.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: D
101 - 200 of 271 matches
Mail list logo
