Hello Marek,
On 05/15/2014 09:01 PM, Marek Vasut wrote:
On Friday, May 09, 2014 at 08:58:02 AM, Przemyslaw Marczak wrote:
Hello,
[...]
struct power_ops_key_power {
int (*key_state) (int *state);
};
This could be a key input device.
struct power_ops_rtc {
int (*sec) (int set_get, int *val);
int (*min) (int set_get, int *val);
int (*hour) (int set_get, int *val);
int (*day) (int set_get, int *val);
int (*month) (int set_get, int *val);
int (*year) (int set_get, int *val);
};
RTC device.
struct power_ops_motor {
int (*configure) (void);
int (*enable) (int time, int gain);
};
struct power_ops_led_flash {
int (*configure) (void);
int (*enable) (void);
int (*disable) (void);
};
LED device.
Yes, they are actually a various devices with separated options.
I looked into some Frescale and Maxim PMICs documentation. And those
integrated devices usually provides various ops on one or two
interfaces. So I think it would be nice to have one framework and e.g.
register available devices options for each interface of each device.
It seems like you're trying to assemble a huge framework while avoiding the
already-present frameworks. No?
You're right - we have some frameworks at present and this framework
could be an additional abstraction level between device and uboot commands.
Device could be presented as it was designed - is it bad idea?
Best regards,
Marek Vasut
Thanks
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
