From: Baruch Siach <baruch@tkos.co.il>
To: u-boot@lists.denx.de
Subject: [PATCH v4 06/12] arm: mvebu: clearfog: Add option for 2.5 Gbps SFP
Date: Mon, 27 Jan 2020 09:20:02 +0200 [thread overview]
Message-ID: <87a7694b8d.fsf@tarshish> (raw)
In-Reply-To: <b73d4832bb3d9f2f0f7051ca8d0fd485@lixil.net>
Hi Joel,
On Mon, Jan 27 2020, Joel Johnson wrote:
> On 2020-01-26 22:29, Baruch Siach wrote:
>> On Mon, Jan 27 2020, Joel Johnson wrote:
>>> While newer Linux kernels provide autoconfiguration of SFP, provide
>>> an option for setting in U-Boot Kconfig for use prior to booting.
>>>
>>> Signed-off-by: Joel Johnson <mrjoel@lixil.net>
>>>
>>> ---
>>>
>>> v2 changes:
>>> - fixed help indentation
>>> v3 changes:
>>> - none
>>> v4 changes:
>>> - adjust static SerDes configuration at runtime instead of #ifdef
>>>
>>> ---
>>> board/solidrun/clearfog/Kconfig | 7 +++++++
>>> board/solidrun/clearfog/clearfog.c | 3 +++
>>> 2 files changed, 10 insertions(+)
>>>
>>> diff --git a/board/solidrun/clearfog/Kconfig
>>> b/board/solidrun/clearfog/Kconfig
>>> index 936d5918f8..c910e17093 100644
>>> --- a/board/solidrun/clearfog/Kconfig
>>> +++ b/board/solidrun/clearfog/Kconfig
>>> @@ -15,4 +15,11 @@ config TARGET_CLEARFOG_BASE
>>> detection via additional EEPROM hardware. This option enables
>>> selecting
>>> the Base variant for older hardware revisions.
>>>
>>> +config CLEARFOG_SFP_25GB
>>> + bool "Enable 2.5 Gbps mode for SFP"
>>> + help
>>> + Set the SFP module connection to support 2.5 Gbps transfer speed for
>>> the
>>> + SGMII connection (requires a supporting SFP). By default, transfer
>>> speed
>>> + of 1.25 Gbps is used, suitable for a more common 1 Gbps SFP module.
>>> +
>>> endmenu
>>> diff --git a/board/solidrun/clearfog/clearfog.c
>>> b/board/solidrun/clearfog/clearfog.c
>>> index 4019e37016..6c5b9a784f 100644
>>> --- a/board/solidrun/clearfog/clearfog.c
>>> +++ b/board/solidrun/clearfog/clearfog.c
>>> @@ -59,6 +59,9 @@ void config_static_serdes_map(void)
>>> board_serdes_map[4].serdes_speed = SERDES_SPEED_5_GBPS;
>>> board_serdes_map[4].serdes_mode = SERDES_DEFAULT_MODE;
>>> }
>>> +
>>> + if (IS_ENABLED(CONFIG_CLEARFOG_SFP_25GB))
>>> + board_serdes_map[5].serdes_speed = SERDES_SPEED_3_125_GBPS;
>>
>> config_static_serdes_map() is not called only when TLV EEPROM is
>> present. So CONFIG_CLEARFOG_SFP_25GB has no effect in that case. This
>> code should move to hws_board_topology_load() to avoid that.
>
> Yeah, that's what I was trying to ask with the question below embedded in
> patch 4.
>
> "Note that this approach *does not* currently provide any mechanism
> for EEPROM detected boards to have their SFP speed changed or switch
> between PCIE/SATA signalling. I'm assuming that will be done based on
> hardware detection, but confirmation/acceptance in review would be
> appreciated so it can be revisited if needed.
>
> After sending the series and thinking about it more, I didn't see any other
> mechanism by which the configuration would be changed. The question was really
> to confirm what I had inferred from code, namely that Pro/Base boards even
> with EEPROM would still have to have a U-Boot built with custom options in
> order to change the PCIe/SATA or SFP options. I would like to confirm with you
> that is desired and expected even in the cases of EEPROM supporting units. If
> that's the case, I'll rework the location of setting, along with updating the
> help text for those options. Pending your confirmation, I plan to get rid of
> the separate config_static_serdes_map function and fold it back in, with the
> SATA and SFP options coming before the board runtime detection configuration.
My thinking is that EEPROM TLV is only meant to describe the hardware as
manufactured, and never change. SATA (read mSATA) and SFP are user setup
that TLV can't cover. So I think that SATA and SFP build time selection
should apply regardless of TLV.
In theory it could have been even better to store SATA/SFP selection in
environment variables. But that is not currently possible, since serdes
configuration takes place at SPL phase where the environment is not
accessible.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
next prev parent reply other threads:[~2020-01-27 7:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-26 22:49 [PATCH v4 00/12] ClearFog Base static variant support Joel Johnson
2020-01-26 22:49 ` [PATCH v4 01/12] arm: mvebu: fix SerDes table alignment Joel Johnson
2020-01-26 22:49 ` [PATCH v4 02/12] arm: mvebu: solidrun: remove hardcoded DTS MAC address Joel Johnson
2020-01-26 22:50 ` [PATCH v4 03/12] arm: mvebu: clearfog: use Pro name by default Joel Johnson
2020-01-27 8:14 ` Baruch Siach
2020-01-26 22:50 ` [PATCH v4 04/12] arm: mvebu: clearfog: initial ClearFog Base variant Joel Johnson
2020-01-26 22:50 ` [PATCH v4 05/12] arm: mvebu: clearfog: Unify DT selection paths Joel Johnson
2020-01-26 22:50 ` [PATCH v4 06/12] arm: mvebu: clearfog: Add option for 2.5 Gbps SFP Joel Johnson
2020-01-27 5:29 ` Baruch Siach
2020-01-27 6:08 ` Joel Johnson
2020-01-27 7:20 ` Baruch Siach [this message]
2020-01-27 16:27 ` Joel Johnson
2020-01-27 16:57 ` Joel Johnson
2020-01-26 22:50 ` [PATCH v4 07/12] arm: mvebu: clearfog: add SPI offsets Joel Johnson
2020-01-26 22:50 ` [PATCH v4 08/12] arm: mvebu: enable working default boot support Joel Johnson
2020-01-26 22:50 ` [PATCH v4 09/12] arm: mvebu: clearfog: move ENV params to Kconfig Joel Johnson
2020-01-26 22:50 ` [PATCH v4 10/12] arm: mvebu: clearfog: don't always use SPL MMC Joel Johnson
2020-01-26 22:50 ` [PATCH v4 11/12] arm: mvebu: clearfog: Add SATA mode flags Joel Johnson
2020-01-26 22:50 ` [PATCH v4 12/12] arm: mvebu: clearfog: Use Pro DT by default Joel Johnson
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=87a7694b8d.fsf@tarshish \
--to=baruch@tkos.co.il \
--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