public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] mips: rename arch mt7620 to mt7628
Date: Mon, 29 Apr 2019 16:27:12 +0200	[thread overview]
Message-ID: <a76656eb-afbc-0344-ca9b-e3885adc9fc8@gmail.com> (raw)
In-Reply-To: <c4267b05-152f-f9ca-eede-7bdb931d7bfb@denx.de>



Am 29.04.19 um 11:40 schrieb Stefan Roese:
> On 29.04.19 11:28, Weijie Gao wrote:
>> On Mon, 2019-04-29 at 07:08 +0200, Stefan Roese wrote:
>>> On 28.04.19 11:38, Weijie Gao wrote:
>>>> The MediaTek MT7620 and MT7628 SoCs are different.
>>>> Although they use the same memory controller, the lowlevel code (CPU
>>>> PLL)
>>>> and other peripherals they use are totally different. Which means they
>>>> should use seperate mach directories.
>>>
>>> s/seperate/separate
>>>
>>>> Currently the mach mt7620 contains only architecture code of MT7628.
>>>> In case we add real arch support of MT7620 in the future, the arch
>>>> should
>>>> be renamed to mt7628, including both Kconfig files and directories.
>>>> Other files affected are also modified.
>>>
>>> Perhaps it would be possible to support both SoC's (MT7620 and
>>> MT7628/88)
>>> in one mach directory? Frankly I don't know the differences in
>>> detail, so
>>> its your call.
> 
> <snip>
> 
>> Dear Stefan,
>>
>> Thanks for pointing out the missing files.
>>
>> Here is the summary of HW components needed by u-boot for MT7620 and
>> MT7628:
>>
>> L1 data cache:            MT7620 can not lock it.
>>                            MT7628 uses it to do DDR calibration.
>> CPU frequency (PLL):      MT7620 can change it. MT7628 can't.
>>                            The PLL registers are different.
>> DRAM controller:          Near the same.
>>                            MT7620 can't do calibration.
>>                            MT7628 has extra PAD configurations.
> 
> These "devices / controllers" are handled in the mach-foo directory.
> 
>> GPIO controller:          Not the same IP core.
>> SPI controller:           Not the same IP core.
>> Frame engine:             Similar IP core, different generation.
>> Built-in Ethernet switch: Not the same IP core.
> 
> And these controllers are handled in the drivers/foo directly. So any
> different IP core (between MT7620 and MT7628) has no effect to the
> mach directory.
> 
> Please don't misunderstand me. I absolutely agree that we need to
> differentiate between those two SoC's. So moving to CONFIG_SOC_MT7628
> instead of SOC_MT7620 makes perfect sense. I only want to avoid the
> creation of another mach-foo directory, where code might be shared
> between both SoC's.
> 
>>
>> So I insist to split them into two mach directory.
> 
> I see. Okay, lets move forward then with your patch and lets finally
> decide if and what can be shared between those SoC's, once (if) support
> for the MT7620 arrives in mainline.
> 
> BTW: Do you plan on adding support for the MT7620 anytime soon?
> 

I agree with Stefan, there is no need to create separate mach-
directories. With the power of Kconfig and Kbuild you can easily handle
multiple SoCs within one mach- directory, for instance look at
mach-bmips or mach-mscc. Could you rather rename to mach-mediatek or
mach-mtmips so that we would have the Kconfig symbols ARCH_MEDIATEK and
SOC_MT7628 (plus SOC_MT7620 in the future)? Thanks.

BTW: it's good to see that another vendor in the MIPS area is stepping
up to maintain its products in mainline ;)

-- 
- Daniel

  reply	other threads:[~2019-04-29 14:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-28  9:38 [U-Boot] [PATCH] mips: rename arch mt7620 to mt7628 Weijie Gao
2019-04-29  5:08 ` Stefan Roese
2019-04-29  9:28   ` Weijie Gao
2019-04-29  9:40     ` Stefan Roese
2019-04-29 14:27       ` Daniel Schwierzeck [this message]
2019-04-30  1:29         ` Weijie Gao

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=a76656eb-afbc-0344-ca9b-e3885adc9fc8@gmail.com \
    --to=daniel.schwierzeck@gmail.com \
    --cc=u-boot@lists.denx.de \
    /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