Re: [PATCH] PCI: dwc: rcar-gen4: Use 4K EPC BAR alignment

[Manivannan Sadhasivam]

On Thu, Mar 05, 2026 at 04:03:03PM +0900, Koichiro Den wrote:
> On Thu, Mar 05, 2026 at 11:27:42AM +0530, Manivannan Sadhasivam wrote:
> > On Thu, Mar 05, 2026 at 10:54:39AM +0900, Koichiro Den wrote:
> > > R-Car S4 Series (R8A779F[4-7]*) uses a 4K minimum iATU region size
> > > (CX_ATU_MIN_REGION_SIZE = 4K) as per R19UH0161EJ0130 Rev.1.30.
> > > 
> > > Update the advertised alignment to 4K, as described in
> > > commit 2a9a801620ef ("PCI: endpoint: Add support to specify alignment
> > > for buffers allocated to BARs").
> > > 
> > > With the previous 1MB alignment requirement, iATU programming for BAR4
> > > on this platform often cannot be performed, since a 1MB-aligned target
> > > address may fall outside the tiny 256B BAR4 window.
> > > 
> > 
> > Can you clarify this part? What do you mean by 'falling outside of the 256B
> > BAR4 window'? Where does the failure happen exactly?
> 
> My primary motivation is to use MSI doorbell [1] for epf-vntb.
> 
> epf_ntb_db_bar_init_msi_doorbell() passes message address 'low' to
> pci_epf_assign_bar_space(). The message address is a fixed physical address,
> or IOVA if EPC is attached to an IOMMU domain.
> 
> Even though the doorbell window size (the difference between the 'high' and
> 'low' message addresses) is typically small, forcing the base address to be
> aligned to a 1MB boundary may push the mapping base much lower than necessary.
> 
> For example:
> 
>   When the doorbell message address 'low' is 0xffdff0a0,
> 
>   - With the previous 1MB alignment, it is aligned down to 0xffd00000.
>     The offset becomes: 0xffdff0a0 - 0xffd00000 = 0xff0a0, which is far larger
>     than the 256B BAR4 window, so the mapping cannot be programmed.
> 
>   - With the correct 4K alignment, it is aligned down to 0xffdff000.
>     The offset becomes: 0xffdff0a0 - 0xffdff000 = 0xa0, which fits within 256B
>     BAR4 window.
> 

Okay, thanks for clarifying. This information should've been present in the
commit message. Though, the top motivation is to comply with the reference
manual.

>   Note: if the address were e.g. 0xffdff1a0 instead of 0xffdff0a0, the
>   4K-aligned offset would become 0x1a0 (416 bytes), which still exceeds the 256B
>   window. (For simplicity, the 32-bit write width is ignored here.) In such a
>   case, programming the mapping would still not be possible.
> 

Hmm, that's probably fine as we would be running into hardware limitation.

>   Also note that I used the term 'aligned_mem_size' above, which is the local
>   variable name in pci_epf_assign_bar_space(). The corresponding struct
>   pci_epf_bar field was renamed from 'aligned_size' to 'mem_size' by commit
>   483768846d66 ("PCI: endpoint: Rename 'epf_bar::aligned_size' to
>   'epf_bar:mem_size'").
> 
> [1] Precisely speaking, the "embedded" doorbell fallback:
>     https://lore.kernel.org/linux-pci/20260302071427.534158-1-den@xxxxxxxxxxxxx/
> 
> > 
> > > Signed-off-by: Koichiro Den <den@xxxxxxxxxxxxx>
> > 
> > Fixes tag?
> 
> Commit e311b3834dfa ("PCI: rcar-gen4: Add endpoint mode support") is much later
> than 2a9a801620ef ("PCI: endpoint: Add support to specify alignment for buffers
> allocated to BARs"), so I believe it makes sense to add:
> 
>   Fixes: e311b3834dfa ("PCI: rcar-gen4: Add endpoint mode support")
> 

Please add it in next version.

- Mani

-- 
மணிவண்ணன் சதாசிவம்