Am Donnerstag, 11. September 2014, 16:54:22 schrieb Wolfram Sang:
On Thu, Sep 11, 2014 at 04:52:22PM +0200, Marc Dietrich wrote:
Am Donnerstag, 11. September 2014, 16:40:04 schrieb Wolfram Sang:
b) could be seen as a configuration thing since the functionality
backend could be changed
Hi Marc,
On Fri, Sep 12, 2014 at 9:51 AM, Marc Dietrich marvi...@gmx.de wrote:
Am Donnerstag, 11. September 2014, 16:54:22 schrieb Wolfram Sang:
On Thu, Sep 11, 2014 at 04:52:22PM +0200, Marc Dietrich wrote:
Am Donnerstag, 11. September 2014, 16:40:04 schrieb Wolfram Sang:
b) could be
Why do you want DT to be involved at all?
Imagine a device which supports both, slave or master mode. The driver needs
to know in which mode it should operate. This cannot be hard coded, because
on
different boards, different modes can be used.
Okay, it sounds weird to me that a
Am Freitag, 12. September 2014, 10:33:48 schrieb Wolfram Sang:
Why do you want DT to be involved at all?
Imagine a device which supports both, slave or master mode. The driver
needs to know in which mode it should operate. This cannot be hard coded,
because on different boards,
ok, take our embedded controller driver (in staging/nvec) as an example. It's
basicly an MFD connecting keyboard, mouse, power, gpio, and some other stuff
to the soc. The MFD operates in master mode while the SOC is the I2C slave.
Theoretically, these roles could also switch (but that's
Hi Wolfram,
On Fri, Sep 12, 2014 at 11:58 AM, Wolfram Sang w...@the-dreams.de wrote:
2) Slave mode is needed for board bringup
Some other components need a specific I2C slave to be present before
userspace is available, otherwise the system is unusable. This is IMO
then a hardware
DT pseudocode:
i2c {
compatible = nvidia, tegra-i2c;
ec-slave@42 {
compatible = nvidia, ax100-ec-slave;
reg = 0x42;
};
};
So distinguishing between drivers
Am Freitag, 12. September 2014, 11:58:21 schrieb Wolfram Sang:
ok, take our embedded controller driver (in staging/nvec) as an example.
It's basicly an MFD connecting keyboard, mouse, power, gpio, and some
other stuff to the soc. The MFD operates in master mode while the SOC is
the I2C
Am I missing something? Board properties can be encoded within the
compatible entries (ax100-ec, ax200-ec...). I'd think this means
mostly different protocols, though.
well, ac100 is the name of the board and nvec is the name of the protocol.
Yes, the driver could be named nvec, yet
cc'ing: devicetree
Am Dienstag, 9. September 2014, 16:54:30 schrieb Wolfram Sang:
From: Wolfram Sang wsa+rene...@sang-engineering.com
Not for upstream!
Signed-off-by: Wolfram Sang wsa+rene...@sang-engineering.com
---
arch/arm/boot/dts/r8a7790-lager.dts | 15 ++-
1 file
On Thu, Sep 11, 2014 at 02:17:16PM +0200, Marc Dietrich wrote:
cc'ing: devicetree
Thanks, I forgot that!
-iic1 {
+i2c1 {
status = ok;
- pinctrl-0 = iic1_pins;
+ pinctrl-0 = i2c1_pins;
pinctrl-names = default;
+
+ eeprom@64 {
+ compatible =
b) could be seen as a configuration thing since the functionality
backend could be changed at runtime even.
Come to think of it, not only the functionality, also the address can be
changed at runtime. This makes me think it should really not be in DT
after all.
People will probably find out
Am Donnerstag, 11. September 2014, 16:12:58 schrieb Wolfram Sang:
On Thu, Sep 11, 2014 at 02:17:16PM +0200, Marc Dietrich wrote:
+ reg = 0x64;
we had some discussions in the past how to represent i2c master devices in
device tree. The outcome was to use to a special
Am Donnerstag, 11. September 2014, 16:40:04 schrieb Wolfram Sang:
b) could be seen as a configuration thing since the functionality
backend could be changed at runtime even.
Come to think of it, not only the functionality, also the address can be
changed at runtime. This makes me think it
On Thu, Sep 11, 2014 at 04:52:22PM +0200, Marc Dietrich wrote:
Am Donnerstag, 11. September 2014, 16:40:04 schrieb Wolfram Sang:
b) could be seen as a configuration thing since the functionality
backend could be changed at runtime even.
Come to think of it, not only the functionality,
From: Wolfram Sang wsa+rene...@sang-engineering.com
Not for upstream!
Signed-off-by: Wolfram Sang wsa+rene...@sang-engineering.com
---
arch/arm/boot/dts/r8a7790-lager.dts | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
16 matches
Mail list logo
