On Monday, March 31, 2014 at 12:38:01 PM, Lucas Stach wrote:

Am Montag, den 31.03.2014, 11:36 +0200 schrieb Marek Vasut:

quoted

On Monday, March 31, 2014 at 11:28:29 AM, Lucas Stach wrote:

quoted

Am Sonntag, den 30.03.2014, 19:36 +0200 schrieb Marek Vasut:

quoted

On Friday, March 28, 2014 at 05:52:53 PM, Lucas Stach wrote:

quoted

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.

quoted

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.

It's the exact same behavior that you get on x86: all devices are
powered after boot, once you loaded a device driver it may choose to
turn the device off. I don't think it makes sense to deviate here for
the sake of being embedded and special.

quoted

quoted

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.

We could just add the regulator to the PCI hierarchy in the DT and
handle it similar to IRQs where we just walk up the DT starting from the
device until we find the matching IRQ/regulator.

Still for this to work with a regulator shared between several devices,
all the device drivers have to be aware of the regulator. Otherwise a
single device may choose to power down and erroneously cut power to a
sibling device, where the driver hasn't requested the regulator.

In all those scenarios the host controller driver still would not have
any business dealing with the regulator. Same situation as with the
legacy IRQs, that aren't handled by the host driver, but just routed to
the right instance through the DT.

OK, it all makes sense. What I find a bit unfortunate is that we loose the Plug-
n-Play nature of the PCIe here, but I guess that cannot be helped.