summaryrefslogtreecommitdiff
path: root/drivers/i2c/i2c-uclass.c
Commit message (Collapse)AuthorAgeLines
* dm: Use dm_scan_fdt_dev() directly where possibleSimon Glass2016-07-27-11/+3
| | | | | | | Quite a few places have a bind() method which just calls dm_scan_fdt_dev(). We may as well call dm_scan_fdt_dev() directly. Update the code to do this. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: Convert users from dm_scan_fdt_node() to dm_scan_fdt_dev()Simon Glass2016-07-27-2/+1
| | | | | | | This new function is more convenient for callers, and handles pre-relocation situations automatically. Signed-off-by: Simon Glass <sjg@chromium.org>
* drivers: i2c: uclass: parse dt parameters only when CONFIG_OF_CONTROL is enableMugunthan V N2016-07-26-0/+14
| | | | | | | | parse dt parameter of i2c devices only when CONFIG_OF_CONTROL is enabled. Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* dm: i2c: Add a function to transfer messagesSimon Glass2015-08-05-0/+11
| | | | | | | | | | | Sometimes it is useful to be able to transfer a raw I2C message. This happens when the chip address needs to be set manually, or when the data to be sent/received is in another buffer. Add a function to provide access to this. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de>
* dm: i2c: Add a message debug functionSimon Glass2015-08-05-0/+16
| | | | | | | Add a way to dump the contents of an I2C message for debugging purposes. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de>
* dm: i2c: Add a function to find out the chip offset lengthSimon Glass2015-05-14-0/+7
| | | | | | | | We can currently set this but there is no API function to get it. Add one. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Joe Hershberger <joe.hershberger@ni.com> Acked-by: Heiko Schocher<hs@denx.de>
* dm: i2c: Add functions to read and write a registerSimon Glass2015-05-05-0/+19
| | | | | | | | Add driver model versions of the legacy functions to read and write a single byte register. These are a useful shortcut in many cases. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de>
* dm: core: Add dev_get_uclass_priv() to access uclass private dataSimon Glass2015-04-16-3/+3
| | | | | | | | Add a convenience function to access the private data that a uclass stores for each of its devices. Convert over most existing uses for consistency and to provide an example for others. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: i2c: Add a missing memory allocaton checkSimon Glass2015-03-05-0/+2
| | | | | | | This strdup() is missing a check. Add it. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de>
* dm: i2c: Add a dm_ prefix to driver model bus speed functionsSimon Glass2015-02-12-8/+3
| | | | | | | | As with i2c_read() and i2c_write(), add a dm_ prefix to the driver model versions of these functions to avoid conflicts. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de>
* dm: i2c: dts: Support an offset-len device tree propertySimon Glass2015-01-29-1/+2
| | | | | | | Since U-Boot can support different offset lengths (0-4 bytes), add a device tree property to specify this. This avoids hard-coding it in the driver. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: i2c: Move slave details to child platdataSimon Glass2015-01-29-22/+32
| | | | | | | | | | | | | | | | | At present we go through various contortions to store the I2C's chip address in its private data. This only exists when the chip is active so must be set up when it is probed. Until the device is probed we don't actually record what address it will appear on. However, now that we can support per-child platform data, we can use that instead. This allows us to set up the address when the child is bound, and avoid the messy contortions. Unfortunately this is a fairly large change and it seems to be difficult to break it down further. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
* dm: core: Add a flag to control sequence numberingSimon Glass2015-01-29-0/+1
| | | | | | | | | | | | | | | | At present we try to use the 'reg' property and device tree aliases to give devices a sequence number. The 'reg' property is often actually a memory address, so the sequence numbers thus-obtained are not useful. It would be better if the devices were just sequentially numbered in that case. In fact neither I2C nor SPI use this feature, so drop it. Some devices need us to look up an alias to number them within the uclass. Add a flag to control this, so it is not done unless it is needed. Adjust the tests to test this new behaviour. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
* dm: i2c: Provide an offset length parameter where neededSimon Glass2015-01-29-7/+9
| | | | | | | | | | Rather than assuming that the chip offset length is 1, allow it to be provided. This allows chips that don't use the default offset length to be used (at present they are only supported by the command line 'i2c' command which sets the offset length explicitly). Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Heiko Schocher <hs@denx.de>
* dm: i2c: Rename driver model I2C functions to permit compatibilitySimon Glass2015-01-29-4/+5
| | | | | | | | | | | Add a dm_ prefix to driver model I2C functions so that we can keep the old ones around. This is a little unfortunate, but on reflection it is too difficult to change the API. We can undo this rename when most boards and drivers are converted to use driver model for I2C. Signed-off-by: Simon Glass <sjg@chromium.org>
* dm: i2c: Add a uclass for I2CSimon Glass2014-12-11-0/+466
The uclass implements the same operations as the current I2C framework but makes some changes to make it fit driver model better: - Remove the chip address from API calls - Remove the address length from API calls - Remove concept of 'current' I2C bus - Drop all existing init functions Acked-by: Heiko Schocher <hs@denx.de> Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Signed-off-by: Simon Glass <sjg@chromium.org>