From: gregory.clement@bootlin•com (Gregory CLEMENT)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v2 1/2] arm64: dts: marvell: add CP110 uart peripherals
Date: Wed, 14 Feb 2018 13:14:34 +0100 [thread overview]
Message-ID: <87bmgrojit.fsf@bootlin.com> (raw)
In-Reply-To: <20180214113045.GQ9418@n2100.armlinux.org.uk> (Russell King's message of "Wed, 14 Feb 2018 11:30:45 +0000")
Hi,
On mer., f?vr. 14 2018, Russell King - ARM Linux <linux@armlinux•org.uk> wrote:
> On Wed, Feb 14, 2018 at 01:17:45PM +0200, Baruch Siach wrote:
>> Hi Ressell,
>>
>> On Wed, Feb 14, 2018 at 11:07:51AM +0000, Russell King - ARM Linux wrote:
>> > On Wed, Feb 14, 2018 at 12:56:53PM +0200, Baruch Siach wrote:
>> > > On Wed, Feb 14, 2018 at 11:42:52AM +0100, Gregory CLEMENT wrote:
>> > > > On mer., janv. 31 2018, Baruch Siach <baruch@tkos•co.il> wrote:
>> > > >
>> > > > > 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
prev parent reply other threads:[~2018-02-14 12:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-31 6:56 [PATCH v2 1/2] arm64: dts: marvell: add CP110 uart peripherals Baruch Siach
2018-01-31 6:56 ` [PATCH v2 2/2] arm64: dts: marvell: mcbin: enable uart headers Baruch Siach
2018-02-14 11:06 ` Gregory CLEMENT
2018-02-14 10:42 ` [PATCH v2 1/2] arm64: dts: marvell: add CP110 uart peripherals Gregory CLEMENT
2018-02-14 10:42 ` Gregory CLEMENT
2018-02-14 10:56 ` Baruch Siach
2018-02-14 11:07 ` Gregory CLEMENT
2018-02-14 11:07 ` Russell King - ARM Linux
2018-02-14 11:17 ` Baruch Siach
2018-02-14 11:30 ` Russell King - ARM Linux
2018-02-14 12:14 ` Gregory CLEMENT [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bmgrojit.fsf@bootlin.com \
--to=gregory.clement@bootlin$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox