On Tue, Nov 26, 2024 at 11:55:13AM -0500, Frank Li wrote:
> On Tue, Nov 26, 2024 at 06:11:12PM +0530, Manivannan Sadhasivam wrote:
> > On Tue, Nov 26, 2024 at 11:00:09AM +0100, Niklas Cassel wrote:
> > > On Tue, Nov 26, 2024 at 09:55:23AM +0530, Manivannan Sadhasivam wrote:
> > > > On Mon, Nov 25, 2024 at 02:17:04PM -0500, Frank Li wrote:
> > > > > On Sun, Nov 24, 2024 at 01:26:45PM +0530, Manivannan Sadhasivam wrote:
> > > > > > On Sat, Nov 16, 2024 at 09:40:44AM -0500, Frank Li wrote:
> > > > > > > Add three registers: doorbell_bar, doorbell_addr, and doorbell_data,
> >
> > I like the idea of calling pci_epf_alloc_doorbell() in
> > pci_epf_{enable/disable}_doorbell() APIs. And as you said, it doesn't make sense
> > to call these APIs too frequently.
>
> I not sure what's you means and direction for next version.
Move pci_epf_alloc_doorbell() from .bind() to pci_epf_enable_doorbell().
Move pci_epf_free_doorbell() from .unbind() to pci_epf_disable_doorbell().
If the pci_epf_alloc_doorbell() call within pci_epf_enable_doorbell() fails,
let pci_epf_enable_doorbell() set STATUS_DOORBELL_ENABLE_FAIL.
> This patch just go first step. If we can append to ITS to bar0 in future,
> pci_epf_alloc_doorbell() will become more reasonable at bind() function.
To be fair, we are probably quite far away from supporting a BAR with two
backing memory areas. It would require a lot of changes in the PCI endpoint
framework, and a lot of changes in the DWC driver.
And even if we do add all the support for it, why can't we keep the
doorbell allocation in pci_epf_enable_doorbell() ?
Kind regards,
Niklas
