Re: 2/5 System Device Driver Modifications

Boie, Andrew P

On Fri, 2016-03-11 at 22:30 +0000, Thomas, Ramesh wrote:

For example, the PMA may chooses to apply .resume on -> APICs, Timers,
ARC, UART in that order because of dependencies and policies. Assuming
it has a list of devices, it can identify these devices in that list by
the name.

The goal is to leave the ordering of operations on devices to the PMA as
kernel can only guarantee the initialization order.
I see. So at boot it could use device_get_binding() or DEVICE_GET() to
populate some data structure with device pointers which is then used at
suspend/resume time.

Another reason of giving the PMA direct access to the device is to
handle the case of DEV_BUSY/DEV_FAIL. It can then choose to
retry .suspend only that device that returned DEV_BUSY.
You're already calling .suspend the first time so presumably you already
have a device pointer, so I'm not sure how this imposes a requirement on

However the custom ordering for suspend/resume dependencies makes
perfect sense, thanks for the additional detail.

Looking at our headers I see some areas needing improvement. These
anonymous drivers use SYS_INIT(). This macro declares a device with ""
for its name, and the name you would use for DEVICE_GET() is very
counter-intuitive. Which means you can't really use either
device_get_binding() or DEVICE_GET() with them.

I think this API needs to be refactored for system devices like this.
Maybe have SYS_INIT() take a dev_name parameter. Here's a potential way
with a new macro SYS_INIT_NAMED(), the difference is in the first couple
args to DEVICE_INIT():

#define SYS_INIT(init_fn, level, prio) \
DEVICE_INIT(sys_init_##init_fn, "", init_fn, NULL, NULL, level, prio)

#define SYS_INIT_NAMED(name, init_fn, level, prio) \
DEVICE_INIT(name, STRINGIFY(name), init_fn, NULL, NULL, level, prio)

Andrew Boie
Staff Engineer - EOS Zephyr
Intel Open Source Technology Center

Join to automatically receive all group messages.