Message-ID: <87frzwasxo.fsf@BL-laptop>
Date: Thu, 21 Dec 2023 08:57:55 +0100
From: Gregory CLEMENT <gregory.clement@...tlin.com>
To: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
Cc: Paul Burton <paulburton@...nel.org>, linux-mips@...r.kernel.org, Jiaxun
 Yang <jiaxun.yang@...goat.com>, Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, Vladimir
 Kondratiev <vladimir.kondratiev@...ileye.com>, Tawfik Bayouk
 <tawfik.bayouk@...ileye.com>, Alexandre Belloni
 <alexandre.belloni@...tlin.com>, Théo Lebrun
 <theo.lebrun@...tlin.com>,
 Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v5 00/22] Add support for the Mobileye EyeQ5 SoC

Hello Thomas,

Thanks for your fedback

> 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 think you could start on Jiaxun series but the one merged in my
series, because I already had a few fixes for it.

>
>> 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.

I do not oppose the addition of a new platform, even though, like
Jiaxun, I would prefer to avoid duplicating code. The only thing
preventing the use of the same kernel for EyeQ5 and other platforms is
the starting address. Therefore, if it were possible to have a
relocatable kernel, this issue would disappear.

However, while waiting for your feedback on Jiaxun's part, I will
attempt to add a new platform to assess exactly what the implications
are.

Gregory

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

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com

Powered by blists - more mailing lists