Nvec dt

Материал из Toshiba AC100 wiki
Перейти к: навигация, поиск

Links

[1] [[RFC binding for nvec mfd device]] [2] Device Tree Usage [3] ePAPR specification [4] arch/arm/boot/dts/tegra20.dtsi [5] http://lists.denx.de/pipermail/u-boot/2014-April/178449.html

Intro

Here is my step-by-step vision of dt for nvec. There is few requirements: 1) DT must describe hardware, but not software. 2) DT must be enough for SW implementation.

Configurations

I. i2c_controller_master { i2c_device_master, i2c_device_master, i2c_device_slave, i2c_device_slave } II. i2c_controller_master { i2c_device_slave, i2c_device_slave } III. i2c_controller_slave { i2c_device_master, i2c_device_master, i2c_device_slave, i2c_device_slave } IV. i2c_controller_slave { i2c_device_slave, i2c_device_slave } - impossible

Addressing

a) #address-cells / #size-cells, master/slave by first value (child)

I2C controller node has #address-cells 1 or 2 (1 means master mode only, 2 mean master/slave mode possible) There are now two ways to set address in the I2C child nodes:

a) reg = <slave address> ordinary child operating in slave mode, address-cells of parent is 1

b) reg = <0 slave address> alternative form of above if address-cells is 2 (master and slave mode of controller possible)

c) reg = <1 master address> child operates in master mode, address-cells must be 2

initially, the i2c controller runs its old setup code (does not enable slave mode). If the child (in master mode operation) gets instantiated, it tells the i2c controller via some api that it should setup slave mode.

I. i2c_controller - master

devices - masters and slaves

i2c_controller {
    reg = <0x7000c500 0x100>
    #address-cells = <2>
    i2c_device_master {
        reg = <0x01 0x87>
    }
    i2c_device_slave {
        reg = <0x00 0x87>
    }
}
II. i2c_controller - master

devices - all slaves

i2c_controller {
    reg = <0x7000c500 0x100>
    #address-cells = <1>
    i2c_device_slave {
        reg = <0x87>
    }
}
III. i2c_controller - slave

devices - masters and slaves

i2c_controller {
    reg = <0x7000c500 0x100>
    #address-cells = <2>
    i2c_device_master {
        reg = <0x01 0x87>
    }
    i2c_device_slave {
        reg = <0x00 0x87>
    }
}

b) extend "reg" property

I. i2c_controller - master

devices - masters and slaves

i2c_controller {
    reg = <0x7000c500 0x100>
    i2c_device_master {
        ???
    }
    i2c_device_slave {
        ???
    }
}
II. i2c_controller - master

devices - all slaves

i2c_controller {
    reg = <0x7000c500 0x100>
    i2c_device_slave {
        reg = <0x87>
    }
}
III. i2c_controller - slave

devices - masters and slaves

i2c_controller {
    reg = <0x7000c500 0x100 0x87 0>
    i2c_device_master {
        reg = <0x00>
    }
    i2c_device_slave {
        reg = <0x87>
    }}

c) use "alternate-reg" property (see PCI Bus Binding to IEEE Std 1275-1994 Standard for Boot)

I. i2c_controller - master

devices - masters and slaves

i2c_controller {
    reg = <0x7000c500 0x100>
    i2c_device_master {
        reg = <0x89>
    }
    i2c_device_slave {
        reg = <0x87>
    }
}
II. i2c_controller - master

devices - all slaves

i2c_controller {
    reg = <0x7000c500 0x100>
    i2c_device_slave {
       reg = <0x87>
    }
}
III. i2c_controller - slave

devices - masters and slaves

i2c_controller {
    reg = <0x7000c500 0x100>
    alternate-reg = <0x87>
    i2c_device_master {
        reg = <0x00>
    }
    i2c_device_slave {
        reg = <0x87>
    }
}

d) use tricky bits ???

e) tricky bits on childs (TODO: make a clear description)

I. i2c_controller - master

devices - masters and slaves

i2c_controller {
    reg = <0x7000c500 0x100>
    ???
    i2c_device_master {
        reg = <0x0187>
    }
    i2c_device_slave {
        reg = <0x0087>
    }
}
II. i2c_controller - master

devices - all slaves

i2c_controller {
    reg = <0x7000c500 0x100>
    i2c_device_slave {
        reg = <0x0087>
    }
}
III. i2c_controller - slave

devices - masters and slaves

i2c_controller {
    reg = <0x7000c500 0x100>
    i2c_device_master {
        reg = <0x0187>
    }
    i2c_device_slave {
        reg = <0x0087>
    }
}


OLD

General

Root node is SOC. <name>[@<unit-address>]. : name - device type, unit-address - address, that is used to access device

a) SOC can have multiple i2c controllers. b) Some of controllers can be master and/or slave at the same time. c) Some of controllers can be connected to same i2c bus. d) In some cases slave may want attention from master.

a) SOC can have multiple i2c controllers. OK, it's current implementation

b) ??? Some of controllers can be master and/or slave at the same time. Q: Need a way for SW to select mode. How it should be done ?

[email protected] {
    compatible = "nvidia,tegra20-i2c";
    ???
}

Possible values: master, slave, master and slave, sw decides In current implementation i2c controller is master, i2c device is slave.

c) Some of controllers can be connected to same i2c bus. Q: Do we need information, that both controllers are on the same bus.

[email protected] {
    compatible = "nvidia,tegra20-i2c";
    ???
}
[email protected] {
    compatible = "nvidia,tegra20-i2c";
    ???
}

A: Useless case. Forget.

d) In some cases slave may want attention from master. Q: Who should contain information about "gpio" ? Master or slave ?

[email protected] {
    compatible = "vendor,device";
    mode = "slave";

    [email protected] {
        compatible = "nvidia,nvec";
        mode = "master";
        reg = <0x87>;
    };
}

If i2c controller don't know about gpios, then there is no reason to add this field to it's node. Only nvec knows about gpios. This is a reason why we should add gpio to nvec node.

Nvec

Root node is tegra20. This means that parent i2c node should be tegra's i2c controller.

[email protected] {
    compatible = "nvidia,tegra20-i2c-slave";
}

Nvec is child node.

[email protected] {
    compatible = "nvidia,tegra20-i2c-slave";
    reg = <0x7000c500 0x100>;

    [email protected] {
        compatible = "nvidia,nvec";
        reg = <0x87>;
    };
}


Software interaction

Common: [ master ] --i2c-- [ slave ] | [ i2c-master ] ---- [ i2c-slave ] Nvec: [ Nvec ] --i2c-- [ Tegra20 ] | [ tegra20-i2c ] ---- [ nvec ] Left side - hardware components, right side - software drivers.

TODO: describe communication process


Discussion

[email protected] {
    compatible = "nvidia,tegra20-i2c-slave", "simple-bus";
    reg = <0x7000c500 0x100>;
    interrupts = <0 92 0x04>;
    #address-cells = <1>;
    #size-cells = <0>;
    clock-frequency = <80000>;
    clocks = <&tegra_car 67>, <&tegra_car 124>;
    clock-names = "div-clk", "fast-clk";

    [email protected] {
        compatible = "nvidia,nvec", "simple-bus";
        reg = <0x87>;
        request-gpios = <&gpio TEGRA_GPIO(V, 2) 0>;

        keyboard {
            compatible = "nvidia,nvec-keyboard";
            ...
            <insert key mappings here>
            ...
        };

        ps2 {
            compatible = "nvidia,nvec-ps2";
            packet-size = 6; /* for the ac100 tp */
        };

        events {
            compatible = "nvidia,nvec-events";
            ...
            <add some system events here,
                e.g. lid switch, power button>
            ...
        };

        charger: ac {
            compatible = "nvidia,nvec-ac";
        };

        battery {
            compatible = "nvidia,nvec-battery";
            charger = <&charger>;
       };

        oem {
            compatible = "compal,nvec-paz00";
            /* ac100 specific extentions to the protocol */
        };
    };
};
  • simple bus (smbus) - where to define
  • GPIO is part of the NVEC (?)
  • If you need to instantiate child nodes as Linux platform devices, this should be done in the driver for the bus. Relying on simple-bus to do this is a hack.