From: Marek Vasut <marex@denx.de>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, devicetree@vger.kernel.org,
Sean Cross <xobs@kosagi.com>, Richard Zhu <r65037@freescale.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Jingoo Han <jg1.han@samsung.com>,
Shawn Guo <shawn.guo@linaro.org>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Mark Rutland <mark.rutland@arm.com>,
Pawel Moll <pawel.moll@arm.com>, Rob Herring <robh+dt@kernel.org>,
Arnd Bergmann <arnd@arndb.de>, Tim Harvey <tharvey@gateworks.com>,
kernel@pengutronix.de
Subject: Re: [PATCH 2/8] PCI: designware: split Exynos and i.MX bindings
Date: Mon, 31 Mar 2014 11:36:49 +0200 [thread overview]
Message-ID: <201403311136.49280.marex@denx.de> (raw)
In-Reply-To: <1396258109.5533.11.camel@weser.hi.pengutronix.de>
On Monday, March 31, 2014 at 11:28:29 AM, Lucas Stach wrote:
> Am Sonntag, den 30.03.2014, 19:36 +0200 schrieb Marek Vasut:
> > On Friday, March 28, 2014 at 05:52:53 PM, Lucas Stach wrote:
> > > The glue around the core designware IP is significantly
> > > different between the Exynos and i.MX implementation,
> > > which is reflected in the DT bindings.
> > >
> > > This changes the i.MX6 binding to reuse as much as
> > > possible from the common designware binding and
> > > removes old cruft.
> > >
> > > I removed the optional GPIOs with the following reasoning:
> > > - disable-gpio: endpoint specific GPIO, not currently
> > >
> > > wired up in any code. Should be handled by the PCI device
> > > driver, not the host controller driver.
> > >
> > > - wake-up-gpio: same as above.
> > > - power-on-gpio: No user in any upstream DT. This should
> > >
> > > be handled by a regulator which shouldn't be controlled
> > > by the host driver, but rather by the PCI device driver.
> >
> > This power-on-gpio should indeed be handled by the regulator, but the
> > regulator cannot be handled by the PCIe device driver. This
> > power-on-gpio must be operated on per-slot basis if I understand it
> > correctly, so it cannot be controlled by the host controller driver
> > either.
> >
> > The reason why this cannot be controlled by the device driver is that if
> > the device is powered down, it won't be detected on the PCIe bus, thus
> > it cannot enable the regulator which will power up the slot the device
> > is sitting in.
>
> So we are on the same page with regard to a GPIO being the wrong
> abstraction for this, I think.
Yes.
> For the regulator part I would argue that PCI is a bus that is built
> around the ability to inspect the bus and detect devices on the bus at
> probe time, so any regulator that's powering a PCI device should be
> boot-on.
This thing about regulator being boot-on should really be documented.
Moreover, I think it's a waste of power to keep the devices ON on boot even if
the PCIe bus was not started (yet). The bus might not be started at all and the
regulators would still be ON, which would be quite a waste.
> Only after the device driver is loaded it should be able to fetch the
> regulator to power down/up the device as it wishes. In the x86 world
> this is AFAIK done using ACPI methods.
>
> I think the host controller driver has no business in controlling the
> device power, more so as there possibly could be a lot of devices on the
> bus even with a single host lane.
The power should be controlled per-slot, but I don't know how to model that.
Note that there might be a PCIe device with a switch popped into a single slot,
which makes things much more interesting. In such case, you need to power up the
slot and neither of the downstream devices should control the power regulator of
that slot.
> > btw. am I blind or do I just not see devicetree-discuss on CC ?
>
> Hm, there is devicetree@vger.kernel.org on CC, which MAINTAINER says is
> the right list for this stuff.
OK, I was blind, sorry.
Best regards,
Marek Vasut
next prev parent reply other threads:[~2014-03-31 9:36 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-28 16:52 [PATCH 0/8] i.MX6 PCIe binding change and MSI support Lucas Stach
2014-03-28 16:52 ` [PATCH 1/8] ARM: imx6q-clk: parent lvds_gate from lvds_sel Lucas Stach
2014-03-30 17:29 ` Marek Vasut
[not found] ` <1396025579-14344-2-git-send-email-l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2014-04-02 12:57 ` Hong-Xing.Zhu-KZfg59tc24xl57MIdRCFDg
2014-04-03 6:49 ` Shawn Guo
2014-03-28 16:52 ` [PATCH 2/8] PCI: designware: split Exynos and i.MX bindings Lucas Stach
2014-03-30 17:36 ` Marek Vasut
2014-03-31 9:28 ` Lucas Stach
2014-03-31 9:36 ` Marek Vasut [this message]
2014-03-31 10:38 ` Lucas Stach
2014-03-31 10:52 ` Marek Vasut
2014-03-28 16:52 ` [PATCH 3/8] ARM: dts: imx6: update pcie to bring in line with new binding Lucas Stach
2014-04-30 6:02 ` Shawn Guo
2014-04-30 10:17 ` Lucas Stach
2014-03-28 16:52 ` [PATCH 5/8] PCI: imx6: drop old irq mapping Lucas Stach
2014-03-28 16:52 ` [PATCH 6/8] PCI: imx6: rip out optional (and unused) irqs Lucas Stach
[not found] ` <1396025579-14344-1-git-send-email-l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2014-03-28 16:52 ` [PATCH 4/8] PCI: imx6: use new clock names Lucas Stach
2014-04-03 6:50 ` Shawn Guo
2014-04-03 8:21 ` Lucas Stach
[not found] ` <1396513265.5057.7.camel-WzVe3FnzCwFR6QfukMTsflXZhhPuCNm+@public.gmane.org>
2014-04-03 8:51 ` Lucas Stach
2014-03-28 16:52 ` [PATCH 7/8] PCI: designware: make MSI isr shared irq aware Lucas Stach
2014-04-28 2:14 ` Jingoo Han
2014-03-28 16:52 ` [PATCH 8/8] PCI: imx6: add support for MSI Lucas Stach
2014-03-30 17:41 ` [PATCH 0/8] i.MX6 PCIe binding change and MSI support Marek Vasut
2014-04-24 17:58 ` Bjorn Helgaas
2014-04-25 10:21 ` Lucas Stach
2014-04-25 14:39 ` Bjorn Helgaas
2014-04-25 15:04 ` Hong-Xing.Zhu
2014-04-29 12:31 ` Lucas Stach
2014-05-12 8:59 ` Lucas Stach
2014-05-27 14:02 ` Fabio Estevam
2014-05-30 17:30 ` Bjorn Helgaas
[not found] ` <20140530173053.GF4607-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2014-06-03 13:22 ` Lucas Stach
2014-06-03 14:50 ` Bjorn Helgaas
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=201403311136.49280.marex@denx.de \
--to=marex@denx.de \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=jg1.han@samsung.com \
--cc=kernel@pengutronix.de \
--cc=l.stach@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=r65037@freescale.com \
--cc=robh+dt@kernel.org \
--cc=shawn.guo@linaro.org \
--cc=tharvey@gateworks.com \
--cc=xobs@kosagi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).