Re: [PATCH v5 00/22] Add support for the Mobileye EyeQ5 SoC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 ]




[Index of Archives]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux