Hello Mani,
On Thu, Apr 17, 2025 at 10:46:31PM +0530, Manivannan Sadhasivam via B4 Relay
wrote:
> @@ -1571,6 +1652,9 @@ static irqreturn_t qcom_pcie_global_irq_thread(int irq,
> void *data)
> pci_unlock_rescan_remove();
>
> qcom_pcie_icc_opp_update(pcie);
> + }
On Wed, Aug 14, 2024 at 10:20:55PM +1000, Michael Ellerman wrote:
> Niklas Cassel writes:
> > On Tue, Aug 13, 2024 at 10:32:36PM +1000, Michael Ellerman wrote:
> >> Niklas Cassel writes:
> >> > On Tue, Aug 13, 2024 at 07:49:34AM +0200, Jonáš Vidra wrote:
> .
Hello Michael,
On Tue, Aug 13, 2024 at 10:32:36PM +1000, Michael Ellerman wrote:
> Niklas Cassel writes:
> > Hello Jonáš, Kolbjørn,
> >
> > thank you for the report.
> >
> > On Tue, Aug 13, 2024 at 07:49:34AM +0200, Jonáš Vidra wrote:
> >> On Tue 13. Au
Hello Jonáš, Kolbjørn,
thank you for the report.
On Tue, Aug 13, 2024 at 07:49:34AM +0200, Jonáš Vidra wrote:
> On Tue 13. Aug 2024 0:32:37 CEST, Kolbjørn Barmen wrote:
> > Ever since 6.10, my macmini G4 behaved unstable when dealing with lots of
> > I/O activity, such as sync'ing of Gentoo porta
On Mon, Jun 24, 2024 at 10:35:37AM +0200, Christoph Hellwig wrote:
> This is odd to say at least. Any chance you can check the value
> of /sys/block/$DEVICE/queue/rotational for the relevant device before
> and after this commit? And is this an ATA or NVMe SSD?
>
Seems to be ATA SSD:
https://do
On Thu, Jun 06, 2024 at 12:56:33PM +0530, Manivannan Sadhasivam wrote:
> Hi,
>
> This series includes patches that were left over from previous series [1] for
> making the host reboot handling robust in endpoint framework.
>
> When the above mentioned series got merged to pci/endpoint, we got a b
_pcie_ep_linkdown(&pci->ep);
> } else if (val & PEX_PF0_PME_MES_DR_HRD) {
> dev_dbg(pci->dev, "Hot reset\n");
> }
>
> --
> 2.25.1
>
Reviewed-by: Niklas Cassel
On Thu, Jun 06, 2024 at 12:56:37PM +0530, Manivannan Sadhasivam wrote:
> Now that the API is available, let's make use of it. It also handles the
> reinitialization of DWC non-sticky registers in addition to sending the
> notification to EPF drivers.
>
> Reviewed-by: Niklas
of code organization, move the dw_pcie_ep_linkup()
> definition just above dw_pcie_ep_linkdown().
>
> Reviewed-by: Niklas Cassel
> Signed-off-by: Manivannan Sadhasivam
> ---
Like Siddharth reported, this patch is already in pci/next.
irectly from glue
> drivers.
>
> Suggested-by: Bjorn Helgaas
> Signed-off-by: Manivannan Sadhasivam
> ---
Reviewed-by: Niklas Cassel
On Thu, Jun 06, 2024 at 09:14:45PM +1000, Michael Ellerman wrote:
> The pata_macio driver advertises a max_segment_size of 0xff00, because
> the hardware doesn't cope with requests >= 64K.
>
> However the SCSI core requires max_segment_size to be at least
> PAGE_SIZE, which is a problem for pata_m
an send the notification
> before the EPF drivers bind() and in those cases the EPF drivers will miss
> the event. To accommodate this, EPC core is now caching the state of the
> EPC initialization in 'init_complete' flag and pci-ep-cfs driver sends the
> notificati
he glue driver can send the notification
> before the EPF drivers bind() and in those cases the EPF drivers will miss
> the event. To accommodate this, EPC core is now caching the state of the
> EPC initialization in 'init_complete' flag and pci-ep-cfs driver sends the
> notificati
gt; drivers/pci/endpoint/pci-ep-cfs.c | 9 +
> drivers/pci/endpoint/pci-epc-core.c | 22 ++
> include/linux/pci-epc.h | 7 ---
> 15 files changed, 58 insertions(+), 18 deletions(-)
FWIW:
Tested-by: Niklas Cassel
t().
>
> With this change, the check for 'core_init_notifier' flag can now be
> dropped from dw_pcie_ep_init() API. This will also allow us to remove the
> 'core_init_notifier' flag completely in the later commits.
>
> Reviewed-by: Yoshihiro Shimoda
> Signed-off-by: Manivannan Sadhasivam
> ---
Reviewed-by: Niklas Cassel
(either
> + * from host or generated locally).
> + */
> int dw_pcie_ep_init_complete(struct dw_pcie_ep *ep)
> {
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> @@ -716,6 +785,15 @@ int dw_pcie_ep_init_complete(struct dw_pcie_ep *ep)
> }
> EXPORT_SYMBOL_GPL(dw_pcie_ep_init_complete);
>
> +/**
> + * dw_pcie_ep_init - Initialize the endpoint device
> + * @ep: DWC EP device
> + *
> + * Initialize the endpoint device. Allocate resources and create the EPC
> + * device with the endpoint framework.
> + *
> + * Return: 0 if success, errno otherwise.
> + */
> int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> {
> int ret;
>
> --
> 2.25.1
>
With nits fixed:
Reviewed-by: Niklas Cassel
On Mon, Mar 11, 2024 at 08:15:59PM +0530, Manivannan Sadhasivam wrote:
> >
> > I would say that it is the following change that breaks things:
> >
> > > - if (!core_init_notifier) {
> > > - ret = pci_epf_test_core_init(epf);
> > > - if (ret)
> > > - return ret;
> >
On Mon, Mar 04, 2024 at 02:52:19PM +0530, Manivannan Sadhasivam wrote:
> "core_init_notifier" flag is set by the glue drivers requiring refclk from
> the host to complete the DWC core initialization. Also, those drivers will
> send a notification to the EPF drivers once the initialization is fully
On Fri, Mar 08, 2024 at 03:19:47PM +0530, Manivannan Sadhasivam wrote:
> > > > > @@ -467,6 +467,13 @@ static int dra7xx_add_pcie_ep(struct dra7xx_pcie
> > > > > *dra7xx,
> > > > > return ret;
> > > > > }
> > > > >
> > > > > + ret = dw_pcie_ep_init_registers(ep);
> > > > >
On Fri, Mar 08, 2024 at 03:16:06PM +0530, Manivannan Sadhasivam wrote:
> On Fri, Mar 08, 2024 at 09:56:33AM +0100, Niklas Cassel wrote:
> > On Fri, Mar 08, 2024 at 11:11:52AM +0530, Manivannan Sadhasivam wrote:
> > > On Thu, Mar 07, 2024 at 10:43:19PM +0100, Niklas Cassel wro
On Fri, Mar 08, 2024 at 11:06:24AM +0530, Manivannan Sadhasivam wrote:
> On Thu, Mar 07, 2024 at 09:36:56PM +0100, Niklas Cassel wrote:
> > On Mon, Mar 04, 2024 at 02:52:18PM +0530, Manivannan Sadhasivam wrote:
> > > Currently, dw_pcie_ep_init_registers() API is directly
On Fri, Mar 08, 2024 at 11:11:52AM +0530, Manivannan Sadhasivam wrote:
> On Thu, Mar 07, 2024 at 10:43:19PM +0100, Niklas Cassel wrote:
> > On Mon, Mar 04, 2024 at 02:52:20PM +0530, Manivannan Sadhasivam wrote:
> > > The PCIe link can go to LINK_DOWN state in one of the f
On Fri, Mar 08, 2024 at 11:08:29AM +0530, Manivannan Sadhasivam wrote:
> On Thu, Mar 07, 2024 at 10:09:06PM +0100, Niklas Cassel wrote:
> > On Mon, Mar 04, 2024 at 02:52:19PM +0530, Manivannan Sadhasivam wrote:
> > > "core_init_notifier" flag is set by the glue d
On Mon, Mar 04, 2024 at 02:52:22PM +0530, Manivannan Sadhasivam wrote:
> All of the APIs are missing the Kernel-doc comments. Hence, add them.
>
> Reviewed-by: Frank Li
> Signed-off-by: Manivannan Sadhasivam
> ---
For the functions that you added in this series, e.g.
dw_pcie_ep_cleanup(), dw_pc
dev_dbg(dev, "Received BME event. Link is enabled!\n");
> pcie_ep->link_status = QCOM_PCIE_EP_LINK_ENABLED;
>
> --
> 2.25.1
>
Reviewed-by: Niklas Cassel
On Mon, Mar 04, 2024 at 02:52:20PM +0530, Manivannan Sadhasivam wrote:
> The PCIe link can go to LINK_DOWN state in one of the following scenarios:
>
> 1. Fundamental (PERST#)/hot/warm reset
> 2. Link transition from L2/L3 to L0
>
> In those cases, LINK_DOWN causes some non-sticky DWC registers t
Considering that you are not changing the name of the callback,
and that it was already confusing before this patch:
Reviewed-by: Niklas Cassel
On Mon, Mar 04, 2024 at 02:52:18PM +0530, Manivannan Sadhasivam wrote:
> Currently, dw_pcie_ep_init_registers() API is directly called by the glue
> drivers requiring active refclk from host. But for the other drivers, it is
> getting called implicitly by dw_pcie_ep_init(). This is due to the fact
causes confusion. So,
> let's rename it to dw_pcie_ep_init_registers() to make it clear that it
> initializes the DWC specific registers.
>
> Reviewed-by: Frank Li
> Signed-off-by: Manivannan Sadhasivam
> ---
Reviewed-by: Niklas Cassel
u want backported,
and it does not depend on any of the previous patches (it doesn't
seem that way), then I think that you should have put it as patch
1/10 in the series.
Patch ordering aside:
Reviewed-by: Niklas Cassel
nup() API that could be called by these
> drivers to cleanup the DWC specific resources. Currently, it just removes
> eDMA.
>
> Reported-by: Niklas Cassel
> Closes: https://lore.kernel.org/linux-pci/ZWYmX8Y%2F7Q9WMxES@x1-carbon
> Reviewed-by: Frank Li
> Signed-off-by: Ma
() to make the
> purpose of this API clear. This also aligns with the DWC host driver.
>
> Reviewed-by: Frank Li
> Signed-off-by: Manivannan Sadhasivam
> ---
Reviewed-by: Niklas Cassel
API in rcar_gen4_remove_dw_pcie_ep().
>
> This simplifies the DWC layer.
>
> Reviewed-by: Frank Li
> Signed-off-by: Manivannan Sadhasivam
> ---
Reviewed-by: Niklas Cassel
On Mon, Mar 04, 2024 at 01:47:13PM +0530, Manivannan Sadhasivam wrote:
> On Thu, Feb 29, 2024 at 01:40:29PM +0100, Niklas Cassel wrote:
> > On Sat, Feb 24, 2024 at 12:24:09PM +0530, Manivannan Sadhasivam wrote:
> >
> > Since e.g. qcom-ep.c does a reset_control_assert() du
Hello Mani,
On Sat, Feb 24, 2024 at 12:24:16PM +0530, Manivannan Sadhasivam wrote:
> All of the APIs are missing the Kernel-doc comments. Hence, add them.
>
> Signed-off-by: Manivannan Sadhasivam
> ---
> drivers/pci/controller/dwc/pcie-designware-ep.c | 92
> +
> 1 file
nup() API that could be called by these
> drivers to cleanup the DWC specific resources. Currently, it just removes
> eDMA.
>
> Reported-by: Niklas Cassel
> Closes: https://lore.kernel.org/linux-pci/ZWYmX8Y%2F7Q9WMxES@x1-carbon
> Signed-off-by: Manivannan Sadhasivam
> ---
>
Hello Mani,
On Sat, Feb 24, 2024 at 12:24:13PM +0530, Manivannan Sadhasivam wrote:
> "core_init_notifier" flag is set by the glue drivers requiring refclk from
> the host to complete the DWC core initialization. Also, those drivers will
> send a notification to the EPF drivers once the initializat
er 32-bits, so an EPF driver cannot
use a BAR succeeding a 64-bit BAR. Ensure that all endpoint controller
drivers are uniform, and actually describe a reserved BAR as reserved.
Signed-off-by: Niklas Cassel
Reviewed-by: Kishon Vijay Abraham I
---
drivers/pci/controller/dwc/pci-imx6.c
Changes since V1:
-Picked up tags from Kishon and Mani.
-Improved commit message for patch 1/2 as suggested by Mani.
-Improved kdoc in patch 2/2 as suggested by Mani.
Niklas Cassel (2):
PCI: endpoint: Clean up hardware description for BARs
PCI: endpoint: Drop only_64bit on reserved BARs
On Wed, Feb 14, 2024 at 09:47:54AM +0530, Kishon Vijay Abraham I wrote:
> Hi Niklas,
>
> On 2/10/2024 6:56 AM, Niklas Cassel wrote:
> > The series is based on top of:
> > https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=endpoint
> >
> >
&g
pci_epc_bar_type, and convert the endpoint controller drivers to use
this more well defined format.
Signed-off-by: Niklas Cassel
---
drivers/pci/controller/dwc/pci-imx6.c | 3 +-
drivers/pci/controller/dwc/pci-keystone.c | 12 +++
.../pci/controller/dwc/pci-layerscape-ep.c
coming week(s).)
Kind regards,
Niklas
Niklas Cassel (2):
PCI: endpoint: Clean up hardware description for BARs
PCI: endpoint: Drop only_64bit on reserved BARs
drivers/pci/controller/dwc/pci-imx6.c | 3 +-
drivers/pci/controller/dwc/pci-keystone.c | 12 +++---
.../pci/controller
Hello Kishon!
It's nice to see that you are improving the dwc framework+drivers.
pcie-artpec6.c has the same quirk as dra7xx,
see define ARTPEC6_CPU_TO_BUS_ADDR.
I could create a patch, but I guess it would make more sense
if it's part of this series.
Keep up the good work!
Regards,
Niklas
43 matches
Mail list logo
