• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 104 subscribers
  • Views 2036 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM335x Slew rate setup in the device tree

Mike Worster
Expert 1575 points

I'm working on a device tree for my product and I'm working off the am335x-evm.dts as a base. I've made it to MDIO, my pin mux definition shows that the MDIO lines should be set up as:

MUX_VAL(CONTROL_PADCONF_MDIO, (IEN | PU | MODE0 )) /* mdio_data */\
MUX_VAL(CONTROL_PADCONF_MDC, (IDIS | PU | MODE0 )) /* mdio_clk */\

So they're:

MDIO Data -
    IEN - input
    PU  - pull up
    MODE0 - Mux_mode0
MDIO Clk -
    IDIS - output
    PU  - pull up
    MODE0 - Mux_mode0

And that's what I was expecting when looking at the /arch/arm/boot/dts/am335x-evm.dts. However instead I found:

 

		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 */
			>;
		};

So the question I have is about the slew rate option. The MDIO Data pin was set not only with the expected input/pull up/mode0, but also had a fast slewrate set.

1) I take it the Pin Mux Utility just doesn't take slew rate into consideration. Is this correct?

2) What made TI choose the fast slew rate for the MDIO Data pin in the device tree? Are there other pins that TI feels are important to have a fast slew rate?

3) Side question: The mdio has the prefix "davinci", why is this here? Is the block within the processor dubbed "davinci" for some reason?

  • 0
    TI__Guru**** 393215 points

    Hi Mike,

    See comments made by peaves in this thread: http://e2e.ti.com/support/arm/sitara_arm/f/791/t/233997.aspx . These should answer your questions.

  • 0
    TI__Guru*** 125430 points

    Mike Worster said:
    1) I take it the Pin Mux Utility just doesn't take slew rate into consideration. Is this correct?

    Correct, for reasons I'll explain in the responses to your other questions.

    Mike Worster said:
    2) What made TI choose the fast slew rate for the MDIO Data pin in the device tree? Are there other pins that TI feels are important to have a fast slew rate?

    The data manual specifies that the timings given all apply to fast mode.

    So in short, you want to use fast mode all the time.  And it just so happens that the way the register is defined, a value of 0 corresponds to fast mode:

    That means for all of the pins that are NOT specifying fast mode, you're actually getting it regardless...

    Mike Worster said:
    3) Side question: The mdio has the prefix "davinci", why is this here? Is the block within the processor dubbed "davinci" for some reason?

    The "davinci" line was a family of processors spanning multiple generations.  It is analogous to "omap".  Some modules may be called things like omap-i2c while others are davinci-mdio.  It just relates to their heritage.

  • 0 in reply to Brad Griffis
    Expert 1575 points

    So what you're saying is that MDIO Data:

    0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)    /* mdio_data.mdio_data */

    Is explicitly setting the slew control to fast, where as MDIO clock:

    0x14c (PIN_OUTPUT_PULLUP | MUX_MODE0)           /* mdio_clk.mdio_clk */

    Is implicitly setting slew control to fast based on the fact that the value "0" is used for "fast" in 9.3.1.50. That's what you're saying?

    The note in the description of table 9-60:

    Says that's not guaranteed to work.. I didn't check all the pad settings in the data manual yet, and based on the linked forum exchange saying that TI doesn't test with slow rate, it sounds like a safe assumption... but it's still an assumption.

    Am I misunderstanding anything here?

  • 0 in reply to Mike Worster
    TI__Guru*** 125430 points

    Mike Worster said:
    Am I misunderstanding anything here?

    We overwrite whatever is in there.  Reset value doesn't matter in this case.

  • 0 in reply to Mike Worster
    Expert 2505 points

    For those reading from home, note that SLEWCTRL_FAST is misdefined as (1 << 6) in the current upstream Linux sources, so the first configuration above is actually setting it to slow.  See https://lists.yoctoproject.org/pipermail/meta-ti/2014-September/005211.html for more details.