From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Vidya Sagar <vidyas@nvidia.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>,
andrew.murray@arm.com, Tom Joseph <tjoseph@cadence.com>,
Milind Parab <mparab@cadence.com>,
jingoohan1@gmail.com, gustavo.pimentel@synopsys.com,
bhelgaas@google.com, thierry.reding@gmail.com,
Jisheng.Zhang@synaptics.com, jonathanh@nvidia.com,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kthota@nvidia.com, mmaddireddy@nvidia.com, sagar.tv@gmail.com
Subject: Re: [PATCH V2 0/5] Add support to defer core initialization
Date: Thu, 20 Feb 2020 16:00:54 +0000 [thread overview]
Message-ID: <20200220160044.GA8859@e121166-lin.cambridge.arm.com> (raw)
In-Reply-To: <7e8dafcd-bc3f-4acc-7023-85e24bebdd94@nvidia.com>
On Wed, Feb 19, 2020 at 07:06:47PM +0530, Vidya Sagar wrote:
> Hi Lorenzo, Andrew,
> Kishon did rebase [1] mentioned below and removed dependencies.
> New patch series is available
> @ http://patchwork.ozlabs.org/project/linux-pci/list/?series=158088
>
> I rebased my patches on top of this and is available for review
> @ http://patchwork.ozlabs.org/project/linux-pci/list/?series=158959
>
> Please let us know the way forward towards merging these patches.
Hi Vidya,
I shall have a look shortly, I have planned to start queueing patches
from next week.
Thanks,
Lorenzo
> Thanks,
> Vidya Sagar
>
> On 2/5/2020 12:07 PM, Kishon Vijay Abraham I wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > +Tom, Milind
> >
> > Hi,
> >
> > On 23/01/20 3:25 PM, Kishon Vijay Abraham I wrote:
> > > Hi Vidya Sagar,
> > >
> > > On 23/01/20 2:54 pm, Vidya Sagar wrote:
> > > > Hi Kishon,
> > > > Apologies for pinging again. Could you please review this series?
> > > >
> > > > Thanks,
> > > > Vidya Sagar
> > > >
> > > > On 1/11/2020 5:18 PM, Vidya Sagar wrote:
> > > > > Hi Kishon,
> > > > > Could you please review this series?
> > > > >
> > > > > Also, this series depends on the following change of yours
> > > > > http://patchwork.ozlabs.org/patch/1109884/
> > > > > Whats the plan to get this merged?
> > >
> > > I've posted the endpoint improvements as a separate series
> > > http://lore.kernel.org/r/20191231100331.6316-1-kishon@ti.com
> > >
> > > I'd prefer this series gets tested by others. I'm also planning to test
> > > this series. Sorry for the delay. I'll test review and test this series
> > > early next week.
> >
> > I tested this series with DRA7 configured in EP mode. So for the series
> > itself
> >
> > Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
> >
> > Tom, Can you test this series in Cadence platform?
> >
> > Lorenzo, Andrew,
> >
> > How do you want to go about merging this series? This series depends on
> > [1] which in turn is dependent on two other series. If required, I can
> > rebase [1] on mainline kernel and remove it's dependencies with the
> > other series. That way this series and [1] could be merged. And the
> > other series could be worked later. Kindly let me know.
> >
> > Thanks
> > Kishon
> >
> > [1] ->
> > https://lore.kernel.org/linux-pci/20191231100331.6316-1-kishon@ti.com/
> > >
> > > Thanks
> > > Kishon
> > >
> > > > >
> > > > > Thanks,
> > > > > Vidya Sagar
> > > > >
> > > > > On 1/3/20 3:37 PM, Vidya Sagar wrote:
> > > > > > EPC/DesignWare core endpoint subsystems assume that the core
> > > > > > registers are
> > > > > > available always for SW to initialize. But, that may not be the case
> > > > > > always.
> > > > > > For example, Tegra194 hardware has the core running on a clock that
> > > > > > is derived
> > > > > > from reference clock that is coming into the endpoint system from host.
> > > > > > Hence core is made available asynchronously based on when host system
> > > > > > is going
> > > > > > for enumeration of devices. To accommodate this kind of hardwares,
> > > > > > support is
> > > > > > required to defer the core initialization until the respective
> > > > > > platform driver
> > > > > > informs the EPC/DWC endpoint sub-systems that the core is indeed
> > > > > > available for
> > > > > > initiaization. This patch series is attempting to add precisely that.
> > > > > > This series is based on Kishon's patch that adds notification mechanism
> > > > > > support from EPC to EPF @ http://patchwork.ozlabs.org/patch/1109884/
> > > > > >
> > > > > > Vidya Sagar (5):
> > > > > > PCI: endpoint: Add core init notifying feature
> > > > > > PCI: dwc: Refactor core initialization code for EP mode
> > > > > > PCI: endpoint: Add notification for core init completion
> > > > > > PCI: dwc: Add API to notify core initialization completion
> > > > > > PCI: pci-epf-test: Add support to defer core initialization
> > > > > >
> > > > > > .../pci/controller/dwc/pcie-designware-ep.c | 79 +++++++-----
> > > > > > drivers/pci/controller/dwc/pcie-designware.h | 11 ++
> > > > > > drivers/pci/endpoint/functions/pci-epf-test.c | 118 ++++++++++++------
> > > > > > drivers/pci/endpoint/pci-epc-core.c | 19 ++-
> > > > > > include/linux/pci-epc.h | 2 +
> > > > > > include/linux/pci-epf.h | 5 +
> > > > > > 6 files changed, 164 insertions(+), 70 deletions(-)
> > > > > >
prev parent reply other threads:[~2020-02-20 16:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-03 10:07 [PATCH V2 0/5] Add support to defer core initialization Vidya Sagar
2020-01-03 10:07 ` [PATCH V2 1/5] PCI: endpoint: Add core init notifying feature Vidya Sagar
2020-01-03 10:07 ` [PATCH V2 2/5] PCI: dwc: Refactor core initialization code for EP mode Vidya Sagar
2020-01-03 10:07 ` [PATCH V2 3/5] PCI: endpoint: Add notification for core init completion Vidya Sagar
2020-01-03 10:07 ` [PATCH V2 4/5] PCI: dwc: Add API to notify core initialization completion Vidya Sagar
2020-01-03 10:07 ` [PATCH V2 5/5] PCI: pci-epf-test: Add support to defer core initialization Vidya Sagar
2020-01-11 11:48 ` [PATCH V2 0/5] " Vidya Sagar
2020-01-23 9:24 ` Vidya Sagar
2020-01-23 9:55 ` Kishon Vijay Abraham I
2020-02-03 9:37 ` Vidya Sagar
2020-02-05 6:37 ` Kishon Vijay Abraham I
2020-02-19 13:36 ` Vidya Sagar
2020-02-20 16:00 ` Lorenzo Pieralisi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200220160044.GA8859@e121166-lin.cambridge.arm.com \
--to=lorenzo.pieralisi@arm.com \
--cc=Jisheng.Zhang@synaptics.com \
--cc=andrew.murray@arm.com \
--cc=bhelgaas@google.com \
--cc=gustavo.pimentel@synopsys.com \
--cc=jingoohan1@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=kishon@ti.com \
--cc=kthota@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mmaddireddy@nvidia.com \
--cc=mparab@cadence.com \
--cc=sagar.tv@gmail.com \
--cc=thierry.reding@gmail.com \
--cc=tjoseph@cadence.com \
--cc=vidyas@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.