Topics

[RFC PATCH 3/6] i2c: add device config helpers


Vlad Dogaru <vlad.dogaru@...>
 

Add some macros that drivers and applications can use in describing I2C
clients.

Change-Id: Ic7af97804e88ed3b9d4f68f9ac358a425f4cc17c
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
include/i2c.h | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

diff --git a/include/i2c.h b/include/i2c.h
index d1c699c..87cb071 100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -266,6 +266,23 @@ static inline int i2c_resume(struct device *dev)
return api->resume(dev);
}

+struct i2c_client_config {
+ //struct device *i2c_master;
+ char *i2c_master;
+ uint16_t i2c_addr;
+};
+
+#define DECLARE_I2C_CLIENT_CONFIG struct i2c_client_config i2c_client
+
+#define I2C_CLIENT(master, addr) \
+ .i2c_client = { \
+ .i2c_master = (master), \
+ .i2c_addr = (addr), \
+ }
+
+#define GET_I2C_MASTER(conf) ((conf)->i2c_client.i2c_master)
+#define GET_I2C_ADDR(conf) ((conf)->i2c_client.i2c_addr)
+
#ifdef __cplusplus
}
#endif
--
1.9.1


Tomasz Bursztyka
 

Hi Vlad,

Add some macros that drivers and applications can use in describing I2C
clients.

Change-Id: Ic7af97804e88ed3b9d4f68f9ac358a425f4cc17c
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
include/i2c.h | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

diff --git a/include/i2c.h b/include/i2c.h
index d1c699c..87cb071 100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -266,6 +266,23 @@ static inline int i2c_resume(struct device *dev)
return api->resume(dev);
}

+struct i2c_client_config {
+ //struct device *i2c_master;
+ char *i2c_master;
+ uint16_t i2c_addr;
+};
+
+#define DECLARE_I2C_CLIENT_CONFIG struct i2c_client_config i2c_client
+
+#define I2C_CLIENT(master, addr) \
I don't know if their is a rule for macro's parameter naming.
My personal - and thus subjective - opinion is to separate those to
actual C code, and
I tend to enclose these with '_', so it would be _master_, _addr_
Or prefixing with '__' works as well.

+ .i2c_client = { \
So it means we cannot use anything else but "i2c_client" as a name in
our device's configuration structure?
Would be easier that way:
{ \
.i2c_master = (master), \
.i2c_addr = (addr) \
}

Thus usage would be:

my_dev_config.i2c_info = I2C_CLIENT(foo, bar)

+ .i2c_master = (master), \
+ .i2c_addr = (addr), \
+ }
+
+#define GET_I2C_MASTER(conf) ((conf)->i2c_client.i2c_master)
+#define GET_I2C_ADDR(conf) ((conf)->i2c_client.i2c_addr)
I2C_ prefixed

And names are not relevant enough. What's the form of master's
information? What address?
So:
I2C_GET_MASTER_NAME()
I2C_GET_CLIENT_ADDR() (or _ADDRESS() actually)


And finally, document the struct and the macros.

Tomasz


Vlad Dogaru <vlad.dogaru@...>
 

On Mon, Apr 25, 2016 at 01:10:49PM +0200, Tomasz Bursztyka wrote:
Hi Vlad,

Add some macros that drivers and applications can use in describing I2C
clients.

Change-Id: Ic7af97804e88ed3b9d4f68f9ac358a425f4cc17c
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
include/i2c.h | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

diff --git a/include/i2c.h b/include/i2c.h
index d1c699c..87cb071 100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -266,6 +266,23 @@ static inline int i2c_resume(struct device *dev)
return api->resume(dev);
}
+struct i2c_client_config {
+ //struct device *i2c_master;
+ char *i2c_master;
+ uint16_t i2c_addr;
+};
+
+#define DECLARE_I2C_CLIENT_CONFIG struct i2c_client_config i2c_client
+
+#define I2C_CLIENT(master, addr) \
I don't know if their is a rule for macro's parameter naming.
My personal - and thus subjective - opinion is to separate those to
actual C code, and
I tend to enclose these with '_', so it would be _master_, _addr_
Or prefixing with '__' works as well.
Sure thing.


+ .i2c_client = { \
So it means we cannot use anything else but "i2c_client" as a name
in our device's configuration structure?
Would be easier that way:
{ \
.i2c_master = (master), \
.i2c_addr = (addr) \
}

Thus usage would be:

my_dev_config.i2c_info = I2C_CLIENT(foo, bar)
The configuration tool needs to generate config structures (see
devices.c in patch 6/6). These structures are device specific, but the
tool should be as generic as possible. Hard coding the struct member
name to "i2c_client" helps achieve that.

Thus, assuming the macros are correctly used, the config tool needs only
information such as "this device is connected to master I2C0, address
0x76", to generate "I2C_CLIENT(I2C0, 0x76)". Allowing the name to
change would be an extra variable.


+ .i2c_master = (master), \
+ .i2c_addr = (addr), \
+ }
+
+#define GET_I2C_MASTER(conf) ((conf)->i2c_client.i2c_master)
+#define GET_I2C_ADDR(conf) ((conf)->i2c_client.i2c_addr)
I2C_ prefixed
Yes.


And names are not relevant enough. What's the form of master's
information? What address?
So:
I2C_GET_MASTER_NAME()
I2C_GET_CLIENT_ADDR() (or _ADDRESS() actually)
Hopefully these will be better once I add some comments. There is an
example in patch 6/6, I hope that will clear these up.

And finally, document the struct and the macros.
Yep.


Tomasz Bursztyka
 

Hi Vlad,

The configuration tool needs to generate config structures (see
devices.c in patch 6/6). These structures are device specific, but the
tool should be as generic as possible. Hard coding the struct member
name to "i2c_client" helps achieve that.

Thus, assuming the macros are correctly used, the config tool needs only
information such as "this device is connected to master I2C0, address
0x76", to generate "I2C_CLIENT(I2C0, 0x76)". Allowing the name to
change would be an extra variable.
Ok, so it would be really great know a lot more about this tool.

Tomasz


Vlad Dogaru <vlad.dogaru@...>
 

On Mon, Apr 25, 2016 at 01:59:42PM +0200, Tomasz Bursztyka wrote:
Hi Vlad,

The configuration tool needs to generate config structures (see
devices.c in patch 6/6). These structures are device specific, but the
tool should be as generic as possible. Hard coding the struct member
name to "i2c_client" helps achieve that.

Thus, assuming the macros are correctly used, the config tool needs only
information such as "this device is connected to master I2C0, address
0x76", to generate "I2C_CLIENT(I2C0, 0x76)". Allowing the name to
change would be an extra variable.
Ok, so it would be really great know a lot more about this tool.
Adding Tony, he can explain more about the tool.

Thanks,
Vlad


Benjamin Walsh <benjamin.walsh@...>
 

On Mon, Apr 25, 2016 at 01:10:49PM +0200, Tomasz Bursztyka wrote:
Hi Vlad,

Add some macros that drivers and applications can use in describing I2C
clients.

Change-Id: Ic7af97804e88ed3b9d4f68f9ac358a425f4cc17c
Signed-off-by: Vlad Dogaru <vlad.dogaru(a)intel.com>
---
include/i2c.h | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

diff --git a/include/i2c.h b/include/i2c.h
index d1c699c..87cb071 100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -266,6 +266,23 @@ static inline int i2c_resume(struct device *dev)
return api->resume(dev);
}
+struct i2c_client_config {
+ //struct device *i2c_master;
+ char *i2c_master;
+ uint16_t i2c_addr;
+};
+
+#define DECLARE_I2C_CLIENT_CONFIG struct i2c_client_config i2c_client
+
+#define I2C_CLIENT(master, addr) \
I don't know if their is a rule for macro's parameter naming.
My personal - and thus subjective - opinion is to separate those to
actual C code, and
I tend to enclose these with '_', so it would be _master_, _addr_
Or prefixing with '__' works as well.
Leading underscore is reserved by the kernel for internal global
symbols.


+ .i2c_client = { \
So it means we cannot use anything else but "i2c_client" as a name
in our device's configuration structure?
Would be easier that way:
{ \
.i2c_master = (master), \
.i2c_addr = (addr) \
}

Thus usage would be:

my_dev_config.i2c_info = I2C_CLIENT(foo, bar)

+ .i2c_master = (master), \
+ .i2c_addr = (addr), \
+ }
+
+#define GET_I2C_MASTER(conf) ((conf)->i2c_client.i2c_master)
+#define GET_I2C_ADDR(conf) ((conf)->i2c_client.i2c_addr)
I2C_ prefixed

And names are not relevant enough. What's the form of master's
information? What address?
So:
I2C_GET_MASTER_NAME()
I2C_GET_CLIENT_ADDR() (or _ADDRESS() actually)


And finally, document the struct and the macros.

Tomasz


Dobre, Antonel G <antonel.g.dobre@...>
 

Hello

I am in charge of development for the configuration tool mentioned by Vlad.

Our tool aims to help developers both for Zephyr and Linux manage device configurations on build time and ACPI, respectively. We plan on creating a small high-level description language in which developers state what components they need on what board, and together with some information like GPIO pin interrupts, bus addresses and/or ACPI properties we either create configuration code for Zephyr ( in the manner Vlad is describing in his patches ) or ACPI tables for Linux.

This tool will be made open source and available to everyone as soon as we have integrated all the features previously mentioned.

Tony Dobre

-----Original Message-----
From: Dogaru, Vlad
Sent: Tuesday, April 26, 2016 5:52 PM
To: Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com>; Dobre, Antonel G <antonel.g.dobre(a)intel.com>
Cc: devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Re: Re: [RFC PATCH 3/6] i2c: add device config helpers

On Mon, Apr 25, 2016 at 01:59:42PM +0200, Tomasz Bursztyka wrote:
Hi Vlad,

The configuration tool needs to generate config structures (see
devices.c in patch 6/6). These structures are device specific, but
the tool should be as generic as possible. Hard coding the struct
member name to "i2c_client" helps achieve that.

Thus, assuming the macros are correctly used, the config tool needs
only information such as "this device is connected to master I2C0,
address 0x76", to generate "I2C_CLIENT(I2C0, 0x76)". Allowing the
name to change would be an extra variable.
Ok, so it would be really great know a lot more about this tool.
Adding Tony, he can explain more about the tool.

Thanks,
Vlad