<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/arch/arm64/boot, branch dev-5.2</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.2</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.2'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2019-08-16T08:11:04+00:00</updated>
<entry>
<title>arm64: dts: imx8mq: fix SAI compatible</title>
<updated>2019-08-16T08:11:04+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>l.stach@pengutronix.de</email>
</author>
<published>2019-07-17T09:54:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=61146106b7388147abd5320dbc75b7fb3ea21ad6'/>
<id>urn:sha1:61146106b7388147abd5320dbc75b7fb3ea21ad6</id>
<content type='text'>
[ Upstream commit 8d0148473dece51675d11dd59b8db5fe4b5d2e7e ]

The i.MX8M SAI block is not compatible with the i.MX6SX one, as the
register layout has changed due to two version registers being added
at the beginning of the address map. Remove the bogus compatible.

Fixes: 8c61538dc945 ("arm64: dts: imx8mq: Add SAI2 node")
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Reviewed-by: Daniel Baluta &lt;daniel.baluta@nxp.com&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: dts: imx8mm: Correct SAI3 RXC/TXFS pin's mux option #1</title>
<updated>2019-08-16T08:11:03+00:00</updated>
<author>
<name>Anson Huang</name>
<email>Anson.Huang@nxp.com</email>
</author>
<published>2019-07-16T03:09:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=c577fb2c7b37c6230d9acf6195b352b5b2932ed9'/>
<id>urn:sha1:c577fb2c7b37c6230d9acf6195b352b5b2932ed9</id>
<content type='text'>
[ Upstream commit 52d09014bb104a9157c0f5530700291052d2955c ]

According to i.MX8MM reference manual Rev.1, 03/2019:

SAI3_RXC pin's mux option #1 should be GPT1_CLK, NOT GPT1_CAPTURE2;
SAI3_TXFS pin's mux option #1 should be GPT1_CAPTURE2, NOT GPT1_CLK.

Fixes: c1c9d41319c3 ("dt-bindings: imx: Add pinctrl binding doc for imx8mm")
Signed-off-by: Anson Huang &lt;Anson.Huang@nxp.com&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: dts: rockchip: Fix USB3 Type-C on rk3399-sapphire</title>
<updated>2019-08-06T17:08:06+00:00</updated>
<author>
<name>Vicente Bergas</name>
<email>vicencb@gmail.com</email>
</author>
<published>2019-06-27T13:12:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=9d3d7e8fc3652bb5399d4b0da506578d469ce30e'/>
<id>urn:sha1:9d3d7e8fc3652bb5399d4b0da506578d469ce30e</id>
<content type='text'>
[ Upstream commit e1d9149e8389f1690cdd4e4056766dd26488a0fe ]

Before this patch, the Type-C port on the Sapphire board is dead.
If setting the 'regulator-always-on' property to 'vcc5v0_typec0'
then the port works for about 4 seconds at start-up. This is a
sample trace with a memory stick plugged in:
1.- The memory stick LED lights on and kernel reports:
[    4.782999] scsi 0:0:0:0: Direct-Access USB DISK PMAP PQ: 0 ANSI: 4
[    5.904580] sd 0:0:0:0: [sdb] 3913344 512-byte logical blocks: (2.00 GB/1.87 GiB)
[    5.906860] sd 0:0:0:0: [sdb] Write Protect is off
[    5.908973] sd 0:0:0:0: [sdb] Mode Sense: 23 00 00 00
[    5.909122] sd 0:0:0:0: [sdb] No Caching mode page found
[    5.911214] sd 0:0:0:0: [sdb] Assuming drive cache: write through
[    5.951585]  sdb: sdb1
[    5.954816] sd 0:0:0:0: [sdb] Attached SCSI removable disk
2.- 4 seconds later the memory stick LED lights off and kernel reports:
[    9.082822] phy phy-ff770000.syscon:usb2-phy@e450.2: charger = USB_DCP_CHARGER
3.- After a minute the kernel reports:
[   71.666761] usb 5-1: USB disconnect, device number 2
It has been checked that, although the LED is off, VBUS is present.

If, instead, the dr_mode is changed to host and the phy-supply changed
accordingly, then it works. It has only been tested in host mode.

Signed-off-by: Vicente Bergas &lt;vicencb@gmail.com&gt;
Signed-off-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: qcom: qcs404: Add reset-cells to GCC node</title>
<updated>2019-08-06T17:08:05+00:00</updated>
<author>
<name>Andy Gross</name>
<email>agross@kernel.org</email>
</author>
<published>2019-06-09T04:19:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ad6c055cc8099719013331476de70e2bf31f293b'/>
<id>urn:sha1:ad6c055cc8099719013331476de70e2bf31f293b</id>
<content type='text'>
[ Upstream commit 0763d0c2273a3c72247d325c48fbac3d918d6b87 ]

This patch adds a reset-cells property to the gcc controller on the QCS404.
Without this in place, we get warnings like the following if nodes reference
a gcc reset:

arch/arm64/boot/dts/qcom/qcs404.dtsi:261.38-310.5: Warning (resets_property):
/soc@0/remoteproc@b00000: Missing property '#reset-cells' in node
/soc@0/clock-controller@1800000 or bad phandle (referred from resets[0])
  also defined at arch/arm64/boot/dts/qcom/qcs404-evb.dtsi:82.18-84.3
  DTC     arch/arm64/boot/dts/qcom/qcs404-evb-4000.dtb
arch/arm64/boot/dts/qcom/qcs404.dtsi:261.38-310.5: Warning (resets_property):
/soc@0/remoteproc@b00000: Missing property '#reset-cells' in node
/soc@0/clock-controller@1800000 or bad phandle (referred from resets[0])
  also defined at arch/arm64/boot/dts/qcom/qcs404-evb.dtsi:82.18-84.3

Signed-off-by: Andy Gross &lt;agross@kernel.org&gt;
Reviewed-by: Niklas Cassel &lt;niklas.cassel@linaro.org&gt;
Reviewed-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Olof Johansson &lt;olof@lixom.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: dts: rockchip: fix isp iommu clocks and power domain</title>
<updated>2019-08-06T17:08:04+00:00</updated>
<author>
<name>Helen Koike</name>
<email>helen.koike@collabora.com</email>
</author>
<published>2019-06-03T14:22:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=78431a1ce524921c9ef583c8ac540f2c7462ab5b'/>
<id>urn:sha1:78431a1ce524921c9ef583c8ac540f2c7462ab5b</id>
<content type='text'>
[ Upstream commit c432a29d3fc9ee928caeca2f5cf68b3aebfa6817 ]

isp iommu requires wrapper variants of the clocks.
noc variants are always on and using the wrapper variants will activate
{A,H}CLK_ISP{0,1} due to the hierarchy.

Tested using the pending isp patch set (which is not upstream
yet). Without this patch, streaming from the isp stalls.

Also add the respective power domain and remove the "disabled" status.

Refer:
 RK3399 TRM v1.4 Fig. 2-4 RK3399 Clock Architecture Diagram
 RK3399 TRM v1.4 Fig. 8-1 RK3399 Power Domain Partition

Signed-off-by: Helen Koike &lt;helen.koike@collabora.com&gt;
Tested-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Signed-off-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: dts: marvell: mcbin: enlarge PCI memory window</title>
<updated>2019-08-06T17:08:03+00:00</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>xypron.glpk@gmx.de</email>
</author>
<published>2019-05-17T16:11:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=5a90ad019dc4b57070f4c2f441fa798ecaae4837'/>
<id>urn:sha1:5a90ad019dc4b57070f4c2f441fa798ecaae4837</id>
<content type='text'>
[ Upstream commit d3446b266a8c72a7bbc94b65f5fc6d206be77d24 ]

Running a graphics adapter on the MACCHIATObin fails due to an
insufficiently sized memory window.

Enlarge the memory window for the PCIe slot to 512 MiB.

With the patch I am able to use a GT710 graphics adapter with 1 GB onboard
memory.

These are the mapped memory areas that the graphics adapter is actually
using:

Region 0: Memory at cc000000 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at c0000000 (64-bit, prefetchable) [size=128M]
Region 3: Memory at c8000000 (64-bit, prefetchable) [size=32M]
Region 5: I/O ports at 1000 [size=128]
Expansion ROM at ca000000 [disabled] [size=512K]

Signed-off-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
Signed-off-by: Gregory CLEMENT &lt;gregory.clement@bootlin.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: dts: qcom: qcs404-evb: fix l3 min voltage</title>
<updated>2019-08-06T17:08:02+00:00</updated>
<author>
<name>Niklas Cassel</name>
<email>niklas.cassel@linaro.org</email>
</author>
<published>2019-04-25T12:34:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=41979b6c0baae98abc4ed601ee6c03fd8850b9c2'/>
<id>urn:sha1:41979b6c0baae98abc4ed601ee6c03fd8850b9c2</id>
<content type='text'>
[ Upstream commit 887b528c958f40b064d53edd0bfa9fea3a69eccd ]

The current l3 min voltage level is not supported by
the regulator (the voltage is not a multiple of the regulator step size),
so a driver requesting this exact voltage would fail, see discussion in:
https://patchwork.kernel.org/comment/22461199/

It was agreed upon to set a min voltage level that is a multiple of the
regulator step size.

There was actually a patch sent that did this:
https://patchwork.kernel.org/patch/10819313/

However, the commit 331ab98f8c4a ("arm64: dts: qcom: qcs404:
Fix voltages l3") that was applied is not identical to that patch.

Signed-off-by: Niklas Cassel &lt;niklas.cassel@linaro.org&gt;
Signed-off-by: Bjorn Andersson &lt;bjorn.andersson@linaro.org&gt;
Signed-off-by: Andy Gross &lt;agross@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: tegra: Fix AGIC register range</title>
<updated>2019-07-26T07:11:00+00:00</updated>
<author>
<name>Jon Hunter</name>
<email>jonathanh@nvidia.com</email>
</author>
<published>2019-06-20T08:17:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=f9458d66de53f13f0c33dddb1163f7c6d2499c0f'/>
<id>urn:sha1:f9458d66de53f13f0c33dddb1163f7c6d2499c0f</id>
<content type='text'>
commit ba24eee6686f6ed3738602b54d959253316a9541 upstream.

The Tegra AGIC interrupt controller is an ARM GIC400 interrupt
controller. Per the ARM GIC device-tree binding, the first address
region is for the GIC distributor registers and the second address
region is for the GIC CPU interface registers. The address space for
the distributor registers is 4kB, but currently this is incorrectly
defined as 8kB for the Tegra AGIC and overlaps with the CPU interface
registers. Correct the address space for the distributor to be 4kB.

Cc: stable@vger.kernel.org
Signed-off-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Fixes: bcdbde433542 ("arm64: tegra: Add AGIC node for Tegra210")
Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arm64: tegra: Fix Jetson Nano GPU regulator</title>
<updated>2019-07-26T07:10:53+00:00</updated>
<author>
<name>Jon Hunter</name>
<email>jonathanh@nvidia.com</email>
</author>
<published>2019-06-20T08:17:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=5ba8c02c299dbf452e8de07a866cc5d78130c5ea'/>
<id>urn:sha1:5ba8c02c299dbf452e8de07a866cc5d78130c5ea</id>
<content type='text'>
commit 434e8aedeaec595933811c2af191db9f11d3ce3b upstream.

There are a few issues with the GPU regulator defined for Jetson Nano
which are:

1. The GPU regulator is a PWM based regulator and not a fixed voltage
   regulator.
2. The output voltages for the GPU regulator are not correct.
3. The regulator enable ramp delay is too short for the regulator and
   needs to be increased. 2ms should be sufficient.
4. This is the same regulator used on Jetson TX1 and so make the ramp
   delay and settling time the same as Jetson TX1.

Cc: stable@vger.kernel.org
Signed-off-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Fixes: 6772cd0eacc8 ("arm64: tegra: Add NVIDIA Jetson Nano Developer Kit support")
Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arm64: tegra: Update Jetson TX1 GPU regulator timings</title>
<updated>2019-07-26T07:10:53+00:00</updated>
<author>
<name>Jon Hunter</name>
<email>jonathanh@nvidia.com</email>
</author>
<published>2019-06-20T08:17:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=57a9365708306734a4f2ea087a7f1c4cee9ece56'/>
<id>urn:sha1:57a9365708306734a4f2ea087a7f1c4cee9ece56</id>
<content type='text'>
commit ece6031ece2dd64d63708cfe1088016cee5b10c0 upstream.

The GPU regulator enable ramp delay for Jetson TX1 is set to 1ms which
not sufficient because the enable ramp delay has been measured to be
greater than 1ms. Furthermore, the downstream kernels released by NVIDIA
for Jetson TX1 are using a enable ramp delay 2ms and a settling delay of
160us. Update the GPU regulator enable ramp delay for Jetson TX1 to be
2ms and add a settling delay of 160us.

Cc: stable@vger.kernel.org
Signed-off-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Fixes: 5e6b9a89afce ("arm64: tegra: Add VDD_GPU regulator to Jetson TX1")
Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
