From: srinivas.kandagatla@st.com (Srinivas KANDAGATLA)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v1 0/4] ARM: STi fixes and ethernet support
Date: Wed, 10 Jul 2013 11:27:24 +0100 [thread overview]
Message-ID: <51DD370C.20902@st.com> (raw)
In-Reply-To: <201307092315.06131.arnd@arndb.de>
Hi Arnd,
On 09/07/13 22:15, Arnd Bergmann wrote:
>> For DT case, At the moment I think callbacks at MACH level is one
>> > possible solution. But am open for any discussions.
> Ok, so a PHY driver might not be the best place to put this, but it's
> one option, since the PHY driver already has to know about the
> interface speed you are setting.
>
> Having a global "*_setup_ethernet" callback is definitely not the
> right way to go. Please describe what the function actually does
> so we can come up with the right subsystem to move that functionality
> to. If you are setting clocks, you should use the clock subsystem,
> for taking the device out of reset, you should use the reset controller
> subsystem and for setting up the phy, you should use the phy subsystem,
> etc.
The purpose of this callback is to do three things.
1> Configuring the MAC signals to select particular PHY interface mode.
MAC signals(wires) are wired up to this Ethernet Configuration register.
2> Select synchronisation clock for data lines retiming. On High speed
interfaces track length/layouts on the boards can directly influence the
signal quality and introduce bit shifts or other errors. So SoC has
additional logic to retime these signals and improve the data
reliability. As there is possibility of multiple clock sources (MAC,
PHY) a correct choice of synchronization clock is made in Ethernet
configuration register. For 125 Mhz clock in Gbit mode, reference clock
is provided by the PHY in other case like 100bit and 10bit, 50MHz, 25MHz
clocks is provide by the MAC.
So this bits depend/driven based on the PHYMODEs and Link Speed.
3> Ethernet Soft reset in Ethernet control register.
Which can probably go into via reset controller driver.
For point 1 and 2, there is no subsystem in the kernel which can
accommodate these kind of SOC specific bits setup. Am not sure if other
platforms have similar SoC setup use cases?
For point 3, I can go for reset controller API.
Just for your reference (Sorry and Please ignore if Its too detailed),
Ethernet configuration register looks like:
Bit to configure signals connected to MAC.
[5] ENMII1: when 1, MII mode
when 0, Reverse MII mode
[4:2] MII1_PHY_SEL:
000: GMII/MII (default)
001: RGMII
010: SGMII
100: RMII
Bit to configure retiming clock for retiming data lines:
[8] ETH1_SEL_TX_RETIMING_CLK: Selection of the clock used to retime TX data
0: clock selected by ETH1_SEL_TXCLK_NOT_CLK125 bit
1: clock fed to or provided by MII_PHYCLK depending
on eth1_sel_internal_notext_phyclk setting
[7] ETH1_SEL_INTERNAL_NOTEXT_PHYCLK: Selection of internal clock or
external clock from MII_PHYCLK for retiming in RMII mode
0: external clock (Beware that eth1_sel_tx_retiming_clk
bit must also be programmed).
1: internal clock (from clockgenA)
[6] ETH1_SEL_TXCLK_NOT_CLK125: Selection of the clock used to
retime TX data
0: MII1_CLK_125 (beware that eth1_sel_tx_retiming_clk bit must also be
programmed)
1: MII1_TXCLK
Thanks,
srini
prev parent reply other threads:[~2013-07-10 10:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-08 8:15 [PATCH v1 0/4] ARM: STi fixes and ethernet support Srinivas KANDAGATLA
2013-07-08 8:17 ` [PATCH v1 1/4] ARM: dts: STi: Fix pinconf setup for STiH416 serial2 Srinivas KANDAGATLA
2013-07-08 8:18 ` [PATCH v1 2/4] ARM: STi: Set correct ARM ERRATAs Srinivas KANDAGATLA
2013-07-08 8:18 ` [PATCH v1 3/4] ARM: STi: Add STiH415 ethernet support Srinivas KANDAGATLA
2013-07-08 8:18 ` [PATCH v1 4/4] ARM: STi: Add STiH416 " Srinivas KANDAGATLA
2013-07-08 23:18 ` [PATCH v1 0/4] ARM: STi fixes and " Arnd Bergmann
2013-07-09 7:05 ` Srinivas KANDAGATLA
2013-07-09 7:56 ` Arnd Bergmann
2013-07-09 10:34 ` Srinivas KANDAGATLA
2013-07-09 21:15 ` Arnd Bergmann
2013-07-10 10:27 ` Srinivas KANDAGATLA [this message]
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=51DD370C.20902@st.com \
--to=srinivas.kandagatla@st.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).