<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/drivers/pci, branch v2016.07</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>pci: tegra: actually program REFCLK_CFG* on recent SoCs</title>
<updated>2016-07-05T18:14:32+00:00</updated>
<author>
<name>Stephen Warren</name>
<email>swarren@nvidia.com</email>
</author>
<published>2016-06-24T14:36:04+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=f39a6a327721285aa68f7e4d57b887c165ed3f14'/>
<id>f39a6a327721285aa68f7e4d57b887c165ed3f14</id>
<content type='text'>
On recent SoCs, tegra_pcie_phy_enable() isn't called; but instead
tegra_pcie_enable_controller() calls tegra_xusb_phy_enable(). However,
part of tegra_pcie_phy_enable() needs to happen in all cases. Move that
code to tegra_pcie_port_enable() instead.

For reference, NVIDIA's downstream Linux kernel performs this operation
in tegra_pcie_enable_rp_features(), which is called immediately after
tegra_pcie_port_enable(). Since that function doesn't exist in the U-Boot
driver, we'll just add it to the tail of tegra_pcie_port_enable() instead.

Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Signed-off-by: Tom Warren &lt;twarren@nvidia.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On recent SoCs, tegra_pcie_phy_enable() isn't called; but instead
tegra_pcie_enable_controller() calls tegra_xusb_phy_enable(). However,
part of tegra_pcie_phy_enable() needs to happen in all cases. Move that
code to tegra_pcie_port_enable() instead.

For reference, NVIDIA's downstream Linux kernel performs this operation
in tegra_pcie_enable_rp_features(), which is called immediately after
tegra_pcie_port_enable(). Since that function doesn't exist in the U-Boot
driver, we'll just add it to the tail of tegra_pcie_port_enable() instead.

Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Signed-off-by: Tom Warren &lt;twarren@nvidia.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>pci: tegra: correctly program PADS_REFCLK registers</title>
<updated>2016-07-05T18:14:32+00:00</updated>
<author>
<name>Stephen Warren</name>
<email>swarren@nvidia.com</email>
</author>
<published>2016-06-21T18:47:51+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3cfc6be4a85c722e9e0a657c7696f5fa1ac2ed48'/>
<id>3cfc6be4a85c722e9e0a657c7696f5fa1ac2ed48</id>
<content type='text'>
The value that should be programmed into the PADS_REFCLK register varies
per SoC. Fix the Tegra PCIe driver to program the correct values. Future
SoCs will require different values in cfg0/1, so the two values are stored
separately in the per-SoC data structures.

For reference, the values are all documented in NV bug 1771116 comment 20.
The Tegra210 value doesn't match the current TRM, but I've filed a bug to
get the TRM fixed. Earlier TRMs don't document the value this register
should contain, but the ASIC team has validated all these values, except
for the Tegra20 value which is simply left unchanged in this patch.

Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Signed-off-by: Tom Warren &lt;twarren@nvidia.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The value that should be programmed into the PADS_REFCLK register varies
per SoC. Fix the Tegra PCIe driver to program the correct values. Future
SoCs will require different values in cfg0/1, so the two values are stored
separately in the per-SoC data structures.

For reference, the values are all documented in NV bug 1771116 comment 20.
The Tegra210 value doesn't match the current TRM, but I've filed a bug to
get the TRM fixed. Earlier TRMs don't document the value this register
should contain, but the ASIC team has validated all these values, except
for the Tegra20 value which is simply left unchanged in this patch.

Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Signed-off-by: Tom Warren &lt;twarren@nvidia.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>pcie/layerscape: fix bug in bus number computation when setting msi-map</title>
<updated>2016-06-03T21:12:10+00:00</updated>
<author>
<name>Bogdan Purcareata</name>
<email>bogdan.purcareata@nxp.com</email>
</author>
<published>2016-05-17T07:18:40+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3378727d13dac410d8ef2d8426d4c9bfc4974405'/>
<id>3378727d13dac410d8ef2d8426d4c9bfc4974405</id>
<content type='text'>
When multiple PCI cards are present in an ls2080a board, the second
card does not get its msi-map set up properly due to a bug in
computing the bus number.

The bus number returned by PCI_BDF() is not the actual PCI bus
number, but instead represents a global u-boot PCI bus number. A
given bus number is relative to hose-&gt;first_busno, so that has to be
subtracted from the PCI device id.

Signed-off-by: Bogdan Purcareata &lt;bogdan.purcareata@nxp.com&gt;
Acked-by: Stuart Yoder &lt;stuart.yoder@nxp.com&gt;
Reviewed-by: York Sun &lt;york.sun@nxp.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When multiple PCI cards are present in an ls2080a board, the second
card does not get its msi-map set up properly due to a bug in
computing the bus number.

The bus number returned by PCI_BDF() is not the actual PCI bus
number, but instead represents a global u-boot PCI bus number. A
given bus number is relative to hose-&gt;first_busno, so that has to be
subtracted from the PCI device id.

Signed-off-by: Bogdan Purcareata &lt;bogdan.purcareata@nxp.com&gt;
Acked-by: Stuart Yoder &lt;stuart.yoder@nxp.com&gt;
Reviewed-by: York Sun &lt;york.sun@nxp.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>pci: Drop CONFIG_SYS_SCSI_SCAN_BUS_REVERSE</title>
<updated>2016-05-17T15:54:43+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2016-05-01T17:35:51+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=cf63084492377108698619f6d33967af2119e584'/>
<id>cf63084492377108698619f6d33967af2119e584</id>
<content type='text'>
This option is not used by any board. Drop it.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This option is not used by any board. Drop it.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>pci: tegra: fix DM conversion issues on Tegra20</title>
<updated>2016-05-04T20:31:04+00:00</updated>
<author>
<name>Stephen Warren</name>
<email>swarren@nvidia.com</email>
</author>
<published>2016-04-20T21:46:50+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=f5c6db84e71c60bfc7ae746bfb2cd1090d0b8765'/>
<id>f5c6db84e71c60bfc7ae746bfb2cd1090d0b8765</id>
<content type='text'>
Tegra20's PCIe controller has a couple of quirks. There are workarounds in
the driver for these, but they don't work after the DM conversion:

1) The PCI_CLASS value is wrong in HW.

This is worked around in pci_tegra_read_config() by patching up the value
read from that register. Pre-DM, the PCIe core always read this via a
16-bit access to the 16-bit offset 0xa. With DM, 32-bit accesses are used,
so we need to check for offset 0x8 instead. Mask the offset value back to
32-bit alignment to make this work in all cases.

2) Accessing devices other than dev 1 causes a data abort.

Pre-DM, this was worked around in pci_skip_dev(), which the PCIe core code
called during enumeration while iterating over a bus. The DM PCIe core
doesn't use this function. Instead, enhance tegra_pcie_conf_address() to
validate the bdf being accessed, and refuse to access invalid devices.
Since pci_skip_dev() isn't used, delete it.

I've also validated that both these WARs are only needed for Tegra20, by
testing on Tegra30/Cardhu and Tegra124/Jetson TKx. So, compile them in
conditionally.

Fixes: e81ca88451cf ("dm: tegra: pci: Convert tegra boards to driver model for PCI")
Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Reviewed-by: Thierry Reding &lt;treding@nvidia.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Signed-off-by: Tom Warren &lt;twarren@nvidia.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Tegra20's PCIe controller has a couple of quirks. There are workarounds in
the driver for these, but they don't work after the DM conversion:

1) The PCI_CLASS value is wrong in HW.

This is worked around in pci_tegra_read_config() by patching up the value
read from that register. Pre-DM, the PCIe core always read this via a
16-bit access to the 16-bit offset 0xa. With DM, 32-bit accesses are used,
so we need to check for offset 0x8 instead. Mask the offset value back to
32-bit alignment to make this work in all cases.

2) Accessing devices other than dev 1 causes a data abort.

Pre-DM, this was worked around in pci_skip_dev(), which the PCIe core code
called during enumeration while iterating over a bus. The DM PCIe core
doesn't use this function. Instead, enhance tegra_pcie_conf_address() to
validate the bdf being accessed, and refuse to access invalid devices.
Since pci_skip_dev() isn't used, delete it.

I've also validated that both these WARs are only needed for Tegra20, by
testing on Tegra30/Cardhu and Tegra124/Jetson TKx. So, compile them in
conditionally.

Fixes: e81ca88451cf ("dm: tegra: pci: Convert tegra boards to driver model for PCI")
Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Reviewed-by: Thierry Reding &lt;treding@nvidia.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Signed-off-by: Tom Warren &lt;twarren@nvidia.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>pci: Device scanning range fix</title>
<updated>2016-04-25T19:10:43+00:00</updated>
<author>
<name>Yoshinori Sato</name>
<email>ysato@users.sourceforge.jp</email>
</author>
<published>2016-04-25T06:41:01+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=6d9f5b035d73129fe0ba4c0d28af55ee565e2490'/>
<id>6d9f5b035d73129fe0ba4c0d28af55ee565e2490</id>
<content type='text'>
The terminal condition in the area where a PCI device is scanned is wrong,
and 1f.7 isn't scanned.

Signed-off-by: Yoshinori Sato &lt;ysato@users.sourceforge.jp&gt;
Reviewed-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The terminal condition in the area where a PCI device is scanned is wrong,
and 1f.7 isn't scanned.

Signed-off-by: Yoshinori Sato &lt;ysato@users.sourceforge.jp&gt;
Reviewed-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>pci/layerscape: set LUT and msi-map for discovered PCI devices</title>
<updated>2016-03-21T19:42:13+00:00</updated>
<author>
<name>Stuart Yoder</name>
<email>stuart.yoder@nxp.com</email>
</author>
<published>2016-03-10T16:52:30+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=5e8e27b743a650aebc3d79823cbd8443ca12d4b8'/>
<id>5e8e27b743a650aebc3d79823cbd8443ca12d4b8</id>
<content type='text'>
msi-map properties are used to tell an OS how PCI requester IDs are
mapped to ARM SMMU stream IDs.

for all PCI devices discovered in a system:
  -allocate a LUT (look-up-table) entry in that PCI controller
  -allocate a stream ID for the device
  -program and enable a LUT entry (maps PCI requester id to stream ID)
  -set the msi-map property on the controller reflecting the
   LUT mapping

basic bus scanning loop/logic was taken from drivers/pci/pci.c
pci_hose_scan_bus().

Signed-off-by: Stuart Yoder &lt;stuart.yoder@nxp.com&gt;
Reviewed-by: York Sun &lt;york.sun@nxp.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
msi-map properties are used to tell an OS how PCI requester IDs are
mapped to ARM SMMU stream IDs.

for all PCI devices discovered in a system:
  -allocate a LUT (look-up-table) entry in that PCI controller
  -allocate a stream ID for the device
  -program and enable a LUT entry (maps PCI requester id to stream ID)
  -set the msi-map property on the controller reflecting the
   LUT mapping

basic bus scanning loop/logic was taken from drivers/pci/pci.c
pci_hose_scan_bus().

Signed-off-by: Stuart Yoder &lt;stuart.yoder@nxp.com&gt;
Reviewed-by: York Sun &lt;york.sun@nxp.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>armv8: ls2080a: remove obsolete stream ID partitioning support</title>
<updated>2016-03-21T19:42:12+00:00</updated>
<author>
<name>Stuart Yoder</name>
<email>stuart.yoder@nxp.com</email>
</author>
<published>2016-03-10T16:52:01+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=2d97fbb4c4c7c576b224aaa38465816e0edbd4d6'/>
<id>2d97fbb4c4c7c576b224aaa38465816e0edbd4d6</id>
<content type='text'>
Remove stream ID partitioning support that has been made
obsolete by upstream device tree bindings that specify how
representing how PCI requester IDs are mapped to MSI specifiers
and SMMU stream IDs.

Signed-off-by: Stuart Yoder &lt;stuart.yoder@nxp.com&gt;
Reviewed-by: York Sun &lt;york.sun@nxp.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove stream ID partitioning support that has been made
obsolete by upstream device tree bindings that specify how
representing how PCI requester IDs are mapped to MSI specifiers
and SMMU stream IDs.

Signed-off-by: Stuart Yoder &lt;stuart.yoder@nxp.com&gt;
Reviewed-by: York Sun &lt;york.sun@nxp.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>pci: Correct a few comments and nits</title>
<updated>2016-03-17T02:27:23+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2016-03-07T02:27:53+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=4974a6ff048fecba6077bf3101c6aba830e038c7'/>
<id>4974a6ff048fecba6077bf3101c6aba830e038c7</id>
<content type='text'>
Two comments are missing a parameter and there is an extra blank line. Also
two of the region access macros are misnamed. Correct these problems.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Two comments are missing a parameter and there is an extra blank line. Also
two of the region access macros are misnamed. Correct these problems.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>pci: Add functions to update PCI configuration registers</title>
<updated>2016-03-17T02:27:23+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2016-03-07T02:27:52+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=319dba1f4d7bf2c82be1c5b0858c4b1c3d8b4cfe'/>
<id>319dba1f4d7bf2c82be1c5b0858c4b1c3d8b4cfe</id>
<content type='text'>
It is common to read a config register value, clear and set some bits, then
write back the updated value. Add functions to do this in one step, for
convenience.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It is common to read a config register value, clear and set some bits, then
write back the updated value. Add functions to do this in one step, for
convenience.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
