From: Gregory CLEMENT <gregory.clement@bootlin.com>
To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
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>,
"Théo Lebrun" <theo.lebrun@bootlin.com>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v5 00/22] Add support for the Mobileye EyeQ5 SoC
Date: Thu, 21 Dec 2023 10:13:53 +0100 [thread overview]
Message-ID: <87cyuzc3zi.fsf@BL-laptop> (raw)
In-Reply-To: <87frzwasxo.fsf@BL-laptop>
Gregory CLEMENT <gregory.clement@bootlin.com> writes:
[...]
>>>
>>> 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.
This sentence was not very clear, let me rephrase it: I recommend
starting the review with Jiaxun's series, specifically examining the
code that has been incorporated into my series. This is important as I
have already made several modifications to his original code
>>
>>> 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.
Is it possible for you to apply the first patch of this series, which is
only a fix? This would enable me to have a slightly shorter
series. Additionally, it would facilitate dividing the entire series
into two parts: the first part for XKPHYS support and the second part
for EyeQ5 support.
Gregory
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
next prev parent reply other threads:[~2023-12-21 9:14 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-12 16:34 [PATCH v5 00/22] Add support for the Mobileye EyeQ5 SoC Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 01/22] MIPS: compressed: Use correct instruction for 64 bit code Gregory CLEMENT
2023-12-21 14:38 ` Thomas Bogendoerfer
2023-12-12 16:34 ` [PATCH v5 02/22] MIPS: Export higher/highest relocation functions in uasm Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 03/22] MIPS: spaces: Define a couple of handy macros Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 04/22] MIPS: genex: Fix except_vec_vi for kernel in XKPHYS Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 05/22] MIPS: Fix set_uncached_handler for ebase " Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 06/22] MIPS: Refactor mips_cps_core_entry implementation Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 07/22] MIPS: Fix cache issue with mips_cps_core_entry Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 08/22] MIPS: Allow kernel base to be set from Kconfig for all platforms Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 09/22] MIPS: traps: Handle CPU with non standard vint offset Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 10/22] MIPS: Avoid unnecessary reservation of exception space Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 11/22] MIPS: traps: Enhance memblock ebase allocation process Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 12/22] MIPS: Get rid of CONFIG_NO_EXCEPT_FILL Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 13/22] MIPS: traps: Give more explanations if ebase doesn't belong to KSEG0 Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 14/22] dt-bindings: Add vendor prefix for Mobileye Vision Technologies Ltd Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 15/22] dt-bindings: mips: cpus: Sort the entries Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 16/22] dt-bindings: mips: cpu: Add I-Class I6500 Multiprocessor Core Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 17/22] dt-bindings: mips: Add bindings for Mobileye SoCs Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 18/22] dt-bindings: mfd: syscon: Document EyeQ5 OLB Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 19/22] MIPS: mobileye: Add EyeQ5 dtsi Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 20/22] MIPS: mobileye: Add EPM5 device tree Gregory CLEMENT
2023-12-12 16:34 ` [PATCH v5 21/22] MIPS: generic: Add support for Mobileye EyeQ5 Gregory CLEMENT
2023-12-14 9:46 ` Jiaxun Yang
2023-12-15 16:52 ` Gregory CLEMENT
2023-12-15 20:29 ` Jiaxun Yang
2023-12-12 16:34 ` [PATCH v5 22/22] MAINTAINERS: Add entry for Mobileye MIPS SoCs Gregory CLEMENT
2023-12-15 16:39 ` [PATCH v5 00/22] Add support for the Mobileye EyeQ5 SoC Gregory CLEMENT
2023-12-20 21:49 ` Thomas Bogendoerfer
2023-12-21 1:57 ` Jiaxun Yang
2023-12-21 7:57 ` Gregory CLEMENT
2023-12-21 9:13 ` Gregory CLEMENT [this message]
2023-12-21 14:40 ` Thomas Bogendoerfer
2023-12-21 14:55 ` Thomas Bogendoerfer
2023-12-21 15:26 ` Gregory CLEMENT
2023-12-21 16:55 ` Thomas Bogendoerfer
2023-12-21 22:25 ` Jiaxun Yang
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=87cyuzc3zi.fsf@BL-laptop \
--to=gregory.clement@bootlin.com \
--cc=alexandre.belloni@bootlin.com \
--cc=devicetree@vger.kernel.org \
--cc=jiaxun.yang@flygoat.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=paulburton@kernel.org \
--cc=robh+dt@kernel.org \
--cc=tawfik.bayouk@mobileye.com \
--cc=theo.lebrun@bootlin.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=tsbogend@alpha.franken.de \
--cc=vladimir.kondratiev@mobileye.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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