[PATCH v2 1/2] arm64: dts: marvell: add CP110 uart peripherals

Hi,
 
 On mer., f?vr. 14 2018, Russell King - ARM Linux [off-list ref] wrote:

On Wed, Feb 14, 2018 at 01:17:45PM +0200, Baruch Siach wrote:

quoted

Hi Ressell,

On Wed, Feb 14, 2018 at 11:07:51AM +0000, Russell King - ARM Linux wrote:

quoted

On Wed, Feb 14, 2018 at 12:56:53PM +0200, Baruch Siach wrote:

quoted

On Wed, Feb 14, 2018 at 11:42:52AM +0100, Gregory CLEMENT wrote:

quoted

 On mer., janv. 31 2018, Baruch Siach [off-list ref] wrote:

quoted

The CP110 component has 4 uart peripherals. All of them use the same clock
gate for slow peripherals that is shared with the i2c and spi peripherals.

Signed-off-by: Baruch Siach <baruch@tkos.co.il>

Applied on mvebu/dt64

Thanks.

What about patch 2/2 in this series?

I'm not entirely convinced that it's something that should be done.
I know that some people are already using the UART headers for other
purposes (other than UART) and the later revision boards have the
placement of the microUSB fixed so it is accessible.

While you can tell Linux to use the other UART headers with this
patch, uboot won't use them, which means you can't configure the
boot loader without (in your case) taking the board out of the case.

I've a similar problem (with the mcbin in a rackmount case), and my
solution to that has been to put a single washer under the mounting
post near the microUSB to lift the board sufficiently to allow a
connector to be plugged in.  Sometimes simple hardware fixes are
better than software fixes.

Others have used a dremel to modify the case to access the microUSB.

Just for the record, I'm fine with dropping 'status = "okay"' from the mcbin 
CP{0,1} UART nodes. This would still allow anyone who needs this functionality 
to enable it with a simple .dts modification, or a run-time dtb modification 
from the bootloader.

Talking more with Jon (who works for SolidRun, the board manufacturer),
the feeling there is:

1. Why enable both UART headers - it makes more sense (given your reason)
   to enable one as UART but keep the other as GPIO.  The labelling up of
   them being a UART is merely a historical artifact of the very early
   development of the board.

2. They are developer boards, not a final product.  Case modification is
   somewhat expected.

Just to let know that I applied the patch but I still can either ammend
it or drop it as it is not yet part of an immutable tag.

Once you will have agreed I will do the change.

Gregory

(2) is especially relevant when SFP support gets added - some of the
early revision boards have the SCL/SDA lines swapped on the I2C bus.
With that fixed, all boards have way too strong pull-ups on the I2C
bus which means some modules don't work - and worse than that, may
result in corrupted module EEPROMs.

I ended up with corruption here, and although I've a rev 1.3 board now,
I'm still using my self-modified rev 1.1 in preference to it, because
I don't want to have to deal with another corrupted EEPROM.

In order for SFP to be reliably functional, board modification is
required (either replacement of resistor packs, or in the case of the
early boards, cutting the I2C lines and rewiring them.)

IOW, board modification will be required for SFP on most mcbins.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

-- 
Gregory Clement, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com