Received-SPF: pass (google.com: domain of linux-kernel+bounces-7482-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Wed, 20 Dec 2023 22:49:33 +0100
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: Gregory CLEMENT <gregory.clement@bootlin.com>
Cc: Paul Burton <paulburton@kernel.org>, linux-mips@vger.kernel.org,
	Jiaxun Yang <jiaxun.yang@flygoat.com>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>,
	Tawfik Bayouk <tawfik.bayouk@mobileye.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	=?iso-8859-1?Q?Th=E9o?= Lebrun <theo.lebrun@bootlin.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v5 00/22] Add support for the Mobileye EyeQ5 SoC
Message-ID: <ZYNhbQjMbAH6I0kI@alpha.franken.de>
References: <20231212163459.1923041-1-gregory.clement@bootlin.com>
 <878r5vctdg.fsf@BL-laptop>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <878r5vctdg.fsf@BL-laptop>

On Fri, Dec 15, 2023 at 05:39:39PM +0100, Gregory CLEMENT wrote:
> Hello Thomas,
> 
> > Hello,
> >
> > The EyeQ5 SoC from Mobileye is based on the MIPS I6500 architecture
> > and features multiple controllers such as the classic UART, I2C, SPI,
> > as well as CAN-FD, PCIe, Octal/Quad SPI Flash interface, Gigabit
> > Ethernet, MIPI CSI-2, and eMMC 5.1. It also includes a Hardware
> > Security Module, Functional Safety Hardware, and MJPEG encoder.
> >
> > One peculiarity of this SoC is that the physical address of the DDDR
> > exceeds 32 bits. Given that the architecture is 64 bits, this is not
> > an issue, but it requires some changes in how the mips64 is currently
> > managed during boot.
> >
> > In this fifth version, there aren't many changes, mostly just tweaking
> > commit messages based on Sergey's feedback and fixing up the code
> > style. But, the real reason for this series is a bit of a whoopsie on
> > my end. It turns out, despite what I confidently claimed in the last
> > round, some configuration tweaks were missing. All sorted now, though!
> >
> 
> A few weeks ago, you were concerned about the introduction of the
> specific kconfig CONFIG_USE_XKPHYS to support EyeQ5, and you wanted us
> to set up a new platform instead. Since then, Jiaxun proposed a series
> that was merged here to provide more generic support.

well, there is more to improve and stuff I don't like in Jaixun series.
For example misusing CONFIG_PHYSICAL_START to force a load address via config
(IMHO it's already a hack for CRASH_DUMP).

As there is your series and Jiaxun series, where should I comment more
detailed ?

> I had other issues in the initial series, and I think that now I've
> fixed all of them. So, I would like to know what your opinion is now
> about this series.
> 
> Will you accept it, or do you still think that a new platform has to be
> set up?

things have improved, but I'm still in favor to use a new platform.
And my main point stays. A "generic" kernel compiled for EyeQ5 will
just run on that platform, which doesn't sound generic to me.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]