On Thu, Apr 18, 2019 at 10:07 AM Jagan Teki jagan@amarulasolutions.com wrote:
On Thu, Apr 18, 2019 at 10:33 PM Chen-Yu Tsai wens@kernel.org wrote:
On Thu, Apr 18, 2019 at 9:51 AM Jagan Teki jagan@amarulasolutions.com wrote:
On Thu, Apr 18, 2019 at 10:19 PM Chen-Yu Tsai wens@kernel.org wrote:
On Thu, Apr 18, 2019 at 9:42 AM Jagan Teki jagan@amarulasolutions.com wrote:
On Thu, Apr 18, 2019 at 10:00 PM Chen-Yu Tsai wens@kernel.org wrote:
On Thu, Apr 18, 2019 at 9:15 AM Chen-Yu Tsai wens@kernel.org wrote: > > On Thu, Apr 18, 2019 at 8:09 AM Chen-Yu Tsai wens@kernel.org wrote: > > > > On Wed, Apr 17, 2019 at 4:38 AM Jagan Teki jagan@amarulasolutions.com wrote: > > > > > > Hi, > > > > > > On Fri, Apr 12, 2019 at 4:05 PM Chen-Yu Tsai wens@kernel.org wrote: > > > > > > > > From: Chen-Yu Tsai wens@csie.org > > > > > > > > (Resending yet again with correct email address now subscribed > > > > and with proper cover letter subject. Sorry for the noise.) > > > > > > > > Hi everyone, > > > > > > > > This series enables EMAC (Ethernet controller) on two A83T boards, > > > > the Cubietruck Plus and Bananapi M3. > > > > > > > > A couple of changes are required to the clock definitions to make the > > > > compiler happy, as it hasn't been coverted to use the common CLK and > > > > DM_RESET framework. These changes are not used in the A83T code path. > > > > > > > > The other two patches enable the sun8i-emac and Realtek PHY driver in > > > > their respective defconfigs. The device trees already have the EMAC > > > > enabled. > > > > > > > > Since these are compile time issues, all patches should go through > > > > the same tree. > > > > > > > > Regards > > > > ChenYu > > > > > > > > > > > > Chen-Yu Tsai (4): > > > > sunxi: Fix compilation of sun8i-emac for A83T > > > > net: sun8i-emac: Fix compilation for A83T > > > > sunxi: Enable EMAC on the Cubietruck Plus > > > > sunxi: Enable EMAC on the Bananapi M3 > > > > > > We have EPHY clock and reset support via respective framework [1] > > > would you rebase these changes on top this. > > > > > > [1] http://git.denx.de/?p=u-boot-sunxi.git;a=commitdiff;h=6b2ccabee2368d059513a9... > > > > Lovely! I'll throw the clock register bit patches out and rework the > > other stuff. > > > > Does anyone else have these boards for testing though? I'm away from > > my boards for the next two weeks (which is past the merge window). > > Looks like the EPHY clock and resets weren't converted. So it still > needs some sort of fix to build. Do you have anything in the works > regarding EPHY?
Looks like sunxi/next has the answer. And the new defconfigs build cleanly. Would you like to me respin on top with RFT? It doesn't actually matter what branch the defconfig patches are based on since they apply cleanly to either branch.
Yes, ie what I'm thinking.
BTW: the existing code doesn't enable the use_internal_phy for H3_EMAC, any idea? ie what I was thought and prepared this EPHY CLK and RESET support enabled it which indeed enabling use_internal_phy
The original code had:
if (priv->variant == H3_EMAC) { int parent = fdt_parent_offset(gd->fdt_blob, offset); if (parent >= 0 && !fdt_node_check_compatible(gd->fdt_blob, parent, "allwinner,sun8i-h3-mdio-internal")) priv->use_internal_phy = true; }in sun8i_emac_eth_ofdata_to_platdata(), which I think is what you're asking about?
Yes, the same but priv->use_internal_phy not assign to true at the end.
Doesn't the last line set it to true?
I'm not sure what you're asking. Are you asking when you should set priv->use_internal_phy?
Inside if statement seems to failed and which intern not setting use_internal_phy to true. so at the end priv->use_internal_phy is false (as default) is it the proper behavior, I thought it is wrong.
Not sure why it fails. fdt_node_check_compatible will return 0 if the node lists the given compatible string. And fdt_parent_offset returns >= 0 for a valid offset. The logic looks correct:
If the PHY node's parent is compatible with "allwinner,sun8i-h3-mdio-internal", set priv->use_internal_phy = true.
ChenYu