From: Andre Przywara <andre.przywara@arm.com> Date: 2021-01-06 15:06:40
In recent Allwinner SoCs the first USB host controller (HCI0) shares
the first PHY with the MUSB controller. Probably to make this sharing
work, we were avoiding to declare this in the DT. This has two
shortcomings:
- U-Boot (which uses the same .dts) cannot use this port in host mode
without a PHY linked, so we were loosing one USB port there.
- It requires the MUSB driver to be enabled and loaded, although we
don't actually use it.
To avoid those issues, let's add this PHY link to the A64 and H6 .dtsi
files. After all PHY port 0 *is* connected to HCI0, so we should describe
it as this. Remove the part from the boards which were already doing
that.
This makes it work in U-Boot, also improves compatiblity when no MUSB
driver is loaded (for instance in distribution installers).
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts | 4 ----
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 4 ++++
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 4 ++++
3 files changed, 8 insertions(+), 4 deletions(-)
From: Andre Przywara <andre.przywara@arm.com> Date: 2021-01-06 15:06:41
The Pine64-LTS board features a blue status LED on pin PL7.
Describe it in the DT.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
.../boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 11 +++++++++++
1 file changed, 11 insertions(+)
From: Andre Przywara <andre.przywara@arm.com> Date: 2021-01-06 15:06:43
The SD card on the SoPine SoM module is somewhat concealed, so was
originally defined as "non-removable".
However there is a working card-detect pin, and in certain SoM base
boards it might be actually accessible at runtime.
Also the Pine64-LTS shares the SoPine base .dtsi, so inherited the
non-removable flag, even though the SD card slot is perfectly accessible
and usable there. (It turns out that just *my* board has a broken card
detect switch, so I originally thought CD wouldn't work on the LTS.)
Drop the "non-removable" flag to describe the SD card slot properly.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi | 1 -
1 file changed, 1 deletion(-)
From: Andre Przywara <andre.przywara@arm.com> Date: 2021-01-06 15:06:44
The H6 manual explicitly lists a frequency limit of 150 MHz for the bus
frequency of the MMC controllers. So far we had no explicit limits in the
DT, which limited eMMC to a rather conservative 52 MHz.
Put those maximum frequencies in the SoC .dtsi, to allow higher speed
modes (which still would need to be explicitly enabled, per board).
Tested with an eMMC using HS-200 on a Pine H64. Running at the spec'ed
200 MHz indeed fails with I/O errors, but 150 MHz seems to work stably.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 3 +++
1 file changed, 3 insertions(+)
From: Andre Przywara <andre.przywara@arm.com> Date: 2021-01-06 15:07:24
In contrast to the H6 (and later) manuals, the A64 datasheet does not
specify any limitations in the maximum possible frequency for eMMC
controllers.
However experimentation has found that a 150 MHz limit similar to other
SoCs and also the MMC0 and MMC1 controllers on the A64 seems to exist
for the MMC2 controller.
Limit the frequency for the MMC2 controller to 150 MHz in the SoC .dtsi.
The Pinebook seems to be the an odd exception, since it apparently seems
to work with 200 MHz as well, so overwrite this in its board .dts file.
Tested on a Pine64-LTS: 200 MHz HS-200 fails, 150 MHz HS-200 works.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts | 1 +
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
From: Andre Przywara <andre.przywara@arm.com> Date: 2021-01-06 15:07:24
The eMMC modules offered for the Pine64 boards are capable of the HS200
eMMC speed mode, when observing the frequency limit of 150 MHz.
Enable that in the DT.
This increases the interface speed from ~80 MB/s to ~120 MB/s.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-sopine-baseboard.dts | 1 +
1 file changed, 1 insertion(+)
From: Andre Przywara <andre.przywara@arm.com> Date: 2021-01-06 15:07:26
The eMMC modules offered for the Pine64 boards are capable of the HS200
eMMC speed mode, when observing the frequency limit of 150 MHz.
Enable that in the DT.
This increases the interface speed from ~80 MB/s to ~120 MB/s.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts | 1 +
1 file changed, 1 insertion(+)
Hi,
On Wed, Jan 6, 2021 at 11:05 PM Andre Przywara [off-list ref] wrote:
The Pine64-LTS board features a blue status LED on pin PL7.
I'd like some clarification about this.
My Pine64-LTS was a used unit personally given to me by TL Lim, which came
with LEDs that I assume were soldered on by hand as their mounting angles
are slightly off. My Pine64+ (the original from the Kickstarter campaign)
and SoPine baseboard (a new unit, also given to me by TL Lim) came without
LEDs soldered on.
I'm OK with adding the LED to the device tree. I'm just not sure about the
color.
ChenYu
quoted hunk
Describe it in the DT.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
.../boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 11 +++++++++++
1 file changed, 11 insertions(+)
Hi,
On Wed, Jan 6, 2021 at 11:05 PM Andre Przywara [off-list ref] wrote:
In recent Allwinner SoCs the first USB host controller (HCI0) shares
the first PHY with the MUSB controller. Probably to make this sharing
work, we were avoiding to declare this in the DT. This has two
shortcomings:
- U-Boot (which uses the same .dts) cannot use this port in host mode
without a PHY linked, so we were loosing one USB port there.
- It requires the MUSB driver to be enabled and loaded, although we
don't actually use it.
To avoid those issues, let's add this PHY link to the A64 and H6 .dtsi
files. After all PHY port 0 *is* connected to HCI0, so we should describe
it as this. Remove the part from the boards which were already doing
that.
This makes it work in U-Boot, also improves compatiblity when no MUSB
driver is loaded (for instance in distribution installers).
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts | 4 ----
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 4 ++++
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 4 ++++
It would be better if the H6 parts were separated out.
Please also add a fixes tag, which helps with backporting.
On Wed, Jan 6, 2021 at 11:05 PM Andre Przywara [off-list ref] wrote:
The SD card on the SoPine SoM module is somewhat concealed, so was
originally defined as "non-removable".
However there is a working card-detect pin, and in certain SoM base
boards it might be actually accessible at runtime.
Also the Pine64-LTS shares the SoPine base .dtsi, so inherited the
non-removable flag, even though the SD card slot is perfectly accessible
and usable there. (It turns out that just *my* board has a broken card
detect switch, so I originally thought CD wouldn't work on the LTS.)
Drop the "non-removable" flag to describe the SD card slot properly.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Please add a fixes tag. This helps with finding the original commit
that introduced the issue and backporting.
ChenYu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Jan 6, 2021 at 11:06 PM Andre Przywara [off-list ref] wrote:
In contrast to the H6 (and later) manuals, the A64 datasheet does not
specify any limitations in the maximum possible frequency for eMMC
controllers.
However experimentation has found that a 150 MHz limit similar to other
SoCs and also the MMC0 and MMC1 controllers on the A64 seems to exist
for the MMC2 controller.
Limit the frequency for the MMC2 controller to 150 MHz in the SoC .dtsi.
The Pinebook seems to be the an odd exception, since it apparently seems
to work with 200 MHz as well, so overwrite this in its board .dts file.
Tested on a Pine64-LTS: 200 MHz HS-200 fails, 150 MHz HS-200 works.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Please add a fixes tag. This helps with finding the original commit
that introduced the issue and backporting.
This would benefit SoPine / Pine64-LTS users that are using eMMC.
ChenYu
On Wed, Jan 6, 2021 at 11:06 PM Andre Przywara [off-list ref] wrote:
The eMMC modules offered for the Pine64 boards are capable of the HS200
eMMC speed mode, when observing the frequency limit of 150 MHz.
Enable that in the DT.
This increases the interface speed from ~80 MB/s to ~120 MB/s.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
On Wed, Jan 6, 2021 at 11:06 PM Andre Przywara [off-list ref] wrote:
The eMMC modules offered for the Pine64 boards are capable of the HS200
eMMC speed mode, when observing the frequency limit of 150 MHz.
Enable that in the DT.
This increases the interface speed from ~80 MB/s to ~120 MB/s.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
From: Maxime Ripard <hidden> Date: 2021-01-06 16:02:29
On Wed, Jan 06, 2021 at 03:05:20PM +0000, Andre Przywara wrote:
quoted hunk
The Pine64-LTS board features a blue status LED on pin PL7.
Describe it in the DT.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
.../boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 11 +++++++++++
1 file changed, 11 insertions(+)
On Wed, Jan 6, 2021 at 11:06 PM Andre Przywara [off-list ref] wrote:
The H6 manual explicitly lists a frequency limit of 150 MHz for the bus
frequency of the MMC controllers. So far we had no explicit limits in the
DT, which limited eMMC to a rather conservative 52 MHz.
I'd say this is implementation specific. FreeBSD might have other defaults?
Put those maximum frequencies in the SoC .dtsi, to allow higher speed
modes (which still would need to be explicitly enabled, per board).
Tested with an eMMC using HS-200 on a Pine H64. Running at the spec'ed
200 MHz indeed fails with I/O errors, but 150 MHz seems to work stably.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
From: André Przywara <andre.przywara@arm.com> Date: 2021-01-06 16:09:55
On 06/01/2021 15:53, Chen-Yu Tsai wrote:
Hi,
On Wed, Jan 6, 2021 at 11:05 PM Andre Przywara [off-list ref] wrote:
quoted
The Pine64-LTS board features a blue status LED on pin PL7.
I'd like some clarification about this.
My Pine64-LTS was a used unit personally given to me by TL Lim, which came
with LEDs that I assume were soldered on by hand as their mounting angles
are slightly off. My Pine64+ (the original from the Kickstarter campaign)
and SoPine baseboard (a new unit, also given to me by TL Lim) came without
LEDs soldered on.
The situation is similar here ;-), and that's why I checked the pictures
in the store. The LEDs look slightly different (not angled), but the
location of the pads is the same and I see two LEDs on the picture. The
schematic seems to confirm both the pins, the polarity and the colour.
Hence I am highly confident that it's a blue LED on PL7, active low.
But we can wait for other people to confirm.
Thanks!
Andre
I'm OK with adding the LED to the device tree. I'm just not sure about the
color.
ChenYu
quoted
Describe it in the DT.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
.../boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 11 +++++++++++
1 file changed, 11 insertions(+)
From: André Przywara <andre.przywara@arm.com> Date: 2021-01-13 10:31:40
On 06/01/2021 15:56, Chen-Yu Tsai wrote:
Hi,
On Wed, Jan 6, 2021 at 11:05 PM Andre Przywara [off-list ref] wrote:
quoted
In recent Allwinner SoCs the first USB host controller (HCI0) shares
the first PHY with the MUSB controller. Probably to make this sharing
work, we were avoiding to declare this in the DT. This has two
shortcomings:
- U-Boot (which uses the same .dts) cannot use this port in host mode
without a PHY linked, so we were loosing one USB port there.
- It requires the MUSB driver to be enabled and loaded, although we
don't actually use it.
To avoid those issues, let's add this PHY link to the A64 and H6 .dtsi
files. After all PHY port 0 *is* connected to HCI0, so we should describe
it as this. Remove the part from the boards which were already doing
that.
This makes it work in U-Boot, also improves compatiblity when no MUSB
driver is loaded (for instance in distribution installers).
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts | 4 ----
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 4 ++++
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 4 ++++
It would be better if the H6 parts were separated out.
Sure.
Please also add a fixes tag, which helps with backporting.
The whole concept of DT backports raises some eyebrows here, but it's
surely easy enough to do.
Thanks,
Andre.
On Wed, Jan 13, 2021 at 6:30 PM André Przywara [off-list ref] wrote:
On 06/01/2021 15:56, Chen-Yu Tsai wrote:
quoted
Hi,
On Wed, Jan 6, 2021 at 11:05 PM Andre Przywara [off-list ref] wrote:
quoted
In recent Allwinner SoCs the first USB host controller (HCI0) shares
the first PHY with the MUSB controller. Probably to make this sharing
work, we were avoiding to declare this in the DT. This has two
shortcomings:
- U-Boot (which uses the same .dts) cannot use this port in host mode
without a PHY linked, so we were loosing one USB port there.
- It requires the MUSB driver to be enabled and loaded, although we
don't actually use it.
To avoid those issues, let's add this PHY link to the A64 and H6 .dtsi
files. After all PHY port 0 *is* connected to HCI0, so we should describe
it as this. Remove the part from the boards which were already doing
that.
This makes it work in U-Boot, also improves compatiblity when no MUSB
driver is loaded (for instance in distribution installers).
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts | 4 ----
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 4 ++++
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 4 ++++
It would be better if the H6 parts were separated out.
Sure.
quoted
Please also add a fixes tag, which helps with backporting.
The whole concept of DT backports raises some eyebrows here, but it's
surely easy enough to do.
Well, whether people choose to backport is their decision. But providing
information used to decide whether to do so, and if yes, what else is
needed, is IMHO something the author can help with.
Likely backport scenarios are distribution kernels AFAICT.
ChenYu
On Wed, 6 Jan 2021 16:08:30 +0000
André Przywara [off-list ref] wrote:
On 06/01/2021 15:53, Chen-Yu Tsai wrote:
Hi,
quoted
On Wed, Jan 6, 2021 at 11:05 PM Andre Przywara [off-list ref] wrote:
quoted
The Pine64-LTS board features a blue status LED on pin PL7.
I'd like some clarification about this.
My Pine64-LTS was a used unit personally given to me by TL Lim, which came
with LEDs that I assume were soldered on by hand as their mounting angles
are slightly off. My Pine64+ (the original from the Kickstarter campaign)
and SoPine baseboard (a new unit, also given to me by TL Lim) came without
LEDs soldered on.
The situation is similar here ;-), and that's why I checked the pictures
in the store. The LEDs look slightly different (not angled), but the
location of the pads is the same and I see two LEDs on the picture. The
schematic seems to confirm both the pins, the polarity and the colour.
Hence I am highly confident that it's a blue LED on PL7, active low.
But we can wait for other people to confirm.
Thanks!
Andre
I have three boards :
- Pine64, no led (bought after the kickstarter)
- A64-LTS, blue color, and active low, no weird mounting angles here
(don't remember if I bought this one or not)
- Sopine Baseboard, no led (definitly bought this myself)
quoted
I'm OK with adding the LED to the device tree. I'm just not sure about the
color.
ChenYu
quoted
Describe it in the DT.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
.../boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 11 +++++++++++
1 file changed, 11 insertions(+)