disable DCDC and Si86xx isolators on USB suspend

[fenugrec]

Reduces current consumption by a lot in USB_SUSPEND state on certain boards. On most targets this PR has no effect (the empty functions are compiled out)

It would take more work to meet USB specs ( 0.5mA !), but this helps on boards with a DCDC and galvanic isolation (Si86xx ICs are fairly power-hungry).

On a cannette board, suspend current is now 15mA (from 56mA at idle with no CAN traffic).

Further steps would be to bring the whole mcu into sleep, to be waked by USB events.

[marckleinebudde]

What does the DCDC converter power?

We currently have:

• the silent pin CAN_S_Pin
• the transceiver standby pin nCANSTBY_Pin

both are per channel, unless someone makes use of a 2-channel transceiver. Currently the silent pin only set once in main(), the transceiver standby pin is set in can_enable() and can_disable. In my multichannel branch I think I'm moving both into the can_ functions.

[fenugrec]

What does the DCDC converter power?

It powers the isolated section on the CAN side, so the transceiver. In some of my use cases the floating +5V also can power other remote nodes, but that's irrelevant for this firmware.
My eventual idea is to maybe move this kind of functionality to board-specific files with per-device, and per-channel, enable/disable functions. So the common code just calls e.g. device_enable() or can_enable(chan) , etc.

CAN_S_Pin and nCANSTBY_Pin

Right - some xvrs have two control pins (tja1051 : Silent + Enable), others just one (tja1042 : STBY), they have slightly different "semantics" but for our use here it could probably be simplified / unified.

both are per channel, unless someone makes use of a 2-channel transceiver. Currently the silent pin only set once in main(), the transceiver standby pin is set in can_enable() and can_disable. In my multichannel branch I think I'm moving both into the can_ functions.

[marckleinebudde]

It powers the isolated section on the CAN side, so the transceiver. In some of my use cases the floating +5V also can power other remote nodes, but that's irrelevant for this firmware. My eventual idea is to maybe move this kind of functionality to board-specific files with per-device, and per-channel, enable/disable functions. So the common code just calls e.g. device_enable() or can_enable(chan) , etc.

Do we need a dedicated device enable function?

Makes sense. I probably need this for multi channel support anyways. How to integrate these functions? Register a callback? __weak function?

CAN_S_Pin and nCANSTBY_Pin

Right - some xvrs have two control pins (tja1051 : Silent + Enable), others just one (tja1042 : STBY), they have slightly different "semantics" but for our use here it could probably be simplified / unified.

ACK different semantics. We have neither in Linux nor in the USB protocol support for setting the silent pin. With transceivers directly attached the SoC, we turn everything off if the CAN interface goes down (turn off power, set standby, set silent) and the opposite if the interface does up.

I think I'll code a generic transceiver in candlelight that supports several pins that can be used from the enable channel function.

As soon as there are transceivers or power isolation shared between channels it gets more complicated. We need ref-counting and the usage must be clean.

[fenugrec]

Do we need a dedicated device enable function?

For now, I think only I do (on cannette) because of the DCDC and the lofty goal of trying to meet USB standby current specs ! Other boards : perhaps not necessary.

Makes sense. I probably need this for multi channel support anyways. How to integrate these functions? Register a callback? __weak function?

Well, all boards would implement a per-channel enable + disable. For multichan , would we need to act on arbitrary sets of channels together or simply "enable/disable-all" would be sufficient ?
Callbacks maybe overkill but what did you have in mind ? I haven't given much thought about multichan.

With transceivers directly attached the SoC, we turn everything off if the CAN interface goes down (turn off power, set standby, set silent) and the opposite if the interface does up.

Agreed.

I think I'll code a generic transceiver in candlelight that supports several pins that can be used from the enable channel function.

Sounds good - that could help reduce the #ifdef population !

As soon as there are transceivers or power isolation shared between channels it gets more complicated.

Yes - future me is not looking forward to having to deal with that !

[ghent360]

IMO the new 'phy_power_set' (multichannel branch) is the ideal place for enabling the DCDC isolator(s) - it may need some small delay for the power rail to stabilize though.

As written "USB suspend" would disable the can channels, disable the STBY pin and the DCDC regulator. However 'USB resume' would only enable the DCDC regulator, which seems odd - you consume power when the CAN device is disabled.

[fenugrec]

IMO the new 'phy_power_set' (multichannel branch) is the ideal place for enabling the DCDC isolator(s)

Right, I knew you guys were working on related features which is why I've held off merging this (nothing to do with me being short on free time... ahem..)

However 'USB resume' would only enable the DCDC regulator, which seems odd - you consume power when the CAN device is disabled.

I was sometimes powering external CAN nodes (on the isolated side) with this, but it's true the DCDC-enable could be only called from the channel-enable hook.
Haven't measured power-on ramp on these RFM-0505 but a delay may be hard to enforce anyway with the gs_usb host protocol... and just NAKing the endpoints for an arbitrary delay seems a bit brutal