Re: [U-Boot] [RFC PATCH 1/7] pinctrl: add pinctrl framework
Hi Masahiro,
On 29 July 2015 at 23:16, Masahiro Yamada yamada.masah...@socionext.com wrote:
Hi Simon,
2015-07-30 11:06 GMT+09:00 Simon Glass s...@chromium.org:
Hi Masahiro,
On 15 July 2015 at 02:16, Masahiro Yamada yamada.masah...@socionext.com
wrote:
Now, a simple pinctrl patch is being proposed by Simon.
http://patchwork.ozlabs.org/patch/487801/
In the design above, as you see, the uclass is just like a wrapper layer
to invoke .request and .get_periph_id of low-level drivers.
In other words, it is Do-It-Yourself thing, so it is up to you how to
identify
which peripheral is being handled in your .get_periph_id().
And here is one example for how a low-level pinctrl driver could be
implemented.
http://patchwork.ozlabs.org/patch/487874/
I'm sending some comments on this series since I think you are
planning to rework it. My plan is:
- you respin the series
- apply this series
- it should includes the 'simple' version added to the uclass and
perhaps a CONFIG to select whether the full pinctrl is available (can
be separate patches on top of what you have)
- work out what we are going to do about GPIO / pull-ups
OK, I will do it.
Now I am pressed, so hopefully I will have some time this weekend.
Can/does this use exactly the same binding as Linux? Re the limitation
about not detecting conflicts, why is that? It seems that code could
be added for that, even if optional.
I think this series can use the same Generic-conf bindings as used in Linux.
Each driver is still allowed to use its own special bindings.
This version does not support it, but it should not be difficult.
To detect pin conflicts, the framework needs to know
which groups each pin belongs to.
For example, pin 10 is shared between I2C, UART, and SPI,
pin 20 is shared between MMC and NAND, etc.
In other words, low level drivers must have big pin group tables
like they have in Linux.
Most of pinctrl drivers in Linux are over 1000 lines.
I thought it was too much for U-Boot.
To support full features, the pinctrl-uclass would get much bigger.
Of course, we can make it optional with some CONFIG, but I wonder
if it is really needed.
I don't think it is that important. Much more important is to use the
same bindings which I understand you already support.
My question is really about understanding the limitation and whether
it can be resolved (as an option, adding lots of extra code, etc.) or
not? We can address it later, or not. I think it's excellent that you
have come up with something reasonable efficient and we don't want to
mess that up.
As you see in the thread, honestly, I do not like this approach.
It is true that you can implement .get_periph_id in your driver
better than parsing interrupts properties, but I guess
many drivers would follow the rockchip implmentation because
no helpful infrastructure is provided by the uclass (at least now).
Device trees describe hardwares in a way independent of software
that they are used with. So, identical device trees can be (should be)
used with U-Boot as well as Linux or whatever.
Thus, I want the pinctrl can be controllable by device trees in the same way
of Linux, that is, by parsing pinctrl-names and pinctrl-N properties.
Of course, it would be possible to do it in my own .get_periph_id,
but pinctrl-names and pinctrl-N are too generic to be done in each
low-level driver.
In this series, I'd like to propose to support it in the uclass, so that
we can easily reuse device trees for pinctrl.
Please put it on the table for discussion.
Let me explain how it works.
The basic idea is pretty much like Linux, but it has been much simplified
because full-support of the Linux's pinctrl is too much a burden for a
boot-loader.
Device Tree
---
To use pinctrl from each peripheral, add some properties in the device node.
pinctrl-names is a list of pin states. The default state is mandatory,
and it would probably be enough for U-Boot. But, in order to show how it
works,
say the example device supports two states: default and sleep.
In this case, the properties should be like this.
pinctrl-names = default, sleep;
And then, add as many pinctrl-N properties as the number of states.
pinctrl-0 = phandle to default config node;
pinctrl-1 = phandle to sleep config node;
Here, pinctrl-0, pinctrl-1 corresponds to default, sleep, respectively.
The config nodes are (direct or indirect) children of a pinctrl device.
To sum up, the device tree would be like this:
foo {
compatible = ...;
reg = ...;
pinctrl-names = default, sleep;
pinctrl-0 = foo_default_pin;
pinctrl-1 = foo_sleep_pin;
...
};
pinctrl {
compatible = ...;
reg = ...;
foo_default_pin: foo_default {
groups = ...;
functions = ...;
};
foo_sleep_pin: foo_sleep {
Re: [U-Boot] [RFC PATCH 1/7] pinctrl: add pinctrl framework
Hi Masahiro,
On 15 July 2015 at 02:16, Masahiro Yamada yamada.masah...@socionext.com wrote:
Now, a simple pinctrl patch is being proposed by Simon.
http://patchwork.ozlabs.org/patch/487801/
In the design above, as you see, the uclass is just like a wrapper layer
to invoke .request and .get_periph_id of low-level drivers.
In other words, it is Do-It-Yourself thing, so it is up to you how to identify
which peripheral is being handled in your .get_periph_id().
And here is one example for how a low-level pinctrl driver could be
implemented.
http://patchwork.ozlabs.org/patch/487874/
I'm sending some comments on this series since I think you are
planning to rework it. My plan is:
- you respin the series
- apply this series
- it should includes the 'simple' version added to the uclass and
perhaps a CONFIG to select whether the full pinctrl is available (can
be separate patches on top of what you have)
- work out what we are going to do about GPIO / pull-ups
Can/does this use exactly the same binding as Linux? Re the limitation
about not detecting conflicts, why is that? It seems that code could
be added for that, even if optional.
As you see in the thread, honestly, I do not like this approach.
It is true that you can implement .get_periph_id in your driver
better than parsing interrupts properties, but I guess
many drivers would follow the rockchip implmentation because
no helpful infrastructure is provided by the uclass (at least now).
Device trees describe hardwares in a way independent of software
that they are used with. So, identical device trees can be (should be)
used with U-Boot as well as Linux or whatever.
Thus, I want the pinctrl can be controllable by device trees in the same way
of Linux, that is, by parsing pinctrl-names and pinctrl-N properties.
Of course, it would be possible to do it in my own .get_periph_id,
but pinctrl-names and pinctrl-N are too generic to be done in each
low-level driver.
In this series, I'd like to propose to support it in the uclass, so that
we can easily reuse device trees for pinctrl.
Please put it on the table for discussion.
Let me explain how it works.
The basic idea is pretty much like Linux, but it has been much simplified
because full-support of the Linux's pinctrl is too much a burden for a
boot-loader.
Device Tree
---
To use pinctrl from each peripheral, add some properties in the device node.
pinctrl-names is a list of pin states. The default state is mandatory,
and it would probably be enough for U-Boot. But, in order to show how it
works,
say the example device supports two states: default and sleep.
In this case, the properties should be like this.
pinctrl-names = default, sleep;
And then, add as many pinctrl-N properties as the number of states.
pinctrl-0 = phandle to default config node;
pinctrl-1 = phandle to sleep config node;
Here, pinctrl-0, pinctrl-1 corresponds to default, sleep, respectively.
The config nodes are (direct or indirect) children of a pinctrl device.
To sum up, the device tree would be like this:
foo {
compatible = ...;
reg = ...;
pinctrl-names = default, sleep;
pinctrl-0 = foo_default_pin;
pinctrl-1 = foo_sleep_pin;
...
};
pinctrl {
compatible = ...;
reg = ...;
foo_default_pin: foo_default {
groups = ...;
functions = ...;
};
foo_sleep_pin: foo_sleep {
groups = ...;
functions = ...;
};
};
API
---
To set a device into a particular pin state, call
int pinctrl_set_state(struct udevice *dev, const char *state_name).
For example, if you want to set the foo device into the sleep state,
you can do like this:
struct udevice *foo_dev;
(device_get or whatever)
pinctrl_set_state(foo_dev, sleep);
When each device is probed, pinctrl_init() is invoked,
which initializes some pinctrl-specific parameters and set it into default
pin state. Because it is automatically done by the core of driver model,
when a device is probed, its pins are in the default state.
Implementation of low-level driver
--
Currently, two methods are supported in the pinctrl operation:
struct pinctrl_ops {
int (*pinmux_set) (struct udevice *dev, const char *group,
const char *function);
int (*pinconf_set) (struct udevice *dev, const char *group,
const char *conf_param, unsigned conf_arg);
};
They are used to change pin-mux, pin-conf, respectively.
If the pin-config node for the target pin-state is like this,
i2c_default_pin: i2c_default {
groups = i2c-0a;
functions = i2c-0;
};
Your pinmux_set() is called with i2c-0a for the group and i2c-0
for the function.
It is totally up to you what you do
Re: [U-Boot] [RFC PATCH 1/7] pinctrl: add pinctrl framework
Hi Simon,
2015-07-30 11:06 GMT+09:00 Simon Glass s...@chromium.org:
Hi Masahiro,
On 15 July 2015 at 02:16, Masahiro Yamada yamada.masah...@socionext.com
wrote:
Now, a simple pinctrl patch is being proposed by Simon.
http://patchwork.ozlabs.org/patch/487801/
In the design above, as you see, the uclass is just like a wrapper layer
to invoke .request and .get_periph_id of low-level drivers.
In other words, it is Do-It-Yourself thing, so it is up to you how to
identify
which peripheral is being handled in your .get_periph_id().
And here is one example for how a low-level pinctrl driver could be
implemented.
http://patchwork.ozlabs.org/patch/487874/
I'm sending some comments on this series since I think you are
planning to rework it. My plan is:
- you respin the series
- apply this series
- it should includes the 'simple' version added to the uclass and
perhaps a CONFIG to select whether the full pinctrl is available (can
be separate patches on top of what you have)
- work out what we are going to do about GPIO / pull-ups
OK, I will do it.
Now I am pressed, so hopefully I will have some time this weekend.
Can/does this use exactly the same binding as Linux? Re the limitation
about not detecting conflicts, why is that? It seems that code could
be added for that, even if optional.
I think this series can use the same Generic-conf bindings as used in Linux.
Each driver is still allowed to use its own special bindings.
This version does not support it, but it should not be difficult.
To detect pin conflicts, the framework needs to know
which groups each pin belongs to.
For example, pin 10 is shared between I2C, UART, and SPI,
pin 20 is shared between MMC and NAND, etc.
In other words, low level drivers must have big pin group tables
like they have in Linux.
Most of pinctrl drivers in Linux are over 1000 lines.
I thought it was too much for U-Boot.
To support full features, the pinctrl-uclass would get much bigger.
Of course, we can make it optional with some CONFIG, but I wonder
if it is really needed.
As you see in the thread, honestly, I do not like this approach.
It is true that you can implement .get_periph_id in your driver
better than parsing interrupts properties, but I guess
many drivers would follow the rockchip implmentation because
no helpful infrastructure is provided by the uclass (at least now).
Device trees describe hardwares in a way independent of software
that they are used with. So, identical device trees can be (should be)
used with U-Boot as well as Linux or whatever.
Thus, I want the pinctrl can be controllable by device trees in the same way
of Linux, that is, by parsing pinctrl-names and pinctrl-N properties.
Of course, it would be possible to do it in my own .get_periph_id,
but pinctrl-names and pinctrl-N are too generic to be done in each
low-level driver.
In this series, I'd like to propose to support it in the uclass, so that
we can easily reuse device trees for pinctrl.
Please put it on the table for discussion.
Let me explain how it works.
The basic idea is pretty much like Linux, but it has been much simplified
because full-support of the Linux's pinctrl is too much a burden for a
boot-loader.
Device Tree
---
To use pinctrl from each peripheral, add some properties in the device node.
pinctrl-names is a list of pin states. The default state is mandatory,
and it would probably be enough for U-Boot. But, in order to show how it
works,
say the example device supports two states: default and sleep.
In this case, the properties should be like this.
pinctrl-names = default, sleep;
And then, add as many pinctrl-N properties as the number of states.
pinctrl-0 = phandle to default config node;
pinctrl-1 = phandle to sleep config node;
Here, pinctrl-0, pinctrl-1 corresponds to default, sleep, respectively.
The config nodes are (direct or indirect) children of a pinctrl device.
To sum up, the device tree would be like this:
foo {
compatible = ...;
reg = ...;
pinctrl-names = default, sleep;
pinctrl-0 = foo_default_pin;
pinctrl-1 = foo_sleep_pin;
...
};
pinctrl {
compatible = ...;
reg = ...;
foo_default_pin: foo_default {
groups = ...;
functions = ...;
};
foo_sleep_pin: foo_sleep {
groups = ...;
functions = ...;
};
};
API
---
To set a device into a particular pin state, call
int pinctrl_set_state(struct udevice *dev, const char *state_name).
For example, if you want to set the foo device into the sleep state,
you can do like this:
struct udevice *foo_dev;
(device_get or whatever)
pinctrl_set_state(foo_dev, sleep);
When each device is probed, pinctrl_init() is invoked,
which initializes some pinctrl-specific parameters and set it into default
Re: [U-Boot] [RFC PATCH 1/7] pinctrl: add pinctrl framework
Hi Simon,
Sorry for being away from this a while.
2015-07-22 23:24 GMT+09:00 Simon Glass s...@chromium.org:
Hi Masahiro,
On 18 July 2015 at 08:37, Simon Glass s...@chromium.org wrote:
Hi Masahiro,
On 15 July 2015 at 02:16, Masahiro Yamada yamada.masah...@socionext.com
wrote:
Now, a simple pinctrl patch is being proposed by Simon.
http://patchwork.ozlabs.org/patch/487801/
In the design above, as you see, the uclass is just like a wrapper layer
to invoke .request and .get_periph_id of low-level drivers.
In other words, it is Do-It-Yourself thing, so it is up to you how to
identify
which peripheral is being handled in your .get_periph_id().
And here is one example for how a low-level pinctrl driver could be
implemented.
http://patchwork.ozlabs.org/patch/487874/
As you see in the thread, honestly, I do not like this approach.
It is true that you can implement .get_periph_id in your driver
better than parsing interrupts properties, but I guess
many drivers would follow the rockchip implmentation because
no helpful infrastructure is provided by the uclass (at least now).
Device trees describe hardwares in a way independent of software
that they are used with. So, identical device trees can be (should be)
used with U-Boot as well as Linux or whatever.
Thus, I want the pinctrl can be controllable by device trees in the same way
of Linux, that is, by parsing pinctrl-names and pinctrl-N properties.
Of course, it would be possible to do it in my own .get_periph_id,
but pinctrl-names and pinctrl-N are too generic to be done in each
low-level driver.
In this series, I'd like to propose to support it in the uclass, so that
we can easily reuse device trees for pinctrl.
Please put it on the table for discussion.
Let me explain how it works.
The basic idea is pretty much like Linux, but it has been much simplified
because full-support of the Linux's pinctrl is too much a burden for a
boot-loader.
Device Tree
---
To use pinctrl from each peripheral, add some properties in the device node.
pinctrl-names is a list of pin states. The default state is mandatory,
and it would probably be enough for U-Boot. But, in order to show how it
works,
say the example device supports two states: default and sleep.
In this case, the properties should be like this.
pinctrl-names = default, sleep;
And then, add as many pinctrl-N properties as the number of states.
pinctrl-0 = phandle to default config node;
pinctrl-1 = phandle to sleep config node;
Here, pinctrl-0, pinctrl-1 corresponds to default, sleep, respectively.
The config nodes are (direct or indirect) children of a pinctrl device.
To sum up, the device tree would be like this:
foo {
compatible = ...;
reg = ...;
pinctrl-names = default, sleep;
pinctrl-0 = foo_default_pin;
pinctrl-1 = foo_sleep_pin;
...
};
pinctrl {
compatible = ...;
reg = ...;
foo_default_pin: foo_default {
groups = ...;
functions = ...;
};
foo_sleep_pin: foo_sleep {
groups = ...;
functions = ...;
};
};
API
---
To set a device into a particular pin state, call
int pinctrl_set_state(struct udevice *dev, const char *state_name).
For example, if you want to set the foo device into the sleep state,
you can do like this:
struct udevice *foo_dev;
(device_get or whatever)
pinctrl_set_state(foo_dev, sleep);
When each device is probed, pinctrl_init() is invoked,
which initializes some pinctrl-specific parameters and set it into default
pin state. Because it is automatically done by the core of driver model,
when a device is probed, its pins are in the default state.
Implementation of low-level driver
--
Currently, two methods are supported in the pinctrl operation:
struct pinctrl_ops {
int (*pinmux_set) (struct udevice *dev, const char *group,
const char *function);
int (*pinconf_set) (struct udevice *dev, const char *group,
const char *conf_param, unsigned conf_arg);
};
They are used to change pin-mux, pin-conf, respectively.
If the pin-config node for the target pin-state is like this,
i2c_default_pin: i2c_default {
groups = i2c-0a;
functions = i2c-0;
};
Your pinmux_set() is called with i2c-0a for the group and i2c-0
for the function.
It is totally up to you what you do for each group function.
Difference from Linux pinctrl (limitation)
-
As you can see in pinctrl drivers in Linux (drivers/pinctrl/*),
the drivers usually contain huge tables for pins, groups, functions,...
But I do not want to force that for U-Boot.
In Linux, group represents a group of pins although a group
Re: [U-Boot] [RFC PATCH 1/7] pinctrl: add pinctrl framework
Hi Masahiro,
On 18 July 2015 at 08:37, Simon Glass s...@chromium.org wrote:
Hi Masahiro,
On 15 July 2015 at 02:16, Masahiro Yamada yamada.masah...@socionext.com
wrote:
Now, a simple pinctrl patch is being proposed by Simon.
http://patchwork.ozlabs.org/patch/487801/
In the design above, as you see, the uclass is just like a wrapper layer
to invoke .request and .get_periph_id of low-level drivers.
In other words, it is Do-It-Yourself thing, so it is up to you how to
identify
which peripheral is being handled in your .get_periph_id().
And here is one example for how a low-level pinctrl driver could be
implemented.
http://patchwork.ozlabs.org/patch/487874/
As you see in the thread, honestly, I do not like this approach.
It is true that you can implement .get_periph_id in your driver
better than parsing interrupts properties, but I guess
many drivers would follow the rockchip implmentation because
no helpful infrastructure is provided by the uclass (at least now).
Device trees describe hardwares in a way independent of software
that they are used with. So, identical device trees can be (should be)
used with U-Boot as well as Linux or whatever.
Thus, I want the pinctrl can be controllable by device trees in the same way
of Linux, that is, by parsing pinctrl-names and pinctrl-N properties.
Of course, it would be possible to do it in my own .get_periph_id,
but pinctrl-names and pinctrl-N are too generic to be done in each
low-level driver.
In this series, I'd like to propose to support it in the uclass, so that
we can easily reuse device trees for pinctrl.
Please put it on the table for discussion.
Let me explain how it works.
The basic idea is pretty much like Linux, but it has been much simplified
because full-support of the Linux's pinctrl is too much a burden for a
boot-loader.
Device Tree
---
To use pinctrl from each peripheral, add some properties in the device node.
pinctrl-names is a list of pin states. The default state is mandatory,
and it would probably be enough for U-Boot. But, in order to show how it
works,
say the example device supports two states: default and sleep.
In this case, the properties should be like this.
pinctrl-names = default, sleep;
And then, add as many pinctrl-N properties as the number of states.
pinctrl-0 = phandle to default config node;
pinctrl-1 = phandle to sleep config node;
Here, pinctrl-0, pinctrl-1 corresponds to default, sleep, respectively.
The config nodes are (direct or indirect) children of a pinctrl device.
To sum up, the device tree would be like this:
foo {
compatible = ...;
reg = ...;
pinctrl-names = default, sleep;
pinctrl-0 = foo_default_pin;
pinctrl-1 = foo_sleep_pin;
...
};
pinctrl {
compatible = ...;
reg = ...;
foo_default_pin: foo_default {
groups = ...;
functions = ...;
};
foo_sleep_pin: foo_sleep {
groups = ...;
functions = ...;
};
};
API
---
To set a device into a particular pin state, call
int pinctrl_set_state(struct udevice *dev, const char *state_name).
For example, if you want to set the foo device into the sleep state,
you can do like this:
struct udevice *foo_dev;
(device_get or whatever)
pinctrl_set_state(foo_dev, sleep);
When each device is probed, pinctrl_init() is invoked,
which initializes some pinctrl-specific parameters and set it into default
pin state. Because it is automatically done by the core of driver model,
when a device is probed, its pins are in the default state.
Implementation of low-level driver
--
Currently, two methods are supported in the pinctrl operation:
struct pinctrl_ops {
int (*pinmux_set) (struct udevice *dev, const char *group,
const char *function);
int (*pinconf_set) (struct udevice *dev, const char *group,
const char *conf_param, unsigned conf_arg);
};
They are used to change pin-mux, pin-conf, respectively.
If the pin-config node for the target pin-state is like this,
i2c_default_pin: i2c_default {
groups = i2c-0a;
functions = i2c-0;
};
Your pinmux_set() is called with i2c-0a for the group and i2c-0
for the function.
It is totally up to you what you do for each group function.
Difference from Linux pinctrl (limitation)
-
As you can see in pinctrl drivers in Linux (drivers/pinctrl/*),
the drivers usually contain huge tables for pins, groups, functions,...
But I do not want to force that for U-Boot.
In Linux, group represents a group of pins although a group sometimes
consists of a signle pin (like GPIO). Pin-muxing is available only against
groups, while pin-conf is
Re: [U-Boot] [RFC PATCH 1/7] pinctrl: add pinctrl framework
Hi Masahiro,
On 15 July 2015 at 02:16, Masahiro Yamada yamada.masah...@socionext.com wrote:
Now, a simple pinctrl patch is being proposed by Simon.
http://patchwork.ozlabs.org/patch/487801/
In the design above, as you see, the uclass is just like a wrapper layer
to invoke .request and .get_periph_id of low-level drivers.
In other words, it is Do-It-Yourself thing, so it is up to you how to identify
which peripheral is being handled in your .get_periph_id().
And here is one example for how a low-level pinctrl driver could be
implemented.
http://patchwork.ozlabs.org/patch/487874/
As you see in the thread, honestly, I do not like this approach.
It is true that you can implement .get_periph_id in your driver
better than parsing interrupts properties, but I guess
many drivers would follow the rockchip implmentation because
no helpful infrastructure is provided by the uclass (at least now).
Device trees describe hardwares in a way independent of software
that they are used with. So, identical device trees can be (should be)
used with U-Boot as well as Linux or whatever.
Thus, I want the pinctrl can be controllable by device trees in the same way
of Linux, that is, by parsing pinctrl-names and pinctrl-N properties.
Of course, it would be possible to do it in my own .get_periph_id,
but pinctrl-names and pinctrl-N are too generic to be done in each
low-level driver.
In this series, I'd like to propose to support it in the uclass, so that
we can easily reuse device trees for pinctrl.
Please put it on the table for discussion.
Let me explain how it works.
The basic idea is pretty much like Linux, but it has been much simplified
because full-support of the Linux's pinctrl is too much a burden for a
boot-loader.
Device Tree
---
To use pinctrl from each peripheral, add some properties in the device node.
pinctrl-names is a list of pin states. The default state is mandatory,
and it would probably be enough for U-Boot. But, in order to show how it
works,
say the example device supports two states: default and sleep.
In this case, the properties should be like this.
pinctrl-names = default, sleep;
And then, add as many pinctrl-N properties as the number of states.
pinctrl-0 = phandle to default config node;
pinctrl-1 = phandle to sleep config node;
Here, pinctrl-0, pinctrl-1 corresponds to default, sleep, respectively.
The config nodes are (direct or indirect) children of a pinctrl device.
To sum up, the device tree would be like this:
foo {
compatible = ...;
reg = ...;
pinctrl-names = default, sleep;
pinctrl-0 = foo_default_pin;
pinctrl-1 = foo_sleep_pin;
...
};
pinctrl {
compatible = ...;
reg = ...;
foo_default_pin: foo_default {
groups = ...;
functions = ...;
};
foo_sleep_pin: foo_sleep {
groups = ...;
functions = ...;
};
};
API
---
To set a device into a particular pin state, call
int pinctrl_set_state(struct udevice *dev, const char *state_name).
For example, if you want to set the foo device into the sleep state,
you can do like this:
struct udevice *foo_dev;
(device_get or whatever)
pinctrl_set_state(foo_dev, sleep);
When each device is probed, pinctrl_init() is invoked,
which initializes some pinctrl-specific parameters and set it into default
pin state. Because it is automatically done by the core of driver model,
when a device is probed, its pins are in the default state.
Implementation of low-level driver
--
Currently, two methods are supported in the pinctrl operation:
struct pinctrl_ops {
int (*pinmux_set) (struct udevice *dev, const char *group,
const char *function);
int (*pinconf_set) (struct udevice *dev, const char *group,
const char *conf_param, unsigned conf_arg);
};
They are used to change pin-mux, pin-conf, respectively.
If the pin-config node for the target pin-state is like this,
i2c_default_pin: i2c_default {
groups = i2c-0a;
functions = i2c-0;
};
Your pinmux_set() is called with i2c-0a for the group and i2c-0
for the function.
It is totally up to you what you do for each group function.
Difference from Linux pinctrl (limitation)
-
As you can see in pinctrl drivers in Linux (drivers/pinctrl/*),
the drivers usually contain huge tables for pins, groups, functions,...
But I do not want to force that for U-Boot.
In Linux, group represents a group of pins although a group sometimes
consists of a signle pin (like GPIO). Pin-muxing is available only against
groups, while pin-conf is supported for both pins and groups.
In contrast, in U-Boot, pins and groups are
Re: [U-Boot] [RFC PATCH 1/7] pinctrl: add pinctrl framework
Memory footprint analysis: This uclass support increased 2.5KB on my board (ARM). Additional 1-2KB would be necessary to implement your low-level driver. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/7] pinctrl: add pinctrl framework
Hello Masahiro,
On Wed, 15 Jul 2015 17:16:16 +0900, Masahiro Yamada
yamada.masah...@socionext.com wrote:
Now, a simple pinctrl patch is being proposed by Simon.
http://patchwork.ozlabs.org/patch/487801/
In the design above, as you see, the uclass is just like a wrapper layer
to invoke .request and .get_periph_id of low-level drivers.
In other words, it is Do-It-Yourself thing, so it is up to you how to identify
which peripheral is being handled in your .get_periph_id().
And here is one example for how a low-level pinctrl driver could be
implemented.
http://patchwork.ozlabs.org/patch/487874/
As you see in the thread, honestly, I do not like this approach.
It is true that you can implement .get_periph_id in your driver
better than parsing interrupts properties, but I guess
many drivers would follow the rockchip implmentation because
no helpful infrastructure is provided by the uclass (at least now).
Device trees describe hardwares in a way independent of software
that they are used with. So, identical device trees can be (should be)
used with U-Boot as well as Linux or whatever.
Thus, I want the pinctrl can be controllable by device trees in the same way
of Linux, that is, by parsing pinctrl-names and pinctrl-N properties.
Of course, it would be possible to do it in my own .get_periph_id,
but pinctrl-names and pinctrl-N are too generic to be done in each
low-level driver.
In this series, I'd like to propose to support it in the uclass, so that
we can easily reuse device trees for pinctrl.
Please put it on the table for discussion.
Let me explain how it works.
The basic idea is pretty much like Linux, but it has been much simplified
because full-support of the Linux's pinctrl is too much a burden for a
boot-loader.
Device Tree
---
To use pinctrl from each peripheral, add some properties in the device node.
pinctrl-names is a list of pin states. The default state is mandatory,
and it would probably be enough for U-Boot. But, in order to show how it
works,
say the example device supports two states: default and sleep.
In this case, the properties should be like this.
pinctrl-names = default, sleep;
And then, add as many pinctrl-N properties as the number of states.
pinctrl-0 = phandle to default config node;
pinctrl-1 = phandle to sleep config node;
Here, pinctrl-0, pinctrl-1 corresponds to default, sleep, respectively.
The config nodes are (direct or indirect) children of a pinctrl device.
To sum up, the device tree would be like this:
foo {
compatible = ...;
reg = ...;
pinctrl-names = default, sleep;
pinctrl-0 = foo_default_pin;
pinctrl-1 = foo_sleep_pin;
...
};
pinctrl {
compatible = ...;
reg = ...;
foo_default_pin: foo_default {
groups = ...;
functions = ...;
};
foo_sleep_pin: foo_sleep {
groups = ...;
functions = ...;
};
};
API
---
To set a device into a particular pin state, call
int pinctrl_set_state(struct udevice *dev, const char *state_name).
For example, if you want to set the foo device into the sleep state,
you can do like this:
struct udevice *foo_dev;
(device_get or whatever)
pinctrl_set_state(foo_dev, sleep);
When each device is probed, pinctrl_init() is invoked,
which initializes some pinctrl-specific parameters and set it into default
pin state. Because it is automatically done by the core of driver model,
when a device is probed, its pins are in the default state.
Implementation of low-level driver
--
Currently, two methods are supported in the pinctrl operation:
struct pinctrl_ops {
int (*pinmux_set) (struct udevice *dev, const char *group,
const char *function);
int (*pinconf_set) (struct udevice *dev, const char *group,
const char *conf_param, unsigned conf_arg);
};
They are used to change pin-mux, pin-conf, respectively.
If the pin-config node for the target pin-state is like this,
i2c_default_pin: i2c_default {
groups = i2c-0a;
functions = i2c-0;
};
Your pinmux_set() is called with i2c-0a for the group and i2c-0
for the function.
It is totally up to you what you do for each group function.
Difference from Linux pinctrl (limitation)
-
As you can see in pinctrl drivers in Linux (drivers/pinctrl/*),
the drivers usually contain huge tables for pins, groups, functions,...
But I do not want to force that for U-Boot.
In Linux, group represents a group of pins although a group sometimes
consists of a signle pin (like GPIO). Pin-muxing is available only against
groups, while pin-conf is supported for both pins and groups.
In contrast,
Re: [U-Boot] [RFC PATCH 1/7] pinctrl: add pinctrl framework
I forgot to mention this: This series needs libfdt fixes as prerequisites: http://patchwork.ozlabs.org/patch/495166/ http://patchwork.ozlabs.org/patch/495168/ This patch depends on some libfdt helpers that are fatally buggy. Masahiro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/7] pinctrl: add pinctrl framework
2015-07-15 17:53 GMT+09:00 Albert ARIBAUD albert.u.b...@aribaud.net:
Hello Masahiro,
On Wed, 15 Jul 2015 17:16:16 +0900, Masahiro Yamada
yamada.masah...@socionext.com wrote:
Now, a simple pinctrl patch is being proposed by Simon.
http://patchwork.ozlabs.org/patch/487801/
In the design above, as you see, the uclass is just like a wrapper layer
to invoke .request and .get_periph_id of low-level drivers.
In other words, it is Do-It-Yourself thing, so it is up to you how to
identify
which peripheral is being handled in your .get_periph_id().
And here is one example for how a low-level pinctrl driver could be
implemented.
http://patchwork.ozlabs.org/patch/487874/
As you see in the thread, honestly, I do not like this approach.
It is true that you can implement .get_periph_id in your driver
better than parsing interrupts properties, but I guess
many drivers would follow the rockchip implmentation because
no helpful infrastructure is provided by the uclass (at least now).
Device trees describe hardwares in a way independent of software
that they are used with. So, identical device trees can be (should be)
used with U-Boot as well as Linux or whatever.
Thus, I want the pinctrl can be controllable by device trees in the same way
of Linux, that is, by parsing pinctrl-names and pinctrl-N properties.
Of course, it would be possible to do it in my own .get_periph_id,
but pinctrl-names and pinctrl-N are too generic to be done in each
low-level driver.
In this series, I'd like to propose to support it in the uclass, so that
we can easily reuse device trees for pinctrl.
Please put it on the table for discussion.
Let me explain how it works.
The basic idea is pretty much like Linux, but it has been much simplified
because full-support of the Linux's pinctrl is too much a burden for a
boot-loader.
Device Tree
---
To use pinctrl from each peripheral, add some properties in the device node.
pinctrl-names is a list of pin states. The default state is mandatory,
and it would probably be enough for U-Boot. But, in order to show how it
works,
say the example device supports two states: default and sleep.
In this case, the properties should be like this.
pinctrl-names = default, sleep;
And then, add as many pinctrl-N properties as the number of states.
pinctrl-0 = phandle to default config node;
pinctrl-1 = phandle to sleep config node;
Here, pinctrl-0, pinctrl-1 corresponds to default, sleep, respectively.
The config nodes are (direct or indirect) children of a pinctrl device.
To sum up, the device tree would be like this:
foo {
compatible = ...;
reg = ...;
pinctrl-names = default, sleep;
pinctrl-0 = foo_default_pin;
pinctrl-1 = foo_sleep_pin;
...
};
pinctrl {
compatible = ...;
reg = ...;
foo_default_pin: foo_default {
groups = ...;
functions = ...;
};
foo_sleep_pin: foo_sleep {
groups = ...;
functions = ...;
};
};
API
---
To set a device into a particular pin state, call
int pinctrl_set_state(struct udevice *dev, const char *state_name).
For example, if you want to set the foo device into the sleep state,
you can do like this:
struct udevice *foo_dev;
(device_get or whatever)
pinctrl_set_state(foo_dev, sleep);
When each device is probed, pinctrl_init() is invoked,
which initializes some pinctrl-specific parameters and set it into default
pin state. Because it is automatically done by the core of driver model,
when a device is probed, its pins are in the default state.
Implementation of low-level driver
--
Currently, two methods are supported in the pinctrl operation:
struct pinctrl_ops {
int (*pinmux_set) (struct udevice *dev, const char *group,
const char *function);
int (*pinconf_set) (struct udevice *dev, const char *group,
const char *conf_param, unsigned conf_arg);
};
They are used to change pin-mux, pin-conf, respectively.
If the pin-config node for the target pin-state is like this,
i2c_default_pin: i2c_default {
groups = i2c-0a;
functions = i2c-0;
};
Your pinmux_set() is called with i2c-0a for the group and i2c-0
for the function.
It is totally up to you what you do for each group function.
Difference from Linux pinctrl (limitation)
-
As you can see in pinctrl drivers in Linux (drivers/pinctrl/*),
the drivers usually contain huge tables for pins, groups, functions,...
But I do not want to force that for U-Boot.
In Linux, group represents a group of pins although a group sometimes
consists of a signle pin (like GPIO). Pin-muxing is available only against
groups, while pin-conf is supported for
