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

[Koichiro Den]

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.

  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.

  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")

Best regards,
Koichiro

> 
> - Mani
> 
> > ---
> >  drivers/pci/controller/dwc/pcie-rcar-gen4.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> > index 3d4a889e38cc..396ef9432299 100644
> > --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> > +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> > @@ -428,7 +428,7 @@ static const struct pci_epc_features rcar_gen4_pcie_epc_features = {
> >  	.bar[BAR_3] = { .type = BAR_RESERVED, },
> >  	.bar[BAR_4] = { .type = BAR_FIXED, .fixed_size = 256 },
> >  	.bar[BAR_5] = { .type = BAR_RESERVED, },
> > -	.align = SZ_1M,
> > +	.align = SZ_4K,
> >  };
> >  
> >  static const struct pci_epc_features*
> > -- 
> > 2.51.0
> > 
> 
> -- 
> மணிவண்ணன் சதாசிவம்