From: Yang Yingliang
check the alloc_workqueue return value in radeon_crtc_init()
to avoid null-ptr-deref.
Fixes: fa7f517cb26e ("drm/radeon: rework page flip handling v4")
Signed-off-by: Yang Yingliang
---
drivers/gpu/drm/radeon/radeon_display.c | 7 ++-
1 file changed, 6 insertions(+), 1
If the call to vmap() fails the "page_nr" is one element beyond the end
of the mips_data->pt_dma_addr[] and mips_data->pt_pages[] arrays.
The way that this is traditionally written is that we clean up the
partial loop iteration before the goto and then we can say
while (--i >= 0). At that point
Hello Sarah Walker,
The patch cc1aeedb98ad: "drm/imagination: Implement firmware
infrastructure and META FW support" from Nov 22, 2023 (linux-next),
leads to the following Smatch static checker warning:
drivers/gpu/drm/imagination/pvr_ccb.c:277
pvr_kccb_send_cmd_reserved_powered()
The pvr_build_firmware_filename() function returns NULL on error. It
doesn't return error pointers.
Fixes: f99f5f3ea7ef ("drm/imagination: Add GPU ID parsing and firmware loading")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/imagination/pvr_device.c | 4 ++--
1 file changed, 2
There is a cut and paste error so this code returns the wrong variable.
Fixes: 1f88f017e649 ("drm/imagination: Get GPU resources")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/imagination/pvr_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Add @Oak to the KFD discussion. I will reply separately elaborating your
questions on GMEM's difference from HMM/MMU notifiers.
Christian, thanks for pointing me to that AMDKFD discussion. I have read the
discussion around the AMDKFD skeleton patch and found the previous discussion
in the
Am 29.11.23 um 17:03 schrieb Alex Deucher:
On Wed, Nov 29, 2023 at 10:47 AM Christian König
wrote:
Am 29.11.23 um 16:22 schrieb Nikita Zhandarovich:
While improbable, there may be a chance of hitting integer
overflow when the result of radeon_get_ib_value() gets shifted
left.
Avoid it by
Hi Christoph,
>
> > +static struct page *alloc_file_page(struct file *file, pgoff_t idx)
>
> alloc_file_pages seems like a weird name for something that assumes
> it is called either on a hugetlbfs or shmemfs file (without any
I see your concern. The word "file" does make it look like this API
Clang static analyzer complains that value stored to 'ret' is never read.
Return the error code when spi_sync() failed.
Signed-off-by: Su Hui
---
drivers/video/backlight/ili922x.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/video/backlight/ili922x.c
On Sat, 28 Oct 2023 at 01:33, Jessica Zhang wrote:
>
> Loosen the requirements for atomic and legacy commit so that, in cases
> where pixel_source != FB, the commit can still go through.
>
> This includes adding framebuffer NULL checks in other areas to account for
> FB being NULL when non-FB
On Sat, 28 Oct 2023 at 01:33, Jessica Zhang wrote:
>
> Document and add support for solid_fill property to drm_plane. In
> addition, add support for setting and getting the values for solid_fill.
>
> To enable solid fill planes, userspace must assign a property blob to
> the "solid_fill" plane
On Wed, 29 Nov 2023 at 19:47, Kuogee Hsieh wrote:
>
> Currently DP driver is executed independent of PM runtime framework.
> This leads msm eDP panel can not being detected by edp_panel driver
> during generic_edp_panel_probe() due to AUX DPCD read failed at
> edp panel driver. Incorporate PM
On Wed, 29 Nov 2023 at 20:42, Paloma Arellano wrote:
>
> Trigger a devcoredump to dump dpu registers and capture the drm atomic
> state when the frame_done_timer timeouts.
>
> Signed-off-by: Paloma Arellano
> ---
>
> Changes since v1:
> - Optimized the format in which frame_done_timeout_cnt is
On Wed, 29 Nov 2023 at 22:31, Kuogee Hsieh wrote:
>
> A DCE (Display Compression Engine) contains two DSC hard slice encoders.
> Each DCE start with even DSC encoder index followed by an odd DSC encoder
> index. Each encoder can work independently. But Only two DSC encoders from
> same DCE can be
On 2023-11-29 22:36, Luben Tuikov wrote:
> On 2023-11-29 15:49, Alex Deucher wrote:
>> On Wed, Nov 29, 2023 at 3:10 PM Alex Deucher wrote:
>>>
>>> Actually I think I see the problem. I'll try and send out a patch
>>> later today to test.
>>
>> Does the attached patch fix it?
>
> Thanks for the
On 2023-11-29 15:49, Alex Deucher wrote:
> On Wed, Nov 29, 2023 at 3:10 PM Alex Deucher wrote:
>>
>> Actually I think I see the problem. I'll try and send out a patch
>> later today to test.
>
> Does the attached patch fix it?
Thanks for the patch, Alex.
Is it possible for AMD to also
Hi Sascha:
On 11/29/23 20:59, Sascha Hauer wrote:
On Wed, Nov 29, 2023 at 07:01:37PM +0800, Andy Yan wrote:
Hi Sascha:
On 11/29/23 16:52, Sascha Hauer wrote:
On Mon, Nov 27, 2023 at 06:56:34PM +0800, Andy Yan wrote:
Hi Sascha:
thanks for you review.
On 11/27/23 18:13,
From: Dave Airlie
This is a hackaround a bug exposed with the GSP code, I'm not sure
what it happening exactly, but it appears some of our flushes don't
result in proper tlb invalidation for out BAR2 and we get a BAR2
fault from GSP and it all dies.
Signed-off-by: Dave Airlie
---
On Thu, Nov 23, 2023 at 02:23:01PM +, Conor Dooley wrote:
> On Tue, Nov 21, 2023 at 07:05:15PM -0800, Samuel Holland wrote:
> > RISC-V uses kernel_fpu_begin()/kernel_fpu_end() like several other
> > architectures. Enabling hardware FP requires overriding the ISA string
> > for the relevant
On Wed, 2023-11-29 at 13:13 -0800, Teres Alexis, Alan Previn wrote:
> On Mon, 2023-11-27 at 15:24 -0500, Vivi, Rodrigo wrote:
> > On Wed, Nov 22, 2023 at 12:30:03PM -0800, Alan Previn wrote:
> alan:snip
> alan: thanks for reviewing and apologize for replying to this late.
>
> > > /*
> > > - *
On Wed, Nov 29, 2023 at 10:06:37AM +0100, Thomas Hellström wrote:
> diff --git a/Documentation/gpu/drm-vm-bind-locking.rst
> b/Documentation/gpu/drm-vm-bind-locking.rst
> new file mode 100644
> index ..a345aa513d12
> --- /dev/null
> +++ b/Documentation/gpu/drm-vm-bind-locking.rst
> @@
This series is the result of debugging issues root caused to
races between the GuC's destroyed_worker_func being triggered
vs repeating suspend-resume cycles with concurrent delayed
fence signals for engine-freeing.
The reproduction steps require that an app is launched right
before the start of
If we are at the end of suspend or very early in resume
its possible an async fence signal (via rcu_call) is triggered
to free_engines which could lead us to the execution of
the context destruction worker (after a prior worker flush).
Thus, when suspending, insert rcu_barriers at the start
of
When suspending, flush the context-guc-id
deregistration worker at the final stages of
intel_gt_suspend_late when we finally call gt_sanitize
that eventually leads down to __uc_sanitize so that
the deregistration worker doesn't fire off later as
we reset the GuC microcontroller.
Signed-off-by:
On 11/16/23 21:52, Yuran Pereira wrote:
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
Hi Abhinav,
Thanks for sending this follow-up patch.
On 11/26/23 15:57, Abhinav Singh wrote:
Fix a sparse warning with this message
"warning:dereference of noderef expression". In this context it means we
are dereferencing a __rcu tagged pointer directly.
We should not be directly
Hi all,
Is there a way to configure a framebuffer console on a specific display
on a machine with multiple displays?
Hi Weixi,
Even though Christian has listed reasons rejecting this proposal (yes they are
very reasonable to me), I would open my mind and further explore the
possibility here. Since the current GPU driver uses a hmm based implementation
(AMD and NV has done this; At Intel we are catching up),
Similar to devres equivalent, it allows to call the "release" action
directly and remove the resource from the managed resources list.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/drm_managed.c | 39 +++
include/drm/drm_managed.h | 4
2 files
Add a simple test that checks whether the action is indeed called right
away and that it is not called on the final drm_dev_put().
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/tests/drm_managed_test.c | 65 ++--
1 file changed, 50 insertions(+), 15 deletions(-)
diff
Upcoming Intel Xe driver will need to have a more fine-grained control
over DRM managed actions - namely, the ability to release a given
action, triggering it manually at a different point in time than the
final drm_dev_put().
This series adds a drmm_release_action function (which is similar to
Make use of GPUVM's drm_exec helper functions preventing direct access
to GPUVM internal data structures, such as the external object list.
This is especially important to ensure following the locking rules
around the GPUVM external object list.
Fixes: ff5f643de0bf ("drm/imagination: Add GEM and
Fall back to drm_exec_lock_obj() if num_fences is zero for the
drm_gpuvm_prepare_* function family.
Otherwise dma_resv_reserve_fences() would actually allocate slots even
though num_fences is zero.
Cc: Christian König
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/drm_gpuvm.c | 43
Hi,
Some major GPUVM changes landed just before v8 of the PowerVR series. Since v8
went in rather quickly (review process was finished otherwise) I haven't had the
chance to review the subsequent code changes.
Hence, this series with a few fixes in this context. Plus a minor GPUVM patch to
make
Because the JD9230P discrete GPU has two vivante 3D GPU (GC9200) cores,
the LingJiu GP102 discrete GPU has two separated GPU core (one is 3D and
another one is 2D). The etnaviv_create_platform_device() has been revised
to create a virtual platform device as the representation for the single
GPU
From: Sui Jingfeng
The instance of struct drm_device and struct etnaviv_drm_private are
intended to be shared by all GPU cores. Embedding struct drm_device into
struct etnaviv_drm_private allow us to allocate storage for them togather.
And use container_of() to retrieve pointer for the
From: Sui Jingfeng
There is a Vivante GC1000 GPU (v5037) in Loongson LS2K1000 (0x0014:0x7a05)
and LS7A1000 (0x0014:0x7a15), the GPU in these chips is a PCI(e) device,
has only one core with both the 3D pipe and 2D pipe. This patch adds PCI
driver wrapper on the top of what drm/etnaviv already
From: Sui Jingfeng
Noticed that there are a lot of members in the struct etnaviv_drm_private,
which are intended to be shared by all GPU cores. Introduces two helpers
for construction and destruction purpose for it. The benefit is that error
handling get simplified a lot.
Signed-off-by: Sui
Tested on X86-64 with JM9100 GPU, the JM9100 discrete GPU has only one
vivante GPU found so far.
$ sudo dmesg | grep etnaviv
etnaviv :0d:00.0: enabling device ( -> 0003)
etnaviv :0d:00.0: Unbalanced pm_runtime_enable!
etnaviv :0d:00.0: model: GC9200, revision: 6304
[drm]
From: Sui Jingfeng
Modern Loongson CPUs choose to define the peripheral devices as DMA
coherent by default, to be specific, the peripheral devices are capable
of snooping CPU's cache. This means that device drivers do not need to
manually maintain the coherency issue between a processor and an
From: Sui Jingfeng
The component helper is used to bind multiple GPU cores to a virtual
master platform device, but there are SoCs and/or chipsets that contain
only one GPU core. On such cases, component framework can be avoided.
The reason is that usperspace programs(such as X server and Mesa)
From: Sui Jingfeng
Because the current implement is DT-based, this is only works when the host
platform has the DT support. Typically, the PLL hardwares are provided by
the host platform, not the GPU core itself. So add a dedicated helper
function to get clocks, only call this function when DT
This series is add PCI device driver wrapper, to support the Vivante GC1000
GPU in LS2K1000 and LS7A1000.
The whole serie have been tested on X86-64 and LoongArch platform, only the
kernel space driver are tested, basically normal and run stable!
v6:
* Fix build issue on system without
On 11/13/2023 5:00 PM, john.c.harri...@intel.com wrote:
From: John Harrison
There is a mechanism for reporting errors from fire and forget H2G
messages. This is the only way to find out about almost any error in
the GuC backend submission path. So it would be useful to know that it
is
On Wed, Nov 22, 2023 at 1:58 PM Christian König
wrote:
>
> Am 22.11.23 um 17:05 schrieb Ramesh Errabolu:
> > Fix the documentation of struct dma_buf members name and exp_name
> > as to how these members are to be used and accessed.
> >
> > Signed-off-by: Ramesh Errabolu
>
> Reviewed-by:
On Mon, 2023-11-27 at 15:24 -0500, Vivi, Rodrigo wrote:
> On Wed, Nov 22, 2023 at 12:30:03PM -0800, Alan Previn wrote:
alan:snip
alan: thanks for reviewing and apologize for replying to this late.
> > /*
> > -* On MTL and newer platforms, protected contexts require setting
> > -* the
On Wed, Nov 29, 2023 at 3:10 PM Alex Deucher wrote:
>
> Actually I think I see the problem. I'll try and send out a patch
> later today to test.
Does the attached patch fix it?
Alex
>
> Alex
>
> On Wed, Nov 29, 2023 at 1:52 PM Alex Deucher wrote:
> >
> > On Wed, Nov 29, 2023 at 11:41 AM
A DCE (Display Compression Engine) contains two DSC hard slice encoders.
Each DCE start with even DSC encoder index followed by an odd DSC encoder
index. Each encoder can work independently. But Only two DSC encoders from
same DCE can be paired to work together to support merge mode. In addition,
Luben Tuikov writes:
> I remember that the problem was really that amdgpu called
> drm_sched_entity_init(),
> in amdgpu_ttm_set_buffer_funcs_status() without actually having initialized
> the scheduler
> used therein. For instance, the code before commit b70438004a14f4, looked
> like this:
>
Cc: Nathan Chancellor
On 11/29/23 13:12, Jani Nikula wrote:
At least the i915 and amd drivers enable a bunch more compiler warnings
than the kernel defaults.
Extend the W=1 warnings to the entire drm subsystem by default. Use the
copy-pasted warnings from scripts/Makefile.extrawarn with
Actually I think I see the problem. I'll try and send out a patch
later today to test.
Alex
On Wed, Nov 29, 2023 at 1:52 PM Alex Deucher wrote:
>
> On Wed, Nov 29, 2023 at 11:41 AM Luben Tuikov wrote:
> >
> > On 2023-11-29 10:22, Alex Deucher wrote:
> > > On Wed, Nov 29, 2023 at 8:50 AM Alex
Hi Dave, Daniel,
This pull request is a bit confusing, as it first adds the panel fixes
and a driver/core change, then immediately revert it.
Cheers,
~Maarten
drm-misc-fixes-2023-11-29:
Fixes for v6.7-rc4:
- Revert panel fixes as they require exporting device_is_dependent.
- Do not double
On 11/29/23 20:20, John Hubbard wrote:
On 11/29/23 01:06, Thomas Hellström wrote:
Add the first version of the VM_BIND locking document which is
intended to be part of the xe driver upstreaming agreement.
The document describes and discuss the locking used during exec-
functions, evicton and
On Wed, Nov 29, 2023 at 05:23:13PM +0100, Thierry Reding wrote:
> > diff --git a/drivers/memory/tegra/tegra186.c
> > b/drivers/memory/tegra/tegra186.c
> > index 533f85a4b2bdb7..3e4fbe94dd666e 100644
> > --- a/drivers/memory/tegra/tegra186.c
> > +++ b/drivers/memory/tegra/tegra186.c
> > @@ -111,21
On Fri, 2023-11-24 at 08:30 +, Tvrtko Ursulin wrote:
> On 22/11/2023 19:15, Alan Previn wrote:
alan:snip
alan: thanks for reviewing.
> > if (iir & GEN12_DISPLAY_STATE_RESET_COMPLETE_INTERRUPT)
> > - pxp->session_events |= PXP_TERMINATION_COMPLETE;
> > +
On 11/29/23 01:06, Thomas Hellström wrote:
Add the first version of the VM_BIND locking document which is
intended to be part of the xe driver upstreaming agreement.
The document describes and discuss the locking used during exec-
functions, evicton and for userptr gpu-vmas. Intention is to be
On Mon, 2023-11-27 at 16:51 -0500, Vivi, Rodrigo wrote:
alan: Firstly, thanks for taking the time to review this, knowing you have a
lot on your plate right now.
>
alan:snip
> > @@ -3301,19 +3315,38 @@ static inline void guc_lrc_desc_unpin(struct
> > intel_context *ce)
> > /* Seal race
Add missing tag for "Wa_14019159160 - Case 2" (for existing
PXP code that ensures run alone mode bit is set to allow
PxP-decryption.
v4: - Include IP_VER 12.71. (Matt Roper)
v3: - Check targeted platforms using IP_VAL. (John Harrison)
v2: - Fix WA id number (John Harrison).
- Improve
On Wed, Nov 29, 2023 at 01:55:04PM +0100, Lorenzo Pieralisi wrote:
> I don't think it should be done this way. Is the goal compile testing
> IORT code ?
Yes
> If so, why are we forcing it through the SMMU (only because
> it can be compile tested while eg SMMUv3 driver can't ?) menu entry ?
On Wed, Nov 29, 2023 at 05:58:08PM +, Robin Murphy wrote:
> On 29/11/2023 12:48 am, Jason Gunthorpe wrote:
> > The iommu_device_lock protects the iommu_device_list which is only read by
> > iommu_ops_from_fwnode().
> >
> > This is now always called under the iommu_probe_device_lock, so we
On Wed, Nov 29, 2023 at 11:41 AM Luben Tuikov wrote:
>
> On 2023-11-29 10:22, Alex Deucher wrote:
> > On Wed, Nov 29, 2023 at 8:50 AM Alex Deucher wrote:
> >>
> >> On Tue, Nov 28, 2023 at 11:45 PM Luben Tuikov wrote:
> >>>
> >>> On 2023-11-28 17:13, Alex Deucher wrote:
> On Mon, Nov 27,
On Wed, Nov 29, 2023 at 11:21 AM Luben Tuikov wrote:
>
> On 2023-11-29 08:50, Alex Deucher wrote:
> > On Tue, Nov 28, 2023 at 11:45 PM Luben Tuikov wrote:
> >>
> >> On 2023-11-28 17:13, Alex Deucher wrote:
> >>> On Mon, Nov 27, 2023 at 6:24 PM Phillip Susi wrote:
>
> Alex Deucher
Trigger a devcoredump to dump dpu registers and capture the drm atomic
state when the frame_done_timer timeouts.
Signed-off-by: Paloma Arellano
---
Changes since v1:
- Optimized the format in which frame_done_timeout_cnt is incremented
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 12
At least the i915 and amd drivers enable a bunch more compiler warnings
than the kernel defaults.
Extend the W=1 warnings to the entire drm subsystem by default. Use the
copy-pasted warnings from scripts/Makefile.extrawarn with
s/KBUILD_CFLAGS/subdir-ccflags-y/ to make it easier to compare and
On 29/11/2023 12:48 am, Jason Gunthorpe wrote:
The iommu_device_lock protects the iommu_device_list which is only read by
iommu_ops_from_fwnode().
This is now always called under the iommu_probe_device_lock, so we don't
need to double lock the linked list. Use the iommu_probe_device_lock on
the
On Tue, 2023-11-28 at 10:03 -0800, Roper, Matthew D wrote:
> On Mon, Nov 27, 2023 at 12:11:50PM -0800, Alan Previn wrote:
> > Add missing tag for "Wa_14019159160 - Case 2" (for existing
> > PXP code that ensures run alone mode bit is set to allow
> > PxP-decryption.
alan:snip.
alan: thanks for
Original both parser->parse() and dp_power_client_init() are done at
dp_display_bind() since eDP population is done at binding time.
In the preparation of having eDP population done at probe() time,
move both function from dp_display_bind() to dp_display_probe().
Changes in v6:
-- move
EV_HPD_INIT_SETUP flag is used to trigger the initialization of external
DP host controller. Since external DP host controller initialization had
been incorporated into pm_runtime_resume(), this flag became obsolete.
msm_dp_irq_postinstall() which triggers EV_HPD_INIT_SETUP event is
obsoleted
Currently eDP population is done at msm_dp_modeset_init() which happen
at binding time. Move eDP population to be done at display probe time
so that probe deferral cases can be handled effectively.
wait_for_hpd_asserted callback is added during drm_dp_aux_init()
to ensure eDP's HPD is up before
Currently the dp_display_request_irq() is executed at
msm_dp_modeset_init() which ties irq registering to the DPU device's
life cycle, while depending on resources that are released as the DP
device is torn down. Move register DP driver irq handler to
dp_display_probe() to have
Currently DP driver is executed independent of PM runtime framework.
This leads msm eDP panel can not being detected by edp_panel driver
during generic_edp_panel_probe() due to AUX DPCD read failed at
edp panel driver. Incorporate PM runtime framework into DP driver so
that host controller's power
Currently DP driver use drm_helper_hpd_irq_event(), bypassing drm bridge
framework, to report HPD status changes to user space frame work.
Replace it with drm_bridge_hpd_notify() since DP driver is part of drm
bridge.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Dmitry Baryshkov
---
The purpose of this patch series is to incorporate pm runtime framework
into MSM eDP/DP driver so that eDP panel can be detected by DRM eDP panel
driver during system probe time. During incorporating procedure, original
customized pm realted fucntions, such as dp_pm_prepare(), dp_pm_suspend(),
The is_connected flag is set to true after DP mainlink successfully
finishes link training to enter into ST_MAINLINK_READY state rather
than being set after the DP dongle is connected. Rename the
is_connected flag with link_ready flag to match the state of DP
driver's state machine.
Changes in
On Wed, 29 Nov 2023, 何敏红 wrote:
> Friendly ping. I think this patch was forgotten.
Pushed, thanks for the patch.
>
>
>
> 主 题：[PATCH v2] drm/i915: correct the input parameter on _intel_dsb_commit()
> 日 期：2023-11-14 10:43
> 发件人：何敏红
> 收件人：何敏红;
>
> Current, the dewake_scanline variable is
On 11/28/2023 12:24 PM, Dmitry Baryshkov wrote:
On Tue, 28 Nov 2023 at 19:43, Paloma Arellano wrote:
On 11/27/2023 5:48 PM, Dmitry Baryshkov wrote:
On Tue, 28 Nov 2023 at 03:12, Paloma Arellano wrote:
Trigger a devcoredump to dump dpu registers and capture the drm atomic
state when the
On 28.11.2023 13:45, AngeloGioacchino Del Regno wrote:
> This series contains a fast fix for the basic GPU poweroff functionality
> and goes further by implementing interrupt masking and synchronization
> before suspend.
>
> For more information, please look at the conversation at [1], which
>
On Wed, 29 Nov 2023, Andy Shevchenko wrote:
> The driver uses math.h and not util_macros.h.
>
> Signed-off-by: Andy Shevchenko
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_snps_phy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Tue, 14 Nov 2023, heminhong wrote:
> Current, the dewake_scanline variable is defined as unsigned int,
> an unsigned int variable that is always greater than or equal to 0.
> when _intel_dsb_commit function is called by intel_dsb_commit function,
> the dewake_scanline variable may have an int
On Wed, Nov 29, 2023 at 05:45:14PM +0100, Flavio Suligoi wrote:
> In the function "pm3309c_parse_dt_node", when the dimming analog control
> mode (by I2C messages) is enabled, the local variable "prop_levels" is
> tested without any initialization, as indicated by the following smatch
> warning:
>
In the function "pm3309c_parse_dt_node", when the dimming analog control
mode (by I2C messages) is enabled, the local variable "prop_levels" is
tested without any initialization, as indicated by the following smatch
warning:
drivers/video/backlight/mp3309c.c:279 pm3309c_parse_dt_node() error:
On 2023-11-29 10:22, Alex Deucher wrote:
> On Wed, Nov 29, 2023 at 8:50 AM Alex Deucher wrote:
>>
>> On Tue, Nov 28, 2023 at 11:45 PM Luben Tuikov wrote:
>>>
>>> On 2023-11-28 17:13, Alex Deucher wrote:
On Mon, Nov 27, 2023 at 6:24 PM Phillip Susi wrote:
>
> Alex Deucher writes:
.get_modes = sharp_ls027b7dh01_connector_get_modes,
> +};
> +
> +static const struct drm_connector_funcs sharp_ls027b7dh01_connector_funcs = {
> + .reset = drm_atomic_helper_connector_reset,
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .destroy =
On Tue, Nov 28, 2023 at 08:48:04PM -0400, Jason Gunthorpe wrote:
> This API was defined to formalize the access to internal iommu details on
> some Tegra SOCs, but a few callers got missed. Add them.
>
> The helper already masks by 0x so remove this code from the callers.
>
> Suggested-by:
7dh01_fops,
+ DRM_GEM_DMA_DRIVER_OPS_VMAP,
+ .name = "sharp_ls027b7dh01",
+ .desc = "Sharp ls027b7dh01 Memory LCD",
+ .date = "20231129",
+ .major = 1,
+
On 2023-11-29 08:50, Alex Deucher wrote:
> On Tue, Nov 28, 2023 at 11:45 PM Luben Tuikov wrote:
>>
>> On 2023-11-28 17:13, Alex Deucher wrote:
>>> On Mon, Nov 27, 2023 at 6:24 PM Phillip Susi wrote:
Alex Deucher writes:
>> In that case those are the already known problems
On Wed, Nov 29, 2023 at 10:47 AM Christian König
wrote:
>
> Am 29.11.23 um 16:22 schrieb Nikita Zhandarovich:
> > While improbable, there may be a chance of hitting integer
> > overflow when the result of radeon_get_ib_value() gets shifted
> > left.
> >
> > Avoid it by casting one of the operands
Get the global screen_info's address once and access the data via
this pointer. Limits the use of global state.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/efifb.c | 113 ++--
1 file changed, 58 insertions(+), 55 deletions(-)
diff --git
Use the screen_info instance from the device instead of dereferencing
the global screen_info state. Decouples the driver from per-architecture
code. Duplicated the screen_info data, so that efifb can modify it at
will.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/efifb.c | 9
Get the global screen_info's address once and access the data via
this pointer. Limits the use of global state.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/vesafb.c | 66 +++-
1 file changed, 35 insertions(+), 31 deletions(-)
diff --git
Hi,
On Wed, 29 Nov 2023 17:07:15 +0800, Yang Yingliang wrote:
> mipi_dsi_device_register_full() never returns NULL pointer, it
> will return ERR_PTR() when it fails, so replace the check with
> IS_ERR().
>
>
Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git
Use the screen_info instance from the device instead of dereferencing
the global screen_info state. Decouples the driver from per-architecture
code. Duplicated the screen_info data, so that vesafb can modify it at
will.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/vesafb.c | 9
Replace the global instance of screen_info with the per-device instance
that is set by the sysfb code. The use of the global screen_info should
be limited and ideally be pushed into per-architecture code.
Thomas Zimmermann (4):
fbdev/efifb: Replace references to global screen_info by local
On 29/11/2023 10:07, Yang Yingliang wrote:
From: Yang Yingliang
mipi_dsi_device_register_full() never returns NULL pointer, it
will return ERR_PTR() when it fails, so replace the check with
IS_ERR().
Fixes: 0993234a0045 ("drm/panel: Add driver for Novatek NT36523")
Signed-off-by: Yang
Hi,
On Wed, 29 Nov 2023 16:41:15 +0800, xiazhengqiao wrote:
> For the "starry, 2081101qfh032011-53g" panel, it is stipulated in the
> panel spec that MIPI needs to keep the LP11 state before the
> lcm_reset pin is pulled high.
>
>
Thanks, Applied to
On Wed, 29 Nov 2023 16:15:27 +0100
Maxime Ripard wrote:
> > Now, let's assume we drop the _locked() suffix on
> > drm_gem_shmem_v[un]map(), but keep it on other helpers that need both
> > variants. This results in an inconsistent naming scheme inside the
> > same source file, which I find
Am 29.11.23 um 16:22 schrieb Nikita Zhandarovich:
While improbable, there may be a chance of hitting integer
overflow when the result of radeon_get_ib_value() gets shifted
left.
Avoid it by casting one of the operands to larger data type (u64).
Found by Linux Verification Center
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202311242159.hh8mwiam-...@intel.com/
Fixes: 3c96dd170efe ("drm/imagination: Add GEM and VM related code")
Signed-off-by: Donald Robson
---
drivers/gpu/drm/imagination/pvr_vm.c | 6 --
1 file changed, 6
Reported-by: Arnd Bergmann
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202311242159.hh8mwiam-...@intel.com/
Fixes: 3c96dd170efe ("drm/imagination: Add GEM and VM related code")
Signed-off-by: Donald Robson
---
drivers/gpu/drm/imagination/pvr_vm.c | 2 +-
1
1 - 100 of 213 matches
Mail list logo
