On 2022/11/8 14:10, Nicolin Chen wrote:
On Mon, Nov 07, 2022 at 08:52:51PM -0400, Jason Gunthorpe wrote:
@@ -795,6 +800,10 @@ static int vfio_device_first_open(struct vfio_device
*device)
ret = vfio_group_use_container(device->group);
if (ret)
On 2022.09.26 14:40:43 +0800, Jiapeng Chong wrote:
> The function get_pt_type is defined in the gtt.c file, but not
> called elsewhere, so delete this unused function.
>
> drivers/gpu/drm/i915/gvt/gtt.c:285:19: warning: unused function 'get_pt_type'.
>
> Link: https://bugzilla.openanolis.cn/show_
On 2022.10.22 14:13:27 +0800, wangjianli wrote:
> Delete the redundant word 'the'.
>
> Signed-off-by: wangjianli
> ---
> drivers/gpu/drm/i915/gvt/gtt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
> inde
On 2022.10.30 16:36:28 +1300, Paulo Miguel Almeida wrote:
> struct gvt_firmware_header has a crc32 member in which all members that
> come after the that field are used to calculate it. The previous
> implementation added the value '4' (crc32's u32 size) to calculate the
> crc32_start offset which
Hey Dave,
This is the pull request for a whole bunch of fixes and prep-work that
was done to support Ampere acceleration prior to GSP-RM being
available. It uses the ACR firmware released by NVIDIA in
linux-firmware, as we do on earlier GPUs. The work to support running
on top of GSP-RM also hea
On Mon, Nov 07, 2022 at 08:52:51PM -0400, Jason Gunthorpe wrote:
> @@ -795,6 +800,10 @@ static int vfio_device_first_open(struct vfio_device
> *device)
> ret = vfio_group_use_container(device->group);
> if (ret)
> goto err_module_put;
> + } el
Am 2022-11-07 um 14:58 schrieb Christian König:
If we got a page pool use it as much as possible.
If we can't get more pages from the pool allocate as much as possible.
Only if that still doesn't work reduce the order and try again.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/t
Hi David,
On Tue, Nov 8, 2022 at 1:19 AM David Hildenbrand wrote:
>
> FOLL_FORCE is really only for debugger access. According to commit
> 707947247e95 ("media: videobuf2-vmalloc: get_userptr: buffers are always
> writable"), the pinned pages are always writable.
Actually that patch is only a wo
devm_gpiod_get_from_of_node() is going away and GPIO consumers should
use generic device/firmware node APIs to fetch GPIOs assigned to them.
Switch the driver to use devm_fwnode_gpiod_get() instead.
Signed-off-by: Dmitry Torokhov
---
Marked as "resend" since the contents of the patch are the sam
On Thu, Nov 3, 2022 at 11:23 PM Mauro Carvalho Chehab
wrote:
>
> Hi,
>
> I'm facing a couple of issues when testing KUnit with the i915 driver.
>
> The DRM subsystem and the i915 driver has, for a long time, his own
> way to do unit tests, which seems to be added before KUnit.
>
> I'm now checking
On Mon, Nov 7, 2022 at 4:22 PM Jessica Zhang wrote:
>
>
>
> On 11/7/2022 2:09 PM, Rob Clark wrote:
> > On Mon, Nov 7, 2022 at 1:32 PM Jessica Zhang
> > wrote:
> >>
> >>
> >>
> >> On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
> >>> On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
> >>
when goto err_free, the object had init, so it should be release when fail.
Signed-off-by: ChunyouTang
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper
when goto err_free, the object had init, so it should be release when fail.
Signed-off-by: ChunyouTang
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper
when goto err_free, the object had init, so it should be release when fail.
Signed-off-by: ChunyouTang
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper
On Fri, Nov 4, 2022 at 12:20 PM Daniel Latypov wrote:
> rm...@google.com was working on them and should hopefully be able to
> send them out real soon.
> You should get CC'd on those.
>
> I think the follow-up work is just crafting an example parser input
> file and iterating until
> $ ./tools/t
On Mon, 2022-11-07 at 00:52 -0800, Niranjana Vishwanathapura wrote:
> Asynchronously unbind the vma upon vm_unbind call.
> Fall back to synchronous unbind if backend doesn't support
> async unbind or if async unbind fails.
>
> No need for vm_unbind out fence support as i915 will internally
> handl
Fixs the function name in kernel-doc comments to clear the below
warnings:
drivers/gpu/drm/i915/gt/intel_engine_cs.c:1295: warning: expecting prototype
for intel_engines_init_common(). Prototype was for engine_init_common() instead
drivers/gpu/drm/i915/gt/intel_engine_cs.c:1377: warning: expectin
This series provides an alternative container layer for VFIO implemented
using iommufd. This is optional, if CONFIG_IOMMUFD is not set then it will
not be compiled in.
At this point iommufd can be injected by passing in a iommfd FD to
VFIO_GROUP_SET_CONTAINER which will use the VFIO compat layer i
This error unwind is getting complicated. Move all the code into two
pair'd function. The functions should be called when the open_count == 1
after incrementing/before decrementing.
Reviewed-by: Kevin Tian
Reviewed-by: Yi Liu
Tested-by: Nicolin Chen
Signed-off-by: Jason Gunthorpe
---
drivers/
iommufd doesn't establish the iommu_domains until after the device FD is
opened, even if the container has been set. This design is part of moving
away from the group centric iommu APIs.
This is fine, except that the normal sequence of establishing the kvm
wbinvd won't work:
group = open("/dev
This creates the iommufd_device for the physical VFIO drivers. These are
all the drivers that are calling vfio_register_group_dev() and expect the
type1 code to setup a real iommu_domain against their parent struct
device.
The design gives the driver a choice in how it gets connected to iommufd
by
Add a kconfig CONFIG_VFIO_CONTAINER that controls compiling the container
code. If 'n' then only iommufd will provide the container service. All the
support for vfio iommu drivers, including type1, will not be built.
This allows a compilation check that no inappropriate dependencies between
the de
The only thing this function does is assert the group has an assigned
container and incrs refcounts.
The overall model we have is that once a container_users refcount is
incremented it cannot be de-assigned from the group -
vfio_group_ioctl_unset_container() will fail and the group FD cannot be
cl
Emulated VFIO devices are calling vfio_register_emulated_iommu_dev() and
consist of all the mdev drivers.
Like the physical drivers, support for iommufd is provided by the driver
supplying the correct standard ops. Provide ops from the core that
duplicate what vfio_register_emulated_iommu_dev() do
The miscdev is in container.c, so should these related MODULE_ALIAS
statements. This is necessary for the next patch to be able to fully
disable /dev/vfio/vfio.
Fixes: cdc71fe4ecbf ("vfio: Move container code into drivers/vfio/container.c")
Reported-by: "Liu, Yi L"
Signed-off-by: Jason Gunthorpe
This legacy module knob has become uAPI, when set on the vfio_iommu_type1
it disables some security protections in the iommu drivers. Move the
storage for this knob to vfio_main.c so that iommufd can access it too.
The may need enhancing as we learn more about how necessary
allow_unsafe_interrupts
These functions don't really assign anything anymore, they just increment
some refcounts and do a sanity check. Call them
vfio_group_[un]use_container()
Reviewed-by: Kevin Tian
Reviewed-by: Yi Liu
Tested-by: Nicolin Chen
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/container.c | 14 ++-
This makes VFIO_GROUP_SET_CONTAINER accept both a vfio container FD and an
iommufd.
In iommufd mode an IOAS will exist after the SET_CONTAINER, but it will
not be attached to any groups.
For VFIO this means that the VFIO_GROUP_GET_STATUS and
VFIO_GROUP_FLAGS_VIABLE works subtly differently. With
If the VFIO container is compiled out, give a kconfig option for iommufd
to provide the miscdev node with the same name and permissions as vfio
uses.
The compatibility node supports the same ioctls as VFIO and automatically
enables the VFIO compatible pinned page accounting mode.
Tested-by: Nicol
There were several updates in the driver on how the workarounds are
handled since its documentation was written. Update the documentation to
reflect the current reality.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 87 +
1 file changed, 56
On 11/7/2022 2:09 PM, Rob Clark wrote:
On Mon, Nov 7, 2022 at 1:32 PM Jessica Zhang wrote:
On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
properties. When the color
appending amdgpu.runpm=0 to the bootargs, it was a suggestion as I
have to append pcie_aspm=off. I get further, and despite a lot of
noise X starts
[ 19.501645] [drm] amdgpu kernel modesetting enabled.
[ 19.515932] amdgpu: CRAT table disabled by module option
[ 19.522205] amdgpu: IO link not
Mr
November 3, 2022 at 8:22 PM, "Sean Anderson" mailto:sean.ander...@seco.com?to=%22Sean%20Anderson%22%20%3Csean.anderson%40seco.com%3E
> wrote:
>
> Every user of this function either uses component_compare_of or
> something equivalent. Most of them immediately put the device node as
> well. Conver
Panel is 800x1280 but mounted on a detachable form factor sidways.
Signed-off-by: Allen Ballway
---
.../gpu/drm/drm_panel_orientation_quirks.c| 20 ---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gp
November 7, 2022 at 7:52 PM, "Paul Cercueil" mailto:p...@crapouillou.net?to=%22Paul%20Cercueil%22%20%3Cpaul%40crapouillou.net%3E
> wrote:
>
> Use the DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr() macros to handle
> the .suspend/.resume callbacks.
>
> These macros allow the suspend and resume fu
When converting from .txt to .yaml we didn't include descriptions for the
existing regulator supplies.
- vdd
- vdda
- vddio
Add those descriptions into the yaml now as they were prior to the
conversion. Mark the supplies as required as was previously the case in the
.txt implementation.
Warnings
Sort the order of the compatible strings alphanumerically.
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Rob Herring
Cc: Krzysztof Kozlowski
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists
There's a typo in describing the core clock as an 'escape' clock. The
accurate description is 'core'.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Rob
When converting from .txt to .yaml dt-binding descriptions we appear to
have missed some of the previous detail on the number and names of
permissible clocks.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Reviewed-by: Dmitry Baryshkov
Cc: Rob Clark
Cc: Abhinav
Currently we do not differentiate between the various users of the
qcom,mdss-dsi-ctrl. The driver is flexible enough to operate from one
compatible string but, the hardware does have some significant differences
in the number of clocks.
To facilitate documenting the clocks add the following compat
Each compatible has a different set of clocks which are associated with it.
Add in the list of clocks for each compatible.
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Rob Herring
Cc: Krzysztof Kozlowski
Cc: linux-arm-...@vger.ke
power-domain is required for the sc7180 dispcc GDSC but not every qcom SoC
has a similar dependency for example the aqp8064.
Most Qcom SoC's using mdss-dsi-ctrl seem to have the ability to
power-collapse the MDP without collapsing DSI.
For example the qcom vendor kernel commit for apq8084, msm822
The existing msm8916.dtsi does not depend on nor require operating points.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Reviewed-by: Dmitry Baryshkov
Acked-by: Krzysztof Kozlowski
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Sean Paul
Cc: David
On Wed, Nov 02, 2022 at 03:28:20PM +0800, Yi Liu wrote:
> On 2022/10/26 02:50, Jason Gunthorpe wrote:
> > This makes VFIO_GROUP_SET_CONTAINER accept both a vfio container FD and an
> > iommufd.
> >
> > In iommufd mode an IOAS will exist after the SET_CONTAINER, but it will
> > not be attached to a
On Mon, Nov 07, 2022 at 07:43:59PM +0530, Iddamsetty, Aravind wrote:
>
>
> On 31-10-2022 23:16, Matt Roper wrote:
> > On Mon, Oct 31, 2022 at 06:01:11PM +0530, Aravind Iddamsetty wrote:
> >> On XE_LPM+ platforms the media engines are carved out into a separate
> >> GT but have a common GGTMMADR a
On Mon, Nov 7, 2022 at 10:38 AM Michał Winiarski
wrote:
>
> On Thu, Nov 03, 2022 at 04:23:02PM +0100, Mauro Carvalho Chehab wrote:
> > Hi,
> >
> > I'm facing a couple of issues when testing KUnit with the i915 driver.
> >
> > The DRM subsystem and the i915 driver has, for a long time, his own
> >
On Mon, Nov 07, 2022 at 09:37:08PM +0200, Ville Syrjälä wrote:
> On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
> > Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
> > properties. When the color fill value is set, and the framebuffer is set
> > to NULL, memory fetch w
On 07/11/2022 07:27, Abhinav Kumar wrote:
On 9/22/2022 4:30 AM, Dmitry Baryshkov wrote:
SM8350 and SM8450 use 5nm DSI PHYs, which share register definitions
with 7nm DSI PHYs. Rather than duplicating the driver, handle 5nm
variants inside the common 5+7nm driver.
I do realize that there is c
v3d_perfmon_open_file() instantiates a mutex for a particular file
instance, but it never destroys it by calling mutex_destroy() in
v3d_perfmon_close_file().
Similarly, v3d_perfmon_create_ioctl() instantiates a mutex for a
particular perfmon, but it never destroys it by calling mutex_destroy()
in
mutex_init() is supposed to be balanced by a call to mutex_destroy(), but
this is not currently happening on the v3d driver.
Considering the introduction of a DRM-managed mutex_init variant, switch
to drmm_mutex_init.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_gem.c | 17 +++
This series introduces some changes to assure the correct resource release on
the V3D driver, especially the mutex. Currently, the V3D has no mutex_destroy()
calls, which means that a mutex is being instantiated, but it is not being
released by the end of its use.
So, use the DRM-managed mutex_ini
On 2022-11-07 14:58, Christian König wrote:
> If we got a page pool use it as much as possible.
>
> If we can't get more pages from the pool allocate as much as possible.
>
> Only if that still doesn't work reduce the order and try again.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/
On Mon, Nov 7, 2022 at 1:32 PM Jessica Zhang wrote:
>
>
>
> On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
> > On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
> >> Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
> >> properties. When the color fill value is set, and the
On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
properties. When the color fill value is set, and the framebuffer is set
to NULL, memory fetch will be disabled.
Thinking
On Mon, Nov 7, 2022 at 6:19 PM David Hildenbrand wrote:
>
> FOLL_FORCE is really only for debugger access. As we unpin the pinned pages
> using unpin_user_pages_dirty_lock(true), the assumption is that all these
> pages are writable.
>
> FOLL_FORCE in this case seems to be due to copy-and-past fro
Thierry,
On 21/10/2022 08:41, Jon Hunter wrote:
On 20/10/2022 15:23, Robin Murphy wrote:
Since commit c7e3ca515e78 ("iommu/tegra: gart: Do not register with
bus") quite some time ago, the GART driver has effectively disabled
itself to avoid issues with the GPU driver expecting it to work in wa
On Mon, Nov 7, 2022 at 6:20 PM Jeffrey Hugo wrote:
>
> On 11/6/2022 2:02 PM, Oded Gabbay wrote:
> > --- a/drivers/accel/drm_accel.c
> > +++ b/drivers/accel/drm_accel.c
> > @@ -8,14 +8,25 @@
> >
> > #include
> > #include
> > +#include
>
> If we are not using xarray at this time, do we still
On Mon, Nov 7, 2022 at 6:12 PM Jeffrey Hugo wrote:
>
> On 11/6/2022 2:02 PM, Oded Gabbay wrote:
> > +int __init accel_core_init(void)
> > +{
> > + int ret;
> > +
> > + ret = accel_sysfs_init();
> > + if (ret < 0) {
> > + DRM_ERROR("Cannot create ACCEL class: %d\n", ret);
>
On Mon, Nov 7, 2022 at 6:25 PM Jeffrey Hugo wrote:
>
> On 11/6/2022 2:02 PM, Oded Gabbay wrote:
>
> > @@ -603,6 +626,14 @@ static int drm_dev_init(struct drm_device *dev,
> > /* no per-device feature limits by default */
> > dev->driver_features = ~0u;
> >
> > + if (drm_core_check_
Hi Lucas,
Le lun. 7 nov. 2022 à 19:07:32 +0100, Lucas Stach
a écrit :
Am Montag, dem 07.11.2022 um 17:52 + schrieb Paul Cercueil:
Use the RUNTIME_PM_OPS() and pm_ptr() macros to handle the
.runtime_suspend/.runtime_resume callbacks.
These macros allow the suspend and resume functions
Hi Rodrigo,
Le lun. 7 nov. 2022 à 15:31:49 -0500, Rodrigo Vivi
a écrit :
On Mon, Nov 07, 2022 at 05:55:10PM +, Paul Cercueil wrote:
Instead of defining two versions of intel_sysfs_rc6_init(), one for
each
value of CONFIG_PM, add a check on !IS_ENABLED(CONFIG_PM) early in
the
function.
Maxime Ripard writes:
> Hi,
>
> On Fri, Nov 04, 2022 at 05:35:29PM +, Aidan MacDonald wrote:
>>
>> Maxime Ripard writes:
>>
>> > Hi Paul,
>> >
>> > On Fri, Nov 04, 2022 at 02:31:20PM +, Paul Cercueil wrote:
>> >> Le ven. 4 nov. 2022 à 14:18:13 +0100, Maxime Ripard a
>> >> écrit :
>> >
On 11/7/22 16:30, Thomas Zimmermann wrote:
Hi
Am 07.11.22 um 14:57 schrieb Helge Deller:
On 11/7/22 11:49, Thomas Zimmermann wrote:
Support the kernel's nomodeset parameter for all PCI-based fbdev
drivers that use aperture helpers to remove other, hardware-agnostic
graphics drivers.
The param
> > >
> > > "drm_minor" is not necessary anymore. Strictly managing minor numbers
> > > lost its value years ago when /dev/ was reorganized. Just use
> > > dynamic minors fully.
> > drm minor is not just about handling minor numbers. It contains the
> > entire code to manage devices that register w
On Mon, Nov 07, 2022 at 05:55:10PM +, Paul Cercueil wrote:
> Instead of defining two versions of intel_sysfs_rc6_init(), one for each
> value of CONFIG_PM, add a check on !IS_ENABLED(CONFIG_PM) early in the
> function. This will allow the compiler to automatically drop the dead
> code when CONF
On 11/6/2022 19:29, Stephen Rothwell wrote:
Hi all,
After merging the drm tree, today's linux-next build (KCONFIG_NAME)
produced this warning:
drivers/gpu/drm/i915/i915_perf_types.h:319: warning: Function parameter or
member 'lock' not described in 'i915_perf_stream'
Introduced by commit
On Mon, 7 Nov 2022 at 23:10, Jason Gunthorpe wrote:
>
> On Mon, Nov 07, 2022 at 03:01:08PM +0200, Oded Gabbay wrote:
> > I don't agree with your statement that it should be "a layer over top of
> > DRM".
> > Anything on top of DRM is a device driver.
> > Accel is not a device driver, it is a new
On Fri, Nov 04, 2022 at 09:42:03AM -0400, Krzysztof Kozlowski wrote:
> On 04/11/2022 02:44, Sandor Yu wrote:
> > Add bindings for i.MX8MQ MHDP HDMI.
>
> Typo in subject - bindings.
And 'dts'. It's 'dt-bindings: display: ...' Same for the rest of the
series.
>
> Also in the subject - drop redun
On Fri, 28 Oct 2022 at 20:19, Jonathan Corbet wrote:
>
> Daniel Vetter writes:
>
> > We love to nest our documenation for good structure, but that means
> > the table of contents needs to keep up or you can't navigate them.
> >
> > Realized this trying to find the drm property documentation, whic
If we got a page pool use it as much as possible.
If we can't get more pages from the pool allocate as much as possible.
Only if that still doesn't work reduce the order and try again.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 81 --
1
On Nov 7, 2022, at 11:27 AM, David Hildenbrand wrote:
> !! External Email
>
> On 07.11.22 20:03, Nadav Amit wrote:
>> On Nov 7, 2022, at 8:17 AM, David Hildenbrand wrote:
>>
>>> !! External Email
>>>
>>> Let's catch abuse of FAULT_FLAG_WRITE early, such that we don't have to
>>> care in all o
On 11/7/2022 06:09, Tvrtko Ursulin wrote:
On 04/11/2022 17:45, John Harrison wrote:
On 11/4/2022 03:01, Tvrtko Ursulin wrote:
On 03/11/2022 19:16, John Harrison wrote:
On 11/3/2022 02:38, Tvrtko Ursulin wrote:
On 03/11/2022 09:18, Tvrtko Ursulin wrote:
On 03/11/2022 01:33, John Harrison wrot
Hi,
On 11/7/22 18:55, Paul Cercueil wrote:
> Use the pm_ptr() macro to handle the .suspend / .resume / .reset_resume
> callbacks.
>
> This macro allows the suspend and resume functions to be automatically
> dropped by the compiler when CONFIG_PM is disabled, without having
> to use #ifdef guards.
Hi,
On 11/7/22 18:52, Paul Cercueil wrote:
> Use the pm_sleep_ptr() macro to handle the .suspend / .resume callbacks.
>
> This macro allows the suspend and resume functions to be automatically
> dropped by the compiler when CONFIG_SUSPEND is disabled, without having
> to use #ifdef guards.
>
> T
On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
> Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
> properties. When the color fill value is set, and the framebuffer is set
> to NULL, memory fetch will be disabled.
Thinking a bit more universally I wonder if there sho
On Mon, Nov 7, 2022 at 6:31 PM Jason Gunthorpe wrote:
>
> On Mon, Nov 07, 2022 at 05:53:55PM +0200, Oded Gabbay wrote:
> > On Mon, Nov 7, 2022 at 4:10 PM Jason Gunthorpe wrote:
> > >
> > > On Mon, Nov 07, 2022 at 04:02:01PM +0200, Oded Gabbay wrote:
> > > > On Mon, Nov 7, 2022 at 3:10 PM Jason Gu
On 07.11.22 20:03, Nadav Amit wrote:
On Nov 7, 2022, at 8:17 AM, David Hildenbrand wrote:
!! External Email
Let's catch abuse of FAULT_FLAG_WRITE early, such that we don't have to
care in all other handlers and might get "surprises" if we forget to do
so.
Write faults without VM_MAYWRITE don
From: Ville Syrjälä
Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head.
Based on the following cocci script, with manual fixups:
@decl@
identifier M;
expression E;
@@
- struct drm_display_mode M = E;
+ struct drm_display_mode M;
@@
identifier decl.M;
e
From: Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destinat
From: Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destinat
From: Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destinat
From: Ville Syrjälä
Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head, or that we aren't copying
over another mode's list head.
Based on the following cocci script, with manual fixups:
@decl@
identifier M;
expression E;
@@
- struct drm_display_mode M =
From: Ville Syrjälä
Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head.
Cc: Xinliang Liu
Cc: Tian Tao
Cc: John Stultz
Cc: Xinwei Kong
Cc: Chen Feng
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 2 +-
1 file chang
From: Ville Syrjälä
Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head, or that we aren't copying
over another mode's list head.
Based on the following cocci script, with manual fixups:
@decl@
identifier M;
expression E;
@@
- struct drm_display_mode M =
From: Ville Syrjälä
Repost of the stragglers from
https://patchwork.freedesktop.org/series/100393/
Note that I didn't rerun the cocci stuff, nor have I had
time to come up with something to inluce the cocci scripts
in the tree. So it's possible this is missing some new
things that have snuck in
On Mon, Nov 7, 2022 at 6:20 PM Matthew Wilcox wrote:
>
> On Sun, Nov 06, 2022 at 04:51:39PM +0200, Oded Gabbay wrote:
> > I tried executing the following code in a dummy driver I wrote:
>
> You don't need to write a dummy driver; you can write test-cases
> entirely in userspace. Just add them to
On 11/7/2022 08:17, Tvrtko Ursulin wrote:
On 07/11/2022 09:33, Tvrtko Ursulin wrote:
On 05/11/2022 01:03, Ceraolo Spurio, Daniele wrote:
On 11/4/2022 10:25 AM, john.c.harri...@intel.com wrote:
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult
On Mon, Nov 7, 2022 at 1:29 AM Maxime Ripard wrote:
>
> On Thu, Oct 27, 2022 at 08:08:28AM -0700, Rob Clark wrote:
> > On Wed, Oct 26, 2022 at 1:17 AM wrote:
> > >
> > > Hi Rob,
> > >
> > > On Mon, Oct 24, 2022 at 08:48:15AM -0700, Rob Clark wrote:
> > > > On Mon, Oct 24, 2022 at 5:43 AM wrote:
This was lost in the code movement done in 8ab59da26bc0
("drm/fb-helper: Move generic fbdev emulation into separate source
file").
Fixes: 8ab59da26bc0 ("drm/fb-helper: Move generic fbdev emulation into separate
source file")
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Signed-off-by: Dani
On Nov 7, 2022, at 8:17 AM, David Hildenbrand wrote:
> !! External Email
>
> Let's catch abuse of FAULT_FLAG_WRITE early, such that we don't have to
> care in all other handlers and might get "surprises" if we forget to do
> so.
>
> Write faults without VM_MAYWRITE don't make any sense, and our
On Mon, Nov 07, 2022 at 11:05:08AM -0700, Alex Williamson wrote:
> After further consideration... I don't think the option on vfio-main
> makes sense, basically for the same reason that the original option
> existed on the IOMMU backend rather than vfio-core. The option
> describes a means to rel
On Thu, Nov 03, 2022 at 04:23:02PM +0100, Mauro Carvalho Chehab wrote:
> Hi,
>
> I'm facing a couple of issues when testing KUnit with the i915 driver.
>
> The DRM subsystem and the i915 driver has, for a long time, his own
> way to do unit tests, which seems to be added before KUnit.
>
> I'm no
On Wed, Nov 02, 2022 at 10:10:45AM -0700, Daniele Ceraolo Spurio wrote:
> The GSC CS re-uses the same interrupt bits that the GSC used in older
> platforms. This means that we can now have an engine interrupt coming
> out of OTHER_CLASS, so we need to handle that appropriately.
>
> v2: clean up th
Den 07.11.2022 15.16, skrev Maxime Ripard:
> From: Noralf Trønnes
>
> Most of the TV connectors will need a similar get_modes implementation
> that will, depending on the drivers' capabilities, register the 480i and
> 576i modes.
>
> That implementation will also need to set the preferred fla
On Mon, Nov 07, 2022 at 05:50:48PM +, Paul Cercueil wrote:
> Use the DEFINE_SIMPLE_DEV_PM_OPS() and pm_sleep_ptr() macros to handle
> the .suspend/.resume callbacks.
>
> These macros allow the suspend and resume functions to be automatically
> dropped by the compiler when CONFIG_SUSPEND is dis
Am Montag, dem 07.11.2022 um 17:52 + schrieb Paul Cercueil:
> Use the RUNTIME_PM_OPS() and pm_ptr() macros to handle the
> .runtime_suspend/.runtime_resume callbacks.
>
> These macros allow the suspend and resume functions to be automatically
> dropped by the compiler when CONFIG_PM is disable
On Mon, 7 Nov 2022 11:32:40 -0400
Jason Gunthorpe wrote:
> On Mon, Nov 07, 2022 at 08:18:53AM -0700, Alex Williamson wrote:
> > On Mon, 7 Nov 2022 09:19:43 -0400
> > Jason Gunthorpe wrote:
> >
> > > On Mon, Oct 31, 2022 at 04:45:26PM -0600, Alex Williamson wrote:
> > >
> > > > > It is one
Den 07.11.2022 15.16, skrev Maxime Ripard:
> Now that we can easily extend the named modes list, let's add a few more
> analog TV modes that were used in the wild, and some unit tests to make
> sure it works as intended.
>
> Signed-off-by: Maxime Ripard
>
> ---
> Changes in v6:
> - Renamed th
1 - 100 of 307 matches
Mail list logo
