From: Daniel Golle <daniel@makrotopia.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Andrew Lunn <andrew@lunn.ch>,
devicetree@vger.kernel.org, netdev@vger.kernel.org,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Qingfang Deng <dqfext@gmail.com>,
SkyLake Huang <SkyLake.Huang@mediatek.com>,
Simon Horman <simon.horman@corigine.com>
Subject: Re: [PATCH net-next v4 1/2] dt-bindings: arm: mediatek: add mediatek,boottrap binding
Date: Thu, 18 May 2023 03:44:45 +0100 [thread overview]
Message-ID: <ZGWRHeE3CXeAnQ-5@makrotopia.org> (raw)
In-Reply-To: <7e8d0945-dfa9-7f61-b075-679e8a89ded9@linaro.org>
On Fri, May 12, 2023 at 08:54:36AM +0200, Krzysztof Kozlowski wrote:
> On 11/05/2023 17:53, Andrew Lunn wrote:
> > On Thu, May 11, 2023 at 04:10:20PM +0200, Daniel Golle wrote:
> >> The boottrap is used to read implementation details from the SoC, such
> >> as the polarity of LED pins. Add bindings for it as we are going to use
> >> it for the LEDs connected to MediaTek built-in 1GE PHYs.
> >
> > What exactly is it? Fuses? Is it memory mapped, or does it need a
> > driver to access it? How is it shared between its different users?
>
> Yes, looks like some efuse/OTP/nvmem, so it should probably use nvmem
> bindings and do not look different than other in such class.
I've asked MediaTek and they have replied with an elaborate definition.
Summary:
The boottrap is a single 32-bit wide register at 0x1001f6f0 which can
be used to read back the bias of bootstrap pins from the SoC as follows:
* bit[8]: Reference CLK source && gphy port0's LED
If bit[8] == 0:
- Reference clock source is XTRL && gphy port0's LED is pulled low on board side
If bit[8] == 1:
- Reference clock source is Oscillator && gphy port0's LED is pulled high on board side
* bit[9]: DDR type && gphy port1's LED
If bit[9] == 0:
- DDR type is DDRx16b x2 && gphy port1's LED is pulled low on board side
If bit[9] == 1:
- DDR type is DDRx16b x1 && gphy port1's LED is pulled high on board side
* bit[10]: gphy port2's LED
If bit[10] == 0:
- phy port2's LED is pulled low on board side
If bit[10] == 1:
- gphy port2's LED is pulled high on board side
* bit[11]: gphy port3's LED
If bit[11] == 0:
- phy port3's LED is pulled low on board side
If bit[11] == 1:
- gphy port3's LED is pulled high on board side
If bit[10] == 0 && bit[11] == 0:
- BROM will boot from SPIM-NOR
If bit[10] == 1 && bit[11] == 0:
- BROM will boot from SPIM-NAND
If bit[10] == 0 && bit[11] == 1:
- BROM will boot from eMMC
If bit[10] == 1 && bit[11] == 1:
- BROM will boot from SNFI-NAND
The boottrap is present in many MediaTek SoCs, however, support for
reading it is only really needed on MT7988 due to the dual-use of some
bootstrap pins as PHY LEDs.
We could say this is some kind of read-only 'syscon' node (and hence
use regmap driver to access it), that would make it easy but it's not
very accurate. Also efuse/OTP/nvmem doesn't seem accurate, though in
terms of software it could work just as well.
I will update DT bindings to contain the gained insights.
Please advise if any existing driver (syscon/regmap or efuse/OTP/nvmem)
should be used or if it's ok to just use plain mmio in the PHY driver.
Best regards
Daniel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Golle <daniel@makrotopia.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Andrew Lunn <andrew@lunn.ch>,
devicetree@vger.kernel.org, netdev@vger.kernel.org,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Qingfang Deng <dqfext@gmail.com>,
SkyLake Huang <SkyLake.Huang@mediatek.com>,
Simon Horman <simon.horman@corigine.com>
Subject: Re: [PATCH net-next v4 1/2] dt-bindings: arm: mediatek: add mediatek,boottrap binding
Date: Thu, 18 May 2023 03:44:45 +0100 [thread overview]
Message-ID: <ZGWRHeE3CXeAnQ-5@makrotopia.org> (raw)
In-Reply-To: <7e8d0945-dfa9-7f61-b075-679e8a89ded9@linaro.org>
On Fri, May 12, 2023 at 08:54:36AM +0200, Krzysztof Kozlowski wrote:
> On 11/05/2023 17:53, Andrew Lunn wrote:
> > On Thu, May 11, 2023 at 04:10:20PM +0200, Daniel Golle wrote:
> >> The boottrap is used to read implementation details from the SoC, such
> >> as the polarity of LED pins. Add bindings for it as we are going to use
> >> it for the LEDs connected to MediaTek built-in 1GE PHYs.
> >
> > What exactly is it? Fuses? Is it memory mapped, or does it need a
> > driver to access it? How is it shared between its different users?
>
> Yes, looks like some efuse/OTP/nvmem, so it should probably use nvmem
> bindings and do not look different than other in such class.
I've asked MediaTek and they have replied with an elaborate definition.
Summary:
The boottrap is a single 32-bit wide register at 0x1001f6f0 which can
be used to read back the bias of bootstrap pins from the SoC as follows:
* bit[8]: Reference CLK source && gphy port0's LED
If bit[8] == 0:
- Reference clock source is XTRL && gphy port0's LED is pulled low on board side
If bit[8] == 1:
- Reference clock source is Oscillator && gphy port0's LED is pulled high on board side
* bit[9]: DDR type && gphy port1's LED
If bit[9] == 0:
- DDR type is DDRx16b x2 && gphy port1's LED is pulled low on board side
If bit[9] == 1:
- DDR type is DDRx16b x1 && gphy port1's LED is pulled high on board side
* bit[10]: gphy port2's LED
If bit[10] == 0:
- phy port2's LED is pulled low on board side
If bit[10] == 1:
- gphy port2's LED is pulled high on board side
* bit[11]: gphy port3's LED
If bit[11] == 0:
- phy port3's LED is pulled low on board side
If bit[11] == 1:
- gphy port3's LED is pulled high on board side
If bit[10] == 0 && bit[11] == 0:
- BROM will boot from SPIM-NOR
If bit[10] == 1 && bit[11] == 0:
- BROM will boot from SPIM-NAND
If bit[10] == 0 && bit[11] == 1:
- BROM will boot from eMMC
If bit[10] == 1 && bit[11] == 1:
- BROM will boot from SNFI-NAND
The boottrap is present in many MediaTek SoCs, however, support for
reading it is only really needed on MT7988 due to the dual-use of some
bootstrap pins as PHY LEDs.
We could say this is some kind of read-only 'syscon' node (and hence
use regmap driver to access it), that would make it easy but it's not
very accurate. Also efuse/OTP/nvmem doesn't seem accurate, though in
terms of software it could work just as well.
I will update DT bindings to contain the gained insights.
Please advise if any existing driver (syscon/regmap or efuse/OTP/nvmem)
should be used or if it's ok to just use plain mmio in the PHY driver.
Best regards
Daniel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-05-18 2:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-11 14:09 [PATCH net-next v4 0/2] net: phy: add driver for MediaTek SoC built-in GE PHYs Daniel Golle
2023-05-11 14:10 ` [PATCH net-next v4 1/2] dt-bindings: arm: mediatek: add mediatek,boottrap binding Daniel Golle
2023-05-11 15:53 ` Andrew Lunn
2023-05-12 6:54 ` Krzysztof Kozlowski
2023-05-18 2:44 ` Daniel Golle [this message]
2023-05-18 2:44 ` Daniel Golle
2023-05-18 7:50 ` Krzysztof Kozlowski
2023-05-18 7:50 ` Krzysztof Kozlowski
2023-05-18 14:21 ` Krzysztof Kozlowski
2023-05-18 14:21 ` Krzysztof Kozlowski
2023-05-11 17:06 ` Krzysztof Kozlowski
2023-05-11 14:10 ` [PATCH net-next v4 2/2] net: phy: add driver for MediaTek SoC built-in GE PHYs Daniel Golle
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=ZGWRHeE3CXeAnQ-5@makrotopia.org \
--to=daniel@makrotopia.org \
--cc=SkyLake.Huang@mediatek.com \
--cc=andrew@lunn.ch \
--cc=angelogioacchino.delregno@collabora.com \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=dqfext@gmail.com \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=robh+dt@kernel.org \
--cc=simon.horman@corigine.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.