On Thursday 17 December 2015 01:39 PM, Pascal Speck (Iktek) wrote:
> Hi Mugunthan,
> please see my comments below:
>
> Am 17.12.2015 um 07:08 schrieb Mugunthan V N:
>> On Tuesday 08 December 2015 09:55 PM, Tony Lindgren wrote:
>>> * ker...@iktek.de <ker...@iktek.de> [151207 09:17]:
>>>> Hi Tony,
>>>>
>>>> there are two ethernet interfaces ( dual-emac-configuration ) used.
>>>> One is connected to another 100mbit switch-ic ( refclk should come from
>>>> switch ic ) via rmii, the other one is connected to a 1gbit fpga rgmii
>>>> interface ( where the clock is served from the fpga ).
>> This means you have both the interfaces with MAC-to-MAC interface. Is
>> MDIO is active or did you disabled it as it is not needed (because of no
>> phy present in the system)?
> Yes, both interfaces are mac-to-mac. The mdio-node is available in the
> dt, but the pinmux has been commented out as the pins are not used.
> These are the relevant parts of the dt:
>
> ---snip---
>
> davinci_mdio_default: davinci_mdio_default {
> pinctrl-single,pins = <
> /* MDIO */
> /* 0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST |
> MUX_MODE0) */ /* mdio_data.mdio_data */
> /* 0x14c (PIN_OUTPUT_PULLUP |
> MUX_MODE0) */ /* mdio_clk.mdio_clk */
> >;
> };
>
> ---snip---
>
> &cpsw_emac0 {
> phy-mode = "rgmii";
> dual_emac_res_vlan = <1>;
> /* fixed-link = <1 1000 0 0>; */
> fixed-link {
> speed = <1000>;
> full-duplex;
> };
> };
>
> &cpsw_emac1 {
> phy-mode = "rmii";
> dual_emac_res_vlan = <2>;
> /* fixed-link = <1 100 0 0>; */
> fixed-link {
> speed = <100>;
> full-duplex;
> };
> };
>
>
> &phy_sel {
> rmii-clock-ext;
> };
>
> &mac {
> pinctrl-names = "default", "sleep";
> pinctrl-0 = <&cpsw_default>;
> pinctrl-1 = <&cpsw_sleep>;
> status = "okay";
> dual_emac;
> };
>
> &davinci_mdio {
> pinctrl-names = "default";
> pinctrl-0 = <&davinci_mdio_default>;
> pinctrl-1 = <&davinci_mdio_sleep>;
> status = "okay";
> };
>
> ---snip---
>
>>>> On both interfaces it may happen that the clock isn't present while the
>>>> mac-address is set (fpga may not have been inited, switch chip could be
>>>> held in reset), but this was the same behaviour with previous kernel
>>>> (3.14 with cpsw patched from ti tree) where this configuration worked.
>>>> As the hardware is in field now there is no chance to change hardware.
>>>>
>>>> On the other hand: when not setting the mac of the interface that
>>>> early,
>>>> the cpsw seems to init proberly but a ping to the outer world does not
>>>> work either, so something else may be different on the new kernel.
>>> Maybe Mugunthan has some ideas what's going on here.
>>>
>> If MDIO is disabled and CPSW is not brought up then CPSW clocks are
>> gated and when you try to set the mac address the system will crash as
>> the driver try to access CPSW registers with CPSW clocks gated. Can you
>> try below options and see what happens
>>
>> * Instead of setting the mac address using *ip link set address*, try to
>> use u-boot env variable (ethaddr/ath1addr) to set the mac address.
>>
>> * You must be storing the MAC address in EEPROM or somewhere, just try
>> to implement the mac address reading mechanism in
>> drivers/net/ethernet/ti/cpsw-common.c file to avoid setting of mac
>> address from userspace.
> I'll try this as soon as possible ( unfortunately this would be
> beginning of next year probably as I'm very busy the last days of the
> year ).
> As the eeprom layout has not been setup by myself, it could take a while
> to reimplement this in kernelspace.
> Would it be a good deal to check somehow if the clocks have been enabled
> before allowing this options to be set by userspace?
You can try accessing the cpsw register space using memtool from userspace.
Even if mdio is enabled in DT, if CPSW is not probed then CPSW clocks
will be in gates state which will cause a crash while accessing its
registers.
Regards
Mugunthan V N
>>
> Thanks for the good opinions. I appreciate your help.
> Regards Pascal
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
