public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: "Marek Behún" <marek.behun@nic.cz>
To: "Pali Rohár" <pali@kernel.org>
Cc: Stefan Roese <sr@denx.de>, u-boot@lists.denx.de
Subject: Re: [PATCH u-boot-marvell 8/8] arm: mvebu: turris_omnia: Add support for USB3.0 mode in WWAN MiniPCIe slot
Date: Wed, 2 Mar 2022 13:46:07 +0100	[thread overview]
Message-ID: <20220302134607.69f4a36c@dellmb> (raw)
In-Reply-To: <20220302114758.21787-9-pali@kernel.org>

On Wed,  2 Mar 2022 12:47:58 +0100
Pali Rohár <pali@kernel.org> wrote:

> PCIe Mini CEM 2.1 spec added support for USB3.0 mode on MiniPCIe cards.
> USB3.0 and PCIe share same pins and only one function can be active at the
> same time. PCIe Mini CEM 2.1 spec says that determining function is
> platform specific and spec does not define any dedicated pin which could
> say if card is USB3.0-based or PCIe-based.
> 
> Implement this platform specific decision (USB3.0 vs PCIe) for WWAN
> MiniPCIe slot on Turris Omnia via U-Boot env variable "omnia_wwan_slot",
> similarly like is implemented forced mode for MiniPCIe/mSATA slot via
> "omnia_msata_slot" env variable. Value "usb3" for "omnia_wwan_slot" would
> mean to set USB3.0 mode and value "pcie" original PCIe mode.
> 
> A385 SoC on Turris Omnia has configurable fifth SerDes line (exported to
> MiniPCIe WWAN slot with SIM card) either to USB3.0 or PCIe functionality,
> so implementation of this new PCIe Mini CEM 2.1 feature is simple, by just
> configuring SerDes to USB 3.0 mode.
> 
> Other twos MiniPCIe slots on Turris Omnia do not have this new
> functionality as their SerDes lines cannot be switched to USB3.0
> functionality.
> 
> Note that A385 SoC does not have too many USB3.0 blocks, so activating
> USB3.0 in MiniPCIe cause that one external USB3.0 USB-A port would loose
> USB3.0 functionality and would be downgraded just to USB2.0.
> 
> By default this MiniPCIe WWAN slot is in PCIe mode, like before.
> 
> To set this MiniPCIe WWAN slot to USB3.0 mode, call U-Boot commands:
> 
>   => setenv omnia_wwan_slot usb3
>   => saveenv
>   => reset  
> 
> Signed-off-by: Pali Rohár <pali@kernel.org>
> ---
>  board/CZ.NIC/turris_omnia/turris_omnia.c | 57 ++++++++++++++++++++++++
>  1 file changed, 57 insertions(+)
> 
> diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c b/board/CZ.NIC/turris_omnia/turris_omnia.c
> index e2f4daa827ed..83cfc80d1930 100644
> --- a/board/CZ.NIC/turris_omnia/turris_omnia.c
> +++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
> @@ -246,6 +246,22 @@ static bool omnia_detect_sata(const char *msata_slot)
>  	return stsword & MSATA_IND_STSBIT ? true : false;
>  }
>  
> +static bool omnia_detect_wwan_usb3(const char *wwan_slot)
> +{
> +	puts("WWAN slot configuration... ");
> +
> +	if (wwan_slot && strcmp(wwan_slot, "usb3") == 0) {
> +		puts("USB3.0\n");
> +		return true;
> +	}
> +
> +	if (wwan_slot && strcmp(wwan_slot, "pcie") != 0)
> +		printf("unsupported env value '%s', fallback to... ", wwan_slot);

If  I recall correctly, Linux' and U-Boot's code style (in contrast to
TF-A) normally wants
  if (expr)        instead of       if (expr != 0)
and
  if (!expr)       instead of       if (expr == 0)

Sometimes in spite of this style it is better to use == or != operator,
for example in cases where one wants to compare a character to multiple
literals:
  if (c == 0x13 || c == 0x12 || c == 0x00)

But for strcmp() and friends, we normaly just use
  if (!strcmp())

This is just a nitpick, I don't mind that much. Just saying this so
you are aware of this in the future...


> +
> +	puts("PCIe+USB2.0\n");
> +	return false;
> +}
> +
>  void *env_sf_get_env_addr(void)
>  {
>  	/* SPI Flash is mapped to address 0xD4000000 only in SPL */
> @@ -276,6 +292,20 @@ int hws_board_topology_load(struct serdes_map **serdes_map_array, u8 *count)
>  		board_serdes_map[0].serdes_mode = SERDES_DEFAULT_MODE;
>  	}
>  
> +#ifdef CONFIG_SPL_ENV_SUPPORT
> +	/* beware that env_get() returns static allocated memory */
> +	env_value = has_env ? env_get("omnia_wwan_slot") : NULL;
> +#endif

Use
  if (IS_ENABLED(CONFIG_SPL_ENV_SUPPORT))
instead of macro wherever possible, so that an error can be caught by
the compiler even if it is in the disabled part of the code.

Marek

  reply	other threads:[~2022-03-02 12:46 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-02 11:47 [PATCH u-boot-marvell 0/8] Turris Omnia: Add support for configuring mSATA and WWAN slots via env variables Pali Rohár
2022-03-02 11:47 ` [PATCH u-boot-marvell 1/8] env: sf: Allow to use env_sf_init_addr() at any stage Pali Rohár
2022-03-02 11:47 ` [PATCH u-boot-marvell 2/8] arm: mvebu: turris_omnia: Provide env_sf_get_env_addr() function Pali Rohár
2022-03-02 12:37   ` Marek Behún
2022-04-22 11:49     ` Pali Rohár
2022-04-22 12:21       ` Marek Behún
2022-03-02 11:47 ` [PATCH u-boot-marvell 3/8] arm: mvebu: turris_omnia: Enable ENV support in SPL Pali Rohár
2022-03-02 11:47 ` [PATCH u-boot-marvell 4/8] arm: mvebu: turris_omnia: Define only one serdes map variable Pali Rohár
2022-03-02 11:47 ` [PATCH u-boot-marvell 5/8] arm: mvebu: turris_omnia: Allow to configure mSATA slot via env variable Pali Rohár
2022-03-02 12:36   ` Marek Behún
2022-03-02 11:47 ` [PATCH u-boot-marvell 6/8] arm: mvebu: turris_omnia: Extract code for disabling sata/pcie Pali Rohár
2022-03-02 12:38   ` Marek Behún
2022-04-22  9:20     ` Pali Rohár
2022-04-22  9:23       ` Stefan Roese
2022-03-02 11:47 ` [PATCH u-boot-marvell 7/8] arm: mvebu: turris_omnia: Signal error when sata/pcie DT mode Pali Rohár
2022-03-02 11:47 ` [PATCH u-boot-marvell 8/8] arm: mvebu: turris_omnia: Add support for USB3.0 mode in WWAN MiniPCIe slot Pali Rohár
2022-03-02 12:46   ` Marek Behún [this message]
2022-04-22 11:47     ` Pali Rohár
2022-04-22 12:20       ` Marek Behún
2022-05-01 14:57 ` [PATCH u-boot-marvell 0/8] Turris Omnia: Add support for configuring mSATA and WWAN slots via env variables Pali Rohár
2022-05-02 15:39 ` Stefan Roese

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=20220302134607.69f4a36c@dellmb \
    --to=marek.behun@nic.cz \
    --cc=pali@kernel.org \
    --cc=sr@denx.de \
    --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