• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 685 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

AM625: davinic_gpio driver probe very late, cause GPIO resquest failed, EPROBE_DEFER(517)

AM6422: GPIO request issue

Ethan Tian
Intellectual 1872 points

Part Number: AM6422
Other Parts Discussed in Thread: PCA9534

Hi experts

I have a question about GPIO initialization.

My customer used an I2C-to-GPIO chip (PCA9534) to control the reset signal of the PHY, and then the PCA9534 shares I2C3 with an EEPROM for some other reason. The 4052 chip enables 1 to 4 I2C channel selection.
That is, the I2C channel is selected via GPIO, the PCA9534 is selected, and the reset of the PHY is controlled via PCA9534. Subsequent optimizations will be made, but the GPIO selection I2C channel design will still be retained.

The issue that is being encountered is a failed request for GPIO. We need to request GPIO in the probe of CPSW and EEPROM.

As shown in the figure below, they used GPIO1_40 and GPIO1_41 in EEPROM@57, but request GPIO failed, and the code is EPROBE_DEFER  517.

later we added the following two lines of dependencies, which can be requested to GPIO via devm_gpiod_get_optional in the EEPROM's probe (they actually use no interrupts needed, just output capability). What is this mechanism?

  interrupt-parent = <&main_gpio1>;

  interrupts = <38 IRQ_TYPE_EDGE_FALLING>;

Then they added it in the same way in the CPSW node, but the probe in am65-cpsw-nuss cannot request GPIO, return code is 517, we thought that the GPIO module has not completed initialization. How should this be configured? 

BR

Ethan

  • 0
    TI__Mastermind 22585 points

    Hello Ethan,

    I am currently looking into this. Please allow some time for a response.

    Best Regards,

    Anshu

  • 0 in reply to Anshu Madwesh
    TI__Intellectual 1872 points

    Hi Anshu

    Thanks, looking forward to your reply

  • 0
    TI__Guru**** 179141 points

    Hi Ethan,

    Ethan Tian said:

    As shown in the figure below, they used GPIO1_40 and GPIO1_41 in EEPROM@57, but request GPIO failed, and the code is EPROBE_DEFER  517.

    later we added the following two lines of dependencies, which can be requested to GPIO via devm_gpiod_get_optional in the EEPROM's probe (they actually use no interrupts needed, just output capability). What is this mechanism?

      interrupt-parent = <&main_gpio1>;

      interrupts = <38 IRQ_TYPE_EDGE_FALLING>;

    These two interrupt related DT properties are not needed.

    In your driver probe() function, when devm_gpiod_get_optional() returns -EPROBE_DEFER, probe() should just stop and return the same error code -EPROBE_DEFER as well, then kernel will call this probe() again later. If the gpio driver has been initialized by then, devm_gpiod_get_optional() should pass.