Hi Javier
Am 30.08.23 um 08:25 schrieb Javier Martinez Canillas:
The commit 45b58669e532 ("drm/ssd130x: Allocate buffer in the plane's
.atomic_check() callback") moved the allocation of the intermediate and
HW buffers from the encoder's .atomic_enable callback to primary plane's
.atomic_check ca
Hi
Am 29.08.23 um 22:02 schrieb Jonathan Neuschäfer:
The files fbmem.c, fb_defio.c, fbsysfs.c, fbmon.c, modedb.c, and
fbcmap.c were moved to drivers/video/fbdev, and subsequently to
drivers/video/fbdev/core, in the commits listed below.
Reported by kalekale in #kernel (Libera IRC).
Fixes: f701
On Tue, 29 Aug 2023, Alex Hung wrote:
> On 2023-08-29 11:03, Jani Nikula wrote:
>> On Tue, 29 Aug 2023, Jani Nikula wrote:
>>> On Tue, 29 Aug 2023, Alex Deucher wrote:
On Tue, Aug 29, 2023 at 6:48 AM Jani Nikula wrote:
>
> On Wed, 23 Aug 2023, Jani Nikula wrote:
>> On Tue, 22
The Monolithic Power (MPS) MP3309C is a WLED step-up converter, featuring a
programmable switching frequency to optimize efficiency.
The brightness can be controlled either by I2C commands (called "analog"
mode) or by a PWM input signal (PWM mode).
This driver supports both modes.
For device drive
From: Elmar Albert
Document support for the AUO G156HAN04.0 LVDS display.
G156HAN04.0 is a Color Active Matrix Liquid Crystal Display composed of
a TFT LCD panel, a driver circuit, and LED backlight system. The screen
format is intended to supportthe 16:9 FHD, 1920(H) x 1080(V) screen
and 16.7M
The Monolithic Power (MPS) MP3309C is a WLED step-up converter, featuring a
programmable switching frequency to optimize efficiency.
The brightness can be controlled either by I2C commands (called "analog"
mode) or by a PWM input signal (PWM mode).
This driver supports both modes.
For DT configura
Hi Liviu,
I have resend that patch and cc to the dri-devel mailing list which
public information about it can be looked up now . Please try to deal with this
patch when you are available.
Best regards,
-邮件原件-
发件人: Huang Menghui/黄梦辉
发送时间: 2023年8月4日 10:06
收件人: airl...@gmail.com
Hi Krzysztof,
Thanks for your quick replay and corrections!
Just some questions about some of your remarks:
> > @@ -0,0 +1,202 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2
> > +---
>
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + mps,dimming-mode:
> > +descript
When testing the d71 writeback layer function,
the output format is set to NV12, and the following error message is displayed:
[drm:komeda_fb_is_layer_supported] Layer TYPE: 4 doesn't support fb FMT: NV12
little-endian (0x3231564e) with modifier: 0x0..
Check the d71 data manual, writeback layer
From: Elmar Albert
G156HAN04.0 is a Color Active Matrix Liquid Crystal Display composed of
a TFT LCD panel, a driver circuit, and LED backlight system. The screen
format is intended to supportthe 16:9 FHD, 1920(H) x 1080(V) screen
and 16.7M colors (RGB 8-bits ) with LED backlight driving circuit.
Hi, Danilo.
Some quick comments since I'm doing some Xe work in this area. Will
probably get back with more.
On 8/20/23 23:53, Danilo Krummrich wrote:
So far the DRM GPUVA manager offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA mappings to the
Hi Thomas,
On Wed, Aug 30, 2023 at 9:08 AM Thomas Zimmermann wrote:
> Am 30.08.23 um 08:25 schrieb Javier Martinez Canillas:
> > The commit 45b58669e532 ("drm/ssd130x: Allocate buffer in the plane's
> > .atomic_check() callback") moved the allocation of the intermediate and
> > HW buffers from th
Hi Geert
Am 30.08.23 um 09:40 schrieb Geert Uytterhoeven:
Hi Thomas,
On Wed, Aug 30, 2023 at 9:08 AM Thomas Zimmermann wrote:
Am 30.08.23 um 08:25 schrieb Javier Martinez Canillas:
The commit 45b58669e532 ("drm/ssd130x: Allocate buffer in the plane's
.atomic_check() callback") moved the allo
Am 20.08.23 um 23:53 schrieb Danilo Krummrich:
So far the DRM GPUVA manager offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA mappings to their
backing buffers and perform more complex mapping operations on the GPU VA
space.
However, there are m
On Thu, Aug 24, 2023 at 06:21:20PM +0530, Ankit Nautiyal wrote:
> As per DP v1.4, a DP DSC Sink device shall support 8bpc in DPCD 6Ah.
> Apparently some panels that do support DSC, are not setting the bit for
> 8bpc.
>
> So always assume 8bpc support by DSC decoder, when DSC is claimed to be
> sup
Am 29.08.23 um 14:31 schrieb Christian König:
Am 29.08.23 um 13:38 schrieb Andi Shyti:
During device bringup it might be that we can't access the debugfs
files.
Return -ENODEV until the registration is completed on access.
just wondering, if the device is not registered, how do we get
there?
Hi Christian,
On Tue, Aug 29, 2023 at 01:01:11PM +0200, Christian König wrote:
> We want to remove per minor debugfs directories. Start by stopping
> drivers from adding anything inside of those in the mid layer callback.
>
> v2: drop it for the accel node as well
>
> Signed-off-by: Christian Kö
On Tue, Aug 29, 2023 at 03:42:40PM +, Biju Das wrote:
> Hi Laurent Pinchart,
>
> Thanks for the feedback.
>
> > Subject: Re: [PATCH 5/7] drm: adv7511: Add has_dsi feature bit to struct
> > adv7511_chip_info
> >
> > Hi Biju,
> >
> > On Tue, Aug 29, 2023 at 02:19:02PM +, Biju Das wrote:
>
> -Original Message-
> From: Harry Wentland
> Sent: Wednesday, August 30, 2023 12:56 AM
> To: Shankar, Uma ; intel-...@lists.freedesktop.org;
> dri-
> de...@lists.freedesktop.org
> Cc: wayland-de...@lists.freedesktop.org; Ville Syrjala
> ; Pekka Paalanen
> ;
> Simon Ser ; Melissa Wen ;
Hi Christian,
> > > > > > During device bringup it might be that we can't access
> > > > > > the debugfs files.
> > > > > > Return -ENODEV until the registration is completed on access.
> > > > > just wondering, if the device is not registered, how do we get
> > > > > there?
> > > > The workflow i
> -Original Message-
> From: Harry Wentland
> Sent: Wednesday, August 30, 2023 1:10 AM
> To: Shankar, Uma ; intel-...@lists.freedesktop.org;
> dri-
> de...@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; wayland-
> de...@lists.freedesktop.org
> Subject: Re: [RFC 01/33] drm/doc/rfc:
On Wed, Aug 30, 2023 at 10:29:46AM +0300, Jani Nikula wrote:
> Upstream code should be reviewed in public.
Yup
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Aug 22, 2023 at 04:26:06PM +0200, Daniel Vetter wrote:
> On Fri, Aug 11, 2023 at 02:19:53PM -0300, Helen Koike wrote:
> > From: Tomeu Vizoso
> >
> > Developers can easily execute several tests on different devices
> > by just pushing their branch to their fork in a repository hosted
> > o
On 24/08/2023 15:46, Jani Nikula wrote:
> CEC needs the source physical address. Parsing it is trivial with the
> existing EDID CEA DB infrastructure.
>
> Default to CEC_PHYS_ADDR_INVALID (0x) instead of 0 to cater for
> easier CEC usage.
>
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.or
On 24/08/2023 15:46, Jani Nikula wrote:
> Connectors have source physical address available in display
> info. There's no need to parse the EDID again for this. Add
> drm_dp_cec_attach() to do this.
>
> Seems like the set_edid/unset_edid naming is a bit specific now that
> there's no need to pass
On 24/08/2023 15:46, Jani Nikula wrote:
> Avoid parsing the EDID again for source physical address. Also gets rids
> of a few remaining raw EDID usages.
>
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Jani Nikula
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
On 24/08/2023 15:46, Jani Nikula wrote:
> In the drm subsystem, the source physical address is, in most cases,
> available without having to parse the EDID again. Add notes about
> preferring to use the pre-parsed address instead.
>
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-of
On Thu, 24 Aug 2023 02:34:45 +0100
Adrián Larumbe wrote:
> The drm-stats fdinfo tags made available to user space are drm-engine,
> drm-cycles, drm-max-freq and drm-curfreq, one per job slot.
Pretty sure this has already been discussed, but it's probably worth
mentioning that drm-cycles is not a
Hi
Am 25.08.23 um 15:22 schrieb Thierry Reding:
From: Thierry Reding
Tegra DRM doesn't support display on Tegra234 and later, so make sure
not to remove any existing framebuffers in that case.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 8 +---
1 file changed, 5 in
On Wed, 30 Aug 2023, Hans Verkuil wrote:
> On 24/08/2023 15:46, Jani Nikula wrote:
>> Connectors have source physical address available in display
>> info. There's no need to parse the EDID again for this. Add
>> drm_dp_cec_attach() to do this.
>>
>> Seems like the set_edid/unset_edid naming is a
Hi Jani,
Sorry, I missed the v2.
On 25/08/2023 15:01, Jani Nikula wrote:
> Connectors have source physical address available in display
> info. There's no need to parse the EDID again for this. Add
> drm_dp_cec_attach() to do this.
>
> Seems like the set_edid/unset_edid naming is a bit specific
On Thu, 24 Aug 2023 02:34:46 +0100
Adrián Larumbe wrote:
> A new DRM GEM object function is added so that drm_show_memory_stats can
> provider more accurate memory usage numbers.
s/provider/provide/
>
> Ideally, in panfrost_gem_status, the BO's purgeable flag would be checked
> after locking
On Thu, 24 Aug 2023 02:34:47 +0100
Adrián Larumbe wrote:
> Some BO's might be mapped onto physical memory chunkwise and on demand,
> like Panfrost's tiler heap. In this case, even though the
> drm_gem_shmem_object page array might already be allocated, only a very
> small fraction of the BO is cu
On Thu, 24 Aug 2023 02:34:44 +0100
Adrián Larumbe wrote:
> These GPU registers will be used when programming the cycle counter, which
> we need for providing accurate fdinfo drm-cycles values to user space.
>
> Signed-off-by: Adrián Larumbe
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/d
On Thu, 24 Aug 2023 02:34:48 +0100
Adrián Larumbe wrote:
> BO's RSS is updated every time new pages are allocated and mapped for the
> object, either in its entirety at creation time for non-heap buffers, or
> else on demand for heap buffers at GPU page fault's IRQ handler.
>
> Same calculations
This won't work. On MT8195 there are two display IPs, vdosys0 and
vdosys1,
vdosys0 only has the main path while vdosys1 only has the external
path. So you
need to loop over each one in all_drm_private[j] to get the right crtc
ID for
MT8195.
Ahh thanks, got it.
-michael
On Wed, 30 Aug 2023, Maxime Ripard wrote:
> On Tue, Aug 22, 2023 at 04:26:06PM +0200, Daniel Vetter wrote:
>> On Fri, Aug 11, 2023 at 02:19:53PM -0300, Helen Koike wrote:
>> > From: Tomeu Vizoso
>> >
>> > Developers can easily execute several tests on different devices
>> > by just pushing their
On 8/28/23 10:17, Pekka Paalanen wrote:
> On Fri, 25 Aug 2023 13:29:44 -0100
> Melissa Wen wrote:
>
>> On 08/22, Pekka Paalanen wrote:
>>> On Thu, 10 Aug 2023 15:02:59 -0100
>>> Melissa Wen wrote:
>>>
The next patch adds pre-blending degamma to AMD color mgmt pipeline, but
pre-blend
While digging through the code I realized that all the outputs and
pipelines
are harcoded. Doh. For all the mediatek SoCs. Looks like major
restriction
to
me. E.g. there is also DSI and HDMI output on the mt8195. I looked at
the
downstream linux and there, the output is not part of the pipeline
On Tue, 29 Aug 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Rename the various names we've used for the DDC bus
> i2c adapter ("i2c", "adapter", etc.) to just "ddc".
> This differentiates it from the various other i2c
> busses we might have (DSI panel stuff, DVO control bus, etc.).
>
> Si
From: Sui Jingfeng
Instead of accessing the PCI_CLASS_DISPLAY_VGA and pdev->class directly.
The PCI_CLASS_NOT_DEFINED_VGA is defined to provide backward compatibility
for devices that were built before the class code field was defined. It
should be visiable via sysfs(boot_vga) as the normal VGA-c
From: Sui Jingfeng
Should be no functional change, just for cleanup purpose.
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/qxl/qxl_drv.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/dr
From: Sui Jingfeng
Should be no functional change, just for cleanup purpose.
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: Gurchetan Singh
Cc: Chia-I Wu
Cc: Daniel Vetter
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
From: Sui Jingfeng
The PCI code and ID assignment specification defined four types of
display controllers for the display base class(03h), and the devices
with 0x00h sub-class code are VGA devices. VGA devices with programming
interface 0x00 is VGA-compatible, VGA devices with programming interfa
From: Sui Jingfeng
The PCI code and ID assignment specification defined four types of
display controllers for the display base class(03h), and the devices
with 0x00h sub-class code are VGA devices. VGA devices with programming
interface 0x00 is VGA-compatible, VGA devices with programming interfa
From: Sui Jingfeng
VGAARB only cares about PCI(e) VGA devices, thus filtering out unqualified
devices as early as possible. This also means that deleting a non-VGA
device snooped won't unnecessarily call into vga_arbiter_del_pci_device()
function. By using the newly implemented pci_is_vga(),
PCI(
On Wednesday, 30 August 2023 11:23:43 CEST David Gow wrote:
> On Wed, 30 Aug 2023 at 15:55, Janusz Krzysztofik
> wrote:
> >
> > Now we have memory space available to a kunit test case log exposed via
> > debugfs limited to 2048 bytes, while some parametrized test cases, e.g.,
> > drm_framebuffer.d
On Wed, Aug 30, 2023 at 01:58:31PM +0300, Jani Nikula wrote:
> On Wed, 30 Aug 2023, Maxime Ripard wrote:
> > On Tue, Aug 22, 2023 at 04:26:06PM +0200, Daniel Vetter wrote:
> >> On Fri, Aug 11, 2023 at 02:19:53PM -0300, Helen Koike wrote:
> >> > From: Tomeu Vizoso
> >> >
> >> > Developers can eas
On Tue, 29 Aug 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use the standard onion peeling approach and call
> drm_debugfs_connector_remove() and
> drm_sysfs_connector_remove() in the reverse order in
> drm_connector_unregister() than what we called their
> add counterpartse in drm_connec
On Tue, 29 Aug 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently drm_sysfs_connector_add() attempts to register
> the "ddc" symlink (based one connector->ddc) before the
> driver's .early_register() hook has been called. That is
> too early for i915 which only fully registers the aux
On Wed, 30 Aug 2023, "Lisovskiy, Stanislav"
wrote:
> On Thu, Aug 24, 2023 at 06:21:20PM +0530, Ankit Nautiyal wrote:
>> As per DP v1.4, a DP DSC Sink device shall support 8bpc in DPCD 6Ah.
>> Apparently some panels that do support DSC, are not setting the bit for
>> 8bpc.
>>
>> So always assume
On Thu, 24 Aug 2023, Ankit Nautiyal wrote:
> Edid specific BPC constraints are stored in limits->max_bpp. Honor these
> limits while computing the input bpp for DSC.
>
> v2: Use int instead of u8 for computations. (Jani)
> Add closes tag. (Ankit)
>
> Closes: https://gitlab.freedesktop.org/drm/inte
On Wed, 30 Aug 2023, Jani Nikula wrote:
> On Tue, 29 Aug 2023, Ville Syrjala wrote:
>> From: Ville Syrjälä
>> @@ -2452,24 +2447,24 @@ intel_hdmi_set_edid(struct drm_connector *connector)
>> {
>> struct drm_i915_private *dev_priv = to_i915(connector->dev);
>> struct intel_hdmi *intel_h
On Tue, 29 Aug 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Populate connector->ddc, and thus create the "ddc" symlink
> in sysfs for the LVDS port.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_lvds.c | 23 +++---
On Tue, 29 Aug 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Populate connector->ddc, and thus create the "ddc" symlink
> in sysfs for analog VGA connectors.
>
> As a bonus we can replace a bunch of intel_gmbus_get_adapter()
> lookups with just the connector->ddc pointer. Sadly one extra
>
On Tue, 29 Aug 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Populate connector->ddc, and thus create the "ddc" symlink
> in sysfs for DVO connectors.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dvo.c | 11 +--
> 1 file
On Tue, 29 Aug 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Populate connector->ddc, and thus create the "ddc" symlink
> in sysfs for analog DP SST connectors.
>
> Let's also reorder intel_dp_aux_init() vs. drm_connector_init_with_ddc()
> a bit to make sure the i2c aux ch is at least some
On Tue, 29 Aug 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Populate connector->ddc, and thus create the "ddc" symlink
> in sysfs for DP MST connectors.
>
> TODO: test that this actually works
:)
Seems legit,
Reviewed-by: Jani Nikula
>
> References: https://gitlab.freedesktop.org/drm
On Tue, 29 Aug 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We already populate connector->ddc for HDMI ports, but
> so far we've not taken full advantage of it. Do that by
> eliminating a bunch of intel_gmbus_get_adapter() lookups.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nik
On Tue, 29 Aug 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We aren't intending to mutate the SDVO device mapping structs,
> so make them const.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_sdvo.c | 6 +++---
> 1 file changed, 3
On Wed, 30 Aug 2023 08:59:36 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: Harry Wentland
> > Sent: Wednesday, August 30, 2023 1:10 AM
> > To: Shankar, Uma ; intel-...@lists.freedesktop.org;
> > dri-
> > de...@lists.freedesktop.org
> > Cc: Borah, Chaitanya Kumar ; wayland
Hi Thomas,
thanks for having a look!
On Wed, Aug 30, 2023 at 09:27:45AM +0200, Thomas Hellström (Intel) wrote:
> Hi, Danilo.
>
> Some quick comments since I'm doing some Xe work in this area. Will probably
> get back with more.
>
> On 8/20/23 23:53, Danilo Krummrich wrote:
> > So far the DRM GP
On Tue, 29 Aug 2023 21:33:51 +0530
Uma Shankar wrote:
> From: Chaitanya Kumar Borah
>
> Each Color Hardware block will be represented uniquely
> in the color pipeline. Define the structure to represent
> the same.
>
> These color operations will form the building blocks of
> a color pipeline w
On Wed, Aug 30, 2023 at 09:48:02AM +0200, Christian König wrote:
>
>
> Am 20.08.23 um 23:53 schrieb Danilo Krummrich:
> > So far the DRM GPUVA manager offers common infrastructure to track GPU VA
> > allocations and mappings, generically connect GPU VA mappings to their
> > backing buffers and pe
On 29/08/2023 15:00, Boris Brezillon wrote:
> On Fri, 11 Aug 2023 16:47:56 +0100
> Steven Price wrote:
>
>> On 09/08/2023 17:53, Boris Brezillon wrote:
>>> The panthor driver is designed in a modular way, where each logical
>>> block is dealing with a specific HW-block or software feature. In ord
Hi all,
Thanks for you comments.
On 30/08/2023 08:37, Maxime Ripard wrote:
On Wed, Aug 30, 2023 at 01:58:31PM +0300, Jani Nikula wrote:
On Wed, 30 Aug 2023, Maxime Ripard wrote:
On Tue, Aug 22, 2023 at 04:26:06PM +0200, Daniel Vetter wrote:
On Fri, Aug 11, 2023 at 02:19:53PM -0300, Helen Ko
On 8/30/23 14:49, Danilo Krummrich wrote:
Hi Thomas,
thanks for having a look!
On Wed, Aug 30, 2023 at 09:27:45AM +0200, Thomas Hellström (Intel) wrote:
Hi, Danilo.
Some quick comments since I'm doing some Xe work in this area. Will probably
get back with more.
On 8/20/23 23:53, Danilo Kru
Hi!
David Airlie suggested that we could implement new wrappers around
(v)memdup_user() for duplicating user arrays.
This small patch series first implements the two new wrapper functions
memdup_array_user() and vmemdup_array_user(). They calculate the
array-sizes safely, i.e., they return an err
Currently, user array duplications are sometimes done without an
overflow check. Sometimes the checks are done manually; sometimes the
array size is calculated with array_size() and sometimes by calculating
n * size directly in code.
Introduce wrappers for arrays for memdup_user() and vmemdup_user
Currently, there is no overflow-check with memdup_user().
Use the new function memdup_array_user() instead of memdup_user() for
duplicating the user-space array safely.
Suggested-by: David Airlie
Signed-off-by: Philipp Stanner
---
kernel/kexec.c | 2 +-
1 file changed, 1 insertion(+), 1 deleti
Currently, there is no overflow-check with memdup_user().
Use the new function memdup_array_user() instead of memdup_user() for
duplicating the user-space array safely.
Suggested-by: David Airlie
Signed-off-by: Philipp Stanner
---
kernel/watch_queue.c | 2 +-
1 file changed, 1 insertion(+), 1
Currently, there is no overflow-check with memdup_user().
Use the new function memdup_array_user() instead of memdup_user() for
duplicating the user-space array safely.
Suggested-by: David Airlie
Signed-off-by: Philipp Stanner
---
drivers/gpu/drm/drm_lease.c | 4 ++--
1 file changed, 2 inserti
Currently, there is no overflow-check with memdup_user().
Use the new function memdup_array_user() instead of memdup_user() for
duplicating the user-space array safely.
Suggested-by: David Airlie
Signed-off-by: Philipp Stanner
---
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 4 ++--
1 file change
On Wed, 30 Aug 2023 14:17:57 +0100
Steven Price wrote:
> >>> +static void panthor_device_reset_work(struct work_struct *work)
> >>> +{
> >>> + struct panthor_device *ptdev = container_of(work, struct
> >>> panthor_device, reset.work);
> >>> + int ret, cookie;
> >>> +
> >>> + if (!drm_dev_enter(&
On Wed, Aug 30, 2023 at 4:46 PM Philipp Stanner wrote:
>
> Currently, user array duplications are sometimes done without an
> overflow check. Sometimes the checks are done manually; sometimes the
> array size is calculated with array_size() and sometimes by calculating
> n * size directly in code.
On 29/08/2023 16:33, Boris Brezillon wrote:
> On Mon, 14 Aug 2023 16:53:09 +0100
> Steven Price wrote:
>
>>> +
>>> +/**
>>> + * struct panthor_vm_op_ctx - VM operation context
>>> + *
>>> + * With VM operations potentially taking place in a dma-signaling path, we
>>> + * need to make sure everyth
On Wed, Aug 30, 2023 at 4:46 PM Philipp Stanner wrote:
> + if (unlikely(check_mul_overflow(n, size, &nbytes)))
> + return ERR_PTR(-EINVAL);
> + if (unlikely(check_mul_overflow(n, size, &nbytes)))
> + return ERR_PTR(-EINVAL);
Btw, why not -EOVERFLOW ?
--
On Wed, 2023-08-30 at 17:11 +0300, Andy Shevchenko wrote:
> On Wed, Aug 30, 2023 at 4:46 PM Philipp Stanner
> wrote:
> >
> > Currently, user array duplications are sometimes done without an
> > overflow check. Sometimes the checks are done manually; sometimes
> > the
> > array size is calculated
Am 30.08.23 um 10:19 schrieb Andi Shyti:
Hi Christian,
On Tue, Aug 29, 2023 at 01:01:11PM +0200, Christian König wrote:
We want to remove per minor debugfs directories. Start by stopping
drivers from adding anything inside of those in the mid layer callback.
v2: drop it for the accel node as w
On Wed, 2023-08-30 at 17:15 +0300, Andy Shevchenko wrote:
> On Wed, Aug 30, 2023 at 4:46 PM Philipp Stanner
> wrote:
>
> > + if (unlikely(check_mul_overflow(n, size, &nbytes)))
> > + return ERR_PTR(-EINVAL);
>
> > + if (unlikely(check_mul_overflow(n, size, &nbytes)))
>
This patch series aims to improve ADV7511 driver by adding
feature bits and data instead of comparing enum adv7511_type for
various hardware differences between ADV7511, ADV7533 and ADV7535.
This patch series tested with[1] on RZ/G2L SMARC EVK which embeds
ADV7535.
[1] https://patchwork.kernel.or
Add struct adv7511_chip_info to handle hw differences between various
chips rather checking against the 'type' variable in various places.
Replace 'adv->type'->'info->type' by moving variable 'type' from
struct adv7511 to struct adv7511_chip_info and add adv7511_chip_info as
device data for both OF
The ADV7533 supports a maximum pixel clock of 80MHz whereas it is 148.5MHz
for ADV7535. Add max_mode_clock_khz variable to struct adv7511_chip_info to
handle this difference.
Signed-off-by: Biju Das
Reviewed-by: Adam Ford
Tested-by: Adam Ford #imx8mm-beacon
Reviewed-by: Laurent Pinchart
---
*
The ADV7533 supports a maximum lane clock of 800MHz whereas it is 891MHz
for ADV7535. Add max_lane_freq_khz variable to struct adv7511_chip_info to
handle this difference.
While at it, drop the unused local variable max_lane_freq.
Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
---
v1->v2
The ADV7511 has 5 power supplies compared to 7 that of ADV75{33,35}. Add
supply_names and num_supplies variables to struct adv7511_chip_info to
handle this difference.
Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
---
v1->v2:
* Added Rb tag from Laurent.
* Added trailing commas for num
The ADV7533 and ADV7535 have an offset(0x70) for the CEC register map
compared to ADV7511. Add the reg_cec_offset variable to struct
adv7511_chip_info to handle this difference and drop the reg_cec_offset
variable from struct adv7511.
This will avoid assigning reg_cec_offset based on chip type and
The ADV7533 and ADV7535 have DSI support. Add a variable has_dsi to
struct adv7511_chip_info for handling configuration related to DSI.
Signed-off-by: Biju Das
---
v1->v2:
* Replaced variable type from unsigned->bool.
* Restored check using type for low_refresh_rate and
regmap_register_patch
The ADV7511 needs link configuration whereas ADV75{33,35} does not need
it. Add a variable link_config to struct adv7511_chip_info to handle
this difference.
Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
---
v1->v2:
* Add Rb tag from Laurent.
* Replaced variable type from unsigned->boo
As per spec, it is allowed to pulse the HPD signal to indicate that the
EDID information has changed. Some monitors do this when they wake up
from standby or are enabled. When the HPD goes low the adv7511 is
reset and the outputs are disabled which might cause the monitor to
go to standby again. To
On Wed, Aug 30, 2023 at 5:19 PM wrote:
> On Wed, 2023-08-30 at 17:11 +0300, Andy Shevchenko wrote:
> > On Wed, Aug 30, 2023 at 4:46 PM Philipp Stanner
> > wrote:
> > > --- a/include/linux/string.h
> > > +++ b/include/linux/string.h
> >
> > I'm wondering if this has no side-effects as string.h/st
replying to a couple points on this thread
On Wed, Aug 30, 2023 at 6:25 AM Helen Koike wrote:
>
> Hi all,
>
> Thanks for you comments.
>
> On 30/08/2023 08:37, Maxime Ripard wrote:
> > On Wed, Aug 30, 2023 at 01:58:31PM +0300, Jani Nikula wrote:
> >> On Wed, 30 Aug 2023, Maxime Ripard wrote:
> >
On Wed, 30 Aug 2023 15:12:43 +0100
Steven Price wrote:
> On 29/08/2023 16:33, Boris Brezillon wrote:
> > On Mon, 14 Aug 2023 16:53:09 +0100
> > Steven Price wrote:
> >
> >>> +
> >>> +/**
> >>> + * struct panthor_vm_op_ctx - VM operation context
> >>> + *
> >>> + * With VM operations potential
On Wed, Aug 30, 2023 at 10:24:49AM -0300, Helen Koike wrote:
> Hi all,
>
> Thanks for you comments.
>
> On 30/08/2023 08:37, Maxime Ripard wrote:
> > On Wed, Aug 30, 2023 at 01:58:31PM +0300, Jani Nikula wrote:
> > > On Wed, 30 Aug 2023, Maxime Ripard wrote:
> > > > On Tue, Aug 22, 2023 at 04:26
On Wed, Aug 30, 2023 at 03:42:08PM +0200, Thomas Hellström (Intel) wrote:
>
> On 8/30/23 14:49, Danilo Krummrich wrote:
> > Hi Thomas,
> >
> > thanks for having a look!
> >
> > On Wed, Aug 30, 2023 at 09:27:45AM +0200, Thomas Hellström (Intel) wrote:
> > > Hi, Danilo.
> > >
> > > Some quick com
On 30/08/2023 11:57, Maxime Ripard wrote:
On Wed, Aug 30, 2023 at 10:24:49AM -0300, Helen Koike wrote:
Hi all,
Thanks for you comments.
On 30/08/2023 08:37, Maxime Ripard wrote:
On Wed, Aug 30, 2023 at 01:58:31PM +0300, Jani Nikula wrote:
On Wed, 30 Aug 2023, Maxime Ripard wrote:
On Tue
On 8/28/23 17:02, Lazar, Lijo wrote:
> [AMD Official Use Only - General]
>
>
> As mentioned with an older version of this series, this is an 'abuse' of
> power profile interface.
>
> This series is oversimplifying what PMFW algorithms are supposed to be doing.
> Whatever this series is doing,
On 29/08/2023 17:15, Boris Brezillon wrote:
> On Wed, 16 Aug 2023 17:01:56 +0100
> Steven Price wrote:
>
>> On 09/08/2023 17:53, Boris Brezillon wrote:
[...]
>>> +/**
>>> + * panthor_fw_mem_alloc() - Allocate a FW memory object and map it to the
>>> MCU VM.
>>> + * @ptdev: Device.
>>> + * @siz
On Wed, Aug 30, 2023 at 06:50:32AM -0700, Christoph Hellwig wrote:
> I know I'm chiming in a bit late, but what ultimate user space is going
> to use this? We should not add anything to the kernel that can't
> be used without fully open user space.
qemu will get the matching VFIO userspace patche
When another discrete video card(SM750 or AST1400) is mounted into the mini
PCIe slot of my ASRock AD2550B-ITX board, the gma500 drivers fails to work.
It probably because the UEFI firmware of that board forget to initialize
the PSB_PGETBL_CTL reg, therefore the value of dev_priv->pge_ctl is 0, the
The PGTBL_CTL register provides the starting physical memory address of
the Graphics Translation Table (GTT). We want to see what's the value in
it. This patch is useful for debug.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/gma500/gtt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/
1 - 100 of 175 matches
Mail list logo
