Hi Patrick! So I started implementing the GPIO_LIB implementation but I have hit an issue where I would like to get some feedback. So in principle the gpiolib works, but only if the device is not asleep and the clock is enabled, which at this very moment means that the can interface has to be up and running. So at this very moment the only option that I see would be to disable the sleep mode which the device enters after probing until the can-network interface is enabled (which enables the clock and start the oscillator) - with SLEEP enabled when GPIOLIB support is disabled. This is obviously not optimal from the power perspective… The other option would be starting the clock and oscillator as soon as a set_direction* (or reques/free) function is called. (where I would need to start using locks to avoid race conditions as well as clock usage counters...). Which of the above is the preferred solution? Are there other ideas how I could solve this dilemma? Martin > On 05.12.2017, at 19:28, Patrick Menschel <menschel.p@xxxxxxxxx> wrote: > > Hi Martin, > > it depends on the daily usage of those alternate functions. > I just took a quick glimpse on the datasheet and if you check appendix B table 9-1 , you'll see that some functions are optional because ISO suggested them, not because there is a practical reason for it. > > CLKO/SOF does make little to no sense with a higher grade embedded system. CLKO is meant to share the osc with the microcontroller. >> The CLKO pin provides the clock to the >> microcontroller. > SOF makes sense for testing in lab configuration, not for regular operation. > > TXCAN also does make little sense as you can only use it in the lab. >> TXCANOD: TXCAN can be configured as Push- >> Pull or as Open Drain out >> put. Open Drain outputs >> allows the user to connect multiple controllers >> together to build a CAN network without using a >> transceiver. > > INTOD is initialized as Push/Pull. Configuring it open drain would be processor specific when the microcontroller has limited options for pin-ctrl, e.g. some PICs. >> INTOD: >> Interrupt pins Open Drain Mode >> 1 >> = Open Drain Output >> 0 >> = Push/Pull Output > > To sum it up, I would drop: > - CLKO/SOF > - TXCAN > - INTOD > > I would implement higher level functions in a second step for INT0/GPIO0/XSTBY and INT1/GPIO1. > Such functions can be: > - power saving via XSTBY > - RX / TX LEDs via INT0 / INT1 > > Actually this second step would wait until a request for feature arises. > > Regards, > Patrick > > Am 05.12.2017 um 11:26 schrieb Martin Sperl: >> Hi Patrick! >> >> >> I had a quick look starting to implement gpiolib, >> >> but I believe I would need to implement pin-ctrl on top to >> >> make the Alternate functions work propperly. >> >> I wonder if this effort is really worth it. >> >> Martin >> -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
