* Re: [PATCH v1 2/3] arm64: mm: Handle invalid large leaf mappings correctly
From: Yang Shi @ 2026-03-24 18:20 UTC (permalink / raw)
To: Ryan Roberts, Catalin Marinas, Will Deacon,
David Hildenbrand (Arm), Dev Jain, Suzuki K Poulose, Jinjiang Tu,
Kevin Brodsky
Cc: linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260323130317.1737522-3-ryan.roberts@arm.com>
On 3/23/26 6:03 AM, Ryan Roberts wrote:
> It has been possible for a long time to mark ptes in the linear map as
> invalid. This is done for secretmem, kfence, realm dma memory un/share,
> and others, by simply clearing the PTE_VALID bit. But until commit
> a166563e7ec37 ("arm64: mm: support large block mapping when
> rodata=full") large leaf mappings were never made invalid in this way.
>
> It turns out various parts of the code base are not equipped to handle
> invalid large leaf mappings (in the way they are currently encoded) and
> I've observed a kernel panic while booting a realm guest on a
> BBML2_NOABORT system as a result:
>
> [ 15.432706] software IO TLB: Memory encryption is active and system is using DMA bounce buffers
> [ 15.476896] Unable to handle kernel paging request at virtual address ffff000019600000
> [ 15.513762] Mem abort info:
> [ 15.527245] ESR = 0x0000000096000046
> [ 15.548553] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 15.572146] SET = 0, FnV = 0
> [ 15.592141] EA = 0, S1PTW = 0
> [ 15.612694] FSC = 0x06: level 2 translation fault
> [ 15.640644] Data abort info:
> [ 15.661983] ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000
> [ 15.694875] CM = 0, WnR = 1, TnD = 0, TagAccess = 0
> [ 15.723740] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [ 15.755776] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000081f3f000
> [ 15.800410] [ffff000019600000] pgd=0000000000000000, p4d=180000009ffff403, pud=180000009fffe403, pmd=00e8000199600704
> [ 15.855046] Internal error: Oops: 0000000096000046 [#1] SMP
> [ 15.886394] Modules linked in:
> [ 15.900029] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc4-dirty #4 PREEMPT
> [ 15.935258] Hardware name: linux,dummy-virt (DT)
> [ 15.955612] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
> [ 15.986009] pc : __pi_memcpy_generic+0x128/0x22c
> [ 16.006163] lr : swiotlb_bounce+0xf4/0x158
> [ 16.024145] sp : ffff80008000b8f0
> [ 16.038896] x29: ffff80008000b8f0 x28: 0000000000000000 x27: 0000000000000000
> [ 16.069953] x26: ffffb3976d261ba8 x25: 0000000000000000 x24: ffff000019600000
> [ 16.100876] x23: 0000000000000001 x22: ffff0000043430d0 x21: 0000000000007ff0
> [ 16.131946] x20: 0000000084570010 x19: 0000000000000000 x18: ffff00001ffe3fcc
> [ 16.163073] x17: 0000000000000000 x16: 00000000003fffff x15: 646e612065766974
> [ 16.194131] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
> [ 16.225059] x11: 0000000000000000 x10: 0000000000000010 x9 : 0000000000000018
> [ 16.256113] x8 : 0000000000000018 x7 : 0000000000000000 x6 : 0000000000000000
> [ 16.287203] x5 : ffff000019607ff0 x4 : ffff000004578000 x3 : ffff000019600000
> [ 16.318145] x2 : 0000000000007ff0 x1 : ffff000004570010 x0 : ffff000019600000
> [ 16.349071] Call trace:
> [ 16.360143] __pi_memcpy_generic+0x128/0x22c (P)
> [ 16.380310] swiotlb_tbl_map_single+0x154/0x2b4
> [ 16.400282] swiotlb_map+0x5c/0x228
> [ 16.415984] dma_map_phys+0x244/0x2b8
> [ 16.432199] dma_map_page_attrs+0x44/0x58
> [ 16.449782] virtqueue_map_page_attrs+0x38/0x44
> [ 16.469596] virtqueue_map_single_attrs+0xc0/0x130
> [ 16.490509] virtnet_rq_alloc.isra.0+0xa4/0x1fc
> [ 16.510355] try_fill_recv+0x2a4/0x584
> [ 16.526989] virtnet_open+0xd4/0x238
> [ 16.542775] __dev_open+0x110/0x24c
> [ 16.558280] __dev_change_flags+0x194/0x20c
> [ 16.576879] netif_change_flags+0x24/0x6c
> [ 16.594489] dev_change_flags+0x48/0x7c
> [ 16.611462] ip_auto_config+0x258/0x1114
> [ 16.628727] do_one_initcall+0x80/0x1c8
> [ 16.645590] kernel_init_freeable+0x208/0x2f0
> [ 16.664917] kernel_init+0x24/0x1e0
> [ 16.680295] ret_from_fork+0x10/0x20
> [ 16.696369] Code: 927cec03 cb0e0021 8b0e0042 a9411c26 (a900340c)
> [ 16.723106] ---[ end trace 0000000000000000 ]---
> [ 16.752866] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [ 16.792556] Kernel Offset: 0x3396ea200000 from 0xffff800080000000
> [ 16.818966] PHYS_OFFSET: 0xfff1000080000000
> [ 16.837237] CPU features: 0x0000000,00060005,13e38581,957e772f
> [ 16.862904] Memory Limit: none
> [ 16.876526] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
>
> This panic occurs because the swiotlb memory was previously shared to
> the host (__set_memory_enc_dec()), which involves transitioning the
> (large) leaf mappings to invalid, sharing to the host, then marking the
> mappings valid again. But pageattr_p[mu]d_entry() would only update the
> entry if it is a section mapping, since otherwise it concluded it must
> be a table entry so shouldn't be modified. But p[mu]d_sect() only
> returns true if the entry is valid. So the result was that the large
> leaf entry was made invalid in the first pass then ignored in the second
> pass. It remains invalid until the above code tries to access it and
> blows up.
Good catch. I recall I met this problem when I worked on a very early
PoC of large block mapping patch. It took a total different approach
than BBML2_NOABORT. I didn't run into that problem when I implemented
BBML2_NOABORT because nobody actually changed valid/invalid attribute on
large block mapping granule so I forgot it. But I definitely missed
realm usecase.
>
> The simple fix would be to update pageattr_pmd_entry() to use
> !pmd_table() instead of pmd_sect(). That would solve this problem.
Yes, I agree.
>
> But the ptdump code also suffers from a similar issue. It checks
> pmd_leaf() and doesn't call into the arch-specific note_page() machinery
> if it returns false. As a result of this, ptdump wasn't even able to
> show the invalid large leaf mappings; it looked like they were valid
> which made this super fun to debug. the ptdump code is core-mm and
> pmd_table() is arm64-specific so we can't use the same trick to solve
> that.
I don't quite get why we need to show invalid mappings in ptdump? IIUC
ptdump is not supposed to show invalid mappings even though they are
transient.
Thanks,
Yang
>
> But we already support the concept of "present-invalid" for user space
> entries. And even better, pmd_leaf() will return true for a leaf mapping
> that is marked present-invalid. So let's just use that encoding for
> present-invalid kernel mappings too. Then we can use pmd_leaf() where we
> previously used pmd_sect() and everything is magically fixed.
>
> Additionally, from inspection kernel_page_present() was broken in a
> similar way, so I'm also updating that to use pmd_leaf().
>
> I haven't spotted any other issues of this shape but plan to do a follow
> up patch to remove pmd_sect() and pud_sect() in favour of the more
> sophisticated pmd_leaf()/pud_leaf() which are core-mm APIs and will
> simplify arm64 code a bit.
>
> Fixes: a166563e7ec37 ("arm64: mm: support large block mapping when rodata=full")
> Cc: stable@vger.kernel.org
> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
> ---
> arch/arm64/mm/pageattr.c | 50 ++++++++++++++++++++++------------------
> 1 file changed, 28 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
> index 358d1dc9a576f..87dfe4c82fa92 100644
> --- a/arch/arm64/mm/pageattr.c
> +++ b/arch/arm64/mm/pageattr.c
> @@ -25,6 +25,11 @@ static ptdesc_t set_pageattr_masks(ptdesc_t val, struct mm_walk *walk)
> {
> struct page_change_data *masks = walk->private;
>
> + /*
> + * Some users clear and set bits which alias eachother (e.g. PTE_NG and
> + * PTE_PRESENT_INVALID). It is therefore important that we always clear
> + * first then set.
> + */
> val &= ~(pgprot_val(masks->clear_mask));
> val |= (pgprot_val(masks->set_mask));
>
> @@ -36,7 +41,7 @@ static int pageattr_pud_entry(pud_t *pud, unsigned long addr,
> {
> pud_t val = pudp_get(pud);
>
> - if (pud_sect(val)) {
> + if (pud_leaf(val)) {
> if (WARN_ON_ONCE((next - addr) != PUD_SIZE))
> return -EINVAL;
> val = __pud(set_pageattr_masks(pud_val(val), walk));
> @@ -52,7 +57,7 @@ static int pageattr_pmd_entry(pmd_t *pmd, unsigned long addr,
> {
> pmd_t val = pmdp_get(pmd);
>
> - if (pmd_sect(val)) {
> + if (pmd_leaf(val)) {
> if (WARN_ON_ONCE((next - addr) != PMD_SIZE))
> return -EINVAL;
> val = __pmd(set_pageattr_masks(pmd_val(val), walk));
> @@ -132,11 +137,12 @@ static int __change_memory_common(unsigned long start, unsigned long size,
> ret = update_range_prot(start, size, set_mask, clear_mask);
>
> /*
> - * If the memory is being made valid without changing any other bits
> - * then a TLBI isn't required as a non-valid entry cannot be cached in
> - * the TLB.
> + * If the memory is being switched from present-invalid to valid without
> + * changing any other bits then a TLBI isn't required as a non-valid
> + * entry cannot be cached in the TLB.
> */
> - if (pgprot_val(set_mask) != PTE_VALID || pgprot_val(clear_mask))
> + if (pgprot_val(set_mask) != (PTE_MAYBE_NG | PTE_VALID) ||
> + pgprot_val(clear_mask) != PTE_PRESENT_INVALID)
> flush_tlb_kernel_range(start, start + size);
> return ret;
> }
> @@ -237,18 +243,18 @@ int set_memory_valid(unsigned long addr, int numpages, int enable)
> {
> if (enable)
> return __change_memory_common(addr, PAGE_SIZE * numpages,
> - __pgprot(PTE_VALID),
> - __pgprot(0));
> + __pgprot(PTE_MAYBE_NG | PTE_VALID),
> + __pgprot(PTE_PRESENT_INVALID));
> else
> return __change_memory_common(addr, PAGE_SIZE * numpages,
> - __pgprot(0),
> - __pgprot(PTE_VALID));
> + __pgprot(PTE_PRESENT_INVALID),
> + __pgprot(PTE_MAYBE_NG | PTE_VALID));
> }
>
> int set_direct_map_invalid_noflush(struct page *page)
> {
> - pgprot_t clear_mask = __pgprot(PTE_VALID);
> - pgprot_t set_mask = __pgprot(0);
> + pgprot_t clear_mask = __pgprot(PTE_MAYBE_NG | PTE_VALID);
> + pgprot_t set_mask = __pgprot(PTE_PRESENT_INVALID);
>
> if (!can_set_direct_map())
> return 0;
> @@ -259,8 +265,8 @@ int set_direct_map_invalid_noflush(struct page *page)
>
> int set_direct_map_default_noflush(struct page *page)
> {
> - pgprot_t set_mask = __pgprot(PTE_VALID | PTE_WRITE);
> - pgprot_t clear_mask = __pgprot(PTE_RDONLY);
> + pgprot_t set_mask = __pgprot(PTE_MAYBE_NG | PTE_VALID | PTE_WRITE);
> + pgprot_t clear_mask = __pgprot(PTE_PRESENT_INVALID | PTE_RDONLY);
>
> if (!can_set_direct_map())
> return 0;
> @@ -296,8 +302,8 @@ static int __set_memory_enc_dec(unsigned long addr,
> * entries or Synchronous External Aborts caused by RIPAS_EMPTY
> */
> ret = __change_memory_common(addr, PAGE_SIZE * numpages,
> - __pgprot(set_prot),
> - __pgprot(clear_prot | PTE_VALID));
> + __pgprot(set_prot | PTE_PRESENT_INVALID),
> + __pgprot(clear_prot | PTE_MAYBE_NG | PTE_VALID));
>
> if (ret)
> return ret;
> @@ -311,8 +317,8 @@ static int __set_memory_enc_dec(unsigned long addr,
> return ret;
>
> return __change_memory_common(addr, PAGE_SIZE * numpages,
> - __pgprot(PTE_VALID),
> - __pgprot(0));
> + __pgprot(PTE_MAYBE_NG | PTE_VALID),
> + __pgprot(PTE_PRESENT_INVALID));
> }
>
> static int realm_set_memory_encrypted(unsigned long addr, int numpages)
> @@ -404,15 +410,15 @@ bool kernel_page_present(struct page *page)
> pud = READ_ONCE(*pudp);
> if (pud_none(pud))
> return false;
> - if (pud_sect(pud))
> - return true;
> + if (pud_leaf(pud))
> + return pud_valid(pud);
>
> pmdp = pmd_offset(pudp, addr);
> pmd = READ_ONCE(*pmdp);
> if (pmd_none(pmd))
> return false;
> - if (pmd_sect(pmd))
> - return true;
> + if (pmd_leaf(pmd))
> + return pmd_valid(pmd);
>
> ptep = pte_offset_kernel(pmdp, addr);
> return pte_valid(__ptep_get(ptep));
^ permalink raw reply
* Re: [PATCH v7 12/41] KVM: arm64: gic-v5: Sanitize ID_AA64PFR2_EL1.GCIE
From: Mark Brown @ 2026-03-24 18:16 UTC (permalink / raw)
To: Marc Zyngier
Cc: Sascha Bischoff, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.linux.dev, kvm@vger.kernel.org, nd,
oliver.upton@linux.dev, Joey Gouly, Suzuki Poulose,
yuzenghui@huawei.com, peter.maydell@linaro.org,
lpieralisi@kernel.org, Timothy Hayes, jonathan.cameron@huawei.com
In-Reply-To: <86qzp945d1.wl-maz@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 336 bytes --]
On Tue, Mar 24, 2026 at 03:25:14PM +0000, Marc Zyngier wrote:
> Mark Brown <broonie@kernel.org> wrote:
> > > Is your TX2 the only machine you have that is AArch64 only at all ELs?
> > Yes, that should be the case.
> The hack below fixes it on my favourite Qualcomm box.
Confirmed on TX2:
Tested-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 05/10] am68k/PCI: Remove unnecessary second application of align
From: Ilpo Järvinen @ 2026-03-24 17:55 UTC (permalink / raw)
To: John Paul Adrian Glaubitz
Cc: linux-pci, Bjorn Helgaas, Guenter Roeck, linux-alpha,
linux-arm-kernel, linux-m68k, linux-mips, linux-parisc,
linuxppc-dev, linux-s390, linux-sh, Russell King,
Geert Uytterhoeven, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Chris Zankel,
Max Filippov, Madhavan Srinivasan, Yoshinori Sato, Rich Felker,
LKML
In-Reply-To: <5de97ed9556bfcc3b1f26bd71e09fa4016ae3ff8.camel@physik.fu-berlin.de>
[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]
On Tue, 24 Mar 2026, John Paul Adrian Glaubitz wrote:
> Hi Ilpo,
>
> On Tue, 2026-03-24 at 18:56 +0200, Ilpo Järvinen wrote:
> > Aligning res->start by align inside pcibios_align_resource() is
> > unnecessary because caller of pcibios_align_resource() is
> > __find_resource_space() that aligns res->start with align before
> > calling pcibios_align_resource().
> >
> > Aligning by align in case of IORESOURCE_IO && start & 0x300 cannot ever
> > result in changing start either because 0x300 bits would have not
> > survived the earlier alignment if align was large enough to have an
> > impact.
> >
> > Thus, remove the duplicated aligning from pcibios_align_resource().
> >
> > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> > ---
> > arch/m68k/kernel/pcibios.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/arch/m68k/kernel/pcibios.c b/arch/m68k/kernel/pcibios.c
> > index 1415f6e4e5ce..7e286ee1976b 100644
> > --- a/arch/m68k/kernel/pcibios.c
> > +++ b/arch/m68k/kernel/pcibios.c
> > @@ -36,8 +36,6 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
> > if ((res->flags & IORESOURCE_IO) && (start & 0x300))
> > start = (start + 0x3ff) & ~0x3ff;
> >
> > - start = (start + align - 1) & ~(align - 1);
> > -
> > return start;
> > }
> >
>
> Sorry if it's a stupid question, but what does "am68k" in the subject refer to?
The extra "a" is a typo. I'm sorry about that.
--
i.
^ permalink raw reply
* Re: [RFC v1 00/11] Add iMX95 neoisp driver
From: Antoine Bouyer @ 2026-03-24 17:44 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Michael Riesch, julien.vuillaumier, alexi.birlinger,
daniel.baluta, peng.fan, frank.li, laurent.pinchart, mchehab,
robh, krzk+dt, conor+dt, shawnguo, s.hauer, kernel, festevam,
linux-kernel, linux-media, devicetree, linux-arm-kernel,
niklas soderlund, Anthony McGivern
In-Reply-To: <acE0_8C8WL3crVMm@zed>
Hi Jacopo
On 3/23/26 2:18 PM, Jacopo Mondi wrote:
>
>
> Hi Antoine
>
> On Fri, Mar 20, 2026 at 05:29:44PM +0100, Antoine Bouyer wrote:
>> Hi Jacopo
>>
>> Quite some updates regarding this RFC after further analysis.
>>
>> Le 05/02/2026 à 10:40, Jacopo Mondi a écrit :
>>>
>>>
>>> Hi Antoine
>>>
>>> On Wed, Feb 04, 2026 at 07:30:18PM +0100, Antoine Bouyer wrote:
>>>> Hi Jacopo
>>>>
>>>> Le 04/02/2026 à 18:12, Jacopo Mondi a écrit :
>>>>>
>>>>> Hello,
>>>>>
>>>>> On Tue, Feb 03, 2026 at 07:37:34PM +0100, Jacopo Mondi wrote:
>>>>>> Hello
>>>>>>
>>>>>> On Thu, Jan 29, 2026 at 12:00:24AM +0100, Michael Riesch wrote:
>>>>>>> Hi Antoine,
>>>>>>>
>>>>>>> Thanks for your response.
>>>>>>>
>>>>>>> On 1/28/26 09:17, Antoine Bouyer wrote:
>>>>>>>> Hi Michael
>>>>>>>>
>>>>>>>> On 1/26/26 10:44 AM, Michael Riesch wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Antoine,
>>>>>>>>>
>>>>>>>>> On 1/23/26 09:09, Antoine Bouyer wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> This RFC patch series introduces the NXP Neo Image Signal Processor
>>>>>>>>>> (ISP)
>>>>>>>>>> driver, used in the NXP i.MX95 SoC and future devices in the i.MX9
>>>>>>>>>> family.
>>>>>>>>>> The series also includes updates to the generic v4l2-isp interface to
>>>>>>>>>> support extended statistics required by the Neo ISP.
>>>>>>>>>>
>>>>>>>>>> The Neo ISP processes one or more camera streams, converting RAW formats
>>>>>>>>>> into YUV or RGB outputs. Its architecture is largely influenced by the
>>>>>>>>>> PISP driver. The hardware supports up to eight contexts, with three sink
>>>>>>>>>> pads (main input, HDR input, and parameter buffers) and three source
>>>>>>>>>> pads
>>>>>>>>>> (RGB output, IR output, and statistics metadata).
>>>>>>>>>>
>>>>>>>>>> At this stage, both legacy (fixed-size) and extensible (dynamic-size)
>>>>>>>>>> parameter/statistics buffers are supported through the generic v4l2-isp
>>>>>>>>>> framework, similar to rkisp1 and Mali-C55. The driver currently supports
>>>>>>>>>> M2M operation; direct CSI-to-ISP streaming is not yet implemented.
>>>>>>>>>
>>>>>>>>> How do you envisage the direct CSI-to-ISP streaming shall be supported?
>>>>>>>>
>>>>>>>> At this stage, this streaming mode still needs to be evaluated on
>>>>>>>> neoisp. We should follow the integration model used by existing ISP
>>>>>>>> drivers to avoid duplicating solutions.
>>>>>>>
>>>>>>> Fair point, but I have had the impression that there are not many
>>>>>>> examples (if any). The rkisp1 driver, for instance, only supports inline
>>>>>>> mode although the HW should be able to do both.
>>>>>>>
>>>>>>> But any pointers most welcome, I won't claim I have the full overview.
>>>>>>>
>>>>>>>>
>>>>>>>> Below are my initial thoughts on the specific points you raised:
>>>>>>>>
>>>>>>>>> - How shall the final media graph(s) look like?
>>>>>>>>
>>>>>>>> The media entities would remain mostly identical, except for the absence
>>>>>>>> of ISI. The topology would be a direct linkg from sensor->csi-
>>>>>>>>> formatter->neoisp.
>>>>>>
>>>>>> If support for inline mode has to be added later, the ISP will need to
>>>>>> be registered in the same media graph of the CSI-2 receiver to be able
>>>>>> to link the two, right ?
>>>>
>>>> yes correct.
>>>>
>>>>>>
>>>>>> How do you envision to control the ISP operating mode, because I'm
>>>>>> afraid if you register the ISP in its own media graph, you're locking
>>>>>> yourself there as implementing inline mode would require a different
>>>>>> media topology with all the implications on the rest of the userspace
>>>>>> stack.
>>>>>>
>>>>>> This might not be a problem if you know that the inline vs m2m mode is
>>>>>> SoC sythesis time parameter. Some SoCs will integrate neoisp inline, some
>>>>>> other as m2m. In this case you'll likely need two pipeline handlers
>>>>>> in libcamera, but if that's per SoC-line maybe is acceptable. The fact
>>>>>> you suggests in inline mode there won't be an ISI makes me think this
>>>>>> actually depends on the SoC design ?
>>>>
>>>> Actually, this is not really at SoC synthesis time, neoisp HW does support
>>>> both modes, that is configurable. But ISP HW can run in a single mode only
>>>
>>>> once it is configured. Streaming mode is tightly coupled with CSI HW, then
>>>> ISP cannot be used in M2M mode with another sensor simultaneously.
>>>>
>>>
>>> Yes, my point is trying to understand "how it is configured" and what
>>> your expectations are.
>>>
>>> Will the board .dts (or a camera .dtso) decide how the ISP is operated
>>> by defining its endpoint connections ? Assuming with the same SoC both
>>> inline and m2m modes are possible, without differences in the SoC
>>> design/integration, will users of the same board have to modify the
>>> .dts or load ad-hoc .dtso to decide what mode is in use ?
>>>
>>> Then, the question of how the media topology will look and which
>>> components registers what has to be clarified.
>>>
>>> Let's try to make a taxonomy of the cases we have in mainline (or on
>>> their way to mainline).
>>>
>>> In the mali example I mentioned, the operating mode is selected by the
>>> .dtsi as Mali can be integrated either inline or in m2m mode in
>>> different SoCs. RZ/V2H in example, will always be m2m as it doesn't
>>> interface the CSI-2 receiver with the ISP but rather interfaces the
>>> ISP with a companion chip the performs memory access on its behalf
>>> (the IVC). A different design that incorporates Mali inline will
>>> instead have to interface the CSI-2 receiver with the ISP with
>>> internal busses/glue logic and will then have to described this in dts.
>>>
>>> This is fine as the ISP integration is different and then having the
>>> description in dts is legit.
>>>
>>> The ISP driver unconditionally registers an async notifier and the
>>> downstream component (csi-2 or IVC) will register its async subdev(s)
>>> which will all appear in the ISP media graph. This is possible because
>>> the assumption is that the CSI-2 receiver (or the companion chip)
>>> won't register their own media graph.
>>>
>>> The Renesas V4H example I mentioned is instead different. The ISP can
>>> be operated in inline and m2m, on the same SoC without any
>>> modification to hardware and to the dts/dtsi. It's basically a user
>>> choice we defer to runtime.
>>>
>>> The V4H already has a component that registers a media graph: the
>>> CSI-2/VIN block which is found in many SoCs of the same (and older)
>>> generations. The ISP is present only in some SoC, but the CSI-2/VIN is
>>> always there. In this case, to support both inline and m2m modes, the
>>> VIN registers the media device and, with the trick I pointed you to in
>>> Niklas' code, the ISP registers a subdev in the VIN media graph. Then
>>> the inline/m2m mode can be selected by media link enablement at
>>> run-time. Now, inline mode is not yet supported on V4H and there might
>>> be dragons there, but at least, both modes should be possible on the same
>>> SoC.
>>>
>>> On the other extremes we have the RaspberryPi PiSP BE and RkISP1.
>>>
>>> RPi knows the only SoC where the PiPS will be found is their one. The
>>> ISP cannot function inline and will always be m2m. In this case, a
>>> dedicated media graph for the ISP is the simplest and cleanest
>>> solution.
>>>
>>> RkISP1 instead will always be inline only. It registers a media device
>>> and an async notifier, the connected CSI-2 receiver will register an
>>> async subdev and will be connected to the device tree endpoint of the
>>> ISP device node.
>>>
>>> What model is the closest one to the neoisp integration that you
>>> envision on NXP SoCs ?
>>
>> Then the closest model is the V4H one I believe: we both support m2m and
>> streaming (inline) modes on the same SoC. I tested the trick you pointed
>> out, and let the formatter sharing the media device (owned by ISI) to the
>> neo ISP, like renesas csisp does. It registers as expected, thanks for the
>> proposal !
>>
>> I think formatter is a good candidate since it is physically connected to
>> ISP through a pixel link for streaming mode. Moreover, I propose to create a
>> dedicated pad b/w formatter and ISP and keep the one b/w formatter and ISI
>> as it is, so that in future we can configure the stream format which is sent
>> to ISP, and the one sent to ISI.
>
> So, if I look at the ISI media graph you shared earlier in the thread,
> the formatter will gain one source pad to be optionally connected to
> the ISP, while the existing one that connectes to the crossbar will
> stay as it is today ?
Yes exactly. However, I don't plan to push the pad changes on the M2M
patch series yet. I would rather create the pads (formatter and ISP)
together with the introduction of the inline mode.
>
>>
>> I also tested the streaming path can be added in device tree with endpoint
>> connections between the nodes, so that ISP can create the media link when it
>> registers itself to the media device.
>
> I think this is fine if there actually is a data path between the
> formatter and the ISP as you have suggested.
Yes there is a pixel link between formatter and ISP (at least on i.MX95
SoC).
>
>>
>> Thus at runtime, if userspace enables this link, then neo runs in streaming
>> mode, otherwise m2m is used.
>
> So if we have an ISI, the ISP can be operated in m2m or inline based
> on run-time link enablement, right ?
Yes. And as per my understanding, ISI could still be used with
inline-ISP, to capture raw frame.
>
>>
>> If another SoC in future doesn't support streaming path, the endpoints can
>> be removed from device tree, the ISP would stay in media graph anyway with
>> m2m mode only.
>
> Nice!
>
> Do you envision a streaming mode only design, where there is no ISI
> and the ISP has to register the media device itself ?
AFAIK, there is no such design, ISI is always there.
However, I initially though about adding an ISP "standalone" mode, where
ISP could register its own media device (as it was done before). That
could ease standalone test I believe, and limit dependency with other
drivers. But I don't know how this can cohabit with the phandle
registration approach, except by adding a new optional property on
neoisp node to force standalone registration, or a module parameter.
Do you think it's worth adding such standalone mode ? and if yes, how
can we enable it in a proper way ?
>
>>
>> Do you think this is good approach ?
>>
>
> Certainly so! Thanks for the effort!
>
>>>
>>>>>
>>>>> One small correction after some more research:
>>>>>
>>>>> we actually already have a pipeline in libcamera that supports inline
>>>>> and (will soon) support m2m: the mali c55 one. My take on "probably
>>>>> need two pipeline handlers" was not correct then.
>>>>
>>>> Yes, I saw your patchwork on libcamera about this coming upgrade. Spent some
>>>> time analyzing it ':) Seems we are quite aligned as per my understanding:
>>>> inline mode (i.e. streaming mode with neoisp) _or_ M2M mode using IVC video
>>>> device from Mali. Is that right ?
>>>>
>>>>>
>>>>> As said, Mali-C55 can be integrated inline or in m2m mode and this is
>>>>> decided based on the device tree endpoint connections.
>>>>
>>>> Good. Do you have an example available ?
>>>
>>> It's in mainline, but there's nothing exciting there as the assumption
>>> is that there will always be a connection on the first endpoint and
>>> the driver simply registers a notifier for the connected async subdev. If
>>> it's a CSI-2 receiver then we're inline. If it's a companion chip
>>> we're m2m.
>>>
>>> The libcamera pipeline (not upstream yet) inspects the media entity
>>> function of the entity connected to the ISP sink pad#0. If it's a
>>> CSI-2 reciver we're inline. If it's not, we're m2m. Based on that it
>>> operated the pipeline differently.
>>>
>>>>
>>>>>
>>>>> So, if you know neoisp will be integrated either inline or m2m in
>>>>> different SoC lines, maybe deferring it to device tree is good enough
>>>>> at the expense of a slightly more complicated pipeline ?
>>>>
>>>> As said, SoC/ISP HW does support both modes. But I think that the selection
>>>> can be done in device tree too. So that after bootup, a camera will be used
>>>> only in 1 mode.
>>>>
>>>>>
>>>>> I guess this has implications on the bindings definition as well..
>>>>
>>>> Most probably yes. Can this be done as second phase once evaluation is
>>>> completed ?
>>>>
>>>
>>> I think you should asses from the very beginning what is the planned
>>> integration model of the ISP in order not to corner yourself in a
>>> place where it will be hard to support inline without re-writing
>>> the driver's media device registration logic.
>>>
>>> Looking at the below media graph of CSI/ISI you should ask the question "how
>>> will I register the ISP subdev in the CSI-2 media graph when inline"
>>> and "how will I describe inline vs m2m mode if the underlying hardware
>>> design doesn't change?" as deferring it to the .dts might not be the
>>> most correct way to go in that case ?
>>
>> So I think we are aligned now: one media graph from the beginning for
>> supporting both modes, even if first mainline version only supports m2m.
>> Would that be ok ?
>>
>
> Yes!
>
> Let's only just clarify if there will ever be a mode where there is no
> ISI as in that case I think we need to clarify who will register the
> media graph and the async notifiers..
Fine. Let me prepare a patchset with all changes already discussed then.
I keep standalone mode out for the moment.
BR
Antoine
>
>>>
>>>>>
>>>>>>
>>>>>> However, if you plan to allow deferring inline/m2m mode selection to
>>>>>> the system integrators or even have it as a run-time parameter, then
>>>>>> you should really consider having the ISP in the same media graph as
>>>>>> the CSI-2 receiver and operate the whole CSI-2/ISI/ISP as a single
>>>>>> media graph, where you could select the operating mode through media link
>>>>>> enablement or dts endpoint connections
>>>>>>
>>>>>> Niklas (in cc) has addressed a similar situation, where inline and m2m
>>>>>> mode can be selected by link enablement at runtime here
>>>>>> https://patchwork.linuxtv.org/project/linux-media/patch/20251225171054.1370856-3-niklas.soderlund+renesas@ragnatech.se/
>>>>>> (see risp_cs_internal_ops)
>>>>>>
>>>>>>>
>>>>>>> OK, I thought that ISI was still around...
>>>>>>>
>>>>>>>>
>>>>>>>>> - How many media devices are registered and which driver registers it
>>>>>>>>> or them?
>>>>>>>>
>>>>>>>> That will be part of the evaluation. My initial assumption is that
>>>>>>>> neoisp would be the appropriate component to register the media device
>>>>>>>> in this mode, since ISI is not involved, and ISI currently performs the
>>>>>>>> registration in the M2M configuration.
>>>>>>
>>>>>> Isn't the ISP registering its own media graph ?
>>>>
>>>> Yes, 8 copies of ISP media graph, that can be used with the 8 output video
>>>> devices of the ISI media graph.
>>>>
>>>
>>> I suggest you do what RPi does. The mainline driver only registers one
>>> instance and they carry a little patch downstream that implements the
>>> for() loop where multiple instances are registered. Duplicating media graphs
>>> is not desirable (at least in mainline) as we can have ISPs with 256
>>> contexts, we don't want 256 media graphs.
>>
>> Ok. Will do same approach then: 1 neoisp instance on mainline + downstream
>> patch to create other instances (x8), all in same media graph.
>
> Thank you. Let's work on a proper solution and then the downstream
> patch will be dropped!
>
>>
>>>
>>> A framework level solution with proper priority handling and job
>>> scheduling is what is required and that's what the context work should
>>> end up being.>
>>>
>>>>>>
>>>>>> Can we get a copy of all media graphs on an i.MX95 system including
>>>>>> the ISI and the CSI-2 receiver ?
>>>>
>>>> Here is an example with multiple sensors. Or do you need it in another
>>>> format ?
>>>
>>> No it's fine, thanks!
>>>
>>>>
>>>>
>>>> digraph board {
>>>> rankdir=TB
>>>> n00000001 [label="{{<port0> 0 | <port1> 1 | <port2> 2 | <port3> 3 |
>>>> <port4> 4} | crossbar\n/dev/v4l-subdev8 | {<port5> 5 | <port6> 6 | <port7> 7
>>>> | <port8> 8 | <port9> 9 | <port10> 10 | <port11> 11 | <port12> 12}}",
>>>> shape=Mrecord, style=filled, fillcolor=green]
>>>> n00000001:port5 -> n0000000f:port0 [style=bold]
>>>> n00000001:port6 -> n0000001a:port0 [style=bold]
>>>> n00000001:port7 -> n00000025:port0 [style=bold]
>>>> n00000001:port8 -> n00000030:port0 [style=bold]
>>>> n00000001:port9 -> n0000003b:port0 [style=bold]
>>>> n00000001:port10 -> n00000046:port0 [style=bold]
>>>> n00000001:port11 -> n00000051:port0 [style=bold]
>>>> n00000001:port12 -> n0000005c:port0 [style=bold]
>>>> n0000000f [label="{{<port0> 0} | mxc_isi.0\n/dev/v4l-subdev9 |
>>>> {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
>>>> n0000000f:port1 -> n00000012 [style=bold]
>>>> n00000012 [label="mxc_isi.0.capture\n/dev/video8", shape=box,
>>>> style=filled, fillcolor=yellow]
>>>> n0000001a [label="{{<port0> 0} | mxc_isi.1\n/dev/v4l-subdev10 |
>>>> {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
>>>> n0000001a:port1 -> n0000001d [style=bold]
>>>> n0000001d [label="mxc_isi.1.capture\n/dev/video9", shape=box,
>>>> style=filled, fillcolor=yellow]
>>>> n00000025 [label="{{<port0> 0} | mxc_isi.2\n/dev/v4l-subdev11 |
>>>> {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
>>>> n00000025:port1 -> n00000028 [style=bold]
>>>> n00000028 [label="mxc_isi.2.capture\n/dev/video10", shape=box,
>>>> style=filled, fillcolor=yellow]
>>>> n00000030 [label="{{<port0> 0} | mxc_isi.3\n/dev/v4l-subdev12 |
>>>> {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
>>>> n00000030:port1 -> n00000033 [style=bold]
>>>> n00000033 [label="mxc_isi.3.capture\n/dev/video13", shape=box,
>>>> style=filled, fillcolor=yellow]
>>>> n0000003b [label="{{<port0> 0} | mxc_isi.4\n/dev/v4l-subdev13 |
>>>> {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
>>>> n0000003b:port1 -> n0000003e [style=bold]
>>>> n0000003e [label="mxc_isi.4.capture\n/dev/video14", shape=box,
>>>> style=filled, fillcolor=yellow]
>>>> n00000046 [label="{{<port0> 0} | mxc_isi.5\n/dev/v4l-subdev14 |
>>>> {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
>>>> n00000046:port1 -> n00000049 [style=bold]
>>>> n00000049 [label="mxc_isi.5.capture\n/dev/video21", shape=box,
>>>> style=filled, fillcolor=yellow]
>>>> n00000051 [label="{{<port0> 0} | mxc_isi.6\n/dev/v4l-subdev15 |
>>>> {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
>>>> n00000051:port1 -> n00000054 [style=bold]
>>>> n00000054 [label="mxc_isi.6.capture\n/dev/video22", shape=box,
>>>> style=filled, fillcolor=yellow]
>>>> n0000005c [label="{{<port0> 0} | mxc_isi.7\n/dev/v4l-subdev16 |
>>>> {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
>>>> n0000005c:port1 -> n0000005f [style=bold]
>>>> n0000005f [label="mxc_isi.7.capture\n/dev/video23", shape=box,
>>>> style=filled, fillcolor=yellow]
>>>> n00000067 [label="mxc_isi.output\n", shape=box, style=filled,
>>>> fillcolor=yellow]
>>>> n00000067 -> n00000001:port4 [style=bold]
>>>> n0000006e [label="{{<port0> 0} |
>>>> 4ac10000.syscon:formatter@20\n/dev/v4l-subdev17 | {<port1> 1}}",
>>>> shape=Mrecord, style=filled, fillcolor=green]
>>>> n0000006e:port1 -> n00000001:port2 [style=bold]
>>>> n00000073 [label="{{<port0> 0} |
>>>> csidev-4ad30000.csi\n/dev/v4l-subdev18 | {<port1> 1}}", shape=Mrecord,
>>>> style=filled, fillcolor=green]
>>>> n00000073:port1 -> n0000006e:port0 [style=bold]
>>>> n00000078 [label="{{<port0> 0 | <port1> 1 | <port2> 2 | <port3> 3} |
>>>> max96724 2-0027\n/dev/v4l-subdev19 | {<port4> 4 | <port5> 5}}",
>>>> shape=Mrecord, style=filled, fillcolor=green]
>>>> n00000078:port4 -> n00000073:port0 [style=dashed]
>>>> n00000081 [label="{{} | mx95mbcam 8-0040\n/dev/v4l-subdev20 |
>>>> {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
>>>> n00000081:port0 -> n00000078:port0 [style=bold]
>>>> n00000085 [label="{{} | mx95mbcam 9-0040\n/dev/v4l-subdev21 |
>>>> {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
>>>> n00000085:port0 -> n00000078:port1 [style=bold]
>>>> n00000089 [label="{{} | mx95mbcam 10-0040\n/dev/v4l-subdev22 |
>>>> {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
>>>> n00000089:port0 -> n00000078:port2 [style=bold]
>>>> n0000008d [label="{{} | mx95mbcam 11-0040\n/dev/v4l-subdev23 |
>>>> {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
>>>> n0000008d:port0 -> n00000078:port3 [style=bold]
>>>> }
>>>>
>>>>
>>>>>>
>>>>>> If I'm not mistaken you'll have 8 copies of the ISP media graphs, and
>>>>>> that's exactly what we're working on with the context framework :)
>>>>>>
>>>>
>>>> Ok. Then I should have a look to context framework too ...
>>>>
>>>
>>> Please, I hope to be able to resume working on it sooner or later
>>> given the right use case.
>>
>> Ok. Will continue monitoring the multi context work. Seems to be a nice
>> feature indeed. But as impact on userspace is more significant, that can be
>> done as a second step I guess, and will keep the multi instance downstream
>> patch meanwhile.
>>
>>>
>>>>>>
>>>>>>>
>>>>>>> ... since it is not, your assumption seems very reasonable.
>>>>>>>
>>>>>>>>
>>>>>>>>> - How can the user decide whether direct (csi2isp) or indirect
>>>>>>>>> (mem2mem) streaming shall be used?
>>>>>>>>
>>>>>>>> That will also be part of the evaluation. From dts would be my first
>>>>>>>> option, but may prevent using both modes on same platform then.
>>>>>>>
>>>>>>> Of course this depends what the hardware is able to do, but in case the
>>>>>>> HW is reconfigurable easily, I doubt that device tree is a good choice
>>>>>>> to solve that.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> While it is certainly OK to introduce this support only at a later
>>>>>>>>> stage, it makes sense to consider this right from the start to avoid
>>>>>>>>> some nasty changes e.g. in how this hardware is exposed to user space.
>>>>>>>>>
>>>>>>>>> Also, we are facing a similiar challenge with recent Rockchip ISP
>>>>>>>>> hardware (RK3588, RK3576, ...) and it would be great to hear your
>>>>>>>>> thoughts about that.
>>>>>>>>
>>>>>>>> Is there an existing discussion thread available on this topic? I would
>>>>>>>> be very interested in following it.
>>>>>>>
>>>>>>> Not yet, I am afraid. But there should be one or two soon (TM) :-)
>>>>>>
>>>>>> It's probably time to have one :)
>>>>
>>>> Good. Please loop me in ;)
>>>
>>> You are in, this is the conversation ;)
>>>
>>> It might be a good discussion point for the media summit in Nice
>>> co-located with Embedded Recipes if people with interest in the topic
>>> will going the be there.
>>
>> Great ! Will try to join then.
>>
>
> I'm not sure yet how many interested parties will be in Nice and if it
> would make sense to organize an "ISP design day" there or should we
> plan a devroom for Plumbers in Prague ?
>
>
>> BR
>> Antoine
>>
>>>
>>> I'm also adding Anthony from ARM as I know he's going through the same
>>> inline/m2m duality you're now facing.
>>>
>>> Thanks
>>> j
>>>
>>>>
>>>> BR
>>>> Antoine
>>>>
>>>>>>
>>>>>>>
>>>>>>> Thanks and regards,
>>>>>>> Michael
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Antoine
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks in advance and best regards,
>>>>>>>>> Michael
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This series is posted as RFC because extending the v4l2-isp interface
>>>>>>>>>> may
>>>>>>>>>> overlap with ongoing work. If similar development already exists, I am
>>>>>>>>>> happy to rebase or adapt the series accordingly. If preferred, the
>>>>>>>>>> series
>>>>>>>>>> can also be split into two parts: the v4l2-isp rework and the Neo ISP
>>>>>>>>>> driver introduction.
>>>>>>>>>>
>>>>>>>>>> A few checkpatch warnings in v4l2-ioctl.c remain intentionally to stay
>>>>>>>>>> consistent with the existing style in that file.
>>>>>>>>>>
>>>>>>>>>> Testing was performed on the i.MX95 EVK using the media/next kernel in
>>>>>>>>>> standalone M2M mode. End-to-end camera-to-ISP capture has been validated
>>>>>>>>>> using the downstream NXP kernel, as some hardware dependencies are not
>>>>>>>>>> yet upstreamed.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Antoine
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>> Here are v4l2-compliance test results:
>>>>>>>>>>
>>>>>>>>>> v4l2-compliance 1.28.1-5233, 64 bits, 64-bit time_t
>>>>>>>>>> v4l2-compliance SHA: fc15e229d9d3 2024-07-23 19:22:15
>>>>>>>>>>
>>>>>>>>>> Compliance test for neoisp device /dev/media0:
>>>>>>>>>>
>>>>>>>>>> Media Driver Info:
>>>>>>>>>> Driver name : neoisp
>>>>>>>>>> Model : neoisp
>>>>>>>>>> Serial :
>>>>>>>>>> Bus info : platform:4ae00000.isp
>>>>>>>>>> Media version : 6.19.0
>>>>>>>>>> Hardware revision: 0x00000002 (2)
>>>>>>>>>> Driver version : 6.19.0
>>>>>>>>>>
>>>>>>>>>> Required ioctls:
>>>>>>>>>> test MEDIA_IOC_DEVICE_INFO: OK
>>>>>>>>>> test invalid ioctls: OK
>>>>>>>>>>
>>>>>>>>>> Allow for multiple opens:
>>>>>>>>>> test second /dev/media0 open: OK
>>>>>>>>>> test MEDIA_IOC_DEVICE_INFO: OK
>>>>>>>>>> test for unlimited opens: OK
>>>>>>>>>>
>>>>>>>>>> Media Controller ioctls:
>>>>>>>>>> test MEDIA_IOC_G_TOPOLOGY: OK
>>>>>>>>>> Entities: 7 Interfaces: 7 Pads: 12 Links: 13
>>>>>>>>>> test MEDIA_IOC_ENUM_ENTITIES/LINKS: OK
>>>>>>>>>> test MEDIA_IOC_SETUP_LINK: OK
>>>>>>>>>>
>>>>>>>>>> Total for neoisp device /dev/media0: 8, Succeeded: 8, Failed: 0,
>>>>>>>>>> Warnings: 0
>>>>>>>>>> --------------------------------------------------------------------------------
>>>>>>>>>> Compliance test for neoisp device /dev/video0:
>>>>>>>>>>
>>>>>>>>>> Driver Info:
>>>>>>>>>> Driver name : neoisp
>>>>>>>>>> Card type : neoisp
>>>>>>>>>> Bus info : platform:4ae00000.isp
>>>>>>>>>> Driver version : 6.19.0
>>>>>>>>>> Capabilities : 0x8ca03000
>>>>>>>>>> Video Capture Multiplanar
>>>>>>>>>> Video Output Multiplanar
>>>>>>>>>> Metadata Capture
>>>>>>>>>> Metadata Output
>>>>>>>>>> Streaming
>>>>>>>>>> Extended Pix Format
>>>>>>>>>> Device Capabilities
>>>>>>>>>> Device Caps : 0x04202000
>>>>>>>>>> Video Output Multiplanar
>>>>>>>>>> Streaming
>>>>>>>>>> Extended Pix Format
>>>>>>>>>> Media Driver Info:
>>>>>>>>>> Driver name : neoisp
>>>>>>>>>> Model : neoisp
>>>>>>>>>> Serial :
>>>>>>>>>> Bus info : platform:4ae00000.isp
>>>>>>>>>> Media version : 6.19.0
>>>>>>>>>> Hardware revision: 0x00000002 (2)
>>>>>>>>>> Driver version : 6.19.0
>>>>>>>>>> Interface Info:
>>>>>>>>>> ID : 0x0300000a
>>>>>>>>>> Type : V4L Video
>>>>>>>>>> Entity Info:
>>>>>>>>>> ID : 0x00000008 (8)
>>>>>>>>>> Name : neoisp-input0
>>>>>>>>>> Function : V4L2 I/O
>>>>>>>>>> Pad 0x01000009 : 0: Source
>>>>>>>>>> Link 0x0200000c: to remote pad 0x1000002 of entity
>>>>>>>>>> 'neoisp' (Image Signal Processor): Data, Enabled, Immutable
>>>>>>>>>>
>>>>>>>>>> Required ioctls:
>>>>>>>>>> test MC information (see 'Media Driver Info' above): OK
>>>>>>>>>> test VIDIOC_QUERYCAP: OK
>>>>>>>>>> test invalid ioctls: OK
>>>>>>>>>>
>>>>>>>>>> Allow for multiple opens:
>>>>>>>>>> test second /dev/video0 open: OK
>>>>>>>>>> test VIDIOC_QUERYCAP: OK
>>>>>>>>>> test VIDIOC_G/S_PRIORITY: OK
>>>>>>>>>> test for unlimited opens: OK
>>>>>>>>>>
>>>>>>>>>> Debug ioctls:
>>>>>>>>>> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
>>>>>>>>>> test VIDIOC_LOG_STATUS: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Input ioctls:
>>>>>>>>>> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>>>>>>>>>> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUMAUDIO: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_AUDIO: OK (Not Supported)
>>>>>>>>>> Inputs: 0 Audio Inputs: 0 Tuners: 0
>>>>>>>>>>
>>>>>>>>>> Output ioctls:
>>>>>>>>>> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
>>>>>>>>>> Outputs: 0 Audio Outputs: 0 Modulators: 0
>>>>>>>>>>
>>>>>>>>>> Input/Output configuration ioctls:
>>>>>>>>>> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
>>>>>>>>>> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_EDID: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Control ioctls:
>>>>>>>>>> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
>>>>>>>>>> test VIDIOC_QUERYCTRL: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_CTRL: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
>>>>>>>>>> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
>>>>>>>>>> Standard Controls: 0 Private Controls: 0
>>>>>>>>>>
>>>>>>>>>> Format ioctls:
>>>>>>>>>> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
>>>>>>>>>> test VIDIOC_G/S_PARM: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_FBUF: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_FMT: OK
>>>>>>>>>> test VIDIOC_TRY_FMT: OK
>>>>>>>>>> test VIDIOC_S_FMT: OK
>>>>>>>>>> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
>>>>>>>>>> test Cropping: OK
>>>>>>>>>> test Composing: OK (Not Supported)
>>>>>>>>>> test Scaling: OK
>>>>>>>>>>
>>>>>>>>>> Codec ioctls:
>>>>>>>>>> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_ENC_INDEX: OK (Not Supported)
>>>>>>>>>> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Buffer ioctls:
>>>>>>>>>> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
>>>>>>>>>> test CREATE_BUFS maximum buffers: OK
>>>>>>>>>> test VIDIOC_REMOVE_BUFS: OK
>>>>>>>>>> test VIDIOC_EXPBUF: OK
>>>>>>>>>> test Requests: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Total for neoisp device /dev/video0: 48, Succeeded: 48, Failed: 0,
>>>>>>>>>> Warnings: 0
>>>>>>>>>> --------------------------------------------------------------------------------
>>>>>>>>>> Compliance test for neoisp device /dev/video1:
>>>>>>>>>>
>>>>>>>>>> Driver Info:
>>>>>>>>>> Driver name : neoisp
>>>>>>>>>> Card type : neoisp
>>>>>>>>>> Bus info : platform:4ae00000.isp
>>>>>>>>>> Driver version : 6.19.0
>>>>>>>>>> Capabilities : 0x8ca03000
>>>>>>>>>> Video Capture Multiplanar
>>>>>>>>>> Video Output Multiplanar
>>>>>>>>>> Metadata Capture
>>>>>>>>>> Metadata Output
>>>>>>>>>> Streaming
>>>>>>>>>> Extended Pix Format
>>>>>>>>>> Device Capabilities
>>>>>>>>>> Device Caps : 0x04202000
>>>>>>>>>> Video Output Multiplanar
>>>>>>>>>> Streaming
>>>>>>>>>> Extended Pix Format
>>>>>>>>>> Media Driver Info:
>>>>>>>>>> Driver name : neoisp
>>>>>>>>>> Model : neoisp
>>>>>>>>>> Serial :
>>>>>>>>>> Bus info : platform:4ae00000.isp
>>>>>>>>>> Media version : 6.19.0
>>>>>>>>>> Hardware revision: 0x00000002 (2)
>>>>>>>>>> Driver version : 6.19.0
>>>>>>>>>> Interface Info:
>>>>>>>>>> ID : 0x03000010
>>>>>>>>>> Type : V4L Video
>>>>>>>>>> Entity Info:
>>>>>>>>>> ID : 0x0000000e (14)
>>>>>>>>>> Name : neoisp-input1
>>>>>>>>>> Function : V4L2 I/O
>>>>>>>>>> Pad 0x0100000f : 0: Source
>>>>>>>>>> Link 0x02000012: to remote pad 0x1000003 of entity
>>>>>>>>>> 'neoisp' (Image Signal Processor): Data
>>>>>>>>>>
>>>>>>>>>> Required ioctls:
>>>>>>>>>> test MC information (see 'Media Driver Info' above): OK
>>>>>>>>>> test VIDIOC_QUERYCAP: OK
>>>>>>>>>> test invalid ioctls: OK
>>>>>>>>>>
>>>>>>>>>> Allow for multiple opens:
>>>>>>>>>> test second /dev/video1 open: OK
>>>>>>>>>> test VIDIOC_QUERYCAP: OK
>>>>>>>>>> test VIDIOC_G/S_PRIORITY: OK
>>>>>>>>>> test for unlimited opens: OK
>>>>>>>>>>
>>>>>>>>>> Debug ioctls:
>>>>>>>>>> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
>>>>>>>>>> test VIDIOC_LOG_STATUS: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Input ioctls:
>>>>>>>>>> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>>>>>>>>>> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUMAUDIO: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_AUDIO: OK (Not Supported)
>>>>>>>>>> Inputs: 0 Audio Inputs: 0 Tuners: 0
>>>>>>>>>>
>>>>>>>>>> Output ioctls:
>>>>>>>>>> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
>>>>>>>>>> Outputs: 0 Audio Outputs: 0 Modulators: 0
>>>>>>>>>>
>>>>>>>>>> Input/Output configuration ioctls:
>>>>>>>>>> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
>>>>>>>>>> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_EDID: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Control ioctls:
>>>>>>>>>> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
>>>>>>>>>> test VIDIOC_QUERYCTRL: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_CTRL: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
>>>>>>>>>> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
>>>>>>>>>> Standard Controls: 0 Private Controls: 0
>>>>>>>>>>
>>>>>>>>>> Format ioctls:
>>>>>>>>>> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
>>>>>>>>>> test VIDIOC_G/S_PARM: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_FBUF: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_FMT: OK
>>>>>>>>>> test VIDIOC_TRY_FMT: OK
>>>>>>>>>> test VIDIOC_S_FMT: OK
>>>>>>>>>> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
>>>>>>>>>> test Cropping: OK
>>>>>>>>>> test Composing: OK (Not Supported)
>>>>>>>>>> test Scaling: OK
>>>>>>>>>>
>>>>>>>>>> Codec ioctls:
>>>>>>>>>> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_ENC_INDEX: OK (Not Supported)
>>>>>>>>>> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Buffer ioctls:
>>>>>>>>>> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
>>>>>>>>>> test CREATE_BUFS maximum buffers: OK
>>>>>>>>>> test VIDIOC_REMOVE_BUFS: OK
>>>>>>>>>> test VIDIOC_EXPBUF: OK
>>>>>>>>>> test Requests: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Total for neoisp device /dev/video1: 48, Succeeded: 48, Failed: 0,
>>>>>>>>>> Warnings: 0
>>>>>>>>>> --------------------------------------------------------------------------------
>>>>>>>>>> Compliance test for neoisp device /dev/video2:
>>>>>>>>>>
>>>>>>>>>> Driver Info:
>>>>>>>>>> Driver name : neoisp
>>>>>>>>>> Card type : neoisp
>>>>>>>>>> Bus info : platform:4ae00000.isp
>>>>>>>>>> Driver version : 6.19.0
>>>>>>>>>> Capabilities : 0x8ca03000
>>>>>>>>>> Video Capture Multiplanar
>>>>>>>>>> Video Output Multiplanar
>>>>>>>>>> Metadata Capture
>>>>>>>>>> Metadata Output
>>>>>>>>>> Streaming
>>>>>>>>>> Extended Pix Format
>>>>>>>>>> Device Capabilities
>>>>>>>>>> Device Caps : 0x0c200000
>>>>>>>>>> Metadata Output
>>>>>>>>>> Streaming
>>>>>>>>>> Extended Pix Format
>>>>>>>>>> Media Driver Info:
>>>>>>>>>> Driver name : neoisp
>>>>>>>>>> Model : neoisp
>>>>>>>>>> Serial :
>>>>>>>>>> Bus info : platform:4ae00000.isp
>>>>>>>>>> Media version : 6.19.0
>>>>>>>>>> Hardware revision: 0x00000002 (2)
>>>>>>>>>> Driver version : 6.19.0
>>>>>>>>>> Interface Info:
>>>>>>>>>> ID : 0x03000016
>>>>>>>>>> Type : V4L Video
>>>>>>>>>> Entity Info:
>>>>>>>>>> ID : 0x00000014 (20)
>>>>>>>>>> Name : neoisp-params
>>>>>>>>>> Function : V4L2 I/O
>>>>>>>>>> Pad 0x01000015 : 0: Source
>>>>>>>>>> Link 0x02000018: to remote pad 0x1000004 of entity
>>>>>>>>>> 'neoisp' (Image Signal Processor): Data, Enabled
>>>>>>>>>>
>>>>>>>>>> Required ioctls:
>>>>>>>>>> test MC information (see 'Media Driver Info' above): OK
>>>>>>>>>> test VIDIOC_QUERYCAP: OK
>>>>>>>>>> test invalid ioctls: OK
>>>>>>>>>>
>>>>>>>>>> Allow for multiple opens:
>>>>>>>>>> test second /dev/video2 open: OK
>>>>>>>>>> test VIDIOC_QUERYCAP: OK
>>>>>>>>>> test VIDIOC_G/S_PRIORITY: OK
>>>>>>>>>> test for unlimited opens: OK
>>>>>>>>>>
>>>>>>>>>> Debug ioctls:
>>>>>>>>>> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
>>>>>>>>>> test VIDIOC_LOG_STATUS: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Input ioctls:
>>>>>>>>>> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>>>>>>>>>> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUMAUDIO: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_AUDIO: OK (Not Supported)
>>>>>>>>>> Inputs: 0 Audio Inputs: 0 Tuners: 0
>>>>>>>>>>
>>>>>>>>>> Output ioctls:
>>>>>>>>>> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
>>>>>>>>>> Outputs: 0 Audio Outputs: 0 Modulators: 0
>>>>>>>>>>
>>>>>>>>>> Input/Output configuration ioctls:
>>>>>>>>>> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
>>>>>>>>>> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_EDID: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Control ioctls:
>>>>>>>>>> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
>>>>>>>>>> test VIDIOC_QUERYCTRL: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_CTRL: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
>>>>>>>>>> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
>>>>>>>>>> Standard Controls: 0 Private Controls: 0
>>>>>>>>>>
>>>>>>>>>> Format ioctls:
>>>>>>>>>> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
>>>>>>>>>> test VIDIOC_G/S_PARM: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_FBUF: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_FMT: OK
>>>>>>>>>> test VIDIOC_TRY_FMT: OK
>>>>>>>>>> test VIDIOC_S_FMT: OK
>>>>>>>>>> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
>>>>>>>>>> test Cropping: OK (Not Supported)
>>>>>>>>>> test Composing: OK (Not Supported)
>>>>>>>>>> test Scaling: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Codec ioctls:
>>>>>>>>>> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_ENC_INDEX: OK (Not Supported)
>>>>>>>>>> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Buffer ioctls:
>>>>>>>>>> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
>>>>>>>>>> test CREATE_BUFS maximum buffers: OK
>>>>>>>>>> test VIDIOC_REMOVE_BUFS: OK
>>>>>>>>>> test VIDIOC_EXPBUF: OK
>>>>>>>>>> test Requests: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Total for neoisp device /dev/video2: 48, Succeeded: 48, Failed: 0,
>>>>>>>>>> Warnings: 0
>>>>>>>>>> --------------------------------------------------------------------------------
>>>>>>>>>> Compliance test for neoisp device /dev/video3:
>>>>>>>>>>
>>>>>>>>>> Driver Info:
>>>>>>>>>> Driver name : neoisp
>>>>>>>>>> Card type : neoisp
>>>>>>>>>> Bus info : platform:4ae00000.isp
>>>>>>>>>> Driver version : 6.19.0
>>>>>>>>>> Capabilities : 0x8ca03000
>>>>>>>>>> Video Capture Multiplanar
>>>>>>>>>> Video Output Multiplanar
>>>>>>>>>> Metadata Capture
>>>>>>>>>> Metadata Output
>>>>>>>>>> Streaming
>>>>>>>>>> Extended Pix Format
>>>>>>>>>> Device Capabilities
>>>>>>>>>> Device Caps : 0x04201000
>>>>>>>>>> Video Capture Multiplanar
>>>>>>>>>> Streaming
>>>>>>>>>> Extended Pix Format
>>>>>>>>>> Media Driver Info:
>>>>>>>>>> Driver name : neoisp
>>>>>>>>>> Model : neoisp
>>>>>>>>>> Serial :
>>>>>>>>>> Bus info : platform:4ae00000.isp
>>>>>>>>>> Media version : 6.19.0
>>>>>>>>>> Hardware revision: 0x00000002 (2)
>>>>>>>>>> Driver version : 6.19.0
>>>>>>>>>> Interface Info:
>>>>>>>>>> ID : 0x0300001c
>>>>>>>>>> Type : V4L Video
>>>>>>>>>> Entity Info:
>>>>>>>>>> ID : 0x0000001a (26)
>>>>>>>>>> Name : neoisp-frame
>>>>>>>>>> Function : V4L2 I/O
>>>>>>>>>> Pad 0x0100001b : 0: Sink
>>>>>>>>>> Link 0x0200001e: from remote pad 0x1000005 of entity
>>>>>>>>>> 'neoisp' (Image Signal Processor): Data, Enabled
>>>>>>>>>>
>>>>>>>>>> Required ioctls:
>>>>>>>>>> test MC information (see 'Media Driver Info' above): OK
>>>>>>>>>> test VIDIOC_QUERYCAP: OK
>>>>>>>>>> test invalid ioctls: OK
>>>>>>>>>>
>>>>>>>>>> Allow for multiple opens:
>>>>>>>>>> test second /dev/video3 open: OK
>>>>>>>>>> test VIDIOC_QUERYCAP: OK
>>>>>>>>>> test VIDIOC_G/S_PRIORITY: OK
>>>>>>>>>> test for unlimited opens: OK
>>>>>>>>>>
>>>>>>>>>> Debug ioctls:
>>>>>>>>>> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
>>>>>>>>>> test VIDIOC_LOG_STATUS: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Input ioctls:
>>>>>>>>>> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>>>>>>>>>> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUMAUDIO: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_AUDIO: OK (Not Supported)
>>>>>>>>>> Inputs: 0 Audio Inputs: 0 Tuners: 0
>>>>>>>>>>
>>>>>>>>>> Output ioctls:
>>>>>>>>>> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
>>>>>>>>>> Outputs: 0 Audio Outputs: 0 Modulators: 0
>>>>>>>>>>
>>>>>>>>>> Input/Output configuration ioctls:
>>>>>>>>>> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
>>>>>>>>>> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_EDID: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Control ioctls:
>>>>>>>>>> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
>>>>>>>>>> test VIDIOC_QUERYCTRL: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_CTRL: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
>>>>>>>>>> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
>>>>>>>>>> Standard Controls: 0 Private Controls: 0
>>>>>>>>>>
>>>>>>>>>> Format ioctls:
>>>>>>>>>> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
>>>>>>>>>> test VIDIOC_G/S_PARM: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_FBUF: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_FMT: OK
>>>>>>>>>> test VIDIOC_TRY_FMT: OK
>>>>>>>>>> test VIDIOC_S_FMT: OK
>>>>>>>>>> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
>>>>>>>>>> test Cropping: OK (Not Supported)
>>>>>>>>>> test Composing: OK (Not Supported)
>>>>>>>>>> test Scaling: OK
>>>>>>>>>>
>>>>>>>>>> Codec ioctls:
>>>>>>>>>> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_ENC_INDEX: OK (Not Supported)
>>>>>>>>>> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Buffer ioctls:
>>>>>>>>>> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
>>>>>>>>>> test CREATE_BUFS maximum buffers: OK
>>>>>>>>>> test VIDIOC_REMOVE_BUFS: OK
>>>>>>>>>> test VIDIOC_EXPBUF: OK
>>>>>>>>>> test Requests: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Total for neoisp device /dev/video3: 48, Succeeded: 48, Failed: 0,
>>>>>>>>>> Warnings: 0
>>>>>>>>>> --------------------------------------------------------------------------------
>>>>>>>>>> Compliance test for neoisp device /dev/video4:
>>>>>>>>>>
>>>>>>>>>> Driver Info:
>>>>>>>>>> Driver name : neoisp
>>>>>>>>>> Card type : neoisp
>>>>>>>>>> Bus info : platform:4ae00000.isp
>>>>>>>>>> Driver version : 6.19.0
>>>>>>>>>> Capabilities : 0x8ca03000
>>>>>>>>>> Video Capture Multiplanar
>>>>>>>>>> Video Output Multiplanar
>>>>>>>>>> Metadata Capture
>>>>>>>>>> Metadata Output
>>>>>>>>>> Streaming
>>>>>>>>>> Extended Pix Format
>>>>>>>>>> Device Capabilities
>>>>>>>>>> Device Caps : 0x04201000
>>>>>>>>>> Video Capture Multiplanar
>>>>>>>>>> Streaming
>>>>>>>>>> Extended Pix Format
>>>>>>>>>> Media Driver Info:
>>>>>>>>>> Driver name : neoisp
>>>>>>>>>> Model : neoisp
>>>>>>>>>> Serial :
>>>>>>>>>> Bus info : platform:4ae00000.isp
>>>>>>>>>> Media version : 6.19.0
>>>>>>>>>> Hardware revision: 0x00000002 (2)
>>>>>>>>>> Driver version : 6.19.0
>>>>>>>>>> Interface Info:
>>>>>>>>>> ID : 0x03000022
>>>>>>>>>> Type : V4L Video
>>>>>>>>>> Entity Info:
>>>>>>>>>> ID : 0x00000020 (32)
>>>>>>>>>> Name : neoisp-ir
>>>>>>>>>> Function : V4L2 I/O
>>>>>>>>>> Pad 0x01000021 : 0: Sink
>>>>>>>>>> Link 0x02000024: from remote pad 0x1000006 of entity
>>>>>>>>>> 'neoisp' (Image Signal Processor): Data
>>>>>>>>>>
>>>>>>>>>> Required ioctls:
>>>>>>>>>> test MC information (see 'Media Driver Info' above): OK
>>>>>>>>>> test VIDIOC_QUERYCAP: OK
>>>>>>>>>> test invalid ioctls: OK
>>>>>>>>>>
>>>>>>>>>> Allow for multiple opens:
>>>>>>>>>> test second /dev/video4 open: OK
>>>>>>>>>> test VIDIOC_QUERYCAP: OK
>>>>>>>>>> test VIDIOC_G/S_PRIORITY: OK
>>>>>>>>>> test for unlimited opens: OK
>>>>>>>>>>
>>>>>>>>>> Debug ioctls:
>>>>>>>>>> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
>>>>>>>>>> test VIDIOC_LOG_STATUS: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Input ioctls:
>>>>>>>>>> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>>>>>>>>>> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUMAUDIO: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_AUDIO: OK (Not Supported)
>>>>>>>>>> Inputs: 0 Audio Inputs: 0 Tuners: 0
>>>>>>>>>>
>>>>>>>>>> Output ioctls:
>>>>>>>>>> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
>>>>>>>>>> Outputs: 0 Audio Outputs: 0 Modulators: 0
>>>>>>>>>>
>>>>>>>>>> Input/Output configuration ioctls:
>>>>>>>>>> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
>>>>>>>>>> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_EDID: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Control ioctls:
>>>>>>>>>> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
>>>>>>>>>> test VIDIOC_QUERYCTRL: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_CTRL: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
>>>>>>>>>> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
>>>>>>>>>> Standard Controls: 0 Private Controls: 0
>>>>>>>>>>
>>>>>>>>>> Format ioctls:
>>>>>>>>>> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
>>>>>>>>>> test VIDIOC_G/S_PARM: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_FBUF: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_FMT: OK
>>>>>>>>>> test VIDIOC_TRY_FMT: OK
>>>>>>>>>> test VIDIOC_S_FMT: OK
>>>>>>>>>> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
>>>>>>>>>> test Cropping: OK (Not Supported)
>>>>>>>>>> test Composing: OK (Not Supported)
>>>>>>>>>> test Scaling: OK
>>>>>>>>>>
>>>>>>>>>> Codec ioctls:
>>>>>>>>>> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_ENC_INDEX: OK (Not Supported)
>>>>>>>>>> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Buffer ioctls:
>>>>>>>>>> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
>>>>>>>>>> test CREATE_BUFS maximum buffers: OK
>>>>>>>>>> test VIDIOC_REMOVE_BUFS: OK
>>>>>>>>>> test VIDIOC_EXPBUF: OK
>>>>>>>>>> test Requests: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Total for neoisp device /dev/video4: 48, Succeeded: 48, Failed: 0,
>>>>>>>>>> Warnings: 0
>>>>>>>>>> --------------------------------------------------------------------------------
>>>>>>>>>> Compliance test for neoisp device /dev/video5:
>>>>>>>>>>
>>>>>>>>>> Driver Info:
>>>>>>>>>> Driver name : neoisp
>>>>>>>>>> Card type : neoisp
>>>>>>>>>> Bus info : platform:4ae00000.isp
>>>>>>>>>> Driver version : 6.19.0
>>>>>>>>>> Capabilities : 0x8ca03000
>>>>>>>>>> Video Capture Multiplanar
>>>>>>>>>> Video Output Multiplanar
>>>>>>>>>> Metadata Capture
>>>>>>>>>> Metadata Output
>>>>>>>>>> Streaming
>>>>>>>>>> Extended Pix Format
>>>>>>>>>> Device Capabilities
>>>>>>>>>> Device Caps : 0x04a00000
>>>>>>>>>> Metadata Capture
>>>>>>>>>> Streaming
>>>>>>>>>> Extended Pix Format
>>>>>>>>>> Media Driver Info:
>>>>>>>>>> Driver name : neoisp
>>>>>>>>>> Model : neoisp
>>>>>>>>>> Serial :
>>>>>>>>>> Bus info : platform:4ae00000.isp
>>>>>>>>>> Media version : 6.19.0
>>>>>>>>>> Hardware revision: 0x00000002 (2)
>>>>>>>>>> Driver version : 6.19.0
>>>>>>>>>> Interface Info:
>>>>>>>>>> ID : 0x03000028
>>>>>>>>>> Type : V4L Video
>>>>>>>>>> Entity Info:
>>>>>>>>>> ID : 0x00000026 (38)
>>>>>>>>>> Name : neoisp-stats
>>>>>>>>>> Function : V4L2 I/O
>>>>>>>>>> Pad 0x01000027 : 0: Sink
>>>>>>>>>> Link 0x0200002a: from remote pad 0x1000007 of entity
>>>>>>>>>> 'neoisp' (Image Signal Processor): Data, Enabled
>>>>>>>>>>
>>>>>>>>>> Required ioctls:
>>>>>>>>>> test MC information (see 'Media Driver Info' above): OK
>>>>>>>>>> test VIDIOC_QUERYCAP: OK
>>>>>>>>>> test invalid ioctls: OK
>>>>>>>>>>
>>>>>>>>>> Allow for multiple opens:
>>>>>>>>>> test second /dev/video5 open: OK
>>>>>>>>>> test VIDIOC_QUERYCAP: OK
>>>>>>>>>> test VIDIOC_G/S_PRIORITY: OK
>>>>>>>>>> test for unlimited opens: OK
>>>>>>>>>>
>>>>>>>>>> Debug ioctls:
>>>>>>>>>> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
>>>>>>>>>> test VIDIOC_LOG_STATUS: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Input ioctls:
>>>>>>>>>> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>>>>>>>>>> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUMAUDIO: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_AUDIO: OK (Not Supported)
>>>>>>>>>> Inputs: 0 Audio Inputs: 0 Tuners: 0
>>>>>>>>>>
>>>>>>>>>> Output ioctls:
>>>>>>>>>> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
>>>>>>>>>> Outputs: 0 Audio Outputs: 0 Modulators: 0
>>>>>>>>>>
>>>>>>>>>> Input/Output configuration ioctls:
>>>>>>>>>> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
>>>>>>>>>> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_EDID: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Control ioctls:
>>>>>>>>>> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
>>>>>>>>>> test VIDIOC_QUERYCTRL: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_CTRL: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
>>>>>>>>>> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
>>>>>>>>>> Standard Controls: 0 Private Controls: 0
>>>>>>>>>>
>>>>>>>>>> Format ioctls:
>>>>>>>>>> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
>>>>>>>>>> test VIDIOC_G/S_PARM: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_FBUF: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_FMT: OK
>>>>>>>>>> test VIDIOC_TRY_FMT: OK
>>>>>>>>>> test VIDIOC_S_FMT: OK
>>>>>>>>>> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
>>>>>>>>>> test Cropping: OK (Not Supported)
>>>>>>>>>> test Composing: OK (Not Supported)
>>>>>>>>>> test Scaling: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Codec ioctls:
>>>>>>>>>> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_ENC_INDEX: OK (Not Supported)
>>>>>>>>>> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Buffer ioctls:
>>>>>>>>>> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
>>>>>>>>>> test CREATE_BUFS maximum buffers: OK
>>>>>>>>>> test VIDIOC_REMOVE_BUFS: OK
>>>>>>>>>> test VIDIOC_EXPBUF: OK
>>>>>>>>>> test Requests: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Total for neoisp device /dev/video5: 48, Succeeded: 48, Failed: 0,
>>>>>>>>>> Warnings: 0
>>>>>>>>>> --------------------------------------------------------------------------------
>>>>>>>>>> Compliance test for neoisp device /dev/v4l-subdev0:
>>>>>>>>>>
>>>>>>>>>> Driver Info:
>>>>>>>>>> Driver version : 6.19.0
>>>>>>>>>> Capabilities : 0x00000000
>>>>>>>>>> Client Capabilities: 0x0000000000000002
>>>>>>>>>> interval-uses-which Media Driver Info:
>>>>>>>>>> Driver name : neoisp
>>>>>>>>>> Model : neoisp
>>>>>>>>>> Serial :
>>>>>>>>>> Bus info : platform:4ae00000.isp
>>>>>>>>>> Media version : 6.19.0
>>>>>>>>>> Hardware revision: 0x00000002 (2)
>>>>>>>>>> Driver version : 6.19.0
>>>>>>>>>> Interface Info:
>>>>>>>>>> ID : 0x0300002c
>>>>>>>>>> Type : V4L Sub-Device
>>>>>>>>>> Entity Info:
>>>>>>>>>> ID : 0x00000001 (1)
>>>>>>>>>> Name : neoisp
>>>>>>>>>> Function : Image Signal Processor
>>>>>>>>>> Pad 0x01000002 : 0: Sink
>>>>>>>>>> Link 0x0200000c: from remote pad 0x1000009 of entity
>>>>>>>>>> 'neoisp-input0' (V4L2 I/O): Data, Enabled, Immutable
>>>>>>>>>> Pad 0x01000003 : 1: Sink
>>>>>>>>>> Link 0x02000012: from remote pad 0x100000f of entity
>>>>>>>>>> 'neoisp-input1' (V4L2 I/O): Data
>>>>>>>>>> Pad 0x01000004 : 2: Sink
>>>>>>>>>> Link 0x02000018: from remote pad 0x1000015 of entity
>>>>>>>>>> 'neoisp-params' (V4L2 I/O): Data, Enabled
>>>>>>>>>> Pad 0x01000005 : 3: Source
>>>>>>>>>> Link 0x0200001e: to remote pad 0x100001b of entity 'neoisp-
>>>>>>>>>> frame' (V4L2 I/O): Data, Enabled
>>>>>>>>>> Pad 0x01000006 : 4: Source
>>>>>>>>>> Link 0x02000024: to remote pad 0x1000021 of entity 'neoisp-
>>>>>>>>>> ir' (V4L2 I/O): Data
>>>>>>>>>> Pad 0x01000007 : 5: Source
>>>>>>>>>> Link 0x0200002a: to remote pad 0x1000027 of entity 'neoisp-
>>>>>>>>>> stats' (V4L2 I/O): Data, Enabled
>>>>>>>>>>
>>>>>>>>>> Required ioctls:
>>>>>>>>>> test MC information (see 'Media Driver Info' above): OK
>>>>>>>>>> test VIDIOC_SUDBEV_QUERYCAP: OK
>>>>>>>>>> test invalid ioctls: OK
>>>>>>>>>>
>>>>>>>>>> Allow for multiple opens:
>>>>>>>>>> test second /dev/v4l-subdev0 open: OK
>>>>>>>>>> test VIDIOC_SUBDEV_QUERYCAP: OK
>>>>>>>>>> test for unlimited opens: OK
>>>>>>>>>>
>>>>>>>>>> Debug ioctls:
>>>>>>>>>> test VIDIOC_LOG_STATUS: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Input ioctls:
>>>>>>>>>> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>>>>>>>>>> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUMAUDIO: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_AUDIO: OK (Not Supported)
>>>>>>>>>> Inputs: 0 Audio Inputs: 0 Tuners: 0
>>>>>>>>>>
>>>>>>>>>> Output ioctls:
>>>>>>>>>> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
>>>>>>>>>> Outputs: 0 Audio Outputs: 0 Modulators: 0
>>>>>>>>>>
>>>>>>>>>> Input/Output configuration ioctls:
>>>>>>>>>> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
>>>>>>>>>> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
>>>>>>>>>> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G/S_EDID: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Sub-Device ioctls (Sink Pad 0):
>>>>>>>>>> Try Stream 0
>>>>>>>>>> test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/
>>>>>>>>>> FRAME_INTERVAL: OK (Not Supported)
>>>>>>>>>> test Try VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
>>>>>>>>>> test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
>>>>>>>>>> Active Stream 0
>>>>>>>>>> test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/
>>>>>>>>>> FRAME_INTERVAL: OK (Not Supported)
>>>>>>>>>> test Active VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
>>>>>>>>>> test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
>>>>>>>>>> test Active VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Sub-Device ioctls (Sink Pad 1):
>>>>>>>>>> Try Stream 0
>>>>>>>>>> test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/
>>>>>>>>>> FRAME_INTERVAL: OK (Not Supported)
>>>>>>>>>> test Try VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
>>>>>>>>>> test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
>>>>>>>>>> Active Stream 0
>>>>>>>>>> test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/
>>>>>>>>>> FRAME_INTERVAL: OK (Not Supported)
>>>>>>>>>> test Active VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
>>>>>>>>>> test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
>>>>>>>>>> test Active VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Sub-Device ioctls (Sink Pad 2):
>>>>>>>>>> Try Stream 0
>>>>>>>>>> test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/
>>>>>>>>>> FRAME_INTERVAL: OK (Not Supported)
>>>>>>>>>> test Try VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
>>>>>>>>>> test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
>>>>>>>>>> Active Stream 0
>>>>>>>>>> test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/
>>>>>>>>>> FRAME_INTERVAL: OK (Not Supported)
>>>>>>>>>> test Active VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
>>>>>>>>>> test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
>>>>>>>>>> test Active VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Sub-Device ioctls (Source Pad 3):
>>>>>>>>>> Try Stream 0
>>>>>>>>>> test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/
>>>>>>>>>> FRAME_INTERVAL: OK (Not Supported)
>>>>>>>>>> test Try VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
>>>>>>>>>> test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
>>>>>>>>>> Active Stream 0
>>>>>>>>>> test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/
>>>>>>>>>> FRAME_INTERVAL: OK (Not Supported)
>>>>>>>>>> test Active VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
>>>>>>>>>> test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
>>>>>>>>>> test Active VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Sub-Device ioctls (Source Pad 4):
>>>>>>>>>> Try Stream 0
>>>>>>>>>> test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/
>>>>>>>>>> FRAME_INTERVAL: OK (Not Supported)
>>>>>>>>>> test Try VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
>>>>>>>>>> test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
>>>>>>>>>> Active Stream 0
>>>>>>>>>> test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/
>>>>>>>>>> FRAME_INTERVAL: OK (Not Supported)
>>>>>>>>>> test Active VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
>>>>>>>>>> test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
>>>>>>>>>> test Active VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Sub-Device ioctls (Source Pad 5):
>>>>>>>>>> Try Stream 0
>>>>>>>>>> test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/
>>>>>>>>>> FRAME_INTERVAL: OK (Not Supported)
>>>>>>>>>> test Try VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
>>>>>>>>>> test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
>>>>>>>>>> Active Stream 0
>>>>>>>>>> test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/
>>>>>>>>>> FRAME_INTERVAL: OK (Not Supported)
>>>>>>>>>> test Active VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
>>>>>>>>>> test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
>>>>>>>>>> test Active VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Control ioctls:
>>>>>>>>>> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
>>>>>>>>>> test VIDIOC_QUERYCTRL: OK
>>>>>>>>>> test VIDIOC_G/S_CTRL: OK
>>>>>>>>>> test VIDIOC_G/S/TRY_EXT_CTRLS: OK
>>>>>>>>>> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
>>>>>>>>>> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
>>>>>>>>>> Standard Controls: 1 Private Controls: 1
>>>>>>>>>>
>>>>>>>>>> Format ioctls:
>>>>>>>>>> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK (Not
>>>>>>>>>> Supported)
>>>>>>>>>> test VIDIOC_G/S_PARM: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_FBUF: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_FMT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_TRY_FMT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_S_FMT: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
>>>>>>>>>> test Cropping: OK (Not Supported)
>>>>>>>>>> test Composing: OK (Not Supported)
>>>>>>>>>> test Scaling: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Codec ioctls:
>>>>>>>>>> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
>>>>>>>>>> test VIDIOC_G_ENC_INDEX: OK (Not Supported)
>>>>>>>>>> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Buffer ioctls:
>>>>>>>>>> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK (Not Supported)
>>>>>>>>>> test CREATE_BUFS maximum buffers: OK
>>>>>>>>>> test VIDIOC_REMOVE_BUFS: OK
>>>>>>>>>> test VIDIOC_EXPBUF: OK (Not Supported)
>>>>>>>>>> test Requests: OK (Not Supported)
>>>>>>>>>>
>>>>>>>>>> Total for neoisp device /dev/v4l-subdev0: 88, Succeeded: 88, Failed:
>>>>>>>>>> 0, Warnings: 0
>>>>>>>>>>
>>>>>>>>>> Grand Total for neoisp device /dev/media0: 384, Succeeded: 384,
>>>>>>>>>> Failed: 0, Warnings: 0
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>> Antoine Bouyer (11):
>>>>>>>>>> media: uapi: v4l2-isp: Add v4l2 ISP extensible statistics definitions
>>>>>>>>>> media: v4l2-isp: Add helper function to compute extended stats size
>>>>>>>>>> media: Documentation: uapi: Update V4L2 ISP for extensible stats
>>>>>>>>>> media: Documentation: Add NXP neoisp driver documentation
>>>>>>>>>> dt-bindings: media: Add nxp neoisp support
>>>>>>>>>> media: v4l2-ctrls: Add user control base for NXP neoisp controls
>>>>>>>>>> media: Add meta formats supported by NXP neoisp driver
>>>>>>>>>> media: uapi: Add NXP NEOISP user interface header file
>>>>>>>>>> media: platform: Add NXP Neoisp Image Signal Processor
>>>>>>>>>> media: platform: neoisp: Add debugfs support
>>>>>>>>>> arm64: dts: freescale: imx95: Add NXP neoisp device tree node
>>>>>>>>>>
>>>>>>>>>> .../admin-guide/media/nxp-neoisp-diagram.dot | 22 +
>>>>>>>>>> .../admin-guide/media/nxp-neoisp.dot | 16 +
>>>>>>>>>> .../admin-guide/media/nxp-neoisp.rst | 189 ++
>>>>>>>>>> .../admin-guide/media/v4l-drivers.rst | 1 +
>>>>>>>>>> .../devicetree/bindings/media/nxp,neoisp.yaml | 65 +
>>>>>>>>>> .../userspace-api/media/v4l/meta-formats.rst | 1 +
>>>>>>>>>> .../media/v4l/metafmt-nxp-neoisp.rst | 114 +
>>>>>>>>>> .../userspace-api/media/v4l/v4l2-isp.rst | 42 +-
>>>>>>>>>> MAINTAINERS | 9 +
>>>>>>>>>> .../boot/dts/freescale/imx95-19x19-evk.dts | 4 +
>>>>>>>>>> arch/arm64/boot/dts/freescale/imx95.dtsi | 11 +
>>>>>>>>>> drivers/media/platform/nxp/Kconfig | 1 +
>>>>>>>>>> drivers/media/platform/nxp/Makefile | 1 +
>>>>>>>>>> drivers/media/platform/nxp/neoisp/Kconfig | 15 +
>>>>>>>>>> drivers/media/platform/nxp/neoisp/Makefile | 8 +
>>>>>>>>>> drivers/media/platform/nxp/neoisp/neoisp.h | 270 ++
>>>>>>>>>> .../media/platform/nxp/neoisp/neoisp_ctx.c | 2798 +++++++++++++++++
>>>>>>>>>> .../media/platform/nxp/neoisp/neoisp_ctx.h | 85 +
>>>>>>>>>> .../platform/nxp/neoisp/neoisp_debugfs.c | 503 +++
>>>>>>>>>> .../media/platform/nxp/neoisp/neoisp_fmt.h | 509 +++
>>>>>>>>>> drivers/media/platform/nxp/neoisp/neoisp_hw.h | 577 ++++
>>>>>>>>>> .../media/platform/nxp/neoisp/neoisp_main.c | 1999 ++++++++++++
>>>>>>>>>> .../media/platform/nxp/neoisp/neoisp_nodes.h | 60 +
>>>>>>>>>> .../media/platform/nxp/neoisp/neoisp_regs.h | 2501 +++++++++++++++
>>>>>>>>>> drivers/media/v4l2-core/v4l2-ioctl.c | 4 +
>>>>>>>>>> include/media/v4l2-isp.h | 13 +
>>>>>>>>>> include/uapi/linux/media/nxp/nxp_neoisp.h | 1968 ++++++++++++
>>>>>>>>>> include/uapi/linux/media/v4l2-isp.h | 85 +
>>>>>>>>>> include/uapi/linux/v4l2-controls.h | 6 +
>>>>>>>>>> include/uapi/linux/videodev2.h | 6 +
>>>>>>>>>> 30 files changed, 11880 insertions(+), 3 deletions(-)
>>>>>>>>>> create mode 100644 Documentation/admin-guide/media/nxp-neoisp-
>>>>>>>>>> diagram.dot
>>>>>>>>>> create mode 100644 Documentation/admin-guide/media/nxp-neoisp.dot
>>>>>>>>>> create mode 100644 Documentation/admin-guide/media/nxp-neoisp.rst
>>>>>>>>>> create mode 100644 Documentation/devicetree/bindings/media/
>>>>>>>>>> nxp,neoisp.yaml
>>>>>>>>>> create mode 100644 Documentation/userspace-api/media/v4l/metafmt-
>>>>>>>>>> nxp-neoisp.rst
>>>>>>>>>> create mode 100644 drivers/media/platform/nxp/neoisp/Kconfig
>>>>>>>>>> create mode 100644 drivers/media/platform/nxp/neoisp/Makefile
>>>>>>>>>> create mode 100644 drivers/media/platform/nxp/neoisp/neoisp.h
>>>>>>>>>> create mode 100644 drivers/media/platform/nxp/neoisp/neoisp_ctx.c
>>>>>>>>>> create mode 100644 drivers/media/platform/nxp/neoisp/neoisp_ctx.h
>>>>>>>>>> create mode 100644 drivers/media/platform/nxp/neoisp/neoisp_debugfs.c
>>>>>>>>>> create mode 100644 drivers/media/platform/nxp/neoisp/neoisp_fmt.h
>>>>>>>>>> create mode 100644 drivers/media/platform/nxp/neoisp/neoisp_hw.h
>>>>>>>>>> create mode 100644 drivers/media/platform/nxp/neoisp/neoisp_main.c
>>>>>>>>>> create mode 100644 drivers/media/platform/nxp/neoisp/neoisp_nodes.h
>>>>>>>>>> create mode 100644 drivers/media/platform/nxp/neoisp/neoisp_regs.h
>>>>>>>>>> create mode 100644 include/uapi/linux/media/nxp/nxp_neoisp.h
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
^ permalink raw reply
* Re: [PATCH net-next 2/2] dt-bindings: remove unimplemented AXI snps,kbbe snps,mb and snps,rb
From: Conor Dooley @ 2026-03-24 17:43 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, Conor Dooley,
David S. Miller, devicetree, Eric Dumazet, Giuseppe Cavallaro,
Jakub Kicinski, Jose Abreu, Krzysztof Kozlowski, linux-arm-kernel,
linux-stm32, netdev, Paolo Abeni, Rob Herring, Yao Zi
In-Reply-To: <E1w4ydt-0000000Dlph-3WvI@rmk-PC.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 569 bytes --]
On Tue, Mar 24, 2026 at 10:05:45AM +0000, Russell King (Oracle) wrote:
> Remove the AXI snps,kbbe snps,mb and snps,rb properties as they have
> not been used, and although the driver parses these, the code hasn't
> ever used the parsed result. This parsing has now been removed.
>
> These were introduced by commit afea03656add ("stmmac: rework DMA bus
> setting and introduce new platform AXI structure").
>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 05/10] am68k/PCI: Remove unnecessary second application of align
From: John Paul Adrian Glaubitz @ 2026-03-24 17:43 UTC (permalink / raw)
To: Ilpo Järvinen, linux-pci, Bjorn Helgaas, Guenter Roeck,
linux-alpha, linux-arm-kernel, linux-m68k, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, Russell King,
Geert Uytterhoeven, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Chris Zankel,
Max Filippov, Madhavan Srinivasan, Yoshinori Sato, Rich Felker,
linux-kernel
In-Reply-To: <20260324165633.4583-6-ilpo.jarvinen@linux.intel.com>
Hi Ilpo,
On Tue, 2026-03-24 at 18:56 +0200, Ilpo Järvinen wrote:
> Aligning res->start by align inside pcibios_align_resource() is
> unnecessary because caller of pcibios_align_resource() is
> __find_resource_space() that aligns res->start with align before
> calling pcibios_align_resource().
>
> Aligning by align in case of IORESOURCE_IO && start & 0x300 cannot ever
> result in changing start either because 0x300 bits would have not
> survived the earlier alignment if align was large enough to have an
> impact.
>
> Thus, remove the duplicated aligning from pcibios_align_resource().
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> ---
> arch/m68k/kernel/pcibios.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/m68k/kernel/pcibios.c b/arch/m68k/kernel/pcibios.c
> index 1415f6e4e5ce..7e286ee1976b 100644
> --- a/arch/m68k/kernel/pcibios.c
> +++ b/arch/m68k/kernel/pcibios.c
> @@ -36,8 +36,6 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
> if ((res->flags & IORESOURCE_IO) && (start & 0x300))
> start = (start + 0x3ff) & ~0x3ff;
>
> - start = (start + align - 1) & ~(align - 1);
> -
> return start;
> }
>
Sorry if it's a stupid question, but what does "am68k" in the subject refer to?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* Re: [PATCH v5 4/5] KVM: selftests: arm64: Skip all 32 bit IDs when set_id_regs is aarch64 only
From: Mark Brown @ 2026-03-24 17:39 UTC (permalink / raw)
To: Marc Zyngier
Cc: Joey Gouly, Suzuki K Poulose, Paolo Bonzini, Shuah Khan,
Oliver Upton, Ben Horgan, linux-arm-kernel, kvmarm, kvm,
linux-kselftest, linux-kernel
In-Reply-To: <86pl4t41kc.wl-maz@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]
On Tue, Mar 24, 2026 at 04:47:15PM +0000, Marc Zyngier wrote:
> Mark Brown <broonie@kernel.org> wrote:
> > On an aarch64 only system the 32 bit ID registers have UNDEFINED values.
> > As a result set_id_regs skips tests for setting fields in these registers
> > when testing an aarch64 only guest. This has the side effect of meaning
> > that we don't record an expected value for these registers, meaning that
> > when the subsequent tests for values being visible in guests and preserved
> > over reset check the value they can spuriously fail. This can be seen by
> > running on an emulated system with both NV and 32 bit enabled, NV will
> > result in the guests created by the test program being 64 bit only but
> > the 32 bit ID registers will have values.
> I don't think papering over this problem is the right thing to do.
> If the issue is that you have HW that has both NV and AArch32, then
> KVM needs to be fixed to make the 32bit IDregs RAZ when NV is present
> because that's not a configuration we support.
Yes, I'm seeing this in practice - it hits by default with qemu which is
rather more readily accessible than actual hardware with NV at this
point and I was concerned that since these registers are explicitly
UNKNOWN (sorry, a mistake in the commit log above there) rather than RAZ
if FEAT_AA32 is not implemented there might be gotchas. I do see that
there's some forcing for the case where the host doesn't support
FEAT_AA32, I figured there must be some reason why it wasn't done based
on the guest configuration.
I'll add something to kvm_finalize_sys_regs(), it'll still need updates
in set_id_regs since that'd make the 32 bit ID registers change value
when the guest is run.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mp: Add DT overlays for DH i.MX8M Plus DHCOM SoM and boards
From: Marek Vasut @ 2026-03-24 17:39 UTC (permalink / raw)
To: Frank Li
Cc: linux-arm-kernel, Christoph Niedermaier, Conor Dooley,
Fabio Estevam, Krzysztof Kozlowski, Pengutronix Kernel Team,
Rob Herring, Sascha Hauer, devicetree, imx, kernel, linux-kernel
In-Reply-To: <acK1YU6M5FGK3qM2@lizhi-Precision-Tower-5810>
On 3/24/26 5:01 PM, Frank Li wrote:
> On Fri, Mar 13, 2026 at 12:24:04AM +0100, Marek Vasut wrote:
> ...
>
>> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-ch101olhlwh.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-ch101olhlwh.dtsi
>> new file mode 100644
>> index 0000000000000..534737363c9f0
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-ch101olhlwh.dtsi
>> @@ -0,0 +1,42 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Copyright (C) 2022 Marek Vasut
>
> 2026?
That was the original copyright year when this was implemented, but I
can update it to 2022-2026 ?
>> + */
>> +
>> +&display_bl {
>> + pwms = <&pwm1 0 5000000 0>;
>> +};
>> +
>> +&DH_OVERLAY_PANEL_I2C_BUS {
>
> why upcase for label, generally it should be lower case
Because this label is really a macro , please read on.
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + touchscreen@41 {
>> + compatible = "ilitek,ili251x";
>> + pinctrl-0 = <DH_OVERLAY_PANEL_I2C_TOUCHSCREEN_PINCTRL>;
>> + pinctrl-names = "default";
>> + reg = <0x41>;
>
> reg should second property, please dt-format for new dts files.
> check others
What is "dt-format" ? Linux kernel source tree, even current next, does
not mention such a tool . I did run schema check and checkpatch on these
patches. obv.
>> + interrupt-parent = <&DH_OVERLAY_PANEL_I2C_TOUCHSCREEN_IRQ_PARENT>;
> ...
>> +
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@1 {
>> + reg = <1>;
>
> need empty line between child node and property.
Fixed in V2
>> + #size-cells = <0>;
>> +
>> + eeprom@56 {
>> + compatible = "atmel,24c04";
>> + reg = <0x56>;
>> + pagesize = <16>;
>> + };
>> +};
>> +
>> +&ecspi2 {
>> + status = "okay";
>
> status should be last property. I stop here because these
> should be identify by tools/script
Neither checkpatch nor schema validation complained about these.
I moved the status=okay to the end. Anything else I should update ?
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mp-debix-model-a: Correct PAD settings for pmicirqgrp
From: Kieran Bingham @ 2026-03-24 17:38 UTC (permalink / raw)
To: Peng Fan (OSS), Laurent Pinchart
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Marco Felsch, Daniel Scally, devicetree, imx, linux-arm-kernel,
linux-kernel, Peng Fan, Stefan Klug
In-Reply-To: <20260324093850.GA2351719@killaraus.ideasonboard.com>
Quoting Laurent Pinchart (2026-03-24 09:38:50)
> Hi Peng,
>
> Thank you for the patch.
>
> On Tue, Mar 24, 2026 at 11:16:13AM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > With commit 5d0efaf47ee90 ("regulator: pca9450: Correct interrupt type"),
> > there is interrupt storm for i.MX8MP DEBIX Model A. Per schematic, there
> > is no on board PULL-UP resistors for GPIO1_IO03, so need to set PAD
> > PUE and PU together to make pull up work properly.
> >
> > Fixes: c86d350aae68e ("arm64: dts: Add device tree for the Debix Model A Board")
> > Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Closes: https://lore.kernel.org/all/20260323105858.GA2185714@killaraus.ideasonboard.com/
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> Frank, would you be able to handle this as a v7.0 regression fix ?
>
> I think the same is needed for imx8mp-debix-som-a.dtsi, but I can't
> confirm it as I don't have the schematics for the SoM, neither do I have
> access to the board.
>
> Dan, Kieran, Stefan, could one of you check if you get an interrupt
> storm from the PMIC on v7.0 ?
Confirmed:
35: 83626 0 0 0 gpio-mxc 3 Level pca9450-irq
and
200: 270180 0 0 0 GICv3 67 Level 30a20000.i2c
...
200: 400925 0 0 0 GICv3 67 Level 30a20000.i2c
...
increasing rapidly on the debix-som.
I started out on the linux-media branches which were 7.0-rc2 based, and
this didn't happen but cherry-picking in 5d0efaf47ee90 certainly causes
this issue to occur on my board.
--
Kieran
>
> > ---
> > arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts b/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts
> > index 9422beee30b29c5a551b08476c80fbff96af3439..df7489587e48ed0c678f11291f6f2b77082ade95 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx8mp-debix-model-a.dts
> > @@ -440,7 +440,7 @@ MX8MP_IOMUXC_SAI5_RXC__I2C6_SDA 0x400001c3
> >
> > pinctrl_pmic: pmicirqgrp {
> > fsl,pins = <
> > - MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x41
> > + MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x000001c0
> > >;
> > };
> >
> >
> > ---
> > base-commit: 09c0f7f1bcdbc3c37a5a760cbec76bf18f278406
> > change-id: 20260324-imx8mp-dts-fix-512530fe4dcd
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 01/10] ACPI: APEI: GHES: share macros via a private header
From: Jonathan Cameron @ 2026-03-24 17:28 UTC (permalink / raw)
To: Ahmed Tiba
Cc: linux-acpi, devicetree, linux-cxl, Michael.Zhao2, robh,
linux-arm-kernel, Dmitry.Lamerov, rafael, conor, will, bp,
catalin.marinas, krzk+dt, linux-doc, mchehab+huawei, tony.luck
In-Reply-To: <20260318-topics-ahmtib01-ras_ffh_arm_internal_review-v3-1-48e6a1c249ef@arm.com>
On Wed, 18 Mar 2026 20:47:58 +0000
Ahmed Tiba <ahmed.tiba@arm.com> wrote:
> Carve the CPER helper macros out of ghes.c and place them in a private
> header so they can be shared with upcoming helper files. This is a
> mechanical include change with no functional differences.
>
> Signed-off-by: Ahmed Tiba <ahmed.tiba@arm.com>
> diff --git a/include/acpi/ghes_cper.h b/include/acpi/ghes_cper.h
> new file mode 100644
> index 000000000000..a38e3440b927
> --- /dev/null
> +++ b/include/acpi/ghes_cper.h
> @@ -0,0 +1,103 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Shared GHES declarations for firmware-first CPER error handling.
> + *
> + * This header groups the GHES declarations that are needed by the shared
> + * CPER handling path.
shared CPER is unclear. Start with something broad like:
GHES declarations are used both for ACPI APEI handling and xyz.
I'm not sure I'd put any additional justification here beyond such a
simple sentence.
> + *
> + * The split lets GHES and other firmware-first error sources use the same
I would consider rewriting this. What split? Not obvious from what you have
in this header.
> + * code for reading status blocks, caching records, handling vendor data,
> + * and reporting errors, so the non-ACPI path follows the same behavior as
> + * GHES instead of carrying a separate copy.
> + *
> + * Derived from the ACPI APEI GHES driver.
> + *
> + * Copyright 2010,2011 Intel Corp.
> + * Author: Huang Ying <ying.huang@intel.com>
> + */
> +
^ permalink raw reply
* [PATCH] KVM: arm64: pkvm: Rollback refcount on hyp share/unshare error
From: Vincent Donnefort @ 2026-03-24 17:27 UTC (permalink / raw)
To: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
Cc: qperret, linux-arm-kernel, kvmarm, kernel-team, Vincent Donnefort
If one of the HVC __pkvm_host_share_hyp or __pkvm_host_unshare_hyp fails,
rollback the refcount to ensure the hyp_shared_pfns tracking reflects
the actual sharing status.
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 17d64a1e11e5..0fb41d2c8b44 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -493,11 +493,17 @@ static int share_pfn_hyp(u64 pfn)
goto unlock;
}
+ ret = kvm_call_hyp_nvhe(__pkvm_host_share_hyp, pfn);
+ if (ret) {
+ kfree(this);
+ goto unlock;
+ }
+
this->pfn = pfn;
this->count = 1;
rb_link_node(&this->node, parent, node);
rb_insert_color(&this->node, &hyp_shared_pfns);
- ret = kvm_call_hyp_nvhe(__pkvm_host_share_hyp, pfn);
+
unlock:
mutex_unlock(&hyp_shared_pfns_lock);
@@ -521,9 +527,15 @@ static int unshare_pfn_hyp(u64 pfn)
if (this->count)
goto unlock;
+ ret = kvm_call_hyp_nvhe(__pkvm_host_unshare_hyp, pfn);
+ if (ret) {
+ this->count++;
+ goto unlock;
+ }
+
rb_erase(&this->node, &hyp_shared_pfns);
kfree(this);
- ret = kvm_call_hyp_nvhe(__pkvm_host_unshare_hyp, pfn);
+
unlock:
mutex_unlock(&hyp_shared_pfns_lock);
base-commit: c369299895a591d96745d6492d4888259b004a9e
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* Re: [PATCH v5] arm64: dts: rockchip: rock-3b: Model PI6C20100 as gated-fixed-clock
From: Jonas Karlman @ 2026-03-24 17:15 UTC (permalink / raw)
To: Heiko Stuebner, MidG971
Cc: linux-rockchip, shawn.lin, jonas, linux-arm-kernel, devicetree
In-Reply-To: <177437177535.786081.7519498810130807269.b4-ty@sntech.de>
Hi Heiko,
On 3/24/2026 6:04 PM, Heiko Stuebner wrote:
>
> On Fri, 20 Mar 2026 10:44:41 +0100, MidG971 wrote:
>> The Radxa ROCK 3B uses a PI6C20100 PCIe reference clock buffer to
>> provide a 100MHz reference clock to the PCIe 3.0 PHY and controllers.
>> This chip is currently modeled only as a fixed regulator
>> (vcc3v3_pi6c_03), with no clock output representation.
>>
>> The PI6C20100 is a clock generator, not a power supply. Model it
>> properly as a gated-fixed-clock, following the pattern established
>> for the Rock 5 ITX and other boards with similar PCIe clock buffer
>> chips.
>>
>> [...]
>
> Applied, thanks!
My comments from v3 [1] was not addressed in v4 och v5. E.g.
regulator-always-on/boot-on not being removed and redundant comments.
[1] https://lore.kernel.org/all/fec0f25d-733a-4b6c-aef1-2ac51bd15798@kwiboo.se/
Regards,
Jonas
>
> [1/1] arm64: dts: rockchip: rock-3b: Model PI6C20100 as gated-fixed-clock
> commit: b61f3c69c87b5f061194f413d810723698534b02
>
> As I somehow expected, that AI messed up ;-) .
>
> In the 2nd part of the patch the reported number of lines
> in the header (the 15 there) does not match the number of lines
> in the diff itself (14). I've fixed that up to not have another
> round.
>
> Best regards,
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: dts: imx8mm: Explicitly set DSI_PHY_REF clock as a child of CLK_24M
From: Frank Li @ 2026-03-24 17:09 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Alexander Stein
Cc: Frank Li, linux, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260313071027.587992-1-alexander.stein@ew.tq-group.com>
On Fri, 13 Mar 2026 08:10:23 +0100, Alexander Stein wrote:
> Since commits a0deedcc0cf0 ("arm64: dts: imx8mm: Slow default video_pll1
> clock rate") and 5fe6ec93f10b0 ("clk: imx8mm: Let IMX8MM_CLK_LCDIF_PIXEL
> set parent rate") VIDEO_PLL1 is dynamically programmed by CLK_LCDIF_PIXEL.
> On imx8mm-tqma8mqml-mba8mx-lvds-tm070jvhg33.dtso this results in a
> VIDEO_PLL1 frequency of 68.2 MHz and DSI_PHY_REF of 17.05MHz (1/4).
> Instead use the 24 MHz clock as parent for DSI PHY reference clock.
>
> [...]
Applied, thanks!
[1/3] arm64: dts: imx8mm: Explicitly set DSI_PHY_REF clock as a child of CLK_24M
commit: 5cb939a70e052948ffb05f1c02e7c83dea5b2426
Fix checkpatch error. since commits ... -> since commit ...
[2/3] arm64: dts: imx8mm-tqma8mqml-mba8mx: LVDS overlay: Reduce DSI burst clock to 600Mhz
commit: 3a96ba67dfd4d88a342c61b229e139598a20734a
[3/3] arm64: dts: imx8mn-tqma8mqnl-mba8mx: LVDS overlay: LVDS overlay: Reduce DSI burst clock to 600Mhz
(no commit info)
Remove duplicate "LVDS overlay",
Add empty line between paragraph
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH 05/10] am68k/PCI: Remove unnecessary second application of align
From: Geert Uytterhoeven @ 2026-03-24 17:06 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: linux-pci, Bjorn Helgaas, Guenter Roeck, linux-alpha,
linux-arm-kernel, linux-m68k, linux-mips, linux-parisc,
linuxppc-dev, linux-s390, linux-sh, Russell King,
Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
Michael Ellerman, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Chris Zankel, Max Filippov,
Madhavan Srinivasan, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz, linux-kernel, Greg Ungerer
In-Reply-To: <20260324165633.4583-6-ilpo.jarvinen@linux.intel.com>
CC gerg
On Tue, 24 Mar 2026 at 17:59, Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
>
> Aligning res->start by align inside pcibios_align_resource() is
> unnecessary because caller of pcibios_align_resource() is
> __find_resource_space() that aligns res->start with align before
> calling pcibios_align_resource().
>
> Aligning by align in case of IORESOURCE_IO && start & 0x300 cannot ever
> result in changing start either because 0x300 bits would have not
> survived the earlier alignment if align was large enough to have an
> impact.
>
> Thus, remove the duplicated aligning from pcibios_align_resource().
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> ---
> arch/m68k/kernel/pcibios.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/m68k/kernel/pcibios.c b/arch/m68k/kernel/pcibios.c
> index 1415f6e4e5ce..7e286ee1976b 100644
> --- a/arch/m68k/kernel/pcibios.c
> +++ b/arch/m68k/kernel/pcibios.c
> @@ -36,8 +36,6 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
> if ((res->flags & IORESOURCE_IO) && (start & 0x300))
> start = (start + 0x3ff) & ~0x3ff;
>
> - start = (start + align - 1) & ~(align - 1);
> -
> return start;
> }
>
> --
> 2.39.5
^ permalink raw reply
* Re: [PATCH v7 1/4] dt-bindings: soc: rockchip: grf: Add RV1103B compatibles
From: Fabio Estevam @ 2026-03-24 17:05 UTC (permalink / raw)
To: Heiko Stuebner
Cc: robh, krzk+dt, conor+dt, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, shawn.lin, Fabio Estevam,
Krzysztof Kozlowski
In-Reply-To: <177437057319.780275.6126712599317976655.b4-ty@sntech.de>
Hi Heiko,
On Tue, Mar 24, 2026 at 1:45 PM Heiko Stuebner <heiko@sntech.de> wrote:
> And dropped the watchdog node for now.
>
> Please resubmit that one, once the watchdog compatible went
> into the watchdog tree (and drop the status=disabled from
> the wdt node, as the watchdog is not dependent on supplies
> from the board dts)
I'll do it as suggested, thanks!
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: Fix RK3562 EVB2 model name
From: Heiko Stuebner @ 2026-03-24 17:04 UTC (permalink / raw)
To: linux-rockchip, 谢致邦 (XIE Zhibang)
Cc: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Finley Xiao, Kever Yang, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <tencent_78E7E3F6991FB4403D5ADC9E6A6BC3BF8307@qq.com>
On Thu, 19 Mar 2026 13:55:00 +0000, 谢致邦 (XIE Zhibang) wrote:
> The model name should be "Rockchip RK3562 EVB2 V10 Board".
>
>
Applied, thanks!
[1/1] arm64: dts: rockchip: Fix RK3562 EVB2 model name
commit: ede6a05606892bab4f6d785ffcfc124150c2eb32
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH v5] arm64: dts: rockchip: rock-3b: Model PI6C20100 as gated-fixed-clock
From: Heiko Stuebner @ 2026-03-24 17:04 UTC (permalink / raw)
To: linux-rockchip, MidG971
Cc: Heiko Stuebner, shawn.lin, jonas, linux-arm-kernel, devicetree
In-Reply-To: <20260320094441.128263-1-midgy971@gmail.com>
On Fri, 20 Mar 2026 10:44:41 +0100, MidG971 wrote:
> The Radxa ROCK 3B uses a PI6C20100 PCIe reference clock buffer to
> provide a 100MHz reference clock to the PCIe 3.0 PHY and controllers.
> This chip is currently modeled only as a fixed regulator
> (vcc3v3_pi6c_03), with no clock output representation.
>
> The PI6C20100 is a clock generator, not a power supply. Model it
> properly as a gated-fixed-clock, following the pattern established
> for the Rock 5 ITX and other boards with similar PCIe clock buffer
> chips.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: rockchip: rock-3b: Model PI6C20100 as gated-fixed-clock
commit: b61f3c69c87b5f061194f413d810723698534b02
As I somehow expected, that AI messed up ;-) .
In the 2nd part of the patch the reported number of lines
in the header (the 15 there) does not match the number of lines
in the diff itself (14). I've fixed that up to not have another
round.
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Ville Syrjälä @ 2026-03-24 17:00 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <20260324-color-format-v11-3-605559af4fb4@collabora.com>
On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> +enum drm_connector_color_format {
> + /**
> + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> + * helpers should pick a suitable color format. All implementations of a
> + * specific display protocol must behave the same way with "AUTO", but
> + * different display protocols do not necessarily have the same "AUTO"
> + * semantics.
> + *
> + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> + * bandwidth required for full-scale RGB is not available, or the mode
> + * is YCbCr 4:2:0-only, as long as the mode and output both support
> + * YCbCr 4:2:0.
> + *
> + * For display protocols other than HDMI, the recursive bridge chain
> + * format selection picks the first chain of bridge formats that works,
> + * as has already been the case before the introduction of the "color
> + * format" property. Non-HDMI bridges should therefore either sort their
> + * bus output formats by preference, or agree on a unified auto format
> + * selection logic that's implemented in a common state helper (like
> + * how HDMI does it).
> + */
> + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> +
> + /**
> + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> + */
> + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> +
> + /**
> + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> + * not subsampled)
> + */
> + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> +
> + /**
> + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> + * with horizontal subsampling)
> + */
> + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> +
> + /**
> + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> + * with horizontal and vertical subsampling)
> + */
> + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
Seems like this should document what the quantization range
should be for each format.
> +
> + /**
> + * @DRM_CONNECTOR_COLOR_FORMAT_COUNT: Number of valid connector color
> + * format values in this enum
> + */
> + DRM_CONNECTOR_COLOR_FORMAT_COUNT,
> +};
> +
> +/**
> + * drm_connector_color_format_valid - Validate drm_connector_color_format value
> + * @fmt: value to check against all values of &enum drm_connector_color_format
> + *
> + * Checks whether the passed in value of @fmt is one of the allowable values in
> + * &enum drm_connector_color_format.
> + *
> + * Returns: %true if it's a valid value for the enum, %false otherwise.
> + */
> +static inline bool __pure
> +drm_connector_color_format_valid(enum drm_connector_color_format fmt)
> +{
> + switch (fmt) {
> + case DRM_CONNECTOR_COLOR_FORMAT_AUTO:
> + case DRM_CONNECTOR_COLOR_FORMAT_RGB444:
> + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR444:
> + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR422:
> + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR420:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> const char *
> drm_hdmi_connector_get_output_format_name(enum drm_output_color_format fmt);
>
> @@ -1129,6 +1217,13 @@ struct drm_connector_state {
> */
> enum drm_colorspace colorspace;
>
> + /**
> + * @color_format: State variable for Connector property to request
> + * color format change on Sink. This is most commonly used to switch
> + * between RGB to YUV and vice-versa.
> + */
> + enum drm_connector_color_format color_format;
> +
> /**
> * @writeback_job: Writeback job for writeback connectors
> *
> @@ -2127,6 +2222,12 @@ struct drm_connector {
> */
> struct drm_property *colorspace_property;
>
> + /**
> + * @color_format_property: Connector property to set the suitable
> + * color format supported by the sink.
> + */
> + struct drm_property *color_format_property;
> +
> /**
> * @path_blob_ptr:
> *
> @@ -2610,6 +2711,9 @@ bool drm_connector_has_possible_encoder(struct drm_connector *connector,
> struct drm_encoder *encoder);
> const char *drm_get_colorspace_name(enum drm_colorspace colorspace);
>
> +int drm_connector_attach_color_format_property(struct drm_connector *connector,
> + unsigned long supported_color_formats);
> +
> /**
> * drm_for_each_connector_iter - connector_list iterator macro
> * @connector: &struct drm_connector pointer used as cursor
>
> --
> 2.53.0
--
Ville Syrjälä
Intel
^ permalink raw reply
* [PATCH 10/10] PCI: Fix alignment calculation for resource size larger than align
From: Ilpo Järvinen @ 2026-03-24 16:56 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Guenter Roeck, linux-alpha,
linux-arm-kernel, linux-m68k, linux-mips, linux-parisc,
linuxppc-dev, linux-s390, linux-sh, Russell King,
Geert Uytterhoeven, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Chris Zankel,
Max Filippov, Madhavan Srinivasan, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz, Ilpo Järvinen, linux-kernel
In-Reply-To: <20260324165633.4583-1-ilpo.jarvinen@linux.intel.com>
The commit bc75c8e50711 ("PCI: Rewrite bridge window head alignment
function") did not use if (r_size <= align) check from pbus_size_mem()
for the new head alignment bookkeeping structure (aligns2[]). In some
configurations, this can result in producing a gap into the bridge
window which the resource larger than its alignment cannot fill.
The old alignment calculation algorithm was removed by the subsequent
commit 3958bf16e2fe ("PCI: Stop over-estimating bridge window size")
which renamed the aligns2[] array leaving only aligns[] array.
Add the if (r_size <= align) check back to avoid this problem.
Fixes: bc75c8e50711 ("PCI: Rewrite bridge window head alignment function")
Closes: https://lore.kernel.org/all/b05a6f14-979d-42c9-924c-d8408cb12ae7@roeck-us.net/
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
drivers/pci/setup-bus.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index edc0d682dcad..e5af8799c36f 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1333,7 +1333,14 @@ static void pbus_size_mem(struct pci_bus *bus, struct resource *b_res,
r_size = resource_size(r);
size += max(r_size, align);
- aligns[order] += align;
+ /*
+ * If resource's size is larger than its alignment,
+ * some configurations result in an unwanted gap in
+ * the head space that the larger resource cannot
+ * fill.
+ */
+ if (r_size <= align)
+ aligns[order] += align;
if (order > max_order)
max_order = order;
}
--
2.39.5
^ permalink raw reply related
* [PATCH 09/10] PCI: Align head space better
From: Ilpo Järvinen @ 2026-03-24 16:56 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Guenter Roeck, linux-alpha,
linux-arm-kernel, linux-m68k, linux-mips, linux-parisc,
linuxppc-dev, linux-s390, linux-sh, Russell King,
Geert Uytterhoeven, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Chris Zankel,
Max Filippov, Madhavan Srinivasan, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz, Nicholas Piggin,
Christophe Leroy (CS GROUP), x86, linux-kernel
Cc: Ilpo Järvinen
In-Reply-To: <20260324165633.4583-1-ilpo.jarvinen@linux.intel.com>
When a bridge window contains big and small resource(s), the small
resource(s) may not amount to the half of the size of the big resource
which would allow calculate_head_align() to shrink the head alignment.
This results in always placing the small resource(s) after the big
resource.
In general, it would be good to be able to place the small resource(s)
before the big resource to achieve better utilization of the address
space. In the cases where the large resource can only fit at the end
of the window, it is even required.
However, carrying the information over from pbus_size_mem() and
calculate_head_align() to __pci_assign_resource() and
pcibios_align_resource() is not easy with the current data structures.
A somewhat hacky way to move the non-aligning tail part to the head is
possible within pcibios_align_resource(). The free space between the
start of the free space span and the aligned start address can be
compared with the non-aligning remainder of the size. If the free space
is larger than the remainder, placing the remainder before the start
address is possible. This relocation should generally work, because PCI
resources consist only power-of-2 atoms.
Various arch requirements may still need to override the relocation, so
the relocation is only applied selectively in such cases.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221205
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
arch/arm/kernel/bios32.c | 3 +++
arch/m68k/kernel/pcibios.c | 4 ++++
arch/mips/pci/pci-generic.c | 3 +++
arch/mips/pci/pci-legacy.c | 2 ++
arch/parisc/kernel/pci.c | 3 +++
arch/powerpc/kernel/pci-common.c | 2 ++
arch/sh/drivers/pci/pci.c | 2 ++
arch/x86/pci/i386.c | 2 ++
arch/xtensa/kernel/pci.c | 2 ++
drivers/pci/setup-res.c | 39 +++++++++++++++++++++++++++++++-
include/linux/pci.h | 5 ++++
kernel/resource.c | 2 +-
12 files changed, 67 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index cedb83a85dd9..ac0e890510da 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -577,6 +577,9 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
return host_bridge->align_resource(dev, res,
start, size, align);
+ if (res->flags & IORESOURCE_MEM)
+ return pci_align_resource(dev, res, empty_res, size, align);
+
return start;
}
diff --git a/arch/m68k/kernel/pcibios.c b/arch/m68k/kernel/pcibios.c
index 7e286ee1976b..7a9e60df79c5 100644
--- a/arch/m68k/kernel/pcibios.c
+++ b/arch/m68k/kernel/pcibios.c
@@ -31,11 +31,15 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
resource_size_t size,
resource_size_t align)
{
+ struct pci_dev *dev = data;
resource_size_t start = res->start;
if ((res->flags & IORESOURCE_IO) && (start & 0x300))
start = (start + 0x3ff) & ~0x3ff;
+ if (res->flags & IORESOURCE_MEM)
+ return pci_align_resource(dev, res, empty_res, size, align);
+
return start;
}
diff --git a/arch/mips/pci/pci-generic.c b/arch/mips/pci/pci-generic.c
index aaa1d6de8bef..c2e23d0c1d77 100644
--- a/arch/mips/pci/pci-generic.c
+++ b/arch/mips/pci/pci-generic.c
@@ -38,6 +38,9 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
return host_bridge->align_resource(dev, res,
start, size, align);
+ if (res->flags & IORESOURCE_MEM)
+ return pci_align_resource(dev, res, empty_res, size, align);
+
return start;
}
diff --git a/arch/mips/pci/pci-legacy.c b/arch/mips/pci/pci-legacy.c
index 817e97402afe..dae6dafdd6e0 100644
--- a/arch/mips/pci/pci-legacy.c
+++ b/arch/mips/pci/pci-legacy.c
@@ -70,6 +70,8 @@ pcibios_align_resource(void *data, const struct resource *res,
if (start & 0x300)
start = (start + 0x3ff) & ~0x3ff;
} else if (res->flags & IORESOURCE_MEM) {
+ start = pci_align_resource(dev, res, empty_res, size, align);
+
/* Make sure we start at our min on all hoses */
if (start < PCIBIOS_MIN_MEM + hose->mem_resource->start)
start = PCIBIOS_MIN_MEM + hose->mem_resource->start;
diff --git a/arch/parisc/kernel/pci.c b/arch/parisc/kernel/pci.c
index f50be1a63c4c..b8007c7400d4 100644
--- a/arch/parisc/kernel/pci.c
+++ b/arch/parisc/kernel/pci.c
@@ -201,6 +201,7 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
resource_size_t size,
resource_size_t alignment)
{
+ struct pci_dev *dev = data;
resource_size_t align, start = res->start;
DBG_RES("pcibios_align_resource(%s, (%p) [%lx,%lx]/%x, 0x%lx, 0x%lx)\n",
@@ -212,6 +213,8 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
align = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM;
if (align > alignment)
start = ALIGN(start, align);
+ else
+ start = pci_align_resource(dev, res, empty_res, size, alignment);
return start;
}
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index e7bfa15da043..8efe95a0c4ff 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1144,6 +1144,8 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
return start;
if (start & 0x300)
start = (start + 0x3ff) & ~0x3ff;
+ } else if (res->flags & IORESOURCE_MEM) {
+ start = pci_align_resource(dev, res, empty_res, size, align);
}
return start;
diff --git a/arch/sh/drivers/pci/pci.c b/arch/sh/drivers/pci/pci.c
index 7a0522316ee3..994c3bd36ef2 100644
--- a/arch/sh/drivers/pci/pci.c
+++ b/arch/sh/drivers/pci/pci.c
@@ -185,6 +185,8 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
*/
if (start & 0x300)
start = (start + 0x3ff) & ~0x3ff;
+ } else (res->flags & IORESOURCE_MEM) {
+ start = pci_align_resource(dev, res, empty_res, size, align);
}
return start;
diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
index 6fbd4b34c3f7..e2de26b82940 100644
--- a/arch/x86/pci/i386.c
+++ b/arch/x86/pci/i386.c
@@ -165,6 +165,8 @@ pcibios_align_resource(void *data, const struct resource *res,
if (start & 0x300)
start = (start + 0x3ff) & ~0x3ff;
} else if (res->flags & IORESOURCE_MEM) {
+ start = pci_align_resource(dev, res, empty_res, size, align);
+
/* The low 1MB range is reserved for ISA cards */
if (start < BIOS_END)
start = BIOS_END;
diff --git a/arch/xtensa/kernel/pci.c b/arch/xtensa/kernel/pci.c
index 64ccb7e0d92f..305031551136 100644
--- a/arch/xtensa/kernel/pci.c
+++ b/arch/xtensa/kernel/pci.c
@@ -54,6 +54,8 @@ pcibios_align_resource(void *data, const struct resource *res,
if (start & 0x300)
start = (start + 0x3ff) & ~0x3ff;
+ } else if (res->flags & IORESOURCE_MEM) {
+ start = pci_align_resource(dev, res, empty_res, size, align);
}
return start;
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index c375e255c509..fbc05cda96ee 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -244,6 +244,41 @@ static int pci_revert_fw_address(struct resource *res, struct pci_dev *dev,
return 0;
}
+/*
+ * For mem bridge windows, try to relocate tail remainder space to space
+ * before res->start if there's enough free space there. This enables
+ * tighter packing for resources.
+ */
+resource_size_t pci_align_resource(struct pci_dev *dev,
+ const struct resource *res,
+ const struct resource *empty_res,
+ resource_size_t size,
+ resource_size_t align)
+{
+ resource_size_t remainder, start_addr;
+
+ if (!(res->flags & IORESOURCE_MEM))
+ return res->start;
+
+ if (IS_ALIGNED(size, align))
+ return res->start;
+
+ remainder = size - ALIGN_DOWN(size, align);
+ /* Don't mess with size that doesn't align with window size granularity */
+ if (!IS_ALIGNED(remainder, pci_min_window_alignment(dev->bus, res->flags)))
+ return res->start;
+ /* Try to place remainder that doesn't fill align before */
+ if (res->start < remainder)
+ return res->start;
+ start_addr = res->start - remainder;
+ if (empty_res->start > start_addr)
+ return res->start;
+
+ pci_dbg(dev, "%pR: moving candidate start address below align to %llx\n",
+ res, (unsigned long long)start_addr);
+ return start_addr;
+}
+
/*
* We don't have to worry about legacy ISA devices, so nothing to do here.
* This is marked as __weak because multiple architectures define it; it should
@@ -255,7 +290,9 @@ resource_size_t __weak pcibios_align_resource(void *data,
resource_size_t size,
resource_size_t align)
{
- return res->start;
+ struct pci_dev *dev = data;
+
+ return pci_align_resource(dev, res, empty_res, size, align);
}
static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev,
diff --git a/include/linux/pci.h b/include/linux/pci.h
index ac332ff9da9f..cedf948dc614 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1210,6 +1210,11 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
const struct resource *empty_res,
resource_size_t size,
resource_size_t align);
+resource_size_t pci_align_resource(struct pci_dev *dev,
+ const struct resource *res,
+ const struct resource *empty_res,
+ resource_size_t size,
+ resource_size_t align);
/* Generic PCI functions used internally */
diff --git a/kernel/resource.c b/kernel/resource.c
index 8c5fcb30fc33..d02a53fb95d8 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -766,7 +766,7 @@ static int __find_resource_space(struct resource *root, struct resource *old,
}
alloc.end = alloc.start + size - 1;
if (alloc.start <= alloc.end &&
- __resource_contains_unbound(&avail, &alloc)) {
+ __resource_contains_unbound(&full_avail, &alloc)) {
new->start = alloc.start;
new->end = alloc.end;
return 0;
--
2.39.5
^ permalink raw reply related
* [PATCH 08/10] PCI: Rename window_alignment() to pci_min_window_alignment()
From: Ilpo Järvinen @ 2026-03-24 16:56 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Guenter Roeck, linux-alpha,
linux-arm-kernel, linux-m68k, linux-mips, linux-parisc,
linuxppc-dev, linux-s390, linux-sh, Russell King,
Geert Uytterhoeven, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Chris Zankel,
Max Filippov, Madhavan Srinivasan, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz, linux-kernel
Cc: Ilpo Järvinen
In-Reply-To: <20260324165633.4583-1-ilpo.jarvinen@linux.intel.com>
window_alignment() lacks prefix. Rename it to pci_min_window_alignment()
in order to include the prefix and also add min to indicate the returned
window alignment is the minimum PCI spec and arch allows.
Also make it available in drivers/pci/pci.h as upcoming changes will need
to call it from outside of setup-bus.c.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
drivers/pci/pci.h | 3 +++
drivers/pci/setup-bus.c | 6 +++---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 13d998fbacce..2edb03c1c6b9 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -1053,6 +1053,9 @@ static inline resource_size_t pci_resource_alignment(struct pci_dev *dev,
return resource_alignment(res);
}
+resource_size_t pci_min_window_alignment(struct pci_bus *bus,
+ unsigned long type);
+
void pci_acs_init(struct pci_dev *dev);
void pci_enable_acs(struct pci_dev *dev);
#ifdef CONFIG_PCI_QUIRKS
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 61f769aaa2f6..edc0d682dcad 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1035,7 +1035,7 @@ resource_size_t __weak pcibios_window_alignment(struct pci_bus *bus,
#define PCI_P2P_DEFAULT_IO_ALIGN SZ_4K
#define PCI_P2P_DEFAULT_IO_ALIGN_1K SZ_1K
-static resource_size_t window_alignment(struct pci_bus *bus, unsigned long type)
+resource_size_t pci_min_window_alignment(struct pci_bus *bus, unsigned long type)
{
resource_size_t align = 1, arch_align;
@@ -1084,7 +1084,7 @@ static void pbus_size_io(struct pci_bus *bus, resource_size_t add_size,
if (resource_assigned(b_res))
return;
- min_align = window_alignment(bus, IORESOURCE_IO);
+ min_align = pci_min_window_alignment(bus, IORESOURCE_IO);
list_for_each_entry(dev, &bus->devices, bus_list) {
struct resource *r;
@@ -1339,7 +1339,7 @@ static void pbus_size_mem(struct pci_bus *bus, struct resource *b_res,
}
}
- win_align = window_alignment(bus, b_res->flags);
+ win_align = pci_min_window_alignment(bus, b_res->flags);
min_align = calculate_head_align(aligns, max_order);
min_align = max(min_align, win_align);
size0 = calculate_memsize(size, realloc_head ? 0 : add_size,
--
2.39.5
^ permalink raw reply related
* [PATCH 07/10] parisc/PCI: Cleanup align handling
From: Ilpo Järvinen @ 2026-03-24 16:56 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Guenter Roeck, linux-alpha,
linux-arm-kernel, linux-m68k, linux-mips, linux-parisc,
linuxppc-dev, linux-s390, linux-sh, Russell King,
Geert Uytterhoeven, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Chris Zankel,
Max Filippov, Madhavan Srinivasan, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz, linux-kernel
Cc: Ilpo Järvinen
In-Reply-To: <20260324165633.4583-1-ilpo.jarvinen@linux.intel.com>
Caller of pcibios_align_resource() (__find_resource_space()) already
aligns the start address by 'alignment' so aligning is only necessary
if align > alignment.
Change also to use ALIGN() instead of open-coding.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
arch/parisc/kernel/pci.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/parisc/kernel/pci.c b/arch/parisc/kernel/pci.c
index f99b20795d5a..f50be1a63c4c 100644
--- a/arch/parisc/kernel/pci.c
+++ b/arch/parisc/kernel/pci.c
@@ -8,6 +8,7 @@
* Copyright (C) 1999-2001 Hewlett-Packard Company
* Copyright (C) 1999-2001 Grant Grundler
*/
+#include <linux/align.h>
#include <linux/eisa.h>
#include <linux/init.h>
#include <linux/module.h>
@@ -200,7 +201,7 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
resource_size_t size,
resource_size_t alignment)
{
- resource_size_t mask, align, start = res->start;
+ resource_size_t align, start = res->start;
DBG_RES("pcibios_align_resource(%s, (%p) [%lx,%lx]/%x, 0x%lx, 0x%lx)\n",
pci_name(((struct pci_dev *) data)),
@@ -209,11 +210,8 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
/* If it's not IO, then it's gotta be MEM */
align = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM;
-
- /* Align to largest of MIN or input size */
- mask = max(alignment, align) - 1;
- start += mask;
- start &= ~mask;
+ if (align > alignment)
+ start = ALIGN(start, align);
return start;
}
--
2.39.5
^ permalink raw reply related
* [PATCH 06/10] MIPS: PCI: Remove unnecessary second application of align
From: Ilpo Järvinen @ 2026-03-24 16:56 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Guenter Roeck, linux-alpha,
linux-arm-kernel, linux-m68k, linux-mips, linux-parisc,
linuxppc-dev, linux-s390, linux-sh, Russell King,
Geert Uytterhoeven, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Chris Zankel,
Max Filippov, Madhavan Srinivasan, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz, linux-kernel
Cc: Ilpo Järvinen
In-Reply-To: <20260324165633.4583-1-ilpo.jarvinen@linux.intel.com>
Aligning res->start by align inside pcibios_align_resource() is
unnecessary because caller of pcibios_align_resource() is
__find_resource_space() that aligns res->start with align before
calling pcibios_align_resource().
Aligning by align in case of IORESOURCE_IO && start & 0x300 cannot ever
result in changing start either because 0x300 bits would have not
survived the earlier alignment if align was large enough to have an
impact.
Thus, remove the duplicated aligning from pcibios_align_resource().
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
arch/mips/pci/pci-generic.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/mips/pci/pci-generic.c b/arch/mips/pci/pci-generic.c
index f4957c26efc7..aaa1d6de8bef 100644
--- a/arch/mips/pci/pci-generic.c
+++ b/arch/mips/pci/pci-generic.c
@@ -32,8 +32,6 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
if (res->flags & IORESOURCE_IO && start & 0x300)
start = (start + 0x3ff) & ~0x3ff;
- start = (start + align - 1) & ~(align - 1);
-
host_bridge = pci_find_host_bridge(dev->bus);
if (host_bridge->align_resource)
--
2.39.5
^ permalink raw reply related
* [PATCH 05/10] am68k/PCI: Remove unnecessary second application of align
From: Ilpo Järvinen @ 2026-03-24 16:56 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Guenter Roeck, linux-alpha,
linux-arm-kernel, linux-m68k, linux-mips, linux-parisc,
linuxppc-dev, linux-s390, linux-sh, Russell King,
Geert Uytterhoeven, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Chris Zankel,
Max Filippov, Madhavan Srinivasan, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz, linux-kernel
Cc: Ilpo Järvinen
In-Reply-To: <20260324165633.4583-1-ilpo.jarvinen@linux.intel.com>
Aligning res->start by align inside pcibios_align_resource() is
unnecessary because caller of pcibios_align_resource() is
__find_resource_space() that aligns res->start with align before
calling pcibios_align_resource().
Aligning by align in case of IORESOURCE_IO && start & 0x300 cannot ever
result in changing start either because 0x300 bits would have not
survived the earlier alignment if align was large enough to have an
impact.
Thus, remove the duplicated aligning from pcibios_align_resource().
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
arch/m68k/kernel/pcibios.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/m68k/kernel/pcibios.c b/arch/m68k/kernel/pcibios.c
index 1415f6e4e5ce..7e286ee1976b 100644
--- a/arch/m68k/kernel/pcibios.c
+++ b/arch/m68k/kernel/pcibios.c
@@ -36,8 +36,6 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
if ((res->flags & IORESOURCE_IO) && (start & 0x300))
start = (start + 0x3ff) & ~0x3ff;
- start = (start + align - 1) & ~(align - 1);
-
return start;
}
--
2.39.5
^ permalink raw reply related
* [PATCH 04/10] ARM/PCI: Remove unnecessary second application of align
From: Ilpo Järvinen @ 2026-03-24 16:56 UTC (permalink / raw)
To: linux-pci, Bjorn Helgaas, Guenter Roeck, linux-alpha,
linux-arm-kernel, linux-m68k, linux-mips, linux-parisc,
linuxppc-dev, linux-s390, linux-sh, Russell King,
Geert Uytterhoeven, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Chris Zankel,
Max Filippov, Madhavan Srinivasan, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz, linux-kernel
Cc: Ilpo Järvinen
In-Reply-To: <20260324165633.4583-1-ilpo.jarvinen@linux.intel.com>
Aligning res->start by align inside pcibios_align_resource() is
unnecessary because caller of pcibios_align_resource() is
__find_resource_space() that aligns res->start with align before
calling pcibios_align_resource().
Aligning by align in case of IORESOURCE_IO && start & 0x300 cannot ever
result in changing start either because 0x300 bits would have not
survived the earlier alignment if align was large enough to have an
impact.
Thus, remove the duplicated aligning from pcibios_align_resource().
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---
arch/arm/kernel/bios32.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index 5b9b4fcd0e54..cedb83a85dd9 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -571,8 +571,6 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
if (res->flags & IORESOURCE_IO && start & 0x300)
start = (start + 0x3ff) & ~0x3ff;
- start = (start + align - 1) & ~(align - 1);
-
host_bridge = pci_find_host_bridge(dev->bus);
if (host_bridge->align_resource)
--
2.39.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox