Hi Maxime Ripard,
Thanks for the feedback.
> -Original Message-
> From: Maxime Ripard
> Sent: Thursday, November 16, 2023 5:58 PM
> Subject: Re: [PATCH v14 4/4] MAINTAINERS: Create entry for Renesas RZ DRM
> drivers
>
> Hi,
>
> On Thu, Nov 16, 2023 at 05:04:03PM +0100, Geert
Hi Ilpo,
Apologies for the long delay.
On 10/18/2023 2:30 PM, Ilpo Järvinen wrote:
> On Wed, 18 Oct 2023, Shyam Sundar S K wrote:
>
>> PMF driver sends constant inputs to TA which its gets via the other
>> subsystems in the kernel. To debug certain TA issues knowing what inputs
>> being sent to
Hello Alexander,
On Fri, Nov 17, 2023 at 08:33:16AM +0100, Alexander Stein wrote:
> Use dev_err_probe to simplify error paths. Also Let dev_err_probe handle
s/Let/let/
> the -EPROBE_DEFER case and also add an entry to
I'd s/also //
> /sys/kernel/debug/devices_deferred when deferred.
>
>
Use dev_err_probe to simplify error paths. Also Let dev_err_probe handle
the -EPROBE_DEFER case and also add an entry to
/sys/kernel/debug/devices_deferred when deferred.
Signed-off-by: Alexander Stein
---
Changes in v2:
* Use dev_err_probe in more places in probe function (as suggested by Uwe)
Hi Sebastian:
On 11/16/23 21:47, Sebastian Reichel wrote:
Hi,
On Thu, Nov 16, 2023 at 06:39:40PM +0800, Andy Yan wrote:
vop2->sys_grf = syscon_regmap_lookup_by_phandle(dev->of_node,
"rockchip,grf");
This already lacks an error check, shame on me...
+ vop2->vop_grf =
No functional modification involved.
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dpms.c:2461
link_set_dpms_on() warn: if statement not indented.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7579
Signed-off-by: Jiapeng Chong
---
Hi Dave, Sima,
Fixes for 6.7.
The following changes since commit b85ea95d086471afb4ad062012a4d73cd328fa86:
Linux 6.7-rc1 (2023-11-12 16:19:07 -0800)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.7-2023-11-17
for you to fetch
Hi,
On 2023/11/16 23:23, Dmitry Baryshkov wrote:
Then you will need some way (fwnode?) to
discover the bridge chain. And at the last point you will get into the
device data and/or properties business.
No, leave that chance to a more better programmer and forgive me please,
too difficult, I'm
drm_{err,warn,...}() use __drm_printk() which takes a drm device pointer and
uses the embedded device pointer to print the device. This facility handles
NULL device pointer, but not NULL drm device pointer. This patch makes
__drm_printk() also handle a NULL drm device pointer. The printed output
On 2023-11-16 04:22, Maxime Ripard wrote:
> Hi,
>
> On Mon, Nov 13, 2023 at 09:56:32PM -0500, Luben Tuikov wrote:
>> On 2023-11-13 21:45, Stephen Rothwell wrote:
>>> Hi Luben,
>>>
>>> On Mon, 13 Nov 2023 20:32:40 -0500 Luben Tuikov wrote:
On 2023-11-13 20:08, Luben Tuikov wrote:
>
The refresh reported by modetest is 60.46Hz, and the actual measurement
is 60.01Hz, which is outside the expected tolerance. Adjust hporch and
pixel clock to fix it. After repair, modetest and actual measurement were
all 60.01Hz.
Modetest refresh = Pixel CLK/ htotal* vtotal, but measurement frame
On 2023-11-15 03:24, Jani Nikula wrote:
> On Tue, 14 Nov 2023, Luben Tuikov wrote:
>> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
>> index a93a387f8a1a15..ce784118e4f762 100644
>> --- a/include/drm/drm_print.h
>> +++ b/include/drm/drm_print.h
>> @@ -453,7 +453,7 @@ void
On 2023-11-13 07:38, Christian König wrote:
> Start to improve the scheduler document. Especially document the
> lifetime of each of the objects as well as the restrictions around
> DMA-fence handling and userspace compatibility.
Thanks Christian for doing this--much needed.
>
> Signed-off-by:
On Thu, 2023-11-16 at 15:20 -0800, Teres Alexis, Alan Previn wrote:
> For Gen12 when using mei-pxp tee backend tranport, if we are coming
> up from a cold boot or from a resume (not runtime resume), we can
> optionally quicken the very first session cleanup that would occur
> as part of starting
Currently enabling CONFIG_TINYDRM_ILI9163 driver - regardless of the device
tree - results in the below confusing log line:
SPI driver ili9163 has no spi_device_id for newhaven,1.8-128160EF
This commit fixes this false alarm by adding "1.8-128160EF" to
spi_device_id table of ili9163 driver.
drm/ili9163: Add "1.8-128160EF" to spi_device_id table
Currently enabling CONFIG_TINYDRM_ILI9163 driver - regardless of the device
tree - results in the below confusing log line:
SPI driver ili9163 has no spi_device_id for newhaven,1.8-128160EF
This commit fixes this false alarm by adding
For Gen12 when using mei-pxp tee backend tranport, if we are coming
up from a cold boot or from a resume (not runtime resume), we can
optionally quicken the very first session cleanup that would occur
as part of starting up a default PXP session. Typically a cleanup
from a cold-start is expected
Hi Christian,
Thanks for sending an update of this patch!
On Thu, Nov 16, 2023 at 03:15:46PM +0100, Christian König wrote:
> Start to improve the scheduler document. Especially document the
> lifetime of each of the objects as well as the restrictions around
> DMA-fence handling and userspace
On 11/16/2023 11:57 AM, Melissa Wen wrote:
DRM_OBJECT_MAX_PROPERTY limits the number of properties to be attached
and we are increasing that value all time we add a new property (generic
or driver-specific).
In this series, we are adding 13 new KMS driver-specific properties for
AMD color
On 11/12/23 14:43, Hans de Goede wrote:
Owen, Kai-Heng thank you for testing. I've submitted these patches
to Rafael (the ACPI maintainer) now (with you on the Cc).
Hopefully they will get merged soon.
That's great, thanks!
Owen
On Thu, 16 Nov 2023 at 00:58, Abhinav Kumar wrote:
>
>
>
> On 11/15/2023 2:44 PM, Rob Clark wrote:
> > From: Rob Clark
> >
> > The dpu devcore's are already associated with the dpu device. So we
> > should associate the gpu devcore's with the gpu device, for easier
> > classification.
> >
> >
On Thu, 16 Nov 2023 at 20:29, Sui Jingfeng wrote:
>
> Hi,
>
>
> On 2023/11/16 21:00, Dmitry Baryshkov wrote:
> > On Thu, 16 Nov 2023 at 14:18, Sui Jingfeng wrote:
> >> Hi,
> >>
> >>
> >> On 2023/11/15 00:06, Dmitry Baryshkov wrote:
> >>> On Tue, 14 Nov 2023 at 17:09, Sui Jingfeng wrote:
>
On 2023-11-07 11:58, Felix Kuehling wrote:
Create GEM handles for exporting DMABufs using GEM-Prime APIs. The GEM
handles are created in a drm_client_dev context to avoid exposing them
in user mode contexts through a DMABuf import.
This patch (and the next one) won't apply upstream because
On 11/16/2023 7:17 AM, Chris Morgan wrote:
On Wed, Nov 15, 2023 at 01:38:11PM -0800, Jessica Zhang wrote:
On 11/15/2023 7:26 AM, Chris Morgan wrote:
From: Chris Morgan
For devices like the Anbernic RG351M and RG351P the panel is wired to
an always on regulator. When the device suspends
On 10/9/23 10:58, Neil Armstrong wrote:
On 09/10/2023 00:33, Marek Vasut wrote:
Add missing .bus_flags = DRM_BUS_FLAG_DE_HIGH to this panel description,
ones which match both the datasheet and the panel display_timing flags .
Fixes: 1e29b840af9f ("drm/panel: simple: Add Innolux G101ICE-L01
On 10/9/23 11:01, Neil Armstrong wrote:
Hi,
On 09/10/2023 00:32, Marek Vasut wrote:
The Innolux G101ICE-L01 datasheet [1] page 17 table
6.1 INPUT SIGNAL TIMING SPECIFICATIONS
indicates that maximum vertical blanking time is 40 lines.
Currently the driver uses 29 lines.
Fix it, and since this
On 11/1/2023 12:23 PM, Abhinav Kumar wrote:
On 10/13/2023 1:25 AM, Dan Carpenter wrote:
This NULL check was required when it was added, but we shuffled the code
around and now it's not. The inconsistent NULL checking triggers a
Smatch warning:
Checking `args` after calling `op_map_prepare` is unnecessary since
if `op_map_prepare` was to be called with NULL args, it would lead
to a NULL pointer dereference, thus never hitting that check.
Hence this check can be removed, and a note added to remind users of
this function to ensure that
On 11/16/2023 12:36 PM, Abhinav Kumar wrote:
On 11/9/2023 4:02 PM, Jonathan Marek wrote:
Use the same value as the downstream driver. This change is needed for
CPHY
mode to work correctly.
Fixes: 8b034e6771113 ("drm/msm/dsi: add support for DSI-PHY on SM8550")
One error here. We need
On 11/9/2023 4:02 PM, Jonathan Marek wrote:
Use the same value as the downstream driver. This change is needed for CPHY
mode to work correctly.
Fixes: 8b034e6771113 ("drm/msm/dsi: add support for DSI-PHY on SM8550")
Signed-off-by: Jonathan Marek
---
v2: fixed the Fixes: line
On 16/11/2023 01:17, Chris Morgan wrote:
> From: Chris Morgan
>
> Add support for the Powkiddy RK2023. The Powkiddy RK2023 is a handheld
> gaming device with a 3.5 inch screen powered by the Rockchip RK3566
> SoC. The device looks physically different from the Powkiddy RGB30,
> but is
On 16/11/2023 01:17, Chris Morgan wrote:
> From: Chris Morgan
>
> Update the NewVision NV3051D compatible strings by adding a new panel,
> the powkiddy,rk2023-panel, and removing another entry, the
> anbernic,rg353v-panel.
>
> The rk2023-panel is similar to the rg353p-panel but has slightly
>
On Fri, Nov 10, 2023 at 12:23 PM André Almeida wrote:
>
> Document what each amdgpu driver reset method does.
>
> Signed-off-by: André Almeida
Applied with Randy's suggestion. Thanks!
Alex
> ---
> v2: Add more details and small correction (Alex)
>
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 25
Plane CTM for pre-blending color space conversion. Only enable
driver-specific plane CTM property on drivers that support both pre- and
post-blending gamut remap matrix, i.e., DCN3+ family. Otherwise it
conflits with DRM CRTC CTM property.
Reviewed-by: Harry Wentland
Signed-off-by: Melissa Wen
Map the plane CTM driver-specific property to DC plane, instead of DC
stream. The remaining steps to program DPP block are already implemented
on DC shared-code.
v3:
- fix comment about plane and CRTC CTMs priorities (Harry)
Reviewed-by: Harry Wentland
Signed-off-by: Melissa Wen
---
From: Joshua Ashton
Create drm_color_ctm_3x4 to support 3x4-dimension plane CTM matrix and
convert DRM CTM to DC CSC float matrix.
v3:
- rename ctm2 to ctm_3x4 (Harry)
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 28
From: Joshua Ashton
Map plane blend properties to DPP blend gamma. Plane blend is a
post-3D LUT curve that linearizes color space for blending. It may be
defined by a user-blob LUT and/or predefined transfer function. As
hardcoded curve (ROM) is not supported on blend gamma, we use AMD color
From: Joshua Ashton
When commiting planes, we copy color mgmt resources to the stream state.
Do the same for shaper and 3D LUTs.
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
---
From: Joshua Ashton
Need to funnel the color caps through to these functions so it can check
that the hardware is capable.
v2:
- remove redundant color caps assignment on plane degamma map (Harry)
- pass color caps to degamma params
v3:
- remove unused color_caps parameter from
Map DC shaper LUT to DM plane color management. Shaper LUT can be used
to delinearize and/or normalize the color space for computational
efficiency and achiving specific visual styles. If a plane degamma is
apply to linearize the color space, a custom shaper 1D LUT can be used
just before applying
Wire up DC 3D LUT to DM plane color management (pre-blending). On AMD
display HW, 3D LUT comes after a shaper curve and we always have to
program a shaper curve to delinearize or normalize the color space
before applying a 3D LUT (since we have a reduced number of LUT
entries).
In this version,
From: Joshua Ashton
Unlike degamma, blend gamma doesn't support hardcoded curve
(predefined/ROM), but we can use AMD color module to fill blend gamma
parameters when we have non-linear plane gamma TF without plane gamma
LUT. The regular degamma path doesn't hit this.
Reviewed-by: Harry Wentland
From: Joshua Ashton
With `dc_fixpt_from_s3132()` translation, we can just use it to set
hdr_mult.
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
We will wire up MPC 3D LUT to DM CRTC color pipeline in the next patch,
but so far, only for atomic interface. By checking
set_output_transfer_func in DC drivers with MPC 3D LUT support, we can
verify that regamma is only programmed when 3D LUT programming fails. As
a groundwork to introduce 3D
Enable usage of predefined transfer func in addition to shaper 1D LUT.
That means we can save some complexity by just setting a predefined
curve, instead of programming a custom curve when preparing color space
for applying 3D LUT.
Reviewed-by: Harry Wentland
Signed-off-by: Melissa Wen
---
From: Joshua Ashton
Set DC plane with user degamma LUT or predefined TF from driver-specific
plane color properties. If plane and CRTC degamma are set in the same
time, plane degamma has priority. That means, we only set CRTC degamma
if we don't have plane degamma LUT or TF to configure. We
From: Joshua Ashton
We should reset a plane state if at least one of the color management
properties differs from old and new state.
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
---
The next patch adds pre-blending degamma to AMD color mgmt pipeline, but
pre-blending degamma caps (DPP) is currently in use to provide DRM CRTC
atomic degamma or implict degamma on legacy gamma. Detach degamma usage
regarging CRTC color properties to manage plane and CRTC color
correction
From: Joshua Ashton
Add predefined transfer function programming. There is no post-blending
out gamma ROM for hardcoded curves, but we can use AMD color modules to
program LUT parameters from pre-defined coefficients and an empty
regamma LUT (or bump up LUT parameters with pre-defined TF
From: Joshua Ashton
Otherwise this is just initialized to 0. This needs to actually have a
value so that compute_curve can work for PQ EOTF.
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
---
From: Joshua Ashton
Detach value translation from CTM to reuse it for programming HDR
multiplier property.
Reviewed-by: Harry Wentland
Signed-off-by: Joshua Ashton
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 8 +---
Add 3D LUT property for plane color transformations using a 3D lookup
table. 3D LUT allows for highly accurate and complex color
transformations and is suitable to adjust the balance between color
channels. It's also more complex to manage and require more
computational resources.
Since a 3D LUT
DC only has pre-blending degamma caps (plane/DPP) that is currently in
use for CRTC/post-blending degamma, so that we don't have HW caps to
perform plane and CRTC degamma at the same time. Reject atomic updates
when serspace sets both plane and CRTC degamma properties.
Reviewed-by: Harry Wentland
Describe some expected behavior of the AMD DM color mgmt programming.
Reviewed-by: Harry Wentland
Signed-off-by: Melissa Wen
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git
From: Joshua Ashton
Multiplier to 'gain' the plane. When PQ is decoded using the fixed func
transfer function to the internal FP16 fb, 1.0 -> 80 nits (on AMD at
least) When sRGB is decoded, 1.0 -> 1.0. Therefore, 1.0 multiplier = 80
nits for SDR content. So if you want, 203 nits for SDR
Brief documentation about pre-defined transfer function usage on AMD
display driver and standardized EOTFs and inverse EOTFs.
v3:
- Document BT709 OETF (Pekka)
- Fix description of sRGB and pure power funcs (Pekka)
v4:
- Add description of linear and non-linear forms (Harry)
Reviewed-by: Harry
Add AMD pre-defined transfer function property to default DRM CRTC gamma
to convert to wire encoding with or without a user gamma LUT. There is
no post-blending regamma ROM for pre-defined TF. When setting Gamma TF
(!= Identity) and LUT at the same time, the color module will combine
the
On AMD HW, 3D LUT always assumes a preceding shaper 1D LUT used for
delinearizing and/or normalizing the color space before applying a 3D
LUT. Add pre-defined transfer function to enable delinearizing content
with or without shaper LUT, where AMD color module calculates the
resulted shaper curve.
Instead of relying on color block names to get the transfer function
intention regarding encoding pixel's luminance, define supported
Electro-Optical Transfer Functions (EOTFs) and inverse EOTFs, that
includes pure gamma or standardized transfer functions.
v3:
- squash linear and unity TFs to
From: Joshua Ashton
Blend 1D LUT or a pre-defined transfer function (TF) can be set to
linearize content before blending, so that it's positioned just before
blending planes in the AMD color mgmt pipeline, and after 3D LUT
(non-linear space). Shaper and Blend LUTs are 1D LUTs that sandwich 3D
From: Joshua Ashton
Allow userspace to tell the kernel driver the input space and,
therefore, uses correct predefined transfer function (TF) to go from
encoded values to linear values.
v2:
- rename TF enum prefix from DRM_ to AMDGPU_ (Harry)
- remove HLG TF
Reviewed-by: Harry Wentland
We will add color mgmt properties to DRM planes in the next patches and
we want to track when one of this properties change to define atomic
commit behaviors. Using a similar approach from CRTC color props, we set
a color_mgmt_changed boolean whenever a plane color prop changes.
Reviewed-by:
Hook up driver-specific atomic operations for managing AMD color
properties. Create AMD driver-specific color management properties
and attach them according to HW capabilities defined by `struct
dc_color_caps`.
First add plane degamma LUT properties that means user-blob and its
size. We will add
Place it in drm_property where drm_property_replace_blob and
drm_property_lookup_blob live. Then we can use the DRM helper for
driver-specific KMS properties too.
Reviewed-by: Harry Wentland
Reviewed-by: Liviu Dudau
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/arm/malidp_crtc.c | 2 +-
Hello,
This series extends the current KMS color management API with AMD
driver-specific properties to enhance the color management support on
AMD Steam Deck. The key additions to the color pipeline include:
- plane degamma LUT and pre-defined TF;
- plane HDR multiplier;
- plane CTM 3x4;
- plane
DRM_OBJECT_MAX_PROPERTY limits the number of properties to be attached
and we are increasing that value all time we add a new property (generic
or driver-specific).
In this series, we are adding 13 new KMS driver-specific properties for
AMD color manage:
- CRTC Gamma enumerated Transfer Function
On Thu, 2023-11-16 at 20:45 +0100, Danilo Krummrich wrote:
> As I already mentioned for Timur's patch [2], I'd prefer to get a fix
> upstream
> (meaning [1] in this case). Of course, that's probably more up to Timur to
> tell
> if this will work out.
Don't count on it.
Even if I did change [0]
Hi Gustavo,
On Thu, Nov 16, 2023 at 12:11:43PM -0600, Gustavo A. R. Silva wrote:
> Fake flexible arrays (zero-length and one-element arrays) are deprecated,
> and should be replaced by flexible-array members. So, replace
> zero-length array with a flexible-array member in `struct
>
On Tue, Nov 14, 2023 at 07:28:55PM +0800, Andy Yan wrote:
> From: Andy Yan
>
> VOP2 on rk3588:
>
> Four video ports:
> VP0 Max 4096x2160
> VP1 Max 4096x2160
> VP2 Max 4096x2160
> VP3 Max 2048x1080
>
> 4 4K Cluster windows with AFBC/line RGB and AFBC-only YUV support
> 4 4K Esmart windows with
On Tue, 14 Nov 2023 19:28:20 +0800, Andy Yan wrote:
> From: Andy Yan
>
> Add VOP and VO GRF syscon compatibles for RK3588
>
> Signed-off-by: Andy Yan
> ---
>
> Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Rob Herring
On Mon, Nov 13, 2023 at 12:50 PM Harry Wentland wrote:
>
> Please just use "drm/amd/display:" as tag in the commit subject.
>
> With that fixed, this is
> Acked-by: Harry Wentland
>
Acked-by: Alex Deucher
Feel free to take this via the i2c tree if you prefer.
Alex
> Harry
>
> On 2023-11-13
On Mon, Nov 13, 2023 at 3:55 PM Wolfram Sang wrote:
>
>
> > We're not in a hurry. It's just my experience with patch series' affecting
> > multiple subsystems that typically the decision was to apply the full
> > series via one tree. Also to avoid inquires from maintainers like:
> > Shall I take
On Mon, Nov 13, 2023 at 6:24 AM Heiner Kallweit wrote:
>
> After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
> olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
> Class-based device auto-detection is a legacy mechanism and shouldn't
> be used in new code.
On Mon, Nov 13, 2023 at 6:37 AM Heiner Kallweit wrote:
>
> I2C_CLASS_SPD was used to expose the EEPROM content to user space,
> via the legacy eeprom driver. Now that this driver has been removed,
> we can remove I2C_CLASS_SPD support. at24 driver with explicit
> instantiation should be used
On Mon, Nov 13, 2023 at 6:24 AM Heiner Kallweit wrote:
>
> After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in
> olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC.
> Class-based device auto-detection is a legacy mechanism and shouldn't
> be used in new code.
strlcpy() reads the entire source buffer first. This read may exceed
the destination size limit. This is both inefficient and can lead
to linear read overflows if a source string is not NUL-terminated[1].
Additionally, it returns the size of the source string, not the
resulting size of the
On Thu, 2023-11-16 at 12:11 -0600, Gustavo A. R. Silva wrote:
typedef struct PACKED_REGISTRY_TABLE
{
-NvU32 size;
-NvU32 numEntries;
-PACKED_REGISTRY_ENTRY entries[0];
+ NvU32 size;
+ NvU32
On Wed, Nov 15, 2023 at 1:14 PM Mikhail Gavrilov
wrote:
>
> On Wed, Nov 8, 2023 at 4:24 AM Mikhail Gavrilov
> wrote:
> >
> > Tested-by: Mikhail Gavrilov
> > Thanks, after applying the patch GPU loading meets expectations.
> > Games are working so overall all looking good for now.
> >
>
>
On 11/15/23 2:38 AM, Dmitry Baryshkov wrote:
On Wed, 15 Nov 2023 at 01:00, Jonathan Marek wrote:
Make it clear why the pkt_per_line value is being "divided by 2".
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
On Thu, Nov 16, 2023 at 9:32 AM Christian König
wrote:
>
> Drop the reference to the deprecated re-submission of jobs.
>
> Mention that it isn't the job which times out, but the hardware fence.
> Mention that drivers can try a context based reset as well.
>
> Signed-off-by: Christian König
On Thu, Nov 16, 2023 at 12:52 PM Christian König
wrote:
>
> Start to improve the scheduler document. Especially document the
> lifetime of each of the objects as well as the restrictions around
> DMA-fence handling and userspace compatibility.
A few minor grammatical suggestions below.
>
> v2:
On 11/15/23 3:53 AM, Dmitry Baryshkov wrote:
On Wed, 15 Nov 2023 at 01:00, Jonathan Marek wrote:
Add necessary DPU changes for DSC to work with DSI video mode.
Note this changes the logic to enable HCTL to match downstream, it will
now be enabled for the no-DSC no-widebus case.
Hi,
On 2023/11/16 21:00, Dmitry Baryshkov wrote:
On Thu, 16 Nov 2023 at 14:18, Sui Jingfeng wrote:
Hi,
On 2023/11/15 00:06, Dmitry Baryshkov wrote:
On Tue, 14 Nov 2023 at 17:09, Sui Jingfeng wrote:
From: Sui Jingfeng
Read the required chip id data back by calling regmap_bulk_read()
On Thu, Nov 16, 2023 at 12:11:43PM -0600, Gustavo A. R. Silva wrote:
> Fake flexible arrays (zero-length and one-element arrays) are deprecated,
> and should be replaced by flexible-array members. So, replace
> zero-length array with a flexible-array member in `struct
> PACKED_REGISTRY_TABLE`.
>
On 11/16/23 17:06, Marc Kleine-Budde wrote:
Hey Marek,
On 15.06.2023 22:19:00, Marek Vasut wrote:
This bridge seems to need the HSE packet, otherwise the image is
shifted up and corrupted at the bottom. This makes the bridge
work with Samsung DSIM on i.MX8MM and i.MX8MP.
I'm using v6.6
Fake flexible arrays (zero-length and one-element arrays) are deprecated,
and should be replaced by flexible-array members. So, replace
zero-length array with a flexible-array member in `struct
PACKED_REGISTRY_TABLE`.
Also annotate array `entries` with `__counted_by()` to prepare for the
coming
This is used to specify the page start address offset of the display RAM.
The value is used as offset when setting the page start address with the
SSD130X_SET_PAGE_RANGE command, and the driver currently sets its value to
1 if the property is not present in the Device Tree.
But the datasheet
This is used to specify the page start address offset of the display RAM.
The value is used as offset when setting the page start address with the
SSD130X_SET_PAGE_RANGE command, and the driver currently sets its value to
1 if the property is not present in the Device Tree.
But the datasheet
This is used to specify the page start address offset of the display RAM.
The value is used as offset when setting the page start address with the
SSD130X_SET_PAGE_RANGE command, and the driver currently sets its value to
1 if the property is not present in the Device Tree.
But the datasheet
Hi,
On Thu, Nov 16, 2023 at 05:04:03PM +0100, Geert Uytterhoeven wrote:
> On Thu, Nov 16, 2023 at 4:58 PM Maxime Ripard wrote:
> > On Thu, Nov 16, 2023 at 02:16:08PM +, Biju Das wrote:
> > > Create entry for Renesas RZ DRM drivers and add my self as a maintainer.
> > >
> > > Signed-off-by:
Oh believe me, I tried. I spent like 2 hours fighting with the CLI to
send it. There are restrictions on what addresses it can send from
that don't line up with the identity I use for git. Our corp setup
can be…complicated.
My workflow for patching the kernel is actually a bit weird: I use the
On Thu, Nov 16, 2023 at 06:17:31PM +0100, Krzysztof Kozlowski wrote:
> On 16/11/2023 17:28, Rob Herring wrote:
> > On Mon, Nov 13, 2023 at 01:51:30PM +, Conor Dooley wrote:
> >> On Sun, Nov 12, 2023 at 07:44:01PM +0100, Krzysztof Kozlowski wrote:
> >>> When number of clock varies between
On 2023/11/16 23:23, Dmitry Baryshkov wrote:
On Thu, 16 Nov 2023 at 14:08, Sui Jingfeng wrote:
On 2023/11/16 19:53, Sui Jingfeng wrote:
Hi,
On 2023/11/16 19:29, Dmitry Baryshkov wrote:
On Thu, 16 Nov 2023 at 13:18, Sui Jingfeng
wrote:
Hi,
On 2023/11/15 00:30, Dmitry Baryshkov wrote:
On 16/11/2023 17:28, Rob Herring wrote:
> On Mon, Nov 13, 2023 at 01:51:30PM +, Conor Dooley wrote:
>> On Sun, Nov 12, 2023 at 07:44:01PM +0100, Krzysztof Kozlowski wrote:
>>> When number of clock varies between variants, the Devicetree bindings
>>> coding convention expects to have widest
On Mon, Nov 13, 2023 at 01:51:30PM +, Conor Dooley wrote:
> On Sun, Nov 12, 2023 at 07:44:01PM +0100, Krzysztof Kozlowski wrote:
> > When number of clock varies between variants, the Devicetree bindings
> > coding convention expects to have widest constraints in top-level
> > definition of the
Hey Marek,
On 15.06.2023 22:19:00, Marek Vasut wrote:
> This bridge seems to need the HSE packet, otherwise the image is
> shifted up and corrupted at the bottom. This makes the bridge
> work with Samsung DSIM on i.MX8MM and i.MX8MP.
I'm using v6.6 (which includes this series) on an i.MX8MP with
Hi Maxime,
On Thu, Nov 16, 2023 at 4:58 PM Maxime Ripard wrote:
> On Thu, Nov 16, 2023 at 02:16:08PM +, Biju Das wrote:
> > Create entry for Renesas RZ DRM drivers and add my self as a maintainer.
> >
> > Signed-off-by: Biju Das
> > Reviewed-by: Laurent Pinchart
> > ---
> > v13->v14:
> >
Hi Maxime Ripard,
Thanks for the feedback.
> -Original Message-
> From: Maxime Ripard
> Sent: Thursday, November 16, 2023 3:58 PM
> Subject: Re: [PATCH v14 4/4] MAINTAINERS: Create entry for Renesas RZ DRM
> drivers
>
> Hi,
>
> On Thu, Nov 16, 2023 at 02:16:08PM +, Biju Das wrote:
Hi,
On Thu, Nov 16, 2023 at 02:16:08PM +, Biju Das wrote:
> Create entry for Renesas RZ DRM drivers and add my self as a maintainer.
>
> Signed-off-by: Biju Das
> Reviewed-by: Laurent Pinchart
> ---
> v13->v14:
> * Now SHMOBILE has maintainer entries. So dropped updating
>DRM DRIVERS
On Thursday, November 9th, 2023 at 08:45, Simon Ser wrote:
> User-space sometimes needs to allocate scanout-capable memory for
> GPU rendering purposes. On a vc4/v3d split render/display SoC, this
> is achieved via DRM dumb buffers: the v3d user-space driver opens
> the primary vc4 node,
1 - 100 of 228 matches
Mail list logo
