提交 3b3969bd 编写于 作者: A Andreas Dannenberg 提交者: Tom Rini

clk: Extend clock control with an optional data field

Some systems require more than a single ID to identify and configure any
clock provider. For those scenarios add an optional data field to the
clock control structure.
Reviewed-by: NTom Rini <trini@konsulko.com>
Signed-off-by: NAndreas Dannenberg <dannenberg@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
上级 65c8a798
......@@ -40,10 +40,12 @@ struct udevice;
*
* @dev: The device which implements the clock signal.
* @id: The clock signal ID within the provider.
* @data: An optional data field for scenarios where a single integer ID is not
* sufficient. If used, it can be populated through an .of_xlate op and
* processed during the various clock ops.
*
* Currently, the clock API assumes that a single integer ID is enough to
* identify and configure any clock signal for any clock provider. If this
* assumption becomes invalid in the future, the struct could be expanded to
* Should additional information to identify and configure any clock signal
* for any provider be required in the future, the struct could be expanded to
* either (a) add more fields to allow clock providers to store additional
* information, or (b) replace the id field with an opaque pointer, which the
* provider would dynamically allocated during its .of_xlate op, and process
......@@ -53,10 +55,10 @@ struct udevice;
struct clk {
struct udevice *dev;
/*
* Written by of_xlate. We assume a single id is enough for now. In the
* future, we might add more fields here.
* Written by of_xlate. In the future, we might add more fields here.
*/
unsigned long id;
unsigned long data;
};
/**
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册