On 2022/11/15 15:05, Helge Deller wrote:
On 11/15/22 07:52, shangxiaojing wrote:
On 2022/11/15 13:14, Helge Deller wrote:
On 11/15/22 03:53, Shang XiaoJing wrote:
Due to viafb_exit() with "__exit" tag, it should not be called by the
__init function via_core_init().
I wonder if you
On 11/15/22 07:52, shangxiaojing wrote:
On 2022/11/15 13:14, Helge Deller wrote:
On 11/15/22 03:53, Shang XiaoJing wrote:
Due to viafb_exit() with "__exit" tag, it should not be called by the
__init function via_core_init().
I wonder if you can't instead of this and your previous patch
The last user of macros from that include was removed in 2018 by the
commit below.
Fixes: 6cc42152b02b ("drm/i915: Remove support for legacy debugfs crc
interface")
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: David Airlie
Cc: Daniel Vetter
Cc:
On Tue, Nov 08, 2022 at 09:49:45AM +, Tvrtko Ursulin wrote:
On 07/11/2022 17:32, Lucas De Marchi wrote:
That section should still be inside "DRM client usage stats" rather than
as a sibling.
Signed-off-by: Lucas De Marchi
---
Documentation/gpu/drm-usage-stats.rst | 1 -
1 file changed,
On 2022/11/15 13:14, Helge Deller wrote:
On 11/15/22 03:53, Shang XiaoJing wrote:
Due to viafb_exit() with "__exit" tag, it should not be called by the
__init function via_core_init().
I wonder if you can't instead of this and your previous patch
(ab885d8c7e15)
turn the i2c and gpio
Set support_hdcp so the connector can register content protect proterty
when it's initializing.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Sean Paul
---
v4->v5: no change
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 1 +
1 file changed, 1 insertion(+)
diff --git
it6505 supports HDCP 1.3, but current implementation lacks the update of
HDCP status through drm_hdcp_update_content_protection(). it6505 default
enables the HDCP. If user set it to undesired then the driver will stop
HDCP.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: allen chen
---
v4->v5: no
Some bridges are able to update HDCP status from userspace request if
they support HDCP.
HDCP property is the same as other connector properties that needs to be
created after the connecter is initialized and before the connector is
registered.
If there exists a bridge that supports HDCP, add
On 2022/11/14 22:37, Yang, Lixiao wrote:
> On 2022/11/14 20:51, Yi Liu wrote:
>> On 2022/11/10 00:57, Jason Gunthorpe wrote:
>>> On Tue, Nov 08, 2022 at 11:18:03PM +0800, Yi Liu wrote:
On 2022/11/8 17:19, Nicolin Chen wrote:
> On Mon, Nov 07, 2022 at 08:52:44PM -0400, Jason Gunthorpe
On 11/15/22 03:53, Shang XiaoJing wrote:
Due to viafb_exit() with "__exit" tag, it should not be called by the
__init function via_core_init().
I wonder if you can't instead of this and your previous patch (ab885d8c7e15)
turn the i2c and gpio drivers to proper platform drivers, e.g.
adding to
Hi Robert,
On Sat, 12 Nov 2022 19:42:10 + Robert Swindells wrote:
>
> Contributors to these files are:
>
> Stephen Rothwell
I don't think my (1 line) contribution is even copyrightable, but anyway
Acked-by: Stephen Rothwell
--
Cheers,
Stephen Rothwell
pgpieGqz3_45S.pgp
Description:
Due to viafb_exit() with "__exit" tag, it should not be called by the
__init function via_core_init().
WARNING: modpost: drivers/video/fbdev/via/viafb.o: section mismatch in
reference: init_module (section: .init.text) -> viafb_exit (section:
.exit.text)
Fixes: ab885d8c7e15 ("fbdev: via: Fix
Make the description of @init to @p in dpu_encoder_phys_wb_init()
and remove @wb_roi in dpu_encoder_phys_wb_setup_fb() to clear the below
warnings:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c:139: warning: Excess
function parameter 'wb_roi' description in 'dpu_encoder_phys_wb_setup_fb'
On 11/9/22 11:57 AM, Jason Gunthorpe wrote:
> On Tue, Nov 08, 2022 at 11:18:03PM +0800, Yi Liu wrote:
>> On 2022/11/8 17:19, Nicolin Chen wrote:
>>> On Mon, Nov 07, 2022 at 08:52:44PM -0400, Jason Gunthorpe wrote:
>>>
This is on github: https://github.com/jgunthorpe/linux/commits/vfio_iommufd
On 11/10/22 16:51, Alistair Popple wrote:
migrate_vma->cpages originally contained a count of the number of
pages migrating including non-present pages which can be poluated
"populated"
directly on the target.
Commit 241f68859656 ("mm/migrate_device.c: refactor migrate_vma and
There are still regular bug reports about monitors (sinks) and sources
disagreeing about the quantization range of the pixel data. In
particular sources sending full range data when the sink expects
limited range. From a user space perspective, this is all hidden in
the kernel. We send full range
https://bugzilla.kernel.org/show_bug.cgi?id=216143
--- Comment #17 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 303181
--> https://bugzilla.kernel.org/attachment.cgi?id=303181=edit
kernel .config (kernel 6.1-rc5, AMD Ryzen 9 5950X)
--
You may reply to this email to add a
https://bugzilla.kernel.org/show_bug.cgi?id=216143
--- Comment #16 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 303180
--> https://bugzilla.kernel.org/attachment.cgi?id=303180=edit
kernel dmesg (kernel 6.1-rc5, AMD Ryzen 9 5950X)
Reinvestigating on kernel 6.1-rc5 built with
There's been a very long running bug that seems to have been neglected for
a while, where amdgpu consistently triggers a KASAN error at start:
BUG: KASAN: global-out-of-bounds in read_indirect_azalia_reg+0x1d4/0x2a0
[amdgpu]
Read of size 4 at addr c2274b28 by task modprobe/1889
This bug hurt me. Basically, it appears that we've been grabbing the
entirely wrong mutex in the MST DSC computation code for amdgpu! While
we've been grabbing:
amdgpu_dm_connector->mst_mgr
That's zero-initialized memory, because the only connectors we'll ever
actually be doing DSC
Now that we've fixed the issue with using the incorrect topology manager,
we're actually grabbing the topology manager's lock - and consequently
deadlocking. Luckily for us though, there's actually nothing in AMD's DSC
state computation code that really should need this lock. The one exception
is
Looks like that we're accidentally dropping a pretty important return code
here. For some reason, we just return -EINVAL if we fail to get the MST
topology state. This is wrong: error codes are important and should never
be squashed without being handled, which here seems to have the potential
to
It appears that amdgpu makes the mistake of completely ignoring the return
values from the DP MST helpers, and instead just returns a simple
true/false. In this case, it seems to have come back to bite us because as
a result of simply returning false from
compute_mst_dsc_configs_for_state(),
On 11/10/2022 01:43, Tvrtko Ursulin wrote:
On 09/11/2022 17:46, John Harrison wrote:
On 11/9/2022 03:05, Tvrtko Ursulin wrote:
On 08/11/2022 20:15, John Harrison wrote:
On 11/8/2022 01:01, Tvrtko Ursulin wrote:
On 07/11/2022 19:14, John Harrison wrote:
On 11/7/2022 08:17, Tvrtko Ursulin
On 11/10/2022 02:33, Jani Nikula wrote:
On Wed, 09 Nov 2022, Michal Wajdeczko wrote:
Instead of merging this patch now, oriented on GT only, I would rather
wait until we discuss and plan solution for the all sub-components.
Once that's done (with agreement on naming and output) we can start
Hi,
On Mon, Nov 14, 2022 at 2:02 AM Jani Nikula wrote:
>
> On Fri, 11 Nov 2022, Doug Anderson wrote:
> > Hi,
> >
> > On Tue, Oct 25, 2022 at 1:39 PM Abhinav Kumar
> > wrote:
> >>
> >> Hi Doug
> >>
> >> On 10/24/2022 1:28 PM, Doug Anderson wrote:
> >> > Hi,
> >> >
> >> > On Fri, Oct 21, 2022
Hi all,
On Wed, Nov 02, 2022 at 08:56:23AM -0700, Nathan Chancellor wrote:
> With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
> indirect call targets are validated against the expected function
> pointer prototype to make sure the call target is valid to help mitigate
> ROP
Hi all,
On Wed, Nov 02, 2022 at 08:42:15AM -0700, Nathan Chancellor wrote:
> With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
> indirect call targets are validated against the expected function
> pointer prototype to make sure the call target is valid to help mitigate
> ROP
On Wed, 2022-11-09 at 09:48 +, Lin, Wayne wrote:
> > }
> > - if (!drm_dp_mst_atomic_check(state) && !debugfs_overwrite) {
> > + ret = drm_dp_mst_atomic_check(state);
> > + if (ret == 0 && !debugfs_overwrite) {
> > set_dsc_configs_from_fairness_vars(params, vars, count,
>
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 5c92ddca1053df02387e8006d06094e18cc8538a Add linux-next specific
files for 20221114
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202211041320.coq8eelj-...@intel.com
https
On Sat, Nov 12, 2022 at 07:42:10PM +, Robert Swindells wrote:
> Contributors to these files are:
>
> Noralf Trønnes
> Liu Zixian
> Dave Airlie
> Thomas Zimmermann
> Lucas De Marchi
> Gerd Hoffmann
> Rob Herring
> Jakub Kicinski
> Marcel Ziswiler
> Stephen Rothwell
> Daniel Vetter
>
On Wed, 2022-11-09 at 09:48 +, Lin, Wayne wrote:
> [Public]
>
> Thanks, Lyude!
> Comments inline.
>
> > -Original Message-
> > From: Lyude Paul
> > Sent: Saturday, November 5, 2022 7:59 AM
> > To: amd-...@lists.freedesktop.org
> > Cc: Wentland, Harry ; sta...@vger.kernel.org;
> >
Hi,
On Mon, Nov 14, 2022 at 12:50 PM Rob Clark wrote:
>
> From: Rob Clark
>
> If we get an error (other than -ENOENT) we need to propagate that up the
> stack. Otherwise if the nvmem driver hasn't probed yet, we'll end up
> end up claiming that we support all the OPPs which is not likely to be
On Mon, Nov 07, 2022 at 04:30:28PM -0800, Lucas De Marchi wrote:
> 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
> ---
>
From: Rob Clark
If we get an error (other than -ENOENT) we need to propagate that up the
stack. Otherwise if the nvmem driver hasn't probed yet, we'll end up
end up claiming that we support all the OPPs which is not likely to be
true (and on some generations impossible to be true, ie. if there
On Mon, Nov 14, 2022 at 11:59 AM Akhil P Oommen
wrote:
>
> On 11/15/2022 1:11 AM, Rob Clark wrote:
> > From: Rob Clark
> >
> > If we get an error (other than -ENOENT) we need to propagate that up the
> > stack. Otherwise if the nvmem driver hasn't probed yet, we'll end up with
> > whatever
On Mon, Nov 14, 2022 at 12:27 PM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Nov 14, 2022 at 11:41 AM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > If we get an error (other than -ENOENT) we need to propagate that up the
> > stack. Otherwise if the nvmem driver hasn't probed yet, we'll end up
On 11/15/2022 1:57 AM, Doug Anderson wrote:
Hi,
On Mon, Nov 14, 2022 at 11:41 AM Rob Clark wrote:
From: Rob Clark
If we get an error (other than -ENOENT) we need to propagate that up the
stack. Otherwise if the nvmem driver hasn't probed yet, we'll end up with
whatever OPP(s) are
Hi,
On Mon, Nov 14, 2022 at 11:41 AM Rob Clark wrote:
>
> From: Rob Clark
>
> If we get an error (other than -ENOENT) we need to propagate that up the
> stack. Otherwise if the nvmem driver hasn't probed yet, we'll end up with
> whatever OPP(s) are represented by bit zero.
Can you explain the
On 11/15/2022 1:11 AM, Rob Clark wrote:
From: Rob Clark
If we get an error (other than -ENOENT) we need to propagate that up the
stack. Otherwise if the nvmem driver hasn't probed yet, we'll end up with
whatever OPP(s) are represented by bit zero.
Fixed: fe7952c629da ("drm/msm: Add speed-bin
Hi,
After more detailed runtime testing I discovered that I didn't re-insert
the console to the correct place in the list. More below...
On 2022-11-14, John Ogness wrote:
> diff --git a/include/linux/console.h b/include/linux/console.h
> index f716e1dd9eaf..9cea254b34b8 100644
> ---
From: Rob Clark
If we get an error (other than -ENOENT) we need to propagate that up the
stack. Otherwise if the nvmem driver hasn't probed yet, we'll end up with
whatever OPP(s) are represented by bit zero.
Fixed: fe7952c629da ("drm/msm: Add speed-bin support to a618 gpu")
Signed-off-by: Rob
From: Rob Clark
The _HI reg is always following the _LO reg, so no need to pass these
offsets seprately.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 3 +--
drivers/gpu/drm/msm/adreno/a5xx_gpu.c |
From: Rob Clark
If the hangcheck timer expires, check if the fw's position in the
cmdstream has advanced (changed) since last timer expiration, and
allow it up to three additional "extensions" to it's alotted time.
The intention is to continue to catch "shader stuck in a loop" type
hangs
From: Rob Clark
Try to detect when submit jobs are making forward progress and give them
a bit more time.
Rob Clark (2):
drm/msm/adreno: Simplify read64/write64 helpers
drm/msm: Hangcheck progress detection
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 3 +-
On Mon, Nov 14, 2022 at 01:02:46PM +0200, Jani Nikula wrote:
> On Mon, 14 Nov 2022, Hans de Goede wrote:
> > Hi,
> >
> > On 11/14/22 11:10, Jani Nikula wrote:
> >> On Mon, 14 Nov 2022, Hans de Goede wrote:
> >>> Hi,
> >>>
> >>> On 11/14/22 00:23, Stephen Rothwell wrote:
> Hi all,
>
>
On Mon, Nov 14, 2022 at 10:21:50AM -0500, Matthew Rosato wrote:
> On 11/14/22 9:59 AM, Jason Gunthorpe wrote:
> > On Mon, Nov 14, 2022 at 09:55:21AM -0500, Matthew Rosato wrote:
> AFAICT there is no equivalent means to specify
> vfio_iommu_type1.dma_entry_limit when using iommufd; looks
On Mon, Nov 14, 2022 at 1:22 PM Andy Shevchenko
wrote:
>
> The list API now provides the list_count() to help with counting
> existing nodes in the list. Uilise it.
s/Uilise/Utilise
On Sat, Nov 12, 2022 at 1:44 PM Robert Swindells wrote:
>
> Contributors to these files are:
>
> Noralf Trønnes
> Liu Zixian
> Dave Airlie
> Thomas Zimmermann
> Lucas De Marchi
> Gerd Hoffmann
> Rob Herring
My contributions are related to the madvise functions. That's largely
lifted or
On 11/14/22 09:56, Xiongfeng Wang wrote:
pci_get_device() will increase the reference count for the returned
pci_dev. For the error path, we need to use pci_dev_put() to decrease
the reference count.
Fixes: dbe7e429fedb ("vmlfb: framebuffer driver for Intel Vermilion Range")
Signed-off-by:
On Mon, Nov 14, 2022 at 06:11:51PM +, Ruhl, Michael J wrote:
...
> So all of the non-list_for_each code appears to be an inline.
This is not true.
> This which, resembles the non-list_for_each pattern is a macro?
>
> Just curious as to why the macro rather than inline?
See above.
>-Original Message-
>From: dri-devel On Behalf Of
>Andy Shevchenko
>Sent: Monday, November 14, 2022 11:22 AM
>To: Jakob Koschel ; Andy Shevchenko
>; Greg Kroah-Hartman
>; Mathias Nyman
>; intel-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; linux-ker...@vger.kernel.org;
On Sat, 12 Nov 2022 19:42:10 +
Robert Swindells wrote:
> Contributors to these files are:
>
> Noralf Trønnes
> Liu Zixian
> Dave Airlie
> Thomas Zimmermann
> Lucas De Marchi
> Gerd Hoffmann
> Rob Herring
> Jakub Kicinski
> Marcel Ziswiler
> Stephen Rothwell
> Daniel Vetter
> Cai
Den 12.11.2022 20.42, skrev Robert Swindells:
> Contributors to these files are:
>
> Noralf Trønnes
Acked-by: Noralf Trønnes
> Liu Zixian
> Dave Airlie
> Thomas Zimmermann
> Lucas De Marchi
> Gerd Hoffmann
> Rob Herring
> Jakub Kicinski
> Marcel Ziswiler
> Stephen Rothwell
>
Den 14.11.2022 14.00, skrev Maxime Ripard:
> KMS supports a number of named modes already, but it's never been
> documented anywhere, let's fix that.
>
> Signed-off-by: Maxime Ripard
>
> ---
Reviewed-by: Noralf Trønnes
Am 2022-11-14 um 11:41 schrieb David Hildenbrand:
On 14.11.22 12:55, Alistair Popple wrote:
The migrate_to_ram() callback should always succeed, but in rare cases
can fail usually returning VM_FAULT_SIGBUS. Commit 16ce101db85d
("mm/memory.c: fix race when faulting a device private page")
Hello Steve,
On 11/14/22 19:54, Steven Price wrote:
> On 05/11/2022 23:27, Dmitry Osipenko wrote:
>> Replace Panfrost's custom memory shrinker with a common drm-shmem
>> memory shrinker.
>>
>> Signed-off-by: Dmitry Osipenko
>
> Sadly this triggers GPU faults under memory pressure - it looks
>
On Mon, Nov 14, 2022 at 8:10 PM Marek Szyprowski
wrote:
>
> On 14.11.2022 11:57, Marek Szyprowski wrote:
> > On 10.11.2022 19:38, Jagan Teki wrote:
> >> Finding the right input bus format throughout the pipeline is hard
> >> so add atomic_get_input_bus_fmts callback and initialize with the
> >>
On 05/11/2022 23:27, Dmitry Osipenko wrote:
> Replace Panfrost's custom memory shrinker with a common drm-shmem
> memory shrinker.
>
> Signed-off-by: Dmitry Osipenko
Sadly this triggers GPU faults under memory pressure - it looks
suspiciously like mappings are being freed while the jobs are
On 14.11.22 12:55, Alistair Popple wrote:
The migrate_to_ram() callback should always succeed, but in rare cases
can fail usually returning VM_FAULT_SIGBUS. Commit 16ce101db85d
("mm/memory.c: fix race when faulting a device private page")
incorrectly stopped passing the return code up the stack.
On Sat, 12 Nov 2022 19:42:10 + Robert Swindells wrote:
> Contributors to these files are:
>
> Noralf Trønnes
> Liu Zixian
> Dave Airlie
> Thomas Zimmermann
> Lucas De Marchi
> Gerd Hoffmann
> Rob Herring
> Jakub Kicinski
> Marcel Ziswiler
> Stephen Rothwell
> Daniel Vetter
> Cai
With commit 9e124fe16ff2("xen: Enable console tty by default in domU
if it's not a dummy") a hack was implemented to make sure that the
tty console remains the console behind the /dev/console device. The
main problem with the hack is that, after getting the console pointer
to the tty console, it
This is v4 of a series to prepare for threaded/atomic
printing. v3 is here [0]. This series focuses on reducing the
scope of the BKL console_lock. It achieves this by switching to
SRCU and a dedicated mutex for console list iteration and
modification, respectively. The console_lock will no longer
The list API now provides the list_count() to help with counting
existing nodes in the list. Uilise it.
Signed-off-by: Andy Shevchenko
---
v2: no change
drivers/usb/gadget/udc/bcm63xx_udc.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git
The list API now provides the list_count() to help with counting
existing nodes in the list. Uilise it.
Signed-off-by: Andy Shevchenko
---
v2: no change
drivers/usb/host/xhci-ring.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c
Some of the existing users, and definitely will be new ones, want to
count existing nodes in the list. Provide a generic API for that by
moving code from i915 to list.h.
Signed-off-by: Andy Shevchenko
---
v2: dropped the duplicate code in i915 (LKP)
drivers/gpu/drm/i915/gt/intel_engine_cs.c |
The list API now provides the list_count() to help with counting
existing nodes in the list. Uilise it.
Signed-off-by: Andy Shevchenko
---
v2: no change
drivers/usb/gadget/legacy/hid.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/legacy/hid.c
On 10/11/2022 23:16, Dmitry Baryshkov wrote:
On 04/11/2022 16:54, Konrad Dybcio wrote:
On 04/11/2022 14:03, 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
On 11/14/22 9:59 AM, Jason Gunthorpe wrote:
> On Mon, Nov 14, 2022 at 09:55:21AM -0500, Matthew Rosato wrote:
AFAICT there is no equivalent means to specify
vfio_iommu_type1.dma_entry_limit when using iommufd; looks like
we'll just always get the default 65535.
>>>
>>> No, there is
* , ,
Hi, Justin:
Justin Green 於 2022年10月13日 週四 凌晨3:12寫道：
>
> Tested on MT8195 and confirmed both correct video output and improved DRAM
> bandwidth performance.
>
> v3:
> * Replaced pitch bitshift math with union based approach.
> * Refactored overlay register writes to shared code between
On Mon, Nov 14, 2022 at 09:55:21AM -0500, Matthew Rosato wrote:
> >> AFAICT there is no equivalent means to specify
> >> vfio_iommu_type1.dma_entry_limit when using iommufd; looks like
> >> we'll just always get the default 65535.
> >
> > No, there is no arbitary limit on iommufd
>
> Yeah,
On 14/10/2022 18:36, Konrad Dybcio wrote:
On 30.09.2022 20:08, Konrad Dybcio wrote:
Add support for the Sony TD4353 JDI 2160x1080 display panel used in
some Sony Xperia XZ2 and XZ2 Compact smartphones. Due to the specifics
of smartphone manufacturing, it is impossible to retrieve a better
On 11/14/22 9:23 AM, Jason Gunthorpe wrote:
> On Thu, Nov 10, 2022 at 10:01:13PM -0500, Matthew Rosato wrote:
>> On 11/7/22 7:52 PM, Jason Gunthorpe wrote:
>>> This series provides an alternative container layer for VFIO implemented
>>> using iommufd. This is optional, if CONFIG_IOMMUFD is not set
Hi Laurent,
On Mon, Nov 14, 2022 at 3:22 PM Laurent Pinchart
wrote:
> On Mon, Nov 14, 2022 at 10:05:58AM +0100, Geert Uytterhoeven wrote:
> > On Sun, Oct 2, 2022 at 12:06 AM Laurent Pinchart wrote:
> > > When the R-Car MIPI DSI driver was added, it was a standalone encoder
> > > driver without
On Fri, Nov 11, 2022 at 12:16:02PM +0800, Yi Liu wrote:
> > +#if IS_ENABLED(CONFIG_IOMMUFD_VFIO_CONTAINER)
> > +MODULE_ALIAS_MISCDEV(VFIO_MINOR);
> > +MODULE_ALIAS("devname:vfio/vfio");
>
> will this line also result in systemd to create this devnodes at boot
> based on the module info even if
On Fri, Nov 11, 2022 at 12:12:36PM +0800, Yi Liu wrote:
> > +int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx)
> > +{
> > + u32 ioas_id;
> > + u32 device_id;
> > + int ret;
> > +
> > + lockdep_assert_held(>dev_set->lock);
> > +
> > + /*
> > +* If the driver
On 2022/11/14 22:38, Jason Gunthorpe wrote:
On Mon, Nov 14, 2022 at 08:51:58PM +0800, Yi Liu wrote:
Our side, Yu He, Lixiao Yang has done below tests on Intel platform with
the above kernel, results are:
1) GVT-g test suit passed, Intel iGFx passthrough passed.
2) NIC passthrough test with
On 14.11.2022 11:57, Marek Szyprowski wrote:
> On 10.11.2022 19:38, Jagan Teki wrote:
>> Finding the right input bus format throughout the pipeline is hard
>> so add atomic_get_input_bus_fmts callback and initialize with the
>> proper input format from list of supported output formats.
>>
>> This
On Mon, Nov 14, 2022 at 08:51:58PM +0800, Yi Liu wrote:
> Our side, Yu He, Lixiao Yang has done below tests on Intel platform with
> the above kernel, results are:
>
> 1) GVT-g test suit passed, Intel iGFx passthrough passed.
>
> 2) NIC passthrough test with different guest memory (1G/4G),
On 2022/11/14 20:51, Yi Liu wrote:
> On 2022/11/10 00:57, Jason Gunthorpe wrote:
>> On Tue, Nov 08, 2022 at 11:18:03PM +0800, Yi Liu wrote:
>>> On 2022/11/8 17:19, Nicolin Chen wrote:
On Mon, Nov 07, 2022 at 08:52:44PM -0400, Jason Gunthorpe wrote:
> This is on github:
>
On Thu, Nov 10, 2022 at 10:01:13PM -0500, Matthew Rosato wrote:
> On 11/7/22 7:52 PM, Jason Gunthorpe wrote:
> > 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.
> >
> >
Hi Geert,
On Mon, Nov 14, 2022 at 10:05:58AM +0100, Geert Uytterhoeven wrote:
> On Sun, Oct 2, 2022 at 12:06 AM Laurent Pinchart wrote:
> > When the R-Car MIPI DSI driver was added, it was a standalone encoder
> > driver without any dependency to or from the R-Car DU driver. Commit
> >
Hi Mikhail,
Am 02.11.22 um 14:43 schrieb Christian König:
Am 02.11.22 um 14:36 schrieb Mikhail Gavrilov:
On Tue, Nov 1, 2022 at 10:52 PM Christian König
wrote:
[SNIP]
But the most interesting thing is that all previous kernels 6.0, 5.19
are affected by the problem. It is not enough to revert
Hi Stefan,
On Mon, Nov 14, 2022 at 01:48:14AM +0100, Stefan Wahren wrote:
> Am 11.11.22 um 22:08 schrieb Stefan Wahren:
> > Hi Maxime,
> >
> > Am 29.09.22 um 11:21 schrieb Maxime Ripard:
> > > This is a revert of commit fd5894fa2413 ("drm/vc4: hdmi: Remove clock
> > > rate initialization"), with
From: Mateusz Kwiatkowski
The VEC can accept pretty much any relatively reasonable mode, but still
has a bunch of constraints to meet.
Let's create an atomic_check() implementation that will make sure we
don't end up accepting a non-functional mode.
Acked-by: Noralf Trønnes
Signed-off-by:
The analog TV connector drivers share some atomic_check logic, and the new
TV standard property have created some boilerplate that can be be shared
across drivers too.
Let's create an atomic_check helper for those use cases.
Reviewed-by: Noralf Trønnes
Tested-by: Mateusz Kwiatkowski
drm_connector_pick_cmdline_mode() is in charge of finding a proper
drm_display_mode from the definition we got in the video= command line
argument.
Let's add some unit tests to make sure we're not getting any regressions
there.
Acked-by: Noralf Trønnes
Tested-by: Mateusz Kwiatkowski
Now that the core can deal fine with analog TV modes, let's convert the vc4
VEC driver to leverage those new features.
We've added some backward compatibility to support the old TV mode property
and translate it into the new TV norm property. We're also making use of
the new analog TV
From: Mateusz Kwiatkowski
Add support for the following composite output modes (all of them are
somewhat more obscure than the previously defined ones):
- NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
4.43361875 MHz (the PAL subcarrier frequency). Never used for
The drm_tv_create_properties() function will create a bunch of properties,
but it's up to each and every driver using that function to properly reset
the state of these properties leading to inconsistent behaviours.
Let's create a helper that will take care of it.
Reviewed-by: Noralf Trønnes
Now that the core can deal fine with analog TV modes, let's convert the
sun4i TV driver to leverage those new features.
Acked-by: Noralf Trønnes
Reviewed-by: Jernej Skrabec
Signed-off-by: Maxime Ripard
---
Changes in v6:
- Convert to new get_modes helper
Changes in v5:
- Removed the count
The framework will get the drm_display_mode from the drm_cmdline_mode it
got by parsing the video command line argument by calling
drm_connector_pick_cmdline_mode().
The heavy lifting will then be done by the drm_mode_create_from_cmdline_mode()
function.
In the case of the named modes though,
The analog TV properties created by the drm_mode_create_tv_properties() are
not properly initialised at reset. Let's switch our implementation to call
drm_atomic_helper_connector_tv_reset().
Reviewed-by: Noralf Trønnes
Tested-by: Mateusz Kwiatkowski
Signed-off-by: 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.
Reviewed-by: Noralf Trønnes
Tested-by: Mateusz Kwiatkowski
Signed-off-by: Maxime Ripard
---
Changes in v9:
- Document the
The current named mode parsing relies only on the mode name, and doesn't
allow to specify any other parameter.
Let's convert that string list to an array of a custom structure that will
hold the name and some additional parameters in the future.
Reviewed-by: Noralf Trønnes
Tested-by: Mateusz
We'll need to get the pixel clock to generate proper display modes for
all the current named modes. Let's add it to struct drm_cmdline_mode and
fill it when parsing the named mode.
Reviewed-by: Noralf Trønnes
Tested-by: Mateusz Kwiatkowski
Signed-off-by: Maxime Ripard
---
Changes in v7:
- Add
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 flag and order
the modes based on the driver and users
drm_mode_create_tv_properties(), among other things, will create the
"mode" property that stores the analog TV mode that connector is
supposed to output.
However, that property is getting deprecated, so let's rename that
function to mention it's deprecated. We'll introduce a new variant of
that
Commit 3aeeb13d8996 ("drm/modes: Support modes names on the command
line") initially introduced the named modes support by essentially
matching the name passed on the command-line to the mode names defined
by the drivers.
This proved to be difficult to work with, since all drivers had to
provide
Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
625-lines modes in their drivers.
Since those modes are fairly standard, and that we'll need to use them
in more places in the future, it makes sense to move their definition
into the core framework.
However, analog display
1 - 100 of 160 matches
Mail list logo
