| Message ID | 20171214151610.19153-1-boris.brezillon@free-electrons.com |
|---|---|
| Headers | show |
| Series | Add the I3C subsystem | expand |
On 12/14/2017 07:16 AM, Boris Brezillon wrote: > Add a driver for Cadence I3C master IP. > > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> > --- > Changes in v2: > - Add basic IBI support. Note that the IP is not really reliable with > regards to IBI because you can't extract IBI payloads as soon as you > have more than one IBI waiting in the HW queue. This is something > that will hopefully be addressed in future revisions of this IP > - Add a simple xfer queueing mechanism to optimize message queuing. > - Fix a few bugs > - Add support for Hot Join > --- > drivers/i3c/master/Kconfig | 5 + > drivers/i3c/master/Makefile | 1 + > drivers/i3c/master/i3c-master-cdns.c | 1797 ++++++++++++++++++++++++++++++++++ > 3 files changed, 1803 insertions(+) > create mode 100644 drivers/i3c/master/i3c-master-cdns.c > > diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig > index e69de29bb2d1..56b9a18543b2 100644 > --- a/drivers/i3c/master/Kconfig > +++ b/drivers/i3c/master/Kconfig > @@ -0,0 +1,5 @@ > +config CDNS_I3C_MASTER > + tristate "Cadence I3C master driver" > + depends on I3C > + help > + Enable this driver if you want to support Cadence I3C master block. > diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile > index e69de29bb2d1..4c4304aa9534 100644 > --- a/drivers/i3c/master/Makefile > +++ b/drivers/i3c/master/Makefile > @@ -0,0 +1 @@ > +obj-$(CONFIG_CDNS_I3C_MASTER) += i3c-master-cdns.o > diff --git a/drivers/i3c/master/i3c-master-cdns.c b/drivers/i3c/master/i3c-master-cdns.c > new file mode 100644 > index 000000000000..3e3ef37c01c2 > --- /dev/null > +++ b/drivers/i3c/master/i3c-master-cdns.c > @@ -0,0 +1,1797 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2017 Cadence Design Systems Inc. > + * > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com> > + */ > + Rule #1 from submit-checklist.rst: 1) If you use a facility then #include the file that defines/declares that facility. Don't depend on other header files pulling in ones that you use. #include <linux/bitops.h> for BIT(x) and hweight8() and clear_bit() and find_next_bit() and hweight32() > +#include <linux/clk.h> #include <linux/err.h> for IS_ERR(), PTR_ERR() #include <linux/errno.h> for error codes > +#include <linux/i3c/master.h> > +#include <linux/interrupt.h> #include <linux/io.h> for writel() > +#include <linux/iopoll.h> #include <linux/ioport.h> for IORESOURCE_MEM #include <linux/kernel.h> for DIV_ROUND_UP() #include <linux/list.h> for list() macros and INIT_LIST_HEAD() > +#include <linux/module.h> > +#include <linux/of.h> > +#include <linux/platform_device.h> > +#include <linux/slab.h> #include <linux/spinlock.h> #include <linux/workqueue.h> for workqueue functions and INIT_WORK() > + > +#define DEV_ID 0x0 > +#define DEV_ID_I3C_MASTER 0x5034 [snip] > +#define I3C_DDR_FIRST_DATA_WORD_PREAMBLE 0x2 > +#define I3C_DDR_DATA_WORD_PREAMBLE 0x3 > + > +#define I3C_DDR_PREAMBLE(p) ((p) << 18) > + > +static u32 prepare_ddr_word(u16 payload) > +{ > + u32 ret; > + u16 pb; > + > + ret = (u32)payload << 2; > + > + /* Calculate parity. */ > + pb = (payload >> 15) ^ (payload >> 13) ^ (payload >> 11) ^ > + (payload >> 9) ^ (payload >> 7) ^ (payload >> 5) ^ > + (payload >> 3) ^ (payload >> 1); > + ret |= (pb & 1) << 1; > + pb = (payload >> 14) ^ (payload >> 12) ^ (payload >> 10) ^ > + (payload >> 8) ^ (payload >> 6) ^ (payload >> 4) ^ > + (payload >> 2) ^ payload ^ 1; > + ret |= (pb & 1); > + > + return ret; > +} > + > +static u32 prepare_ddr_data_word(u16 data, bool first) > +{ > + return prepare_ddr_word(data) | I3C_DDR_PREAMBLE(first ? 2 : 3); Just defined macros for 2 & 3 above. Use them instead of magic numbers? > +} > + > +#define I3C_DDR_READ_CMD BIT(15) > + > +static u32 prepare_ddr_cmd_word(u16 cmd) > +{ > + return prepare_ddr_word(cmd) | I3C_DDR_PREAMBLE(1); > +} > + > +static u32 prepare_ddr_crc_word(u8 crc5) > +{ > + return (((u32)crc5 & 0x1f) << 9) | (0xc << 14) | > + I3C_DDR_PREAMBLE(1); > +} > + > +static u8 update_crc5(u8 crc5, u16 word) > +{ > + u8 crc0; > + int i; > + > + /* > + * crc0 = next_data_bit ^ crc[4] > + * 1 2 3 4 > + * crc[4:0] = { crc[3:2], crc[1]^crc0, crc[0], crc0 } > + */ > + for (i = 0; i < 16; ++i) { > + crc0 = ((word >> (15 - i)) ^ (crc5 >> 4)) & 0x1; > + crc5 = ((crc5 << 1) & (0x18 | 0x2)) | > + (((crc5 >> 1) ^ crc0) << 2) | crc0; > + } > + > + return crc5 & 0x1F; > +} > + [snip] > +static int cdns_i3c_master_do_daa_locked(struct cdns_i3c_master *master) > +{ > + unsigned long i3c_lim_period, pres_step, i3c_scl_lim; > + struct i3c_device_info devinfo; > + struct i3c_device *i3cdev; > + u32 prescl1, ctrl, devs; > + int ret, slot, ncycles; > + > + ret = i3c_master_entdaa_locked(&master->base); > + if (ret) > + return ret; > + > + /* Now, add discovered devices to the bus. */ > + i3c_scl_lim = master->i3c_scl_lim; > + devs = readl(master->regs + DEVS_CTRL); > + for (slot = find_next_bit(&master->free_dev_slots, BITS_PER_LONG, 1); > + slot < BITS_PER_LONG; > + slot = find_next_bit(&master->free_dev_slots, > + BITS_PER_LONG, slot + 1)) { > + struct cdns_i3c_i2c_dev_data *data; > + u32 rr, max_fscl = 0; > + u8 addr; > + > + if (!(devs & DEVS_CTRL_DEV_ACTIVE(slot))) > + continue; > + > + data = kzalloc(sizeof(*data), GFP_KERNEL); > + if (!data) > + return -ENOMEM; > + > + data->ibi = -1; > + data->id = slot; > + rr = readl(master->regs + DEV_ID_RR0(slot)); > + addr = DEV_ID_RR0_GET_DEV_ADDR(rr); > + i3cdev = i3c_master_add_i3c_dev_locked(&master->base, addr); > + if (IS_ERR(i3cdev)) > + return PTR_ERR(i3cdev); > + > + i3c_device_get_info(i3cdev, &devinfo); > + clear_bit(data->id, &master->free_dev_slots); > + i3c_device_set_master_data(i3cdev, data); > + > + max_fscl = max(I3C_CCC_MAX_SDR_FSCL(devinfo.max_read_ds), > + I3C_CCC_MAX_SDR_FSCL(devinfo.max_write_ds)); > + switch (max_fscl) { > + case I3C_SDR_DR_FSCL_8MHZ: > + max_fscl = 8000000; > + break; > + case I3C_SDR_DR_FSCL_6MHZ: > + max_fscl = 6000000; > + break; > + case I3C_SDR_DR_FSCL_4MHZ: > + max_fscl = 4000000; > + break; > + case I3C_SDR_DR_FSCL_2MHZ: > + max_fscl = 2000000; > + break; > + case I3C_SDR_DR_FSCL_MAX: > + default: > + max_fscl = 0; > + break; > + } > + > + if (max_fscl && (max_fscl < i3c_scl_lim || !i3c_scl_lim)) > + i3c_scl_lim = max_fscl; > + } > + > + i3c_master_defslvs_locked(&master->base); > + > + pres_step = 1000000000 / (master->base.bus->scl_rate.i3c * 4); Does that build OK on 32-bit target arch? > + > + /* No bus limitation to apply, bail out. */ > + if (!i3c_scl_lim || > + (master->i3c_scl_lim && master->i3c_scl_lim <= i3c_scl_lim)) > + return 0; > + > + /* Configure PP_LOW to meet I3C slave limitations. */ > + prescl1 = readl(master->regs + PRESCL_CTRL1) & > + ~PRESCL_CTRL1_PP_LOW_MASK; > + ctrl = readl(master->regs + CTRL) & ~CTRL_DEV_EN; > + > + i3c_lim_period = DIV_ROUND_UP(1000000000, i3c_scl_lim); > + ncycles = DIV_ROUND_UP(i3c_lim_period, pres_step) - 4; > + if (ncycles < 0) > + ncycles = 0; > + prescl1 |= PRESCL_CTRL1_PP_LOW(ncycles); > + > + /* Disable I3C master before updating PRESCL_CTRL1. */ > + ret = cdns_i3c_master_disable(master); > + if (!ret) { > + writel(prescl1, master->regs + PRESCL_CTRL1); > + master->i3c_scl_lim = i3c_scl_lim; > + } > + cdns_i3c_master_enable(master); > + > + return ret; > +} > + > +static int cdns_i3c_master_bus_init(struct i3c_master_controller *m) > +{ > + struct cdns_i3c_master *master = to_cdns_i3c_master(m); > + unsigned long pres_step, sysclk_rate, max_i2cfreq; > + u32 ctrl, prescl0, prescl1, pres, low; > + struct i3c_device_info info = { }; > + struct i3c_ccc_events events; > + struct i2c_device *i2cdev; > + struct i3c_device *i3cdev; > + int ret, slot, ncycles; > + u8 last_addr = 0; > + > + switch (m->bus->mode) { > + case I3C_BUS_MODE_PURE: > + ctrl = CTRL_PURE_BUS_MODE; > + break; > + > + case I3C_BUS_MODE_MIXED_FAST: > + ctrl = CTRL_MIXED_FAST_BUS_MODE; > + break; > + > + case I3C_BUS_MODE_MIXED_SLOW: > + ctrl = CTRL_MIXED_SLOW_BUS_MODE; > + break; > + > + default: > + return -EINVAL; > + } > + > + sysclk_rate = clk_get_rate(master->sysclk); > + if (!sysclk_rate) > + return -EINVAL; > + > + pres = DIV_ROUND_UP(sysclk_rate, (m->bus->scl_rate.i3c * 4)) - 1; > + if (pres > PRESCL_CTRL0_MAX) > + return -ERANGE; > + > + m->bus->scl_rate.i3c = sysclk_rate / ((pres + 1) * 4); > + > + prescl0 = PRESCL_CTRL0_I3C(pres); > + > + low = ((I3C_BUS_TLOW_OD_MIN_NS * sysclk_rate) / (pres + 1)) - 2; > + prescl1 = PRESCL_CTRL1_OD_LOW(low); > + > + max_i2cfreq = m->bus->scl_rate.i2c; > + > + pres = (sysclk_rate / (max_i2cfreq * 5)) - 1; > + if (pres > PRESCL_CTRL0_MAX) > + return -ERANGE; > + > + m->bus->scl_rate.i2c = sysclk_rate / ((pres + 1) * 5); > + > + prescl0 |= PRESCL_CTRL0_I2C(pres); > + > + writel(DEVS_CTRL_DEV_CLR_ALL, master->regs + DEVS_CTRL); > + > + i3c_bus_for_each_i2cdev(m->bus, i2cdev) { > + ret = cdns_i3c_master_attach_i2c_dev(master, i2cdev); > + if (ret) > + goto err_detach_devs; > + } > + > + writel(prescl0, master->regs + PRESCL_CTRL0); > + > + /* Calculate OD and PP low. */ > + pres_step = 1000000000 / (m->bus->scl_rate.i3c * 4); > + ncycles = DIV_ROUND_UP(I3C_BUS_TLOW_OD_MIN_NS, pres_step) - 2; > + if (ncycles < 0) > + ncycles = 0; > + prescl1 = PRESCL_CTRL1_OD_LOW(ncycles); > + writel(prescl1, master->regs + PRESCL_CTRL1); > + > + i3c_bus_for_each_i3cdev(m->bus, i3cdev) { > + ret = cdns_i3c_master_attach_i3c_dev(master, i3cdev); > + if (ret) > + goto err_detach_devs; > + } > + > + /* Get an address for the master. */ > + ret = i3c_master_get_free_addr(m, 0); > + if (ret < 0) > + goto err_detach_devs; > + > + writel(prepare_rr0_dev_address(ret) | DEV_ID_RR0_IS_I3C, > + master->regs + DEV_ID_RR0(0)); > + > + cdns_i3c_master_dev_rr_to_info(master, 0, &info); > + if (info.bcr & I3C_BCR_HDR_CAP) > + info.hdr_cap = I3C_CCC_HDR_MODE(I3C_HDR_DDR); > + > + ret = i3c_master_set_info(&master->base, &info); > + if (ret) > + goto err_detach_devs; > + > + /* Prepare RR slots before lauching DAA. */ launching > + for (slot = find_next_bit(&master->free_dev_slots, BITS_PER_LONG, 1); > + slot < BITS_PER_LONG; > + slot = find_next_bit(&master->free_dev_slots, > + BITS_PER_LONG, slot + 1)) { > + ret = i3c_master_get_free_addr(m, last_addr + 1); > + if (ret < 0) > + goto err_disable_master; > + > + last_addr = ret; > + writel(prepare_rr0_dev_address(last_addr) | DEV_ID_RR0_IS_I3C, > + master->regs + DEV_ID_RR0(slot)); > + writel(0, master->regs + DEV_ID_RR1(slot)); > + writel(0, master->regs + DEV_ID_RR2(slot)); > + } > + > + /* > + * Enable Hot-Join and when a Hot-Join request happen, disable all happens, > + * events coming from this device. > + * > + * We will issue ENTDAA afterwards from the threaded IRQ handler. > + */ > + ctrl |= CTRL_HJ_ACK | CTRL_HJ_DISEC | CTRL_HALT_EN; > + writel(ctrl, master->regs + CTRL); > + > + cdns_i3c_master_enable(master); > + > + /* > + * Reset all dynamic addresses on the bus, because we don't know what > + * happened before this point (the bootloader may have assigned dynamic > + * addresses that we're not aware of). > + */ > + ret = i3c_master_rstdaa_locked(m, I3C_BROADCAST_ADDR); > + if (ret) > + goto err_disable_master; > + > + /* Disable all slave events (interrupts) before starting DAA. */ > + events.events = I3C_CCC_EVENT_SIR | I3C_CCC_EVENT_MR | > + I3C_CCC_EVENT_HJ; > + ret = i3c_master_disec_locked(m, I3C_BROADCAST_ADDR, &events); > + if (ret) > + goto err_disable_master; > + > + ret = cdns_i3c_master_do_daa_locked(master); > + if (ret < 0) > + goto err_disable_master; > + > + /* Unmask Hot-Join and Marstership request interrupts. */ Is that Mastership ? > + events.events = I3C_CCC_EVENT_HJ | I3C_CCC_EVENT_MR; > + ret = i3c_master_enec_locked(m, I3C_BROADCAST_ADDR, &events); > + if (ret) > + pr_info("Failed to re-enable H-J"); Not very good info... > + > + writel(MST_INT_HJ_REQ, master->regs + MST_IER); > + return 0; > + > +err_disable_master: > + cdns_i3c_master_disable(master); > + > +err_detach_devs: > + cdns_i3c_master_bus_cleanup(m); > + > + return ret; > +} > + [snip]
Hi Randy, On Thu, 14 Dec 2017 11:54:16 -0800 Randy Dunlap <rdunlap@infradead.org> wrote: > On 12/14/2017 07:16 AM, Boris Brezillon wrote: > > Add a driver for Cadence I3C master IP. > > > > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> > > --- > > Changes in v2: > > - Add basic IBI support. Note that the IP is not really reliable with > > regards to IBI because you can't extract IBI payloads as soon as you > > have more than one IBI waiting in the HW queue. This is something > > that will hopefully be addressed in future revisions of this IP > > - Add a simple xfer queueing mechanism to optimize message queuing. > > - Fix a few bugs > > - Add support for Hot Join > > --- > > drivers/i3c/master/Kconfig | 5 + > > drivers/i3c/master/Makefile | 1 + > > drivers/i3c/master/i3c-master-cdns.c | 1797 ++++++++++++++++++++++++++++++++++ > > 3 files changed, 1803 insertions(+) > > create mode 100644 drivers/i3c/master/i3c-master-cdns.c > > > > diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig > > index e69de29bb2d1..56b9a18543b2 100644 > > --- a/drivers/i3c/master/Kconfig > > +++ b/drivers/i3c/master/Kconfig > > @@ -0,0 +1,5 @@ > > +config CDNS_I3C_MASTER > > + tristate "Cadence I3C master driver" > > + depends on I3C > > + help > > + Enable this driver if you want to support Cadence I3C master block. > > diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile > > index e69de29bb2d1..4c4304aa9534 100644 > > --- a/drivers/i3c/master/Makefile > > +++ b/drivers/i3c/master/Makefile > > @@ -0,0 +1 @@ > > +obj-$(CONFIG_CDNS_I3C_MASTER) += i3c-master-cdns.o > > diff --git a/drivers/i3c/master/i3c-master-cdns.c b/drivers/i3c/master/i3c-master-cdns.c > > new file mode 100644 > > index 000000000000..3e3ef37c01c2 > > --- /dev/null > > +++ b/drivers/i3c/master/i3c-master-cdns.c > > @@ -0,0 +1,1797 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (C) 2017 Cadence Design Systems Inc. > > + * > > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com> > > + */ > > + > > Rule #1 from submit-checklist.rst: > 1) If you use a facility then #include the file that defines/declares > that facility. Don't depend on other header files pulling in ones > that you use. > > > #include <linux/bitops.h> > for BIT(x) and hweight8() and clear_bit() and find_next_bit() > and hweight32() > > > +#include <linux/clk.h> > > #include <linux/err.h> > for IS_ERR(), PTR_ERR() > > #include <linux/errno.h> > for error codes > > > +#include <linux/i3c/master.h> > > +#include <linux/interrupt.h> > > #include <linux/io.h> > for writel() > > > +#include <linux/iopoll.h> > > #include <linux/ioport.h> > for IORESOURCE_MEM > > #include <linux/kernel.h> > for DIV_ROUND_UP() > > #include <linux/list.h> > for list() macros and INIT_LIST_HEAD() > > > +#include <linux/module.h> > > +#include <linux/of.h> > > +#include <linux/platform_device.h> > > +#include <linux/slab.h> > > #include <linux/spinlock.h> > > #include <linux/workqueue.h> > for workqueue functions and INIT_WORK() Will fix that. > > > + > > +#define DEV_ID 0x0 > > +#define DEV_ID_I3C_MASTER 0x5034 > > [snip] > > > > > +#define I3C_DDR_FIRST_DATA_WORD_PREAMBLE 0x2 > > +#define I3C_DDR_DATA_WORD_PREAMBLE 0x3 > > + > > +#define I3C_DDR_PREAMBLE(p) ((p) << 18) > > + > > +static u32 prepare_ddr_word(u16 payload) > > +{ > > + u32 ret; > > + u16 pb; > > + > > + ret = (u32)payload << 2; > > + > > + /* Calculate parity. */ > > + pb = (payload >> 15) ^ (payload >> 13) ^ (payload >> 11) ^ > > + (payload >> 9) ^ (payload >> 7) ^ (payload >> 5) ^ > > + (payload >> 3) ^ (payload >> 1); > > + ret |= (pb & 1) << 1; > > + pb = (payload >> 14) ^ (payload >> 12) ^ (payload >> 10) ^ > > + (payload >> 8) ^ (payload >> 6) ^ (payload >> 4) ^ > > + (payload >> 2) ^ payload ^ 1; > > + ret |= (pb & 1); > > + > > + return ret; > > +} > > + > > +static u32 prepare_ddr_data_word(u16 data, bool first) > > +{ > > + return prepare_ddr_word(data) | I3C_DDR_PREAMBLE(first ? 2 : 3); > > Just defined macros for 2 & 3 above. Use them instead of magic numbers? Oops, that was my intention, just forgot to use the macros I had defined. > > > +} > > + > > +#define I3C_DDR_READ_CMD BIT(15) > > + > > +static u32 prepare_ddr_cmd_word(u16 cmd) > > +{ > > + return prepare_ddr_word(cmd) | I3C_DDR_PREAMBLE(1); > > +} > > + > > +static u32 prepare_ddr_crc_word(u8 crc5) > > +{ > > + return (((u32)crc5 & 0x1f) << 9) | (0xc << 14) | > > + I3C_DDR_PREAMBLE(1); > > +} > > + > > +static u8 update_crc5(u8 crc5, u16 word) > > +{ > > + u8 crc0; > > + int i; > > + > > + /* > > + * crc0 = next_data_bit ^ crc[4] > > + * 1 2 3 4 > > + * crc[4:0] = { crc[3:2], crc[1]^crc0, crc[0], crc0 } > > + */ > > + for (i = 0; i < 16; ++i) { > > + crc0 = ((word >> (15 - i)) ^ (crc5 >> 4)) & 0x1; > > + crc5 = ((crc5 << 1) & (0x18 | 0x2)) | > > + (((crc5 >> 1) ^ crc0) << 2) | crc0; > > + } > > + > > + return crc5 & 0x1F; > > +} > > + > > [snip] > > > > > +static int cdns_i3c_master_do_daa_locked(struct cdns_i3c_master *master) > > +{ > > + unsigned long i3c_lim_period, pres_step, i3c_scl_lim; > > + struct i3c_device_info devinfo; > > + struct i3c_device *i3cdev; > > + u32 prescl1, ctrl, devs; > > + int ret, slot, ncycles; > > + > > + ret = i3c_master_entdaa_locked(&master->base); > > + if (ret) > > + return ret; > > + > > + /* Now, add discovered devices to the bus. */ > > + i3c_scl_lim = master->i3c_scl_lim; > > + devs = readl(master->regs + DEVS_CTRL); > > + for (slot = find_next_bit(&master->free_dev_slots, BITS_PER_LONG, 1); > > + slot < BITS_PER_LONG; > > + slot = find_next_bit(&master->free_dev_slots, > > + BITS_PER_LONG, slot + 1)) { > > + struct cdns_i3c_i2c_dev_data *data; > > + u32 rr, max_fscl = 0; > > + u8 addr; > > + > > + if (!(devs & DEVS_CTRL_DEV_ACTIVE(slot))) > > + continue; > > + > > + data = kzalloc(sizeof(*data), GFP_KERNEL); > > + if (!data) > > + return -ENOMEM; > > + > > + data->ibi = -1; > > + data->id = slot; > > + rr = readl(master->regs + DEV_ID_RR0(slot)); > > + addr = DEV_ID_RR0_GET_DEV_ADDR(rr); > > + i3cdev = i3c_master_add_i3c_dev_locked(&master->base, addr); > > + if (IS_ERR(i3cdev)) > > + return PTR_ERR(i3cdev); > > + > > + i3c_device_get_info(i3cdev, &devinfo); > > + clear_bit(data->id, &master->free_dev_slots); > > + i3c_device_set_master_data(i3cdev, data); > > + > > + max_fscl = max(I3C_CCC_MAX_SDR_FSCL(devinfo.max_read_ds), > > + I3C_CCC_MAX_SDR_FSCL(devinfo.max_write_ds)); > > + switch (max_fscl) { > > + case I3C_SDR_DR_FSCL_8MHZ: > > + max_fscl = 8000000; > > + break; > > + case I3C_SDR_DR_FSCL_6MHZ: > > + max_fscl = 6000000; > > + break; > > + case I3C_SDR_DR_FSCL_4MHZ: > > + max_fscl = 4000000; > > + break; > > + case I3C_SDR_DR_FSCL_2MHZ: > > + max_fscl = 2000000; > > + break; > > + case I3C_SDR_DR_FSCL_MAX: > > + default: > > + max_fscl = 0; > > + break; > > + } > > + > > + if (max_fscl && (max_fscl < i3c_scl_lim || !i3c_scl_lim)) > > + i3c_scl_lim = max_fscl; > > + } > > + > > + i3c_master_defslvs_locked(&master->base); > > + > > + pres_step = 1000000000 / (master->base.bus->scl_rate.i3c * 4); > > Does that build OK on 32-bit target arch? It's a 32 bit integer divided by another 32 bit integer, and yes, I tested it on a 32 platform. This being said, I should use NSEC_PER_SEC instead of 1000000000. > > > + > > + /* No bus limitation to apply, bail out. */ > > + if (!i3c_scl_lim || > > + (master->i3c_scl_lim && master->i3c_scl_lim <= i3c_scl_lim)) > > + return 0; > > + > > + /* Configure PP_LOW to meet I3C slave limitations. */ > > + prescl1 = readl(master->regs + PRESCL_CTRL1) & > > + ~PRESCL_CTRL1_PP_LOW_MASK; > > + ctrl = readl(master->regs + CTRL) & ~CTRL_DEV_EN; > > + > > + i3c_lim_period = DIV_ROUND_UP(1000000000, i3c_scl_lim); > > + ncycles = DIV_ROUND_UP(i3c_lim_period, pres_step) - 4; > > + if (ncycles < 0) > > + ncycles = 0; > > + prescl1 |= PRESCL_CTRL1_PP_LOW(ncycles); > > + > > + /* Disable I3C master before updating PRESCL_CTRL1. */ > > + ret = cdns_i3c_master_disable(master); > > + if (!ret) { > > + writel(prescl1, master->regs + PRESCL_CTRL1); > > + master->i3c_scl_lim = i3c_scl_lim; > > + } > > + cdns_i3c_master_enable(master); > > + > > + return ret; > > +} > > + > > +static int cdns_i3c_master_bus_init(struct i3c_master_controller *m) > > +{ > > + struct cdns_i3c_master *master = to_cdns_i3c_master(m); > > + unsigned long pres_step, sysclk_rate, max_i2cfreq; > > + u32 ctrl, prescl0, prescl1, pres, low; > > + struct i3c_device_info info = { }; > > + struct i3c_ccc_events events; > > + struct i2c_device *i2cdev; > > + struct i3c_device *i3cdev; > > + int ret, slot, ncycles; > > + u8 last_addr = 0; > > + > > + switch (m->bus->mode) { > > + case I3C_BUS_MODE_PURE: > > + ctrl = CTRL_PURE_BUS_MODE; > > + break; > > + > > + case I3C_BUS_MODE_MIXED_FAST: > > + ctrl = CTRL_MIXED_FAST_BUS_MODE; > > + break; > > + > > + case I3C_BUS_MODE_MIXED_SLOW: > > + ctrl = CTRL_MIXED_SLOW_BUS_MODE; > > + break; > > + > > + default: > > + return -EINVAL; > > + } > > + > > + sysclk_rate = clk_get_rate(master->sysclk); > > + if (!sysclk_rate) > > + return -EINVAL; > > + > > + pres = DIV_ROUND_UP(sysclk_rate, (m->bus->scl_rate.i3c * 4)) - 1; > > + if (pres > PRESCL_CTRL0_MAX) > > + return -ERANGE; > > + > > + m->bus->scl_rate.i3c = sysclk_rate / ((pres + 1) * 4); > > + > > + prescl0 = PRESCL_CTRL0_I3C(pres); > > + > > + low = ((I3C_BUS_TLOW_OD_MIN_NS * sysclk_rate) / (pres + 1)) - 2; > > + prescl1 = PRESCL_CTRL1_OD_LOW(low); > > + > > + max_i2cfreq = m->bus->scl_rate.i2c; > > + > > + pres = (sysclk_rate / (max_i2cfreq * 5)) - 1; > > + if (pres > PRESCL_CTRL0_MAX) > > + return -ERANGE; > > + > > + m->bus->scl_rate.i2c = sysclk_rate / ((pres + 1) * 5); > > + > > + prescl0 |= PRESCL_CTRL0_I2C(pres); > > + > > + writel(DEVS_CTRL_DEV_CLR_ALL, master->regs + DEVS_CTRL); > > + > > + i3c_bus_for_each_i2cdev(m->bus, i2cdev) { > > + ret = cdns_i3c_master_attach_i2c_dev(master, i2cdev); > > + if (ret) > > + goto err_detach_devs; > > + } > > + > > + writel(prescl0, master->regs + PRESCL_CTRL0); > > + > > + /* Calculate OD and PP low. */ > > + pres_step = 1000000000 / (m->bus->scl_rate.i3c * 4); > > + ncycles = DIV_ROUND_UP(I3C_BUS_TLOW_OD_MIN_NS, pres_step) - 2; > > + if (ncycles < 0) > > + ncycles = 0; > > + prescl1 = PRESCL_CTRL1_OD_LOW(ncycles); > > + writel(prescl1, master->regs + PRESCL_CTRL1); > > + > > + i3c_bus_for_each_i3cdev(m->bus, i3cdev) { > > + ret = cdns_i3c_master_attach_i3c_dev(master, i3cdev); > > + if (ret) > > + goto err_detach_devs; > > + } > > + > > + /* Get an address for the master. */ > > + ret = i3c_master_get_free_addr(m, 0); > > + if (ret < 0) > > + goto err_detach_devs; > > + > > + writel(prepare_rr0_dev_address(ret) | DEV_ID_RR0_IS_I3C, > > + master->regs + DEV_ID_RR0(0)); > > + > > + cdns_i3c_master_dev_rr_to_info(master, 0, &info); > > + if (info.bcr & I3C_BCR_HDR_CAP) > > + info.hdr_cap = I3C_CCC_HDR_MODE(I3C_HDR_DDR); > > + > > + ret = i3c_master_set_info(&master->base, &info); > > + if (ret) > > + goto err_detach_devs; > > + > > + /* Prepare RR slots before lauching DAA. */ > > launching > > > + for (slot = find_next_bit(&master->free_dev_slots, BITS_PER_LONG, 1); > > + slot < BITS_PER_LONG; > > + slot = find_next_bit(&master->free_dev_slots, > > + BITS_PER_LONG, slot + 1)) { > > + ret = i3c_master_get_free_addr(m, last_addr + 1); > > + if (ret < 0) > > + goto err_disable_master; > > + > > + last_addr = ret; > > + writel(prepare_rr0_dev_address(last_addr) | DEV_ID_RR0_IS_I3C, > > + master->regs + DEV_ID_RR0(slot)); > > + writel(0, master->regs + DEV_ID_RR1(slot)); > > + writel(0, master->regs + DEV_ID_RR2(slot)); > > + } > > + > > + /* > > + * Enable Hot-Join and when a Hot-Join request happen, disable all > > happens, > > > + * events coming from this device. > > + * > > + * We will issue ENTDAA afterwards from the threaded IRQ handler. > > + */ > > + ctrl |= CTRL_HJ_ACK | CTRL_HJ_DISEC | CTRL_HALT_EN; > > + writel(ctrl, master->regs + CTRL); > > + > > + cdns_i3c_master_enable(master); > > + > > + /* > > + * Reset all dynamic addresses on the bus, because we don't know what > > + * happened before this point (the bootloader may have assigned dynamic > > + * addresses that we're not aware of). > > + */ > > + ret = i3c_master_rstdaa_locked(m, I3C_BROADCAST_ADDR); > > + if (ret) > > + goto err_disable_master; > > + > > + /* Disable all slave events (interrupts) before starting DAA. */ > > + events.events = I3C_CCC_EVENT_SIR | I3C_CCC_EVENT_MR | > > + I3C_CCC_EVENT_HJ; > > + ret = i3c_master_disec_locked(m, I3C_BROADCAST_ADDR, &events); > > + if (ret) > > + goto err_disable_master; > > + > > + ret = cdns_i3c_master_do_daa_locked(master); > > + if (ret < 0) > > + goto err_disable_master; > > + > > + /* Unmask Hot-Join and Marstership request interrupts. */ > > Is that Mastership ? It is. I'll fix the other typos you pointed. > > > + events.events = I3C_CCC_EVENT_HJ | I3C_CCC_EVENT_MR; > > + ret = i3c_master_enec_locked(m, I3C_BROADCAST_ADDR, &events); > > + if (ret) > > + pr_info("Failed to re-enable H-J"); > > Not very good info... What do you mean? Is it the H-J that bothers you (I can replace it by 'Hot-Join'), or is it something else? Thanks for the review. Boris -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/14/2017 12:17 PM, Boris Brezillon wrote: >>> + events.events = I3C_CCC_EVENT_HJ | I3C_CCC_EVENT_MR; >>> + ret = i3c_master_enec_locked(m, I3C_BROADCAST_ADDR, &events); >>> + if (ret) >>> + pr_info("Failed to re-enable H-J"); >> Not very good info... > What do you mean? Is it the H-J that bothers you (I can replace it by > 'Hot-Join'), or is it something else? Who is the message for? If it's for developers, you could use pr_debug(). If it's for users, it needs more clarity. Does it print the source of the message? (module name e.g.) and yes, Hot-Join would be better IMO.
On Thu, 14 Dec 2017 12:25:14 -0800 Randy Dunlap <rdunlap@infradead.org> wrote: > On 12/14/2017 12:17 PM, Boris Brezillon wrote: > >>> + events.events = I3C_CCC_EVENT_HJ | I3C_CCC_EVENT_MR; > >>> + ret = i3c_master_enec_locked(m, I3C_BROADCAST_ADDR, &events); > >>> + if (ret) > >>> + pr_info("Failed to re-enable H-J"); > >> Not very good info... > > What do you mean? Is it the H-J that bothers you (I can replace it by > > 'Hot-Join'), or is it something else? > > Who is the message for? If it's for developers, you could use > pr_debug(). If it's for users, it needs more clarity. I think it's of interest to anyone including users. If we fail to re-enable Hot-Join that means hotplug is no longer working which is a bad news. > > Does it print the source of the message? (module name e.g.) I could replace it by dev_err(m->parent, "Failed to re-enable Hot-Join"); > and yes, Hot-Join would be better IMO. > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/14/2017 12:44 PM, Boris Brezillon wrote: > On Thu, 14 Dec 2017 12:25:14 -0800 > Randy Dunlap <rdunlap@infradead.org> wrote: > >> On 12/14/2017 12:17 PM, Boris Brezillon wrote: >>>>> + events.events = I3C_CCC_EVENT_HJ | I3C_CCC_EVENT_MR; >>>>> + ret = i3c_master_enec_locked(m, I3C_BROADCAST_ADDR, &events); >>>>> + if (ret) >>>>> + pr_info("Failed to re-enable H-J"); >>>> Not very good info... >>> What do you mean? Is it the H-J that bothers you (I can replace it by >>> 'Hot-Join'), or is it something else? >> >> Who is the message for? If it's for developers, you could use >> pr_debug(). If it's for users, it needs more clarity. > > I think it's of interest to anyone including users. If we fail to > re-enable Hot-Join that means hotplug is no longer working which is > a bad news. > >> >> Does it print the source of the message? (module name e.g.) > > I could replace it by > > dev_err(m->parent, "Failed to re-enable Hot-Join"); > Yes, that's a good plan. Thanks. > > >> and yes, Hot-Join would be better IMO.
On 12/14/17 07:16, Boris Brezillon wrote: > Add core infrastructure to support I3C in Linux and document it. > > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> > --- > drivers/Kconfig | 2 + > drivers/Makefile | 2 +- > drivers/i3c/Kconfig | 24 + > drivers/i3c/Makefile | 4 + > drivers/i3c/core.c | 573 ++++++++++++++++ > drivers/i3c/device.c | 344 ++++++++++ > drivers/i3c/internals.h | 34 + > drivers/i3c/master.c | 1433 +++++++++++++++++++++++++++++++++++++++ > drivers/i3c/master/Kconfig | 0 > drivers/i3c/master/Makefile | 0 > include/linux/i3c/ccc.h | 380 +++++++++++ > include/linux/i3c/device.h | 321 +++++++++ > include/linux/i3c/master.h | 564 +++++++++++++++ > include/linux/mod_devicetable.h | 17 + > 14 files changed, 3697 insertions(+), 1 deletion(-) > create mode 100644 drivers/i3c/Kconfig > create mode 100644 drivers/i3c/Makefile > create mode 100644 drivers/i3c/core.c > create mode 100644 drivers/i3c/device.c > create mode 100644 drivers/i3c/internals.h > create mode 100644 drivers/i3c/master.c > create mode 100644 drivers/i3c/master/Kconfig > create mode 100644 drivers/i3c/master/Makefile > create mode 100644 include/linux/i3c/ccc.h > create mode 100644 include/linux/i3c/device.h > create mode 100644 include/linux/i3c/master.h > > diff --git a/drivers/i3c/Kconfig b/drivers/i3c/Kconfig > new file mode 100644 > index 000000000000..cf3752412ae9 > --- /dev/null > +++ b/drivers/i3c/Kconfig > @@ -0,0 +1,24 @@ > +# SPDX-License-Identifier: GPL-2.0 > + > +menuconfig I3C > + tristate "I3C support" > + select I2C > + help > + I3C is a serial protocol standardized by the MIPI alliance. > + > + It's supposed to be backward compatible with I2C while providing > + support for high speed transfers and native interrupt support > + without the need for extra pins. > + > + The I3C protocol also standardizes the slave device types and is > + mainly design to communicate with sensors. > + > + If you want I3C support, you should say Y here and also to the > + specific driver for your bus adapter(s) below. > + > + This I3C support can also be built as a module. If so, the module > + will be called i3c. > + > +if I3C > +source "drivers/i3c/master/Kconfig" > +endif # I3C > diff --git a/drivers/i3c/core.c b/drivers/i3c/core.c > new file mode 100644 > index 000000000000..7eb8e84acd33 > --- /dev/null > +++ b/drivers/i3c/core.c > @@ -0,0 +1,573 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2017 Cadence Design Systems Inc. > + * > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com> > + */ > + > +#include <linux/idr.h> > +#include <linux/module.h> > +#include <linux/of_device.h> > +#include <linux/slab.h> #include <linux/device.h> #include <linux/init.h> #include <linux/list.h> #include <linux/mutex.h> #include <linux/rwsem.h> > +#include "internals.h" > + > +static DEFINE_IDR(i3c_bus_idr); > +static DEFINE_MUTEX(i3c_core_lock); > + > +/** > + * i3c_bus_maintenance_lock - Release the bus lock after a maintenance unlock > + * operation > + * @bus: I3C bus to release the lock on > + * > + * Should be called when the bus maintenance operation is done. See > + * i3c_bus_maintenance_lock() for more details on what these maintenance > + * operations are. > + */ > +void i3c_bus_maintenance_unlock(struct i3c_bus *bus) > +{ > + up_write(&bus->lock); > +} > +EXPORT_SYMBOL_GPL(i3c_bus_maintenance_unlock); > + > +/** > + * i3c_bus_normaluse_lock - Release the bus lock after a normal operation unlock > + * @bus: I3C bus to release the lock on > + * > + * Should be called when a normal operation is done. See > + * i3c_bus_normaluse_lock() for more details on what these normal operations > + * are. > + */ > +void i3c_bus_normaluse_unlock(struct i3c_bus *bus) > +{ > + up_read(&bus->lock); > +} > +EXPORT_SYMBOL_GPL(i3c_bus_normaluse_unlock); > +static int i3c_device_match(struct device *dev, struct device_driver *drv) bool? > +{ > + struct i3c_device *i3cdev; > + struct i3c_driver *i3cdrv; > + > + if (dev->type != &i3c_device_type) > + return 0; > + > + i3cdev = dev_to_i3cdev(dev); > + i3cdrv = drv_to_i3cdrv(drv); > + if (i3c_device_match_id(i3cdev, i3cdrv->id_table)) > + return 1; > + > + return 0; > +} > diff --git a/drivers/i3c/device.c b/drivers/i3c/device.c > new file mode 100644 > index 000000000000..dcf51150b7cb > --- /dev/null > +++ b/drivers/i3c/device.c > @@ -0,0 +1,344 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2017 Cadence Design Systems Inc. > + * > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com> > + */ > + > +#include <linux/slab.h> #include <linux/atomic.h> #include <linux/bug.h> #include <linux/completion.h> #include <linux/device.h> #include <linux/mutex.h> > +#include "internals.h" > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c > new file mode 100644 > index 000000000000..1c85abac08d5 > --- /dev/null > +++ b/drivers/i3c/master.c > @@ -0,0 +1,1433 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2017 Cadence Design Systems Inc. > + * > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com> > + */ #include <linux/atomic.h> #include <linux/device.h> #include <linux/err.h> #include <linux/export.h> #include <linux/kernel.h> #include <linux/list.h> #include <linux/of.h> > +#include <linux/slab.h> #include <linux/spinlock.h> #include <linux/workqueue.h> #include <asm-generic/bug.h> > +#include "internals.h" and I probably missed a few. > diff --git a/include/linux/i3c/ccc.h b/include/linux/i3c/ccc.h > new file mode 100644 > index 000000000000..ff3e1a3e2c4c > --- /dev/null > +++ b/include/linux/i3c/ccc.h > @@ -0,0 +1,380 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright (C) 2017 Cadence Design Systems Inc. > + * > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com> > + */ > +/** > + * struct i3c_ccc_dev_desc - I3C/I3C device descriptor used for DEFSLVS Is one of those I3C above supposed to be I2C? > + * > + * @dyn_addr: dynamic address assigned to the I3C slave or 0 if the entry is > + * describing an I2C slave. > + * @dcr: DCR value (not applicable to entries describing I2C devices) > + * @lvr: LVR value (not applicable to entries describing I3C devices) > + * @bcr: BCR value or 0 if this entry is describing an I2C slave > + * @static_addr: static address or 0 if the device does not have a static > + * address > + * > + * The DEFSLVS command should be passed an array of i3c_ccc_dev_desc > + * descriptors (one entry per I3C/I2C dev controlled by the master). > + */ > +struct i3c_ccc_dev_desc { > + u8 dyn_addr; > + union { > + u8 dcr; > + u8 lvr; > + }; > + u8 bcr; > + u8 static_addr; > +} __packed; Needs bitops.h > diff --git a/include/linux/i3c/device.h b/include/linux/i3c/device.h > new file mode 100644 > index 000000000000..83958d3a02e2 > --- /dev/null > +++ b/include/linux/i3c/device.h > @@ -0,0 +1,321 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright (C) 2017 Cadence Design Systems Inc. > + * > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com> > + */ > + > +#ifndef I3C_DEV_H > +#define I3C_DEV_H > + > +#include <linux/device.h> > +#include <linux/i2c.h> > +#include <linux/mod_devicetable.h> > +#include <linux/module.h> Needs bitops.h, kconfig.h. > diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h > new file mode 100644 > index 000000000000..7ec9a4821bac > --- /dev/null > +++ b/include/linux/i3c/master.h > @@ -0,0 +1,564 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright (C) 2017 Cadence Design Systems Inc. > + * > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com> > + */ > + > +#ifndef I3C_MASTER_H > +#define I3C_MASTER_H > + > +#include <linux/i2c.h> > +#include <linux/i3c/ccc.h> > +#include <linux/i3c/device.h> > +#include <linux/spinlock.h> > + > +#define I3C_HOT_JOIN_ADDR 0x2 > +#define I3C_BROADCAST_ADDR 0x7e > +#define I3C_MAX_ADDR GENMASK(6, 0) > + Needs bitops.h, workqueue.h, rwsem.h Needs <asm-generic/bitsperlong.h> > diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h > index abb6dc2ebbf8..e59da92d8ac9 100644 > --- a/include/linux/mod_devicetable.h > +++ b/include/linux/mod_devicetable.h > @@ -442,6 +442,23 @@ struct pci_epf_device_id { > kernel_ulong_t driver_data; > }; > > +/* i3c */ > + > +#define I3C_MATCH_DCR BIT(0) > +#define I3C_MATCH_MANUF BIT(1) > +#define I3C_MATCH_PART BIT(2) > +#define I3C_MATCH_EXTRA_INFO BIT(3) Needs bitops.h. > +struct i3c_device_id { > + __u8 match_flags; > + __u8 dcr; > + __u16 manuf_id; > + __u16 part_id; > + __u16 extra_info; > + > + const void *data; > +}; > + > /* spi */ > > #define SPI_NAME_SIZE 32 >
On Sun, 17 Dec 2017 14:32:04 -0800 Randy Dunlap <rdunlap@infradead.org> wrote: > On 12/14/17 07:16, Boris Brezillon wrote: > > Add core infrastructure to support I3C in Linux and document it. > > > > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> > > --- > > drivers/Kconfig | 2 + > > drivers/Makefile | 2 +- > > drivers/i3c/Kconfig | 24 + > > drivers/i3c/Makefile | 4 + > > drivers/i3c/core.c | 573 ++++++++++++++++ > > drivers/i3c/device.c | 344 ++++++++++ > > drivers/i3c/internals.h | 34 + > > drivers/i3c/master.c | 1433 +++++++++++++++++++++++++++++++++++++++ > > drivers/i3c/master/Kconfig | 0 > > drivers/i3c/master/Makefile | 0 > > include/linux/i3c/ccc.h | 380 +++++++++++ > > include/linux/i3c/device.h | 321 +++++++++ > > include/linux/i3c/master.h | 564 +++++++++++++++ > > include/linux/mod_devicetable.h | 17 + > > 14 files changed, 3697 insertions(+), 1 deletion(-) > > create mode 100644 drivers/i3c/Kconfig > > create mode 100644 drivers/i3c/Makefile > > create mode 100644 drivers/i3c/core.c > > create mode 100644 drivers/i3c/device.c > > create mode 100644 drivers/i3c/internals.h > > create mode 100644 drivers/i3c/master.c > > create mode 100644 drivers/i3c/master/Kconfig > > create mode 100644 drivers/i3c/master/Makefile > > create mode 100644 include/linux/i3c/ccc.h > > create mode 100644 include/linux/i3c/device.h > > create mode 100644 include/linux/i3c/master.h > > > > diff --git a/drivers/i3c/Kconfig b/drivers/i3c/Kconfig > > new file mode 100644 > > index 000000000000..cf3752412ae9 > > --- /dev/null > > +++ b/drivers/i3c/Kconfig > > @@ -0,0 +1,24 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > + > > +menuconfig I3C > > + tristate "I3C support" > > + select I2C > > + help > > + I3C is a serial protocol standardized by the MIPI alliance. > > + > > + It's supposed to be backward compatible with I2C while providing > > + support for high speed transfers and native interrupt support > > + without the need for extra pins. > > + > > + The I3C protocol also standardizes the slave device types and is > > + mainly design to communicate with sensors. > > + > > + If you want I3C support, you should say Y here and also to the > > + specific driver for your bus adapter(s) below. > > + > > + This I3C support can also be built as a module. If so, the module > > + will be called i3c. > > + > > +if I3C > > +source "drivers/i3c/master/Kconfig" > > +endif # I3C > > > diff --git a/drivers/i3c/core.c b/drivers/i3c/core.c > > new file mode 100644 > > index 000000000000..7eb8e84acd33 > > --- /dev/null > > +++ b/drivers/i3c/core.c > > @@ -0,0 +1,573 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (C) 2017 Cadence Design Systems Inc. > > + * > > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com> > > + */ > > + > > +#include <linux/idr.h> > > +#include <linux/module.h> > > +#include <linux/of_device.h> > > +#include <linux/slab.h> > > #include <linux/device.h> > #include <linux/init.h> > #include <linux/list.h> > #include <linux/mutex.h> > #include <linux/rwsem.h> Do you have a tool to detect those missing inclusions? > > > > +#include "internals.h" > > + > > +static DEFINE_IDR(i3c_bus_idr); > > +static DEFINE_MUTEX(i3c_core_lock); > > + > > > +/** > > + * i3c_bus_maintenance_lock - Release the bus lock after a maintenance > > unlock > Will fix that. > > + * operation > > + * @bus: I3C bus to release the lock on > > + * > > + * Should be called when the bus maintenance operation is done. See > > + * i3c_bus_maintenance_lock() for more details on what these maintenance > > + * operations are. > > + */ > > +void i3c_bus_maintenance_unlock(struct i3c_bus *bus) > > +{ > > + up_write(&bus->lock); > > +} > > +EXPORT_SYMBOL_GPL(i3c_bus_maintenance_unlock); > > + > > > +/** > > + * i3c_bus_normaluse_lock - Release the bus lock after a normal operation > > unlock Ditto. > > > + * @bus: I3C bus to release the lock on > > + * > > + * Should be called when a normal operation is done. See > > + * i3c_bus_normaluse_lock() for more details on what these normal operations > > + * are. > > + */ > > +void i3c_bus_normaluse_unlock(struct i3c_bus *bus) > > +{ > > + up_read(&bus->lock); > > +} > > +EXPORT_SYMBOL_GPL(i3c_bus_normaluse_unlock); > > > > > +static int i3c_device_match(struct device *dev, struct device_driver *drv) > > bool? > > > +{ > > + struct i3c_device *i3cdev; > > + struct i3c_driver *i3cdrv; > > + > > + if (dev->type != &i3c_device_type) > > + return 0; > > + > > + i3cdev = dev_to_i3cdev(dev); > > + i3cdrv = drv_to_i3cdrv(drv); > > + if (i3c_device_match_id(i3cdev, i3cdrv->id_table)) > > + return 1; > > + > > + return 0; > > +} > > > > diff --git a/drivers/i3c/device.c b/drivers/i3c/device.c > > new file mode 100644 > > index 000000000000..dcf51150b7cb > > --- /dev/null > > +++ b/drivers/i3c/device.c > > @@ -0,0 +1,344 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (C) 2017 Cadence Design Systems Inc. > > + * > > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com> > > + */ > > + > > +#include <linux/slab.h> > > #include <linux/atomic.h> > #include <linux/bug.h> > #include <linux/completion.h> > #include <linux/device.h> > #include <linux/mutex.h> > > > +#include "internals.h" > > > > > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c > > new file mode 100644 > > index 000000000000..1c85abac08d5 > > --- /dev/null > > +++ b/drivers/i3c/master.c > > @@ -0,0 +1,1433 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (C) 2017 Cadence Design Systems Inc. > > + * > > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com> > > + */ > > #include <linux/atomic.h> > #include <linux/device.h> > #include <linux/err.h> > #include <linux/export.h> > #include <linux/kernel.h> > #include <linux/list.h> > #include <linux/of.h> > > > +#include <linux/slab.h> > > #include <linux/spinlock.h> > #include <linux/workqueue.h> > > #include <asm-generic/bug.h> > > > +#include "internals.h" > > > and I probably missed a few. > > > > > > diff --git a/include/linux/i3c/ccc.h b/include/linux/i3c/ccc.h > > new file mode 100644 > > index 000000000000..ff3e1a3e2c4c > > --- /dev/null > > +++ b/include/linux/i3c/ccc.h > > @@ -0,0 +1,380 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* > > + * Copyright (C) 2017 Cadence Design Systems Inc. > > + * > > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com> > > + */ > > > +/** > > + * struct i3c_ccc_dev_desc - I3C/I3C device descriptor used for DEFSLVS > > Is one of those I3C above supposed to be I2C? Indeed, should be I2C/I3C. > > > + * > > + * @dyn_addr: dynamic address assigned to the I3C slave or 0 if the entry is > > + * describing an I2C slave. > > + * @dcr: DCR value (not applicable to entries describing I2C devices) > > + * @lvr: LVR value (not applicable to entries describing I3C devices) > > + * @bcr: BCR value or 0 if this entry is describing an I2C slave > > + * @static_addr: static address or 0 if the device does not have a static > > + * address > > + * > > + * The DEFSLVS command should be passed an array of i3c_ccc_dev_desc > > + * descriptors (one entry per I3C/I2C dev controlled by the master). > > + */ > > +struct i3c_ccc_dev_desc { > > + u8 dyn_addr; > > + union { > > + u8 dcr; > > + u8 lvr; > > + }; > > + u8 bcr; > > + u8 static_addr; > > +} __packed; > > > Needs bitops.h > > > diff --git a/include/linux/i3c/device.h b/include/linux/i3c/device.h > > new file mode 100644 > > index 000000000000..83958d3a02e2 > > --- /dev/null > > +++ b/include/linux/i3c/device.h > > @@ -0,0 +1,321 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* > > + * Copyright (C) 2017 Cadence Design Systems Inc. > > + * > > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com> > > + */ > > + > > +#ifndef I3C_DEV_H > > +#define I3C_DEV_H > > + > > +#include <linux/device.h> > > +#include <linux/i2c.h> > > +#include <linux/mod_devicetable.h> > > +#include <linux/module.h> > > > Needs bitops.h, kconfig.h. > > > > diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h > > new file mode 100644 > > index 000000000000..7ec9a4821bac > > --- /dev/null > > +++ b/include/linux/i3c/master.h > > @@ -0,0 +1,564 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* > > + * Copyright (C) 2017 Cadence Design Systems Inc. > > + * > > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com> > > + */ > > + > > +#ifndef I3C_MASTER_H > > +#define I3C_MASTER_H > > + > > +#include <linux/i2c.h> > > +#include <linux/i3c/ccc.h> > > +#include <linux/i3c/device.h> > > +#include <linux/spinlock.h> > > + > > +#define I3C_HOT_JOIN_ADDR 0x2 > > +#define I3C_BROADCAST_ADDR 0x7e > > +#define I3C_MAX_ADDR GENMASK(6, 0) > > + > > Needs bitops.h, workqueue.h, rwsem.h > > > Needs <asm-generic/bitsperlong.h> Okay, that's really weird to directly include a header from the asm-generic directory, are you sure this is the right thing to do here? > > > > > diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h > > index abb6dc2ebbf8..e59da92d8ac9 100644 > > --- a/include/linux/mod_devicetable.h > > +++ b/include/linux/mod_devicetable.h > > @@ -442,6 +442,23 @@ struct pci_epf_device_id { > > kernel_ulong_t driver_data; > > }; > > > > +/* i3c */ > > + > > +#define I3C_MATCH_DCR BIT(0) > > +#define I3C_MATCH_MANUF BIT(1) > > +#define I3C_MATCH_PART BIT(2) > > +#define I3C_MATCH_EXTRA_INFO BIT(3) > > Needs bitops.h. I think I'll just avoid using BIT() here, as done for other definitions in this file. > > > +struct i3c_device_id { > > + __u8 match_flags; > > + __u8 dcr; > > + __u16 manuf_id; > > + __u16 part_id; > > + __u16 extra_info; > > + > > + const void *data; > > +}; > > + > > /* spi */ > > > > #define SPI_NAME_SIZE 32 > > > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/18/2017 12:37 AM, Boris Brezillon wrote: > On Sun, 17 Dec 2017 14:32:04 -0800 > Randy Dunlap <rdunlap@infradead.org> wrote: > >> On 12/14/17 07:16, Boris Brezillon wrote: >>> Add core infrastructure to support I3C in Linux and document it. >>> >>> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> >>> --- >>> drivers/Kconfig | 2 + >>> drivers/Makefile | 2 +- >>> drivers/i3c/Kconfig | 24 + >>> drivers/i3c/Makefile | 4 + >>> drivers/i3c/core.c | 573 ++++++++++++++++ >>> drivers/i3c/device.c | 344 ++++++++++ >>> drivers/i3c/internals.h | 34 + >>> drivers/i3c/master.c | 1433 +++++++++++++++++++++++++++++++++++++++ >>> drivers/i3c/master/Kconfig | 0 >>> drivers/i3c/master/Makefile | 0 >>> include/linux/i3c/ccc.h | 380 +++++++++++ >>> include/linux/i3c/device.h | 321 +++++++++ >>> include/linux/i3c/master.h | 564 +++++++++++++++ >>> include/linux/mod_devicetable.h | 17 + >>> 14 files changed, 3697 insertions(+), 1 deletion(-) >>> create mode 100644 drivers/i3c/Kconfig >>> create mode 100644 drivers/i3c/Makefile >>> create mode 100644 drivers/i3c/core.c >>> create mode 100644 drivers/i3c/device.c >>> create mode 100644 drivers/i3c/internals.h >>> create mode 100644 drivers/i3c/master.c >>> create mode 100644 drivers/i3c/master/Kconfig >>> create mode 100644 drivers/i3c/master/Makefile >>> create mode 100644 include/linux/i3c/ccc.h >>> create mode 100644 include/linux/i3c/device.h >>> create mode 100644 include/linux/i3c/master.h >>> diff --git a/drivers/i3c/core.c b/drivers/i3c/core.c >>> new file mode 100644 >>> index 000000000000..7eb8e84acd33 >>> --- /dev/null >>> +++ b/drivers/i3c/core.c >>> @@ -0,0 +1,573 @@ >>> +// SPDX-License-Identifier: GPL-2.0 >>> +/* >>> + * Copyright (C) 2017 Cadence Design Systems Inc. >>> + * >>> + * Author: Boris Brezillon <boris.brezillon@free-electrons.com> >>> + */ >>> + >>> +#include <linux/idr.h> >>> +#include <linux/module.h> >>> +#include <linux/of_device.h> >>> +#include <linux/slab.h> >> >> #include <linux/device.h> >> #include <linux/init.h> >> #include <linux/list.h> >> #include <linux/mutex.h> >> #include <linux/rwsem.h> > > Do you have a tool to detect those missing inclusions? Nope, I've often wanted one, but for now it's just slow reading. >>> diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h >>> new file mode 100644 >>> index 000000000000..7ec9a4821bac >>> --- /dev/null >>> +++ b/include/linux/i3c/master.h >>> @@ -0,0 +1,564 @@ >>> +/* SPDX-License-Identifier: GPL-2.0 */ >>> +/* >>> + * Copyright (C) 2017 Cadence Design Systems Inc. >>> + * >>> + * Author: Boris Brezillon <boris.brezillon@free-electrons.com> >>> + */ >>> + >>> +#ifndef I3C_MASTER_H >>> +#define I3C_MASTER_H >>> + >>> +#include <linux/i2c.h> >>> +#include <linux/i3c/ccc.h> >>> +#include <linux/i3c/device.h> >>> +#include <linux/spinlock.h> >>> + >>> +#define I3C_HOT_JOIN_ADDR 0x2 >>> +#define I3C_BROADCAST_ADDR 0x7e >>> +#define I3C_MAX_ADDR GENMASK(6, 0) >>> + >> >> Needs bitops.h, workqueue.h, rwsem.h >> >> >> Needs <asm-generic/bitsperlong.h> > > Okay, that's really weird to directly include a header from the > asm-generic directory, are you sure this is the right thing to do here? Looks like it should be <asm/bitsperlong.h>, which will grab the correct one.
On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote: > +/** > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev > + * @i3cdev: the I3C device we're searching a match for > + * @id_table: the I3C device ID table > + * > + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's > + * no match. > + */ > +const struct i3c_device_id * > +i3c_device_match_id(struct i3c_device *i3cdev, > + const struct i3c_device_id *id_table) > +{ > + const struct i3c_device_id *id; > + > + /* > + * The lower 32bits of the provisional ID is just filled with a random > + * value, try to match using DCR info. > + */ > + if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) { > + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid); > + u16 part = I3C_PID_PART_ID(i3cdev->info.pid); > + u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid); > + > + /* First try to match by manufacturer/part ID. */ > + for (id = id_table; id->match_flags != 0; id++) { > + if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) != > + I3C_MATCH_MANUF_AND_PART) > + continue; > + > + if (manuf != id->manuf_id || part != id->part_id) > + continue; > + > + if ((id->match_flags & I3C_MATCH_EXTRA_INFO) && > + ext_info != id->extra_info) > + continue; > + > + return id; > + } > + } > + > + /* Fallback to DCR match. */ > + for (id = id_table; id->match_flags != 0; id++) { > + if ((id->match_flags & I3C_MATCH_DCR) && > + id->dcr == i3cdev->info.dcr) > + return id; > + } > + > + return NULL; > +} > +EXPORT_SYMBOL_GPL(i3c_device_match_id); I just picked one random export here, but it feels like you are exporting a bunch of symbols you don't need to. Why would something outside of the i3c "core" need to call this function? Have you looked to see if you really have callers for everything you are exporting? Other than that, the driver core interaction looks good now, nice job. greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 19 Dec 2017 09:52:50 +0100 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote: > > +/** > > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev > > + * @i3cdev: the I3C device we're searching a match for > > + * @id_table: the I3C device ID table > > + * > > + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's > > + * no match. > > + */ > > +const struct i3c_device_id * > > +i3c_device_match_id(struct i3c_device *i3cdev, > > + const struct i3c_device_id *id_table) > > +{ > > + const struct i3c_device_id *id; > > + > > + /* > > + * The lower 32bits of the provisional ID is just filled with a random > > + * value, try to match using DCR info. > > + */ > > + if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) { > > + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid); > > + u16 part = I3C_PID_PART_ID(i3cdev->info.pid); > > + u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid); > > + > > + /* First try to match by manufacturer/part ID. */ > > + for (id = id_table; id->match_flags != 0; id++) { > > + if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) != > > + I3C_MATCH_MANUF_AND_PART) > > + continue; > > + > > + if (manuf != id->manuf_id || part != id->part_id) > > + continue; > > + > > + if ((id->match_flags & I3C_MATCH_EXTRA_INFO) && > > + ext_info != id->extra_info) > > + continue; > > + > > + return id; > > + } > > + } > > + > > + /* Fallback to DCR match. */ > > + for (id = id_table; id->match_flags != 0; id++) { > > + if ((id->match_flags & I3C_MATCH_DCR) && > > + id->dcr == i3cdev->info.dcr) > > + return id; > > + } > > + > > + return NULL; > > +} > > +EXPORT_SYMBOL_GPL(i3c_device_match_id); > > I just picked one random export here, but it feels like you are > exporting a bunch of symbols you don't need to. Why would something > outside of the i3c "core" need to call this function? Because I'm not passing the i3c_device_id to the ->probe() method, and if the driver is supporting different variants of the device, it may want to know which one is being probed. I considered retrieving this information in the core just before probing the driver and passing it to the ->probe() function, but it means having an extra i3c_device_match_id() call for everyone even those who don't care about the device_id information, so I thought exporting this function was a good alternative (device drivers can use it when they actually need to retrieve the device_id). Anyway, that's something I can change if you think passing the i3c_device_id to the ->probe() method is preferable. > Have you looked > to see if you really have callers for everything you are exporting? Yes, I tried to only export functions that I think will be needed by I3C device drivers and I3C master drivers. Note that I didn't post the dummy device driver I developed to test the framework (partly because this is > > Other than that, the driver core interaction looks good now, nice job. Thanks. Boris -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 19 Dec 2017 10:09:00 +0100 Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > On Tue, 19 Dec 2017 09:52:50 +0100 > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote: > > > +/** > > > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev > > > + * @i3cdev: the I3C device we're searching a match for > > > + * @id_table: the I3C device ID table > > > + * > > > + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's > > > + * no match. > > > + */ > > > +const struct i3c_device_id * > > > +i3c_device_match_id(struct i3c_device *i3cdev, > > > + const struct i3c_device_id *id_table) > > > +{ > > > + const struct i3c_device_id *id; > > > + > > > + /* > > > + * The lower 32bits of the provisional ID is just filled with a random > > > + * value, try to match using DCR info. > > > + */ > > > + if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) { > > > + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid); > > > + u16 part = I3C_PID_PART_ID(i3cdev->info.pid); > > > + u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid); > > > + > > > + /* First try to match by manufacturer/part ID. */ > > > + for (id = id_table; id->match_flags != 0; id++) { > > > + if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) != > > > + I3C_MATCH_MANUF_AND_PART) > > > + continue; > > > + > > > + if (manuf != id->manuf_id || part != id->part_id) > > > + continue; > > > + > > > + if ((id->match_flags & I3C_MATCH_EXTRA_INFO) && > > > + ext_info != id->extra_info) > > > + continue; > > > + > > > + return id; > > > + } > > > + } > > > + > > > + /* Fallback to DCR match. */ > > > + for (id = id_table; id->match_flags != 0; id++) { > > > + if ((id->match_flags & I3C_MATCH_DCR) && > > > + id->dcr == i3cdev->info.dcr) > > > + return id; > > > + } > > > + > > > + return NULL; > > > +} > > > +EXPORT_SYMBOL_GPL(i3c_device_match_id); > > > > I just picked one random export here, but it feels like you are > > exporting a bunch of symbols you don't need to. Why would something > > outside of the i3c "core" need to call this function? > > Because I'm not passing the i3c_device_id to the ->probe() method, and > if the driver is supporting different variants of the device, it may > want to know which one is being probed. > > I considered retrieving this information in the core just before probing > the driver and passing it to the ->probe() function, but it means > having an extra i3c_device_match_id() call for everyone even those who > don't care about the device_id information, so I thought exporting this > function was a good alternative (device drivers can use it when they > actually need to retrieve the device_id). > > Anyway, that's something I can change if you think passing the > i3c_device_id to the ->probe() method is preferable. > > > Have you looked > > to see if you really have callers for everything you are exporting? > > Yes, I tried to only export functions that I think will be needed by > I3C device drivers and I3C master drivers. Note that I didn't post the > dummy device driver I developed to test the framework (partly because > this is Sorry, I hit the send button before finishing my sentence :-). " Note that I didn't post the dummy device driver [1] I developed to test the framework (partly because the quality of the code does not meet mainline standards and I was ashamed of posting it publicly :-)), but this driver is using some of the exported functions. " [1]https://github.com/bbrezillon/linux-0day/commit/10054caf3493524b6ae352a1bdcb71e82c885a6e -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Dec 19, 2017 at 10:13:36AM +0100, Boris Brezillon wrote: > On Tue, 19 Dec 2017 10:09:00 +0100 > Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > > > On Tue, 19 Dec 2017 09:52:50 +0100 > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > > > > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote: > > > > +/** > > > > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev > > > > + * @i3cdev: the I3C device we're searching a match for > > > > + * @id_table: the I3C device ID table > > > > + * > > > > + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's > > > > + * no match. > > > > + */ > > > > +const struct i3c_device_id * > > > > +i3c_device_match_id(struct i3c_device *i3cdev, > > > > + const struct i3c_device_id *id_table) > > > > +{ > > > > + const struct i3c_device_id *id; > > > > + > > > > + /* > > > > + * The lower 32bits of the provisional ID is just filled with a random > > > > + * value, try to match using DCR info. > > > > + */ > > > > + if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) { > > > > + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid); > > > > + u16 part = I3C_PID_PART_ID(i3cdev->info.pid); > > > > + u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid); > > > > + > > > > + /* First try to match by manufacturer/part ID. */ > > > > + for (id = id_table; id->match_flags != 0; id++) { > > > > + if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) != > > > > + I3C_MATCH_MANUF_AND_PART) > > > > + continue; > > > > + > > > > + if (manuf != id->manuf_id || part != id->part_id) > > > > + continue; > > > > + > > > > + if ((id->match_flags & I3C_MATCH_EXTRA_INFO) && > > > > + ext_info != id->extra_info) > > > > + continue; > > > > + > > > > + return id; > > > > + } > > > > + } > > > > + > > > > + /* Fallback to DCR match. */ > > > > + for (id = id_table; id->match_flags != 0; id++) { > > > > + if ((id->match_flags & I3C_MATCH_DCR) && > > > > + id->dcr == i3cdev->info.dcr) > > > > + return id; > > > > + } > > > > + > > > > + return NULL; > > > > +} > > > > +EXPORT_SYMBOL_GPL(i3c_device_match_id); > > > > > > I just picked one random export here, but it feels like you are > > > exporting a bunch of symbols you don't need to. Why would something > > > outside of the i3c "core" need to call this function? > > > > Because I'm not passing the i3c_device_id to the ->probe() method, and > > if the driver is supporting different variants of the device, it may > > want to know which one is being probed. > > > > I considered retrieving this information in the core just before probing > > the driver and passing it to the ->probe() function, but it means > > having an extra i3c_device_match_id() call for everyone even those who > > don't care about the device_id information, so I thought exporting this > > function was a good alternative (device drivers can use it when they > > actually need to retrieve the device_id). > > > > Anyway, that's something I can change if you think passing the > > i3c_device_id to the ->probe() method is preferable. > > > > > Have you looked > > > to see if you really have callers for everything you are exporting? > > > > Yes, I tried to only export functions that I think will be needed by > > I3C device drivers and I3C master drivers. Note that I didn't post the > > dummy device driver I developed to test the framework (partly because > > this is > > Sorry, I hit the send button before finishing my sentence :-). > > " > Note that I didn't post the dummy device driver [1] I developed to test > the framework (partly because the quality of the code does not meet > mainline standards and I was ashamed of posting it publicly :-)), but > this driver is using some of the exported functions. > " We don't export functions that has no in-kernel users :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 19 Dec 2017 10:21:19 +0100 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Tue, Dec 19, 2017 at 10:13:36AM +0100, Boris Brezillon wrote: > > On Tue, 19 Dec 2017 10:09:00 +0100 > > Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > > > > > On Tue, 19 Dec 2017 09:52:50 +0100 > > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > > > > > > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote: > > > > > +/** > > > > > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev > > > > > + * @i3cdev: the I3C device we're searching a match for > > > > > + * @id_table: the I3C device ID table > > > > > + * > > > > > + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's > > > > > + * no match. > > > > > + */ > > > > > +const struct i3c_device_id * > > > > > +i3c_device_match_id(struct i3c_device *i3cdev, > > > > > + const struct i3c_device_id *id_table) > > > > > +{ > > > > > + const struct i3c_device_id *id; > > > > > + > > > > > + /* > > > > > + * The lower 32bits of the provisional ID is just filled with a random > > > > > + * value, try to match using DCR info. > > > > > + */ > > > > > + if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) { > > > > > + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid); > > > > > + u16 part = I3C_PID_PART_ID(i3cdev->info.pid); > > > > > + u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid); > > > > > + > > > > > + /* First try to match by manufacturer/part ID. */ > > > > > + for (id = id_table; id->match_flags != 0; id++) { > > > > > + if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) != > > > > > + I3C_MATCH_MANUF_AND_PART) > > > > > + continue; > > > > > + > > > > > + if (manuf != id->manuf_id || part != id->part_id) > > > > > + continue; > > > > > + > > > > > + if ((id->match_flags & I3C_MATCH_EXTRA_INFO) && > > > > > + ext_info != id->extra_info) > > > > > + continue; > > > > > + > > > > > + return id; > > > > > + } > > > > > + } > > > > > + > > > > > + /* Fallback to DCR match. */ > > > > > + for (id = id_table; id->match_flags != 0; id++) { > > > > > + if ((id->match_flags & I3C_MATCH_DCR) && > > > > > + id->dcr == i3cdev->info.dcr) > > > > > + return id; > > > > > + } > > > > > + > > > > > + return NULL; > > > > > +} > > > > > +EXPORT_SYMBOL_GPL(i3c_device_match_id); > > > > > > > > I just picked one random export here, but it feels like you are > > > > exporting a bunch of symbols you don't need to. Why would something > > > > outside of the i3c "core" need to call this function? > > > > > > Because I'm not passing the i3c_device_id to the ->probe() method, and > > > if the driver is supporting different variants of the device, it may > > > want to know which one is being probed. > > > > > > I considered retrieving this information in the core just before probing > > > the driver and passing it to the ->probe() function, but it means > > > having an extra i3c_device_match_id() call for everyone even those who > > > don't care about the device_id information, so I thought exporting this > > > function was a good alternative (device drivers can use it when they > > > actually need to retrieve the device_id). > > > > > > Anyway, that's something I can change if you think passing the > > > i3c_device_id to the ->probe() method is preferable. > > > > > > > Have you looked > > > > to see if you really have callers for everything you are exporting? > > > > > > Yes, I tried to only export functions that I think will be needed by > > > I3C device drivers and I3C master drivers. Note that I didn't post the > > > dummy device driver I developed to test the framework (partly because > > > this is > > > > Sorry, I hit the send button before finishing my sentence :-). > > > > " > > Note that I didn't post the dummy device driver [1] I developed to test > > the framework (partly because the quality of the code does not meet > > mainline standards and I was ashamed of posting it publicly :-)), but > > this driver is using some of the exported functions. > > " > > We don't export functions that has no in-kernel users :) But then, I can't export device driver related functions, because there's no official device driver yet :-). So what should I do? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Dec 19, 2017 at 10:28:58AM +0100, Boris Brezillon wrote: > On Tue, 19 Dec 2017 10:21:19 +0100 > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > > On Tue, Dec 19, 2017 at 10:13:36AM +0100, Boris Brezillon wrote: > > > On Tue, 19 Dec 2017 10:09:00 +0100 > > > Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > > > > > > > On Tue, 19 Dec 2017 09:52:50 +0100 > > > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > > > > > > > > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote: > > > > > > +/** > > > > > > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev > > > > > > + * @i3cdev: the I3C device we're searching a match for > > > > > > + * @id_table: the I3C device ID table > > > > > > + * > > > > > > + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's > > > > > > + * no match. > > > > > > + */ > > > > > > +const struct i3c_device_id * > > > > > > +i3c_device_match_id(struct i3c_device *i3cdev, > > > > > > + const struct i3c_device_id *id_table) > > > > > > +{ > > > > > > + const struct i3c_device_id *id; > > > > > > + > > > > > > + /* > > > > > > + * The lower 32bits of the provisional ID is just filled with a random > > > > > > + * value, try to match using DCR info. > > > > > > + */ > > > > > > + if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) { > > > > > > + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid); > > > > > > + u16 part = I3C_PID_PART_ID(i3cdev->info.pid); > > > > > > + u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid); > > > > > > + > > > > > > + /* First try to match by manufacturer/part ID. */ > > > > > > + for (id = id_table; id->match_flags != 0; id++) { > > > > > > + if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) != > > > > > > + I3C_MATCH_MANUF_AND_PART) > > > > > > + continue; > > > > > > + > > > > > > + if (manuf != id->manuf_id || part != id->part_id) > > > > > > + continue; > > > > > > + > > > > > > + if ((id->match_flags & I3C_MATCH_EXTRA_INFO) && > > > > > > + ext_info != id->extra_info) > > > > > > + continue; > > > > > > + > > > > > > + return id; > > > > > > + } > > > > > > + } > > > > > > + > > > > > > + /* Fallback to DCR match. */ > > > > > > + for (id = id_table; id->match_flags != 0; id++) { > > > > > > + if ((id->match_flags & I3C_MATCH_DCR) && > > > > > > + id->dcr == i3cdev->info.dcr) > > > > > > + return id; > > > > > > + } > > > > > > + > > > > > > + return NULL; > > > > > > +} > > > > > > +EXPORT_SYMBOL_GPL(i3c_device_match_id); > > > > > > > > > > I just picked one random export here, but it feels like you are > > > > > exporting a bunch of symbols you don't need to. Why would something > > > > > outside of the i3c "core" need to call this function? > > > > > > > > Because I'm not passing the i3c_device_id to the ->probe() method, and > > > > if the driver is supporting different variants of the device, it may > > > > want to know which one is being probed. > > > > > > > > I considered retrieving this information in the core just before probing > > > > the driver and passing it to the ->probe() function, but it means > > > > having an extra i3c_device_match_id() call for everyone even those who > > > > don't care about the device_id information, so I thought exporting this > > > > function was a good alternative (device drivers can use it when they > > > > actually need to retrieve the device_id). > > > > > > > > Anyway, that's something I can change if you think passing the > > > > i3c_device_id to the ->probe() method is preferable. > > > > > > > > > Have you looked > > > > > to see if you really have callers for everything you are exporting? > > > > > > > > Yes, I tried to only export functions that I think will be needed by > > > > I3C device drivers and I3C master drivers. Note that I didn't post the > > > > dummy device driver I developed to test the framework (partly because > > > > this is > > > > > > Sorry, I hit the send button before finishing my sentence :-). > > > > > > " > > > Note that I didn't post the dummy device driver [1] I developed to test > > > the framework (partly because the quality of the code does not meet > > > mainline standards and I was ashamed of posting it publicly :-)), but > > > this driver is using some of the exported functions. > > > " > > > > We don't export functions that has no in-kernel users :) > > But then, I can't export device driver related functions, because > there's no official device driver yet :-). So what should I do? Export them when you have a driver. Or better yet, submit a driver as part of the patch series. Why would we want infrastructure that no one uses? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Greg, On Tue, 19 Dec 2017 10:36:43 +0100 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Tue, Dec 19, 2017 at 10:28:58AM +0100, Boris Brezillon wrote: > > On Tue, 19 Dec 2017 10:21:19 +0100 > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > > > > On Tue, Dec 19, 2017 at 10:13:36AM +0100, Boris Brezillon wrote: > > > > On Tue, 19 Dec 2017 10:09:00 +0100 > > > > Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > > > > > > > > > On Tue, 19 Dec 2017 09:52:50 +0100 > > > > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > > > > > > > > > > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote: > > > > > > > +/** > > > > > > > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev > > > > > > > + * @i3cdev: the I3C device we're searching a match for > > > > > > > + * @id_table: the I3C device ID table > > > > > > > + * > > > > > > > + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's > > > > > > > + * no match. > > > > > > > + */ > > > > > > > +const struct i3c_device_id * > > > > > > > +i3c_device_match_id(struct i3c_device *i3cdev, > > > > > > > + const struct i3c_device_id *id_table) > > > > > > > +{ > > > > > > > + const struct i3c_device_id *id; > > > > > > > + > > > > > > > + /* > > > > > > > + * The lower 32bits of the provisional ID is just filled with a random > > > > > > > + * value, try to match using DCR info. > > > > > > > + */ > > > > > > > + if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) { > > > > > > > + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid); > > > > > > > + u16 part = I3C_PID_PART_ID(i3cdev->info.pid); > > > > > > > + u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid); > > > > > > > + > > > > > > > + /* First try to match by manufacturer/part ID. */ > > > > > > > + for (id = id_table; id->match_flags != 0; id++) { > > > > > > > + if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) != > > > > > > > + I3C_MATCH_MANUF_AND_PART) > > > > > > > + continue; > > > > > > > + > > > > > > > + if (manuf != id->manuf_id || part != id->part_id) > > > > > > > + continue; > > > > > > > + > > > > > > > + if ((id->match_flags & I3C_MATCH_EXTRA_INFO) && > > > > > > > + ext_info != id->extra_info) > > > > > > > + continue; > > > > > > > + > > > > > > > + return id; > > > > > > > + } > > > > > > > + } > > > > > > > + > > > > > > > + /* Fallback to DCR match. */ > > > > > > > + for (id = id_table; id->match_flags != 0; id++) { > > > > > > > + if ((id->match_flags & I3C_MATCH_DCR) && > > > > > > > + id->dcr == i3cdev->info.dcr) > > > > > > > + return id; > > > > > > > + } > > > > > > > + > > > > > > > + return NULL; > > > > > > > +} > > > > > > > +EXPORT_SYMBOL_GPL(i3c_device_match_id); > > > > > > > > > > > > I just picked one random export here, but it feels like you are > > > > > > exporting a bunch of symbols you don't need to. Why would something > > > > > > outside of the i3c "core" need to call this function? > > > > > > > > > > Because I'm not passing the i3c_device_id to the ->probe() method, and > > > > > if the driver is supporting different variants of the device, it may > > > > > want to know which one is being probed. > > > > > > > > > > I considered retrieving this information in the core just before probing > > > > > the driver and passing it to the ->probe() function, but it means > > > > > having an extra i3c_device_match_id() call for everyone even those who > > > > > don't care about the device_id information, so I thought exporting this > > > > > function was a good alternative (device drivers can use it when they > > > > > actually need to retrieve the device_id). > > > > > > > > > > Anyway, that's something I can change if you think passing the > > > > > i3c_device_id to the ->probe() method is preferable. > > > > > > > > > > > Have you looked > > > > > > to see if you really have callers for everything you are exporting? > > > > > > > > > > Yes, I tried to only export functions that I think will be needed by > > > > > I3C device drivers and I3C master drivers. Note that I didn't post the > > > > > dummy device driver I developed to test the framework (partly because > > > > > this is > > > > > > > > Sorry, I hit the send button before finishing my sentence :-). > > > > > > > > " > > > > Note that I didn't post the dummy device driver [1] I developed to test > > > > the framework (partly because the quality of the code does not meet > > > > mainline standards and I was ashamed of posting it publicly :-)), but > > > > this driver is using some of the exported functions. > > > > " > > > > > > We don't export functions that has no in-kernel users :) > > > > But then, I can't export device driver related functions, because > > there's no official device driver yet :-). So what should I do? > > Export them when you have a driver. Or better yet, submit a driver as > part of the patch series. Why would we want infrastructure that no one > uses? I understand your point of view, it may sound odd to add a framework for a bus that we have no slave devices for. But, as far as I can tell, many vendors (both IP vendors and sensor manufacturers) are working actively on creating master and slave I3C devices. Actually, I've even been contacted privately by an IP vendor after posting this patchset. So, I think one argument for pushing the current framework with no users yet is that it may help others develop drivers for their device early on, or even help them test those devices more easily than if they had to develop baremetal code. The kernel community has been asking hardware vendors for a long time to upstream their code as early as possible. And this is exactly what is happening with I3C: even before actual devices are shipping, we have the opportunity to start merging support for I3C in the mainline kernel. It would be good to merge it before vendors spend time working on competing implementations, which will take even more time to reconcile when they will be submitted for upstream inclusion. Also, we're not talking about some random bus/protocol, I3C spec is developed and pushed by MIPI, and for once, they decided to open the spec, so anyone can actually make sure the framework is matching the protocol description if they want to. Now, if you still think an I3C device driver is needed to consider merging these patches, I can provide one. As I said earlier, I developed a driver for a dummy device to test the various features I add support for in this series, it's just that this device will never ever be available in real life and it's not even fitting in any of the subsystem we have in the kernel, hence my initial decision to not upstream it. Regards, Boris
On Wed, Feb 21, 2018 at 03:22:48PM +0100, Boris Brezillon wrote: > Hi Greg, > > On Tue, 19 Dec 2017 10:36:43 +0100 > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > > On Tue, Dec 19, 2017 at 10:28:58AM +0100, Boris Brezillon wrote: > > > On Tue, 19 Dec 2017 10:21:19 +0100 > > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > > > > > > On Tue, Dec 19, 2017 at 10:13:36AM +0100, Boris Brezillon wrote: > > > > > On Tue, 19 Dec 2017 10:09:00 +0100 > > > > > Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > > > > > > > > > > > On Tue, 19 Dec 2017 09:52:50 +0100 > > > > > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > > > > > > > > > > > > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote: > > > > > > > > +/** > > > > > > > > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev > > > > > > > > + * @i3cdev: the I3C device we're searching a match for > > > > > > > > + * @id_table: the I3C device ID table > > > > > > > > + * > > > > > > > > + * Return: a pointer to the first entry matching @i3cdev, or NULL if there's > > > > > > > > + * no match. > > > > > > > > + */ > > > > > > > > +const struct i3c_device_id * > > > > > > > > +i3c_device_match_id(struct i3c_device *i3cdev, > > > > > > > > + const struct i3c_device_id *id_table) > > > > > > > > +{ > > > > > > > > + const struct i3c_device_id *id; > > > > > > > > + > > > > > > > > + /* > > > > > > > > + * The lower 32bits of the provisional ID is just filled with a random > > > > > > > > + * value, try to match using DCR info. > > > > > > > > + */ > > > > > > > > + if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) { > > > > > > > > + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid); > > > > > > > > + u16 part = I3C_PID_PART_ID(i3cdev->info.pid); > > > > > > > > + u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid); > > > > > > > > + > > > > > > > > + /* First try to match by manufacturer/part ID. */ > > > > > > > > + for (id = id_table; id->match_flags != 0; id++) { > > > > > > > > + if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) != > > > > > > > > + I3C_MATCH_MANUF_AND_PART) > > > > > > > > + continue; > > > > > > > > + > > > > > > > > + if (manuf != id->manuf_id || part != id->part_id) > > > > > > > > + continue; > > > > > > > > + > > > > > > > > + if ((id->match_flags & I3C_MATCH_EXTRA_INFO) && > > > > > > > > + ext_info != id->extra_info) > > > > > > > > + continue; > > > > > > > > + > > > > > > > > + return id; > > > > > > > > + } > > > > > > > > + } > > > > > > > > + > > > > > > > > + /* Fallback to DCR match. */ > > > > > > > > + for (id = id_table; id->match_flags != 0; id++) { > > > > > > > > + if ((id->match_flags & I3C_MATCH_DCR) && > > > > > > > > + id->dcr == i3cdev->info.dcr) > > > > > > > > + return id; > > > > > > > > + } > > > > > > > > + > > > > > > > > + return NULL; > > > > > > > > +} > > > > > > > > +EXPORT_SYMBOL_GPL(i3c_device_match_id); > > > > > > > > > > > > > > I just picked one random export here, but it feels like you are > > > > > > > exporting a bunch of symbols you don't need to. Why would something > > > > > > > outside of the i3c "core" need to call this function? > > > > > > > > > > > > Because I'm not passing the i3c_device_id to the ->probe() method, and > > > > > > if the driver is supporting different variants of the device, it may > > > > > > want to know which one is being probed. > > > > > > > > > > > > I considered retrieving this information in the core just before probing > > > > > > the driver and passing it to the ->probe() function, but it means > > > > > > having an extra i3c_device_match_id() call for everyone even those who > > > > > > don't care about the device_id information, so I thought exporting this > > > > > > function was a good alternative (device drivers can use it when they > > > > > > actually need to retrieve the device_id). > > > > > > > > > > > > Anyway, that's something I can change if you think passing the > > > > > > i3c_device_id to the ->probe() method is preferable. > > > > > > > > > > > > > Have you looked > > > > > > > to see if you really have callers for everything you are exporting? > > > > > > > > > > > > Yes, I tried to only export functions that I think will be needed by > > > > > > I3C device drivers and I3C master drivers. Note that I didn't post the > > > > > > dummy device driver I developed to test the framework (partly because > > > > > > this is > > > > > > > > > > Sorry, I hit the send button before finishing my sentence :-). > > > > > > > > > > " > > > > > Note that I didn't post the dummy device driver [1] I developed to test > > > > > the framework (partly because the quality of the code does not meet > > > > > mainline standards and I was ashamed of posting it publicly :-)), but > > > > > this driver is using some of the exported functions. > > > > > " > > > > > > > > We don't export functions that has no in-kernel users :) > > > > > > But then, I can't export device driver related functions, because > > > there's no official device driver yet :-). So what should I do? > > > > Export them when you have a driver. Or better yet, submit a driver as > > part of the patch series. Why would we want infrastructure that no one > > uses? > > I understand your point of view, it may sound odd to add a framework > for a bus that we have no slave devices for. But, as far as I can tell, > many vendors (both IP vendors and sensor manufacturers) are working > actively on creating master and slave I3C devices. Actually, I've even > been contacted privately by an IP vendor after posting this patchset. > So, I think one argument for pushing the current framework with no > users yet is that it may help others develop drivers for their device > early on, or even help them test those devices more easily than if they > had to develop baremetal code. > > The kernel community has been asking hardware vendors for a long time to > upstream their code as early as possible. And this is exactly what is > happening with I3C: even before actual devices are shipping, we have > the opportunity to start merging support for I3C in the mainline > kernel. It would be good to merge it before vendors spend time working > on competing implementations, which will take even more time to > reconcile when they will be submitted for upstream inclusion. But without real users of an api, you do not even know if it works or not at all. In reality, you need at least 3 users of an api to know if it is correct. How do you even know this works or not? Again, we don't merge "frameworks" that no one uses. > Also, we're not talking about some random bus/protocol, I3C spec is > developed and pushed by MIPI, and for once, they decided to open the > spec, so anyone can actually make sure the framework is matching the > protocol description if they want to. One might consider i3c any "random" bus, given that there are no devices for it yet :) > Now, if you still think an I3C device driver is needed to consider > merging these patches, I can provide one. As I said earlier, I > developed a driver for a dummy device to test the various features I > add support for in this series, it's just that this device will never > ever be available in real life and it's not even fitting in any of the > subsystem we have in the kernel, hence my initial decision to not > upstream it. What is stopping you from working with one of those aformentioned companies to get a driver working for their hardware? Without that type of testing, you don't even know if your framework is correct or not. Dummy drivers are nice, but those are written to fit into your framework more than they are to driver an actual device, which might require changes to the framework. So please, just work with those companies, get a real driver, and then I will be glad to merge it all, driver included. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Boris, We are very interested in your I3C subsystem proposal and we would like to colaborate with you in order to add support for the Synopsys Host Controller. We are doing the review for this patch-set and will send our conclusions as soon as possible. Best regards, Vitor Soares Às 3:16 PM de 12/14/2017, Boris Brezillon escreveu: > This patch series is a proposal for a new I3C [1] subsystem. > > This infrastructure is not complete yet and will be extended over > time. > > There are a few design choices that are worth mentioning because they > impact the way I3C device drivers can interact with their devices: > > - all functions used to send I3C/I2C frames must be called in > non-atomic context. Mainly done this way to ease implementation, but > this is still open to discussion. Please let me know if you think it's > worth considering an asynchronous model here > - the bus element is a separate object and is not implicitly described > by the master (as done in I2C). The reason is that I want to be able > to handle multiple master connected to the same bus and visible to > Linux. > In this situation, we should only have one instance of the device and > not one per master, and sharing the bus object would be part of the > solution to gracefully handle this case. > I'm not sure if we will ever need to deal with multiple masters > controlling the same bus and exposed under Linux, but separating the > bus and master concept is pretty easy, hence the decision to do it > now, just in case we need it some day. > The other benefit of separating the bus and master concepts is that > master devices appear under the bus directory in sysfs. > - I2C backward compatibility has been designed to be transparent to I2C > drivers and the I2C subsystem. The I3C master just registers an I2C > adapter which creates a new I2C bus. I'd say that, from a > representation PoV it's not ideal because what should appear as a > single I3C bus exposing I3C and I2C devices here appears as 2 > different busses connected to each other through the parenting (the > I3C master is the parent of the I2C and I3C busses). > On the other hand, I don't see a better solution if we want something > that is not invasive. > > Missing features in this preliminary version: > - no support for multi-master and the associated concepts (mastership > handover, support for secondary masters, ...) > - I2C devices can only be described using DT because this is the only > use case I have. However, the framework can easily be extended with > ACPI and board info support > - I3C slave framework. This has been completely omitted, but shouldn't > have a huge impact on the I3C framework because I3C slaves don't see > the whole bus, it's only about handling master requests and generating > IBIs. Some of the struct, constant and enum definitions could be > shared, but most of the I3C slave framework logic will be different > > Main changes between the initial RFC and this v2 are: > - Add a generic infrastructure to support IBIs. It's worth mentioning > that I tried exposing IBIs as a regular IRQs, but after several > attempts and a discussion with Mark Zyngier, it appeared that it was > not really fitting in the Linux IRQ model (the fact that you have > payload attached to IBIs, the fact that most of the time an IBI will > generate a transfer on the bus which has to be done in an atomic > context, ...) > The counterpart of this decision is the latency induced by the > workqueue approach, but since I don't have real use cases, I don't > know if this can be a problem or not. > - Add helpers to support Hot Join > - Add support for IBIs and Hot Join in Cadence I3C master driver > - Address several issues in how I was using the device model > > I'll finish on a good news: this week the MIPI alliance opened the I3C > spec. So everyone can now review the patches (no need to be member of > the MIPI I3C group). > I'll let you find the link in the doc, this way maybe I'll have reviews > on the doc itself :-). > > Thanks, > > Boris > > Boris Brezillon (7): > i2c: Export of_i2c_get_board_info() > i3c: Add core I3C infrastructure > docs: driver-api: Add I3C documentation > i3c: Add sysfs ABI spec > dt-bindings: i3c: Document core bindings > i3c: master: Add driver for Cadence IP > dt-bindings: i3c: Document Cadence I3C master bindings > > Documentation/ABI/testing/sysfs-bus-i3c | 95 ++ > .../devicetree/bindings/i3c/cdns,i3c-master.txt | 45 + > Documentation/devicetree/bindings/i3c/i3c.txt | 128 ++ > Documentation/driver-api/i3c/conf.py | 10 + > Documentation/driver-api/i3c/device-driver-api.rst | 7 + > Documentation/driver-api/i3c/index.rst | 9 + > Documentation/driver-api/i3c/master-driver-api.rst | 8 + > Documentation/driver-api/i3c/protocol.rst | 201 +++ > Documentation/driver-api/index.rst | 1 + > drivers/Kconfig | 2 + > drivers/Makefile | 2 +- > drivers/i2c/i2c-core-base.c | 2 +- > drivers/i2c/i2c-core-of.c | 66 +- > drivers/i3c/Kconfig | 24 + > drivers/i3c/Makefile | 4 + > drivers/i3c/core.c | 573 +++++++ > drivers/i3c/device.c | 344 ++++ > drivers/i3c/internals.h | 34 + > drivers/i3c/master.c | 1433 ++++++++++++++++ > drivers/i3c/master/Kconfig | 5 + > drivers/i3c/master/Makefile | 1 + > drivers/i3c/master/i3c-master-cdns.c | 1797 ++++++++++++++++++++ > include/linux/i2c.h | 10 + > include/linux/i3c/ccc.h | 380 +++++ > include/linux/i3c/device.h | 321 ++++ > include/linux/i3c/master.h | 564 ++++++ > include/linux/mod_devicetable.h | 17 + > 27 files changed, 6053 insertions(+), 30 deletions(-) > create mode 100644 Documentation/ABI/testing/sysfs-bus-i3c > create mode 100644 Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt > create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt > create mode 100644 Documentation/driver-api/i3c/conf.py > create mode 100644 Documentation/driver-api/i3c/device-driver-api.rst > create mode 100644 Documentation/driver-api/i3c/index.rst > create mode 100644 Documentation/driver-api/i3c/master-driver-api.rst > create mode 100644 Documentation/driver-api/i3c/protocol.rst > create mode 100644 drivers/i3c/Kconfig > create mode 100644 drivers/i3c/Makefile > create mode 100644 drivers/i3c/core.c > create mode 100644 drivers/i3c/device.c > create mode 100644 drivers/i3c/internals.h > create mode 100644 drivers/i3c/master.c > create mode 100644 drivers/i3c/master/Kconfig > create mode 100644 drivers/i3c/master/Makefile > create mode 100644 drivers/i3c/master/i3c-master-cdns.c > create mode 100644 include/linux/i3c/ccc.h > create mode 100644 include/linux/i3c/device.h > create mode 100644 include/linux/i3c/master.h > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Boris, Às 3:16 PM de 12/14/2017, Boris Brezillon escreveu: > + > +enum i3c_addr_slot_status i3c_bus_get_addr_slot_status(struct i3c_bus *bus, > + u16 addr) > +{ > + int status, bitpos = addr * 2; > + > + if (addr > I2C_MAX_ADDR) > + return I3C_ADDR_SLOT_RSVD; > + > + status = bus->addrslots[bitpos / BITS_PER_LONG]; > + status >>= bitpos % BITS_PER_LONG; > + > + return status & I3C_ADDR_SLOT_STATUS_MASK; > +} I don't understand the size of addr. The I3C only allow 7-bit addresses. Is the addrslots used to store the addresses and its status? > + > +void i3c_bus_set_addr_slot_status(struct i3c_bus *bus, u16 addr, > + enum i3c_addr_slot_status status) > +{ > + int bitpos = addr * 2; > + unsigned long *ptr; > + > + if (addr > I2C_MAX_ADDR) > + return; > + > + ptr = bus->addrslots + (bitpos / BITS_PER_LONG); > + *ptr &= ~(I3C_ADDR_SLOT_STATUS_MASK << (bitpos % BITS_PER_LONG)); > + *ptr |= status << (bitpos % BITS_PER_LONG); > +} > + > +bool i3c_bus_dev_addr_is_avail(struct i3c_bus *bus, u8 addr) > +{ > + enum i3c_addr_slot_status status; > + > + status = i3c_bus_get_addr_slot_status(bus, addr); > + > + return status == I3C_ADDR_SLOT_FREE; > +} > + > +int i3c_bus_get_free_addr(struct i3c_bus *bus, u8 start_addr) > +{ > + enum i3c_addr_slot_status status; > + u8 addr; > + > + for (addr = start_addr; addr < I3C_MAX_ADDR; addr++) { > + status = i3c_bus_get_addr_slot_status(bus, addr); > + if (status == I3C_ADDR_SLOT_FREE) > + return addr; > + } > + > + return -ENOMEM; > +} > + > +static void i3c_bus_init_addrslots(struct i3c_bus *bus) > +{ > + int i; > + > + /* Addresses 0 to 7 are reserved. */ > + for (i = 0; i < 8; i++) > + i3c_bus_set_addr_slot_status(bus, i, I3C_ADDR_SLOT_RSVD); > + > + /* > + * Reserve broadcast address and all addresses that might collide > + * with the broadcast address when facing a single bit error. > + */ > + i3c_bus_set_addr_slot_status(bus, I3C_BROADCAST_ADDR, > + I3C_ADDR_SLOT_RSVD); > + for (i = 0; i < 7; i++) > + i3c_bus_set_addr_slot_status(bus, I3C_BROADCAST_ADDR ^ BIT(i), > + I3C_ADDR_SLOT_RSVD); > +} > + > +static const char * const i3c_bus_mode_strings[] = { > + [I3C_BUS_MODE_PURE] = "pure", > + [I3C_BUS_MODE_MIXED_FAST] = "mixed-fast", > + [I3C_BUS_MODE_MIXED_SLOW] = "mixed-slow", > +}; > + > +static ssize_t mode_show(struct device *dev, > + struct device_attribute *da, > + char *buf) > +{ > + struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev); > + ssize_t ret; > + > + i3c_bus_normaluse_lock(i3cbus); > + if (i3cbus->mode < 0 || > + i3cbus->mode > ARRAY_SIZE(i3c_bus_mode_strings) || > + !i3c_bus_mode_strings[i3cbus->mode]) > + ret = sprintf(buf, "unknown\n"); > + else > + ret = sprintf(buf, "%s\n", i3c_bus_mode_strings[i3cbus->mode]); > + i3c_bus_normaluse_unlock(i3cbus); > + > + return ret; > +} > +static DEVICE_ATTR_RO(mode); > + > +static ssize_t current_master_show(struct device *dev, > + struct device_attribute *da, > + char *buf) > +{ > + struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev); > + ssize_t ret; > + > + i3c_bus_normaluse_lock(i3cbus); > + ret = sprintf(buf, "%s\n", dev_name(&i3cbus->cur_master->dev)); > + i3c_bus_normaluse_unlock(i3cbus); > + > + return ret; > +} > +static DEVICE_ATTR_RO(current_master); > + > +static ssize_t i3c_scl_frequency_show(struct device *dev, > + struct device_attribute *da, > + char *buf) > +{ > + struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev); > + ssize_t ret; > + > + i3c_bus_normaluse_lock(i3cbus); > + ret = sprintf(buf, "%ld\n", i3cbus->scl_rate.i3c); > + i3c_bus_normaluse_unlock(i3cbus); > + > + return ret; > +} > +static DEVICE_ATTR_RO(i3c_scl_frequency); > + > +static ssize_t i2c_scl_frequency_show(struct device *dev, > + struct device_attribute *da, > + char *buf) > +{ > + struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev); > + ssize_t ret; > + > + i3c_bus_normaluse_lock(i3cbus); > + ret = sprintf(buf, "%ld\n", i3cbus->scl_rate.i2c); > + i3c_bus_normaluse_unlock(i3cbus); > + > + return ret; > +} > +static DEVICE_ATTR_RO(i2c_scl_frequency); > + > +static struct attribute *i3c_busdev_attrs[] = { > + &dev_attr_mode.attr, > + &dev_attr_current_master.attr, > + &dev_attr_i3c_scl_frequency.attr, > + &dev_attr_i2c_scl_frequency.attr, > + NULL, > +}; > +ATTRIBUTE_GROUPS(i3c_busdev); > + > +static void i3c_busdev_release(struct device *dev) > +{ > + struct i3c_bus *bus = container_of(dev, struct i3c_bus, dev); > + > + while (!list_empty(&bus->devs.i2c)) { > + struct i2c_device *i2cdev; > + > + i2cdev = list_first_entry(&bus->devs.i2c, struct i2c_device, > + common.node); > + list_del(&i2cdev->common.node); > + of_node_put(i2cdev->info.of_node); > + kfree(i2cdev); > + } > + > + while (!list_empty(&bus->devs.i3c)) { > + struct i3c_device *i3cdev; > + > + i3cdev = list_first_entry(&bus->devs.i3c, struct i3c_device, > + common.node); > + list_del(&i3cdev->common.node); > + put_device(&i3cdev->dev); > + } > + > + mutex_lock(&i3c_core_lock); > + idr_remove(&i3c_bus_idr, bus->id); > + mutex_unlock(&i3c_core_lock); > + > + of_node_put(bus->dev.of_node); > + kfree(bus); > +} > + > +static const struct device_type i3c_busdev_type = { > + .groups = i3c_busdev_groups, > +}; > + > +void i3c_bus_unref(struct i3c_bus *bus) > +{ > + put_device(&bus->dev); > +} > + > +struct i3c_bus *i3c_bus_create(struct device *parent) > +{ > + struct i3c_bus *i3cbus; > + int ret; > + > + i3cbus = kzalloc(sizeof(*i3cbus), GFP_KERNEL); > + if (!i3cbus) > + return ERR_PTR(-ENOMEM); > + > + init_rwsem(&i3cbus->lock); > + INIT_LIST_HEAD(&i3cbus->devs.i2c); > + INIT_LIST_HEAD(&i3cbus->devs.i3c); > + i3c_bus_init_addrslots(i3cbus); > + i3cbus->mode = I3C_BUS_MODE_PURE; > + i3cbus->dev.parent = parent; > + i3cbus->dev.of_node = of_node_get(parent->of_node); > + i3cbus->dev.bus = &i3c_bus_type; > + i3cbus->dev.type = &i3c_busdev_type; > + i3cbus->dev.release = i3c_busdev_release; > + > + mutex_lock(&i3c_core_lock); > + ret = idr_alloc(&i3c_bus_idr, i3cbus, 0, 0, GFP_KERNEL); > + mutex_unlock(&i3c_core_lock); > + if (ret < 0) > + goto err_free_bus; > + > + i3cbus->id = ret; > + device_initialize(&i3cbus->dev); > + > + return i3cbus; > + > +err_free_bus: > + kfree(i3cbus); > + > + return ERR_PTR(ret); > +} > + > +void i3c_bus_unregister(struct i3c_bus *bus) > +{ > + device_unregister(&bus->dev); > +} > + > +int i3c_bus_register(struct i3c_bus *i3cbus) > +{ > + struct i2c_device *i2cdev; > + > + i3c_bus_for_each_i2cdev(i3cbus, i2cdev) { > + switch (i2cdev->lvr & I3C_LVR_I2C_INDEX_MASK) { > + case I3C_LVR_I2C_INDEX(0): > + if (i3cbus->mode < I3C_BUS_MODE_MIXED_FAST) > + i3cbus->mode = I3C_BUS_MODE_MIXED_FAST; > + break; > + > + case I3C_LVR_I2C_INDEX(1): > + case I3C_LVR_I2C_INDEX(2): > + if (i3cbus->mode < I3C_BUS_MODE_MIXED_SLOW) > + i3cbus->mode = I3C_BUS_MODE_MIXED_SLOW; > + break; > + > + default: > + return -EINVAL; > + } > + } > + > + if (!i3cbus->scl_rate.i3c) > + i3cbus->scl_rate.i3c = I3C_BUS_TYP_I3C_SCL_RATE; > + > + if (!i3cbus->scl_rate.i2c) { > + if (i3cbus->mode == I3C_BUS_MODE_MIXED_SLOW) > + i3cbus->scl_rate.i2c = I3C_BUS_I2C_FM_SCL_RATE; > + else > + i3cbus->scl_rate.i2c = I3C_BUS_I2C_FM_PLUS_SCL_RATE; > + } > + > + /* > + * I3C/I2C frequency may have been overridden, check that user-provided > + * values are not exceeding max possible frequency. > + */ > + if (i3cbus->scl_rate.i3c > I3C_BUS_MAX_I3C_SCL_RATE || > + i3cbus->scl_rate.i2c > I3C_BUS_I2C_FM_PLUS_SCL_RATE) { > + return -EINVAL; > + } > + > + dev_set_name(&i3cbus->dev, "i3c-%d", i3cbus->id); > + > + return device_add(&i3cbus->dev); > +} > + > +static int __init i3c_init(void) > +{ > + return bus_register(&i3c_bus_type); > +} > +subsys_initcall(i3c_init); > + > +static void __exit i3c_exit(void) > +{ > + idr_destroy(&i3c_bus_idr); > + bus_unregister(&i3c_bus_type); > +} > +module_exit(i3c_exit); > + > +MODULE_AUTHOR("Boris Brezillon<boris.brezillon@free-electrons.com>"); > +MODULE_DESCRIPTION("I3C core"); > +MODULE_LICENSE("GPL v2"); > diff --git a/drivers/i3c/device.c b/drivers/i3c/device.c > new file mode 100644 > index 000000000000..dcf51150b7cb > --- /dev/null > +++ b/drivers/i3c/device.c > @@ -0,0 +1,344 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2017 Cadence Design Systems Inc. > + * > + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> > + */ > + > +#include <linux/slab.h> > + > +#include "internals.h" > + > +/** > + * i3c_device_do_priv_xfers() - do I3C SDR private transfers directed to a > + * specific device > + * > + * @dev: device with which the transfers should be done > + * @xfers: array of transfers > + * @nxfers: number of transfers > + * > + * Initiate one or several private SDR transfers with @dev. > + * > + * This function can sleep and thus cannot be called in atomic context. > + * > + * Return: 0 in case of success, a negative error core otherwise. > + */ > +int i3c_device_do_priv_xfers(struct i3c_device *dev, > + struct i3c_priv_xfer *xfers, > + int nxfers) > +{ > + struct i3c_master_controller *master; > + int i, ret; > + > + master = i3c_device_get_master(dev); > + if (!master) > + return -EINVAL; > + > + i3c_bus_normaluse_lock(master->bus); > + for (i = 0; i < nxfers; i++) > + xfers[i].addr = dev->info.dyn_addr; > + > + ret = i3c_master_do_priv_xfers_locked(master, xfers, nxfers); > + i3c_bus_normaluse_unlock(master->bus); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers); The controller should know the speed mode for each xfer. The SDR0 mode is used by default but if any device have read or write speed limitations the controller can use SDRx. This could be also applied to i2c transfers. > +#endif /* I3C_INTERNAL_H */ > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c > new file mode 100644 > index 000000000000..1c85abac08d5 > --- /dev/null > +++ b/drivers/i3c/master.c > @@ -0,0 +1,1433 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2017 Cadence Design Systems Inc. > + * > + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> > + */ > + > +#include <linux/slab.h> > + > +#include "internals.h" > + > +/** > + * i3c_master_entdaa_locked() - start a DAA (Dynamic Address Assignment) > + * procedure > + * @master: master used to send frames on the bus > + * > + * Send a ENTDAA CCC command to start a DAA procedure. > + * > + * Note that this function only sends the ENTDAA CCC command, all the logic > + * behind dynamic address assignment has to be handled in the I3C master > + * driver. > + * > + * This function must be called with the bus lock held in write mode. > + * > + * Return: 0 in case of success, a negative error code otherwise. > + */ > +int i3c_master_entdaa_locked(struct i3c_master_controller *master) > +{ > + struct i3c_ccc_cmd_dest dest = { }; > + struct i3c_ccc_cmd cmd = { }; > + int ret; > + > + dest.addr = I3C_BROADCAST_ADDR; > + cmd.dests = &dest; > + cmd.ndests = 1; > + cmd.rnw = false; > + cmd.id = I3C_CCC_ENTDAA; > + > + ret = i3c_master_send_ccc_cmd_locked(master, &cmd); > + if (ret) > + return ret; > + > + return 0; > +} > +EXPORT_SYMBOL_GPL(i3c_master_entdaa_locked); can you explain the process? the command is only execute once, what if there is more devices on the bus? > + > +/** > + * i3c_master_defslvs_locked() - send a DEFSLVS CCC command > + * @master: master used to send frames on the bus > + * > + * Send a DEFSLVS CCC command containing all the devices known to the @master. > + * This is useful when you have secondary masters on the bus to propagate > + * device information. > + * > + * This should be called after all I3C devices have been discovered (in other > + * words, after the DAA procedure has finished) and instantiated in > + * i3c_master_controller_ops->bus_init(). > + * It should also be called if a master ACKed an Hot-Join request and assigned > + * a dynamic address to the device joining the bus. > + * > + * This function must be called with the bus lock held in write mode. > + * > + * Return: 0 in case of success, a negative error code otherwise. > + */ > +int i3c_master_defslvs_locked(struct i3c_master_controller *master) > +{ > + struct i3c_ccc_cmd_dest dest = { > + .addr = I3C_BROADCAST_ADDR, > + }; > + struct i3c_ccc_cmd cmd = { > + .id = I3C_CCC_DEFSLVS, > + .dests = &dest, > + .ndests = 1, > + }; > + struct i3c_ccc_defslvs *defslvs; > + struct i3c_ccc_dev_desc *desc; > + struct i3c_device *i3cdev; > + struct i2c_device *i2cdev; > + struct i3c_bus *bus; > + bool send = false; > + int ndevs = 0, ret; > + > + if (!master) > + return -EINVAL; > + > + bus = i3c_master_get_bus(master); > + i3c_bus_for_each_i3cdev(bus, i3cdev) { > + ndevs++; > + if (I3C_BCR_DEVICE_ROLE(i3cdev->info.bcr) == I3C_BCR_I3C_MASTER) > + send = true; > + } > + > + /* No other master on the bus, skip DEFSLVS. */ > + if (!send) > + return 0; > + > + i3c_bus_for_each_i2cdev(bus, i2cdev) > + ndevs++; > + > + dest.payload.len = sizeof(*defslvs) + > + ((ndevs - 1) * sizeof(struct i3c_ccc_dev_desc)); > + defslvs = kzalloc(dest.payload.len, GFP_KERNEL); > + if (!defslvs) > + return -ENOMEM; > + > + dest.payload.data = defslvs; > + > + defslvs->count = ndevs; > + defslvs->master.bcr = master->this->info.bcr; > + defslvs->master.dcr = master->this->info.dcr; > + defslvs->master.dyn_addr = master->this->info.dyn_addr; > + defslvs->master.static_addr = I3C_BROADCAST_ADDR; Why defslvs->master.static_addr = I3C_BROADCAST_ADDR? > + > + desc = defslvs->slaves; > + i3c_bus_for_each_i2cdev(bus, i2cdev) { > + desc->lvr = i2cdev->lvr; > + desc->static_addr = i2cdev->info.addr; > + desc++; > + } > + > + i3c_bus_for_each_i3cdev(bus, i3cdev) { > + /* Skip the I3C dev representing this master. */ > + if (i3cdev == master->this) > + continue; > + > + desc->bcr = i3cdev->info.bcr; > + desc->dcr = i3cdev->info.dcr; > + desc->dyn_addr = i3cdev->info.dyn_addr; > + desc->static_addr = i3cdev->info.static_addr; > + desc++; > + } > + > + ret = i3c_master_send_ccc_cmd_locked(master, &cmd); > + kfree(defslvs); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(i3c_master_defslvs_locked); > + > + > +static int i3c_master_i2c_adapter_xfer(struct i2c_adapter *adap, > + struct i2c_msg *xfers, int nxfers) > +{ > + struct i3c_master_controller *master = i2c_adapter_to_i3c_master(adap); > + int i, ret; > + > + for (i = 0; i < nxfers; i++) { > + enum i3c_addr_slot_status status; > + > + status = i3c_bus_get_addr_slot_status(master->bus, > + xfers[i].addr); > + if (status != I3C_ADDR_SLOT_I2C_DEV) > + return -EINVAL; > + } > + > + ret = i3c_master_do_i2c_xfers(master, xfers, nxfers); > + if (ret) > + return ret; > + > + return nxfers; > +} > + > +static u32 i3c_master_i2c_functionalities(struct i2c_adapter *adap) > +{ > + return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR; > +} Is I2C_FUNC_10BIT_ADDR allowed ? > diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig > new file mode 100644 > index 000000000000..e69de29bb2d1 > diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile > new file mode 100644 > index 000000000000..e69de29bb2d1 > diff --git a/include/linux/i3c/ccc.h b/include/linux/i3c/ccc.h > new file mode 100644 > index 000000000000..ff3e1a3e2c4c > --- /dev/null > +++ b/include/linux/i3c/ccc.h > @@ -0,0 +1,380 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright (C) 2017 Cadence Design Systems Inc. > + * > + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> > + */ > + > + > +/** > + * enum i3c_ccc_test_mode - enum listing all available test modes > + * > + * @I3C_CCC_EXIT_TEST_MODE: exit test mode > + * @I3C_CCC_VENDOR_TEST_MODE: enter vendor test mode > + */ > +enum i3c_ccc_test_mode { > + I3C_CCC_EXIT_TEST_MODE, > + I3C_CCC_VENDOR_TEST_MODE, > +}; > + > +/** > + * struct i3c_ccc_enttm - payload passed to ENTTM CCC > + * > + * @mode: one of the &enum i3c_ccc_test_mode modes > + * > + * Information passed to the ENTTM CCC to instruct an I3C device to enter a > + * specific test mode. > + */ > +struct i3c_ccc_enttm { > + u8 mode; > +} __packed; > + > +/** > + * struct i3c_ccc_setda - payload passed to ENTTM CCC > + * > + * @mode: one of the &enum i3c_ccc_test_mode modes > + * > + * Information passed to the ENTTM CCC to instruct an I3C device to enter a > + * specific test mode. > + */ > +struct i3c_ccc_setda { > + u8 addr; > +} __packed; what do you mean with struct? Maybe setdasa? if so, what is the addr? > +/** > + * enum i3c_sdr_max_data_rate - max data rate values for private SDR transfers > + */ > +enum i3c_sdr_max_data_rate { > + I3C_SDR_DR_FSCL_MAX, > + I3C_SDR_DR_FSCL_8MHZ, > + I3C_SDR_DR_FSCL_6MHZ, > + I3C_SDR_DR_FSCL_4MHZ, > + I3C_SDR_DR_FSCL_2MHZ, > +}; Can you change the names to: I3C_SDR0_FSCL_MAX, I3C_SDR1_FSCL_8MHZ, I3C_SDR2_FSCL_6MHZ, I3C_SDR3_FSCL_4MHZ, I3C_SDR4_FSCL_2MHZ, thus the data rate isn't repeated. > + > +/** > + * enum i3c_tsco - clock to data turn-around > + */ > +enum i3c_tsco { > + I3C_TSCO_LT_8NS, > + I3C_TSCO_LT_9NS, > + I3C_TSCO_LT_10NS, > + I3C_TSCO_LT_11NS, > + I3C_TSCO_LT_12NS, > +}; what's the meaning of _LT_ ? > + > +#endif /* I3C_CCC_H */ > diff --git a/include/linux/i3c/device.h b/include/linux/i3c/device.h > new file mode 100644 > index 000000000000..83958d3a02e2 > --- /dev/null > +++ b/include/linux/i3c/device.h > @@ -0,0 +1,321 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright (C) 2017 Cadence Design Systems Inc. > + * > + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> > + */ > + > +#ifndef I3C_DEV_H > +#define I3C_DEV_H > + > +#include <linux/device.h> > +#include <linux/i2c.h> > +#include <linux/mod_devicetable.h> > +#include <linux/module.h> > + > +/** > + * enum i3c_hdr_mode - HDR mode ids > + * @I3C_HDR_DDR: DDR mode > + * @I3C_HDR_TSP: TSP mode > + * @I3C_HDR_TSL: TSL mode > + */ > +enum i3c_hdr_mode { > + I3C_HDR_DDR, > + I3C_HDR_TSP, > + I3C_HDR_TSL, > +}; > + > +/** > + * struct i3c_hdr_cmd - I3C HDR command > + * @mode: HDR mode selected for this command > + * @code: command opcode > + * @addr: I3C dynamic address > + * @ndatawords: number of data words (a word is 16bits wide) > + * @data: input/output buffer > + */ > +struct i3c_hdr_cmd { > + enum i3c_hdr_mode mode; > + u8 code; > + u8 addr; > + int ndatawords; > + union { > + u16 *in; > + const u16 *out; > + } data; > +}; > + > +/* Private SDR read transfer */ > +#define I3C_PRIV_XFER_READ BIT(0) > +/* > + * Instruct the controller to issue a STOP after a specific transfer instead > + * of a REPEATED START. > + */ > +#define I3C_PRIV_XFER_STOP BIT(1) > + > +/** > + * struct i3c_priv_xfer - I3C SDR private transfer > + * @addr: I3C dynamic address > + * @len: transfer length in bytes of the transfer > + * @flags: combination of I3C_PRIV_XFER_xxx flags > + * @data: input/output buffer > + */ > +struct i3c_priv_xfer { > + u8 addr; > + u16 len; > + u32 flags; > + struct { > + void *in; > + const void *out; > + } data; > +}; Same as above, i3c_sdr_max_data_rate to change the bus scl. > + > +/** > + * enum i3c_dcr - I3C DCR values > + * @I3C_DCR_GENERIC_DEVICE: generic I3C device > + */ > +enum i3c_dcr { > + I3C_DCR_GENERIC_DEVICE = 0, > +}; > + > +#define I3C_PID_MANUF_ID(pid) (((pid) & GENMASK_ULL(47, 33)) >> 33) > +#define I3C_PID_RND_LOWER_32BITS(pid) (!!((pid) & BIT_ULL(32))) > +#define I3C_PID_RND_VAL(pid) ((pid) & GENMASK_ULL(31, 0)) > +#define I3C_PID_PART_ID(pid) (((pid) & GENMASK_ULL(31, 16)) >> 16) > +#define I3C_PID_INSTANCE_ID(pid) (((pid) & GENMASK_ULL(15, 12)) >> 12) > +#define I3C_PID_EXTRA_INFO(pid) ((pid) & GENMASK_ULL(11, 0)) > + > +#define I3C_BCR_DEVICE_ROLE(bcr) ((bcr) & GENMASK(7, 6)) > +#define I3C_BCR_I3C_SLAVE (0 << 6) > +#define I3C_BCR_I3C_MASTER (1 << 6) > +#define I3C_BCR_HDR_CAP BIT(5) > +#define I3C_BCR_BRIDGE BIT(4) > +#define I3C_BCR_OFFLINE_CAP BIT(3) > +#define I3C_BCR_IBI_PAYLOAD BIT(2) > +#define I3C_BCR_IBI_REQ_CAP BIT(1) > +#define I3C_BCR_MAX_DATA_SPEED_LIM BIT(0) > + > +/** > + * struct i3c_device_info - I3C device information > + * @pid: Provisional ID > + * @bcr: Bus Characteristic Register > + * @dcr: Device Characteristic Register > + * @static_addr: static/I2C address > + * @dyn_addr: dynamic address > + * @hdr_cap: supported HDR modes > + * @max_read_ds: max read speed information > + * @max_write_ds: max write speed information > + * @max_ibi_len: max IBI payload length > + * @max_read_turnaround: max read turn-around time in micro-seconds > + * @max_read_len: max private SDR read length in bytes > + * @max_write_len: max private SDR write length in bytes > + * > + * These are all basic information that should be advertised by an I3C device. > + * Some of them are optional depending on the device type and device > + * capabilities. > + * For each I3C slave attached to a master with > + * i3c_master_add_i3c_dev_locked(), the core will send the relevant CCC command > + * to retrieve these data. > + */ > +struct i3c_device_info { > + u64 pid; > + u8 bcr; > + u8 dcr; > + u8 static_addr; > + u8 dyn_addr; > + u8 hdr_cap; > + u8 max_read_ds; > + u8 max_write_ds; > + u8 max_ibi_len; > + u32 max_read_turnaround; > + u16 max_read_len; > + u16 max_write_len; > +}; > + is this information filled with data provided from CCC commands? > + > +#endif /* I3C_DEV_H */ > diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h > new file mode 100644 > index 000000000000..7ec9a4821bac > --- /dev/null > +++ b/include/linux/i3c/master.h > @@ -0,0 +1,564 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright (C) 2017 Cadence Design Systems Inc. > + * > + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> > + */ > + > +#ifndef I3C_MASTER_H > +#define I3C_MASTER_H > + > +#include <linux/i2c.h> > +#include <linux/i3c/ccc.h> > +#include <linux/i3c/device.h> > +#include <linux/spinlock.h> > + > +#define I3C_HOT_JOIN_ADDR 0x2 > +#define I3C_BROADCAST_ADDR 0x7e > +#define I3C_MAX_ADDR GENMASK(6, 0) > + > +struct i3c_master_controller; > +struct i3c_bus; > + > +/** > + * struct i3c_i2c_dev - I3C/I2C common information > + * @node: node element used to insert the device into the I2C or I3C device > + * list > + * @bus: I3C bus this device is connected to > + * @master: I3C master that instantiated this device. Will be used to send > + * I2C/I3C frames on the bus > + * @master_priv: master private data assigned to the device. Can be used to > + * add master specific information > + * > + * This structure is describing common I3C/I2C dev information. > + */ > +struct i3c_i2c_dev { > + struct list_head node; > + struct i3c_bus *bus; > + struct i3c_master_controller *master; > + void *master_priv; > +}; > + > +#define I3C_LVR_I2C_INDEX_MASK GENMASK(7, 5) > +#define I3C_LVR_I2C_INDEX(x) ((x) << 5) > +#define I3C_LVR_I2C_FM_MODE BIT(4) > + > +#define I2C_MAX_ADDR GENMASK(9, 0) why 10-bit address? > + > +/** > + * struct i2c_device - I2C device object > + * @common: inherit common I3C/I2C description > + * @info: I2C board info used to instantiate the I2C device. If you are > + * using DT to describe your hardware, this will be filled for you > + * @client: I2C client object created by the I2C framework. This will only > + * be valid after i3c_master_register() returns > + * @lvr: Legacy Virtual Register value as described in the I3C specification > + * > + * I2C device object. Note that the real I2C device is represented by > + * i2c_device->client, but we need extra information to handle the device when > + * it's connected to an I3C bus, hence the &struct i2c_device wrapper. > + * > + * The I2C framework is not impacted by this new representation. > + */ > +struct i2c_device { > + struct i3c_i2c_dev common; > + struct i2c_board_info info; > + struct i2c_client *client; > + u8 lvr; > +}; > + It is usefull to know the speed limitations of the device. > + > +/** > + * enum i3c_addr_slot_status - I3C address slot status > + * @I3C_ADDR_SLOT_FREE: address is free > + * @I3C_ADDR_SLOT_RSVD: address is reserved > + * @I3C_ADDR_SLOT_I2C_DEV: address is assigned to an I2C device > + * @I3C_ADDR_SLOT_I3C_DEV: address is assigned to an I3C device > + * @I3C_ADDR_SLOT_STATUS_MASK: address slot mask > + * > + * On an I3C bus, addresses are assigned dynamically, and we need to know which > + * addresses are free to use and which ones are already assigned. > + * > + * Addresses marked as reserved are those reserved by the I3C protocol > + * (broadcast address, ...). > + */ > +enum i3c_addr_slot_status { > + I3C_ADDR_SLOT_FREE, > + I3C_ADDR_SLOT_RSVD, > + I3C_ADDR_SLOT_I2C_DEV, > + I3C_ADDR_SLOT_I3C_DEV, > + I3C_ADDR_SLOT_STATUS_MASK = 3, > +}; > + > +/** > + * struct i3c_bus - I3C bus object > + * @dev: device to be registered to the device-model > + * @cur_master: I3C master currently driving the bus. Since I3C is multi-master > + * this can change over the time. Will be used to let a master > + * know whether it needs to request bus ownership before sending > + * a frame or not > + * @id: bus ID. Assigned by the framework when register the bus > + * @addrslots: a bitmap with 2-bits per-slot to encode the address status and > + * ease the DAA (Dynamic Address Assignment) procedure (see > + * &enum i3c_addr_slot_status) > + * @mode: bus mode (see &enum i3c_bus_mode) > + * @scl_rate: SCL signal rate for I3C and I2C mode > + * @devs: 2 lists containing all I3C/I2C devices connected to the bus > + * @lock: read/write lock on the bus. This is needed to protect against > + * operations that have an impact on the whole bus and the devices > + * connected to it. For example, when asking slaves to drop their > + * dynamic address (RSTDAA CCC), we need to make sure no one is trying > + * to send I3C frames to these devices. > + * Note that this lock does not protect against concurrency between > + * devices: several drivers can send different I3C/I2C frames through > + * the same master in parallel. This is the responsibility of the > + * master to guarantee that frames are actually sent sequentially and > + * not interlaced > + * > + * The I3C bus is represented with its own object and not implicitly described > + * by the I3C master to cope with the multi-master functionality, where one bus > + * can be shared amongst several masters, each of them requesting bus ownership > + * when they need to. > + */ > +struct i3c_bus { > + struct device dev; > + struct i3c_device *cur_master; > + int id; > + unsigned long addrslots[((I2C_MAX_ADDR + 1) * 2) / BITS_PER_LONG]; > + enum i3c_bus_mode mode; > + struct { > + unsigned long i3c; > + unsigned long i2c; > + } scl_rate; > + struct { > + struct list_head i3c; > + struct list_head i2c; > + } devs; > + struct rw_semaphore lock; > +}; Can you explain the addrslots[] ? > + > +static inline struct i3c_device *dev_to_i3cdev(struct device *dev) > +{ > + return container_of(dev, struct i3c_device, dev); > +} > + > +struct i3c_master_controller; > + > +/** > + * struct i3c_master_controller_ops - I3C master methods > + * @bus_init: hook responsible for the I3C bus initialization. This > + * initialization should follow the steps described in the I3C > + * specification. This hook is called with the bus lock held in > + * write mode, which means all _locked() helpers can safely be > + * called from there > + * @bus_cleanup: cleanup everything done in > + * &i3c_master_controller_ops->bus_init(). This function is > + * optional and should only be implemented if > + * &i3c_master_controller_ops->bus_init() attached private data > + * to I3C/I2C devices. This hook is called with the bus lock > + * held in write mode, which means all _locked() helpers can > + * safely be called from there > + * @supports_ccc_cmd: should return true if the CCC command is supported, false > + * otherwise > + * @send_ccc_cmd: send a CCC command > + * @send_hdr_cmds: send one or several HDR commands. If there is more than one > + * command, they should ideally be sent in the same HDR > + * transaction > + * @priv_xfers: do one or several private I3C SDR transfers > + * @i2c_xfers: do one or several I2C transfers > + * @request_ibi: attach an IBI handler to an I3C device. This implies defining > + * an IBI handler and the constraints of the IBI (maximum payload > + * length and number of pre-allocated slots). > + * Some controllers support less IBI-capable devices than regular > + * devices, so this method might return -%EBUSY if there's no > + * more space for an extra IBI registration > + * @free_ibi: free an IBI previously requested with ->request_ibi(). The IBI > + * should have been disabled with ->disable_irq() prior to that > + * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has been called > + * prior to ->enable_ibi(). The controller should first enable > + * the IBI on the controller end (for example, unmask the hardware > + * IRQ) and then send the ENEC CCC command (with the IBI flag set) > + * to the I3C device > + * @disable_ibi: disable an IBI. First send the DISEC CCC command with the IBI > + * flag set and then deactivate the hardware IRQ on the > + * controller end > + * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI has been > + * processed by its handler. The IBI slot should be put back > + * in the IBI slot pool so that the controller can re-use it > + * for a future IBI > + * > + * One of the most important hooks in these ops is > + * &i3c_master_controller_ops->bus_init(). Here is a non-exhaustive list of > + * things that should be done in &i3c_master_controller_ops->bus_init(): > + * > + * 1) call i3c_master_set_info() with all information describing the master > + * 2) ask all slaves to drop their dynamic address by sending the RSTDAA CCC > + * with i3c_master_rstdaa_locked() > + * 3) ask all slaves to disable IBIs using i3c_master_disec_locked() > + * 4) start a DDA procedure by sending the ENTDAA CCC with > + * i3c_master_entdaa_locked(), or using the internal DAA logic provided by > + * your controller You mean SETDASA CCC command? > + * 5) assign a dynamic address to each I3C device discovered during DAA and > + * for each of them, call i3c_master_add_i3c_dev_locked() > + * 6) propagate device table to secondary masters by calling > + * i3c_master_defslvs_locked() > + * > + * Note that these steps do not include all controller specific initialization. > + */ > +struct i3c_master_controller_ops { > + int (*bus_init)(struct i3c_master_controller *master); > + void (*bus_cleanup)(struct i3c_master_controller *master); > + bool (*supports_ccc_cmd)(struct i3c_master_controller *master, > + const struct i3c_ccc_cmd *cmd); > + int (*send_ccc_cmd)(struct i3c_master_controller *master, > + struct i3c_ccc_cmd *cmd); > + int (*send_hdr_cmds)(struct i3c_master_controller *master, > + const struct i3c_hdr_cmd *cmds, > + int ncmds); > + int (*priv_xfers)(struct i3c_master_controller *master, > + const struct i3c_priv_xfer *xfers, > + int nxfers); > + int (*i2c_xfers)(struct i3c_master_controller *master, > + const struct i2c_msg *xfers, int nxfers); > + int (*request_ibi)(struct i3c_master_controller *master, > + struct i3c_device *dev, > + const struct i3c_ibi_setup *req); > + void (*free_ibi)(struct i3c_master_controller *master, > + struct i3c_device *dev); > + int (*enable_ibi)(struct i3c_master_controller *master, > + struct i3c_device *dev); > + int (*disable_ibi)(struct i3c_master_controller *master, > + struct i3c_device *dev); > + void (*recycle_ibi_slot)(struct i3c_master_controller *master, > + struct i3c_device *dev, > + struct i3c_ibi_slot *slot); > +}; > + > Best regards, Vitor Soares -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Vitor, On Fri, 23 Feb 2018 16:56:14 +0000 Vitor Soares <Vitor.Soares@synopsys.com> wrote: > Hi Boris, > > Às 3:16 PM de 12/14/2017, Boris Brezillon escreveu: > > + > > +enum i3c_addr_slot_status i3c_bus_get_addr_slot_status(struct i3c_bus *bus, > > + u16 addr) > > +{ > > + int status, bitpos = addr * 2; > > + > > + if (addr > I2C_MAX_ADDR) > > + return I3C_ADDR_SLOT_RSVD; > > + > > + status = bus->addrslots[bitpos / BITS_PER_LONG]; > > + status >>= bitpos % BITS_PER_LONG; > > + > > + return status & I3C_ADDR_SLOT_STATUS_MASK; > > +} > > I don't understand the size of addr. The I3C only allow 7-bit addresses. > > Is the addrslots used to store the addresses and its status? No, slots are used for both I2C and I3C addresses, and an I2C address can be 10-bits wide, hence the u16 type. [...] > > +/** > > + * i3c_device_do_priv_xfers() - do I3C SDR private transfers directed to a > > + * specific device > > + * > > + * @dev: device with which the transfers should be done > > + * @xfers: array of transfers > > + * @nxfers: number of transfers > > + * > > + * Initiate one or several private SDR transfers with @dev. > > + * > > + * This function can sleep and thus cannot be called in atomic context. > > + * > > + * Return: 0 in case of success, a negative error core otherwise. > > + */ > > +int i3c_device_do_priv_xfers(struct i3c_device *dev, > > + struct i3c_priv_xfer *xfers, > > + int nxfers) > > +{ > > + struct i3c_master_controller *master; > > + int i, ret; > > + > > + master = i3c_device_get_master(dev); > > + if (!master) > > + return -EINVAL; > > + > > + i3c_bus_normaluse_lock(master->bus); > > + for (i = 0; i < nxfers; i++) > > + xfers[i].addr = dev->info.dyn_addr; > > + > > + ret = i3c_master_do_priv_xfers_locked(master, xfers, nxfers); > > + i3c_bus_normaluse_unlock(master->bus); > > + > > + return ret; > > +} > > +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers); > > The controller should know the speed mode for each xfer. The SDR0 mode > is used by default but if any device have read or write speed > limitations the controller can use SDRx. I might be wrong, but that's not my understanding of the spec. A device can express a speed limitation for SDR priv transfers, but this limitation applies to all SDR transfers. The speed R/W speed limitation is encoded in the device object, so, if the controller has to configure that on a per-transfer basis, one solution would be to pass the device to the ->priv_xfers(). > > This could be also applied to i2c transfers. Not really. The max SCL frequency is something that applies to the whole bus, because all I2C devices have to decode the address when messages are sent on the bus to determine if they should ignore or process the message. > > +#endif /* I3C_INTERNAL_H */ > > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c > > new file mode 100644 > > index 000000000000..1c85abac08d5 > > --- /dev/null > > +++ b/drivers/i3c/master.c > > @@ -0,0 +1,1433 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (C) 2017 Cadence Design Systems Inc. > > + * > > + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> > > + */ > > + > > +#include <linux/slab.h> > > + > > +#include "internals.h" > > + > > +/** > > + * i3c_master_entdaa_locked() - start a DAA (Dynamic Address Assignment) > > + * procedure > > + * @master: master used to send frames on the bus > > + * > > + * Send a ENTDAA CCC command to start a DAA procedure. > > + * > > + * Note that this function only sends the ENTDAA CCC command, all the logic > > + * behind dynamic address assignment has to be handled in the I3C master > > + * driver. > > + * > > + * This function must be called with the bus lock held in write mode. > > + * > > + * Return: 0 in case of success, a negative error code otherwise. > > + */ > > +int i3c_master_entdaa_locked(struct i3c_master_controller *master) > > +{ > > + struct i3c_ccc_cmd_dest dest = { }; > > + struct i3c_ccc_cmd cmd = { }; > > + int ret; > > + > > + dest.addr = I3C_BROADCAST_ADDR; > > + cmd.dests = &dest; > > + cmd.ndests = 1; > > + cmd.rnw = false; > > + cmd.id = I3C_CCC_ENTDAA; > > + > > + ret = i3c_master_send_ccc_cmd_locked(master, &cmd); > > + if (ret) > > + return ret; > > + > > + return 0; > > +} > > +EXPORT_SYMBOL_GPL(i3c_master_entdaa_locked); > > can you explain the process? Not sure what you mean. The ENTDAA is just a CCC command that is used to trigger a DAA procedure. What the master controller does when it sends such a command is likely to be controller dependent, and it might even be possible that you don't need to call this function in your controller driver to trigger a DAA. If you want more details about the bus initialization steps and how the ENTDAA CCC command fits into it I recommend reading section "5.1.4 Bus Initialization and Dynamic Address Assignment Mode" > the command is only execute once, what if > there is more devices on the bus? Again, I'm not sure what you mean. The ENTDAA command is sent every time a controller wants to discover new devices on the bus, that can be when initializing the bus, after a Hot Join event or simply triggered by the user (the last case is not supported yet though). Now, if you're interested in what happens after an ENTDAA CCC is sent, the controller will keep sending RepeatedStart until there's no more devices acking the request. You can have a look at "B.3 Error Types in Dynamic Address Arbitration" for more details. > > > + > > +/** > > + * i3c_master_defslvs_locked() - send a DEFSLVS CCC command > > + * @master: master used to send frames on the bus > > + * > > + * Send a DEFSLVS CCC command containing all the devices known to the @master. > > + * This is useful when you have secondary masters on the bus to propagate > > + * device information. > > + * > > + * This should be called after all I3C devices have been discovered (in other > > + * words, after the DAA procedure has finished) and instantiated in > > + * i3c_master_controller_ops->bus_init(). > > + * It should also be called if a master ACKed an Hot-Join request and assigned > > + * a dynamic address to the device joining the bus. > > + * > > + * This function must be called with the bus lock held in write mode. > > + * > > + * Return: 0 in case of success, a negative error code otherwise. > > + */ > > +int i3c_master_defslvs_locked(struct i3c_master_controller *master) > > +{ > > + struct i3c_ccc_cmd_dest dest = { > > + .addr = I3C_BROADCAST_ADDR, > > + }; > > + struct i3c_ccc_cmd cmd = { > > + .id = I3C_CCC_DEFSLVS, > > + .dests = &dest, > > + .ndests = 1, > > + }; > > + struct i3c_ccc_defslvs *defslvs; > > + struct i3c_ccc_dev_desc *desc; > > + struct i3c_device *i3cdev; > > + struct i2c_device *i2cdev; > > + struct i3c_bus *bus; > > + bool send = false; > > + int ndevs = 0, ret; > > + > > + if (!master) > > + return -EINVAL; > > + > > + bus = i3c_master_get_bus(master); > > + i3c_bus_for_each_i3cdev(bus, i3cdev) { > > + ndevs++; > > + if (I3C_BCR_DEVICE_ROLE(i3cdev->info.bcr) == I3C_BCR_I3C_MASTER) > > + send = true; > > + } > > + > > + /* No other master on the bus, skip DEFSLVS. */ > > + if (!send) > > + return 0; > > + > > + i3c_bus_for_each_i2cdev(bus, i2cdev) > > + ndevs++; > > + > > + dest.payload.len = sizeof(*defslvs) + > > + ((ndevs - 1) * sizeof(struct i3c_ccc_dev_desc)); > > + defslvs = kzalloc(dest.payload.len, GFP_KERNEL); > > + if (!defslvs) > > + return -ENOMEM; > > + > > + dest.payload.data = defslvs; > > + > > + defslvs->count = ndevs; > > + defslvs->master.bcr = master->this->info.bcr; > > + defslvs->master.dcr = master->this->info.dcr; > > + defslvs->master.dyn_addr = master->this->info.dyn_addr; > > + defslvs->master.static_addr = I3C_BROADCAST_ADDR; > > Why defslvs->master.static_addr = I3C_BROADCAST_ADDR? I just follow what's document in "5.1.9.3.7 Define List of Slaves (DEFSLVS)" > > > + > > + desc = defslvs->slaves; > > + i3c_bus_for_each_i2cdev(bus, i2cdev) { > > + desc->lvr = i2cdev->lvr; > > + desc->static_addr = i2cdev->info.addr; > > + desc++; > > + } > > + > > + i3c_bus_for_each_i3cdev(bus, i3cdev) { > > + /* Skip the I3C dev representing this master. */ > > + if (i3cdev == master->this) > > + continue; > > + > > + desc->bcr = i3cdev->info.bcr; > > + desc->dcr = i3cdev->info.dcr; > > + desc->dyn_addr = i3cdev->info.dyn_addr; > > + desc->static_addr = i3cdev->info.static_addr; > > + desc++; > > + } > > + > > + ret = i3c_master_send_ccc_cmd_locked(master, &cmd); > > + kfree(defslvs); > > + > > + return ret; > > +} > > +EXPORT_SYMBOL_GPL(i3c_master_defslvs_locked); > > + > > + > > +static int i3c_master_i2c_adapter_xfer(struct i2c_adapter *adap, > > + struct i2c_msg *xfers, int nxfers) > > +{ > > + struct i3c_master_controller *master = i2c_adapter_to_i3c_master(adap); > > + int i, ret; > > + > > + for (i = 0; i < nxfers; i++) { > > + enum i3c_addr_slot_status status; > > + > > + status = i3c_bus_get_addr_slot_status(master->bus, > > + xfers[i].addr); > > + if (status != I3C_ADDR_SLOT_I2C_DEV) > > + return -EINVAL; > > + } > > + > > + ret = i3c_master_do_i2c_xfers(master, xfers, nxfers); > > + if (ret) > > + return ret; > > + > > + return nxfers; > > +} > > + > > +static u32 i3c_master_i2c_functionalities(struct i2c_adapter *adap) > > +{ > > + return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR; > > +} > > Is I2C_FUNC_10BIT_ADDR allowed ? According to "Table 4 I 2 C Features Allowed in I3C Slaves", yes (at least that my understanding). And the Cadence controller supports it. > > > diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig > > new file mode 100644 > > index 000000000000..e69de29bb2d1 > > diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile > > new file mode 100644 > > index 000000000000..e69de29bb2d1 > > diff --git a/include/linux/i3c/ccc.h b/include/linux/i3c/ccc.h > > new file mode 100644 > > index 000000000000..ff3e1a3e2c4c > > --- /dev/null > > +++ b/include/linux/i3c/ccc.h > > @@ -0,0 +1,380 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* > > + * Copyright (C) 2017 Cadence Design Systems Inc. > > + * > > + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> > > + */ > > + > > + > > +/** > > + * enum i3c_ccc_test_mode - enum listing all available test modes > > + * > > + * @I3C_CCC_EXIT_TEST_MODE: exit test mode > > + * @I3C_CCC_VENDOR_TEST_MODE: enter vendor test mode > > + */ > > +enum i3c_ccc_test_mode { > > + I3C_CCC_EXIT_TEST_MODE, > > + I3C_CCC_VENDOR_TEST_MODE, > > +}; > > + > > +/** > > + * struct i3c_ccc_enttm - payload passed to ENTTM CCC > > + * > > + * @mode: one of the &enum i3c_ccc_test_mode modes > > + * > > + * Information passed to the ENTTM CCC to instruct an I3C device to enter a > > + * specific test mode. > > + */ > > +struct i3c_ccc_enttm { > > + u8 mode; > > +} __packed; > > + > > +/** > > + * struct i3c_ccc_setda - payload passed to ENTTM CCC > > + * > > + * @mode: one of the &enum i3c_ccc_test_mode modes > > + * > > + * Information passed to the ENTTM CCC to instruct an I3C device to enter a > > + * specific test mode. > > + */ > > +struct i3c_ccc_setda { > > + u8 addr; > > +} __packed; > > what do you mean with struct? Maybe setdasa? if so, what is the addr? > > > +/** > > + * enum i3c_sdr_max_data_rate - max data rate values for private SDR transfers > > + */ > > +enum i3c_sdr_max_data_rate { > > + I3C_SDR_DR_FSCL_MAX, > > + I3C_SDR_DR_FSCL_8MHZ, > > + I3C_SDR_DR_FSCL_6MHZ, > > + I3C_SDR_DR_FSCL_4MHZ, > > + I3C_SDR_DR_FSCL_2MHZ, > > +}; > Can you change the names to: > > I3C_SDR0_FSCL_MAX, > I3C_SDR1_FSCL_8MHZ, > I3C_SDR2_FSCL_6MHZ, > I3C_SDR3_FSCL_4MHZ, > I3C_SDR4_FSCL_2MHZ, > > thus the data rate isn't repeated. What's the problem with the name I use? Moreover, I see no mention to the SDR0,1,2,3,4 modes in the public spec. > > > + > > +/** > > + * enum i3c_tsco - clock to data turn-around > > + */ > > +enum i3c_tsco { > > + I3C_TSCO_LT_8NS, > > + I3C_TSCO_LT_9NS, > > + I3C_TSCO_LT_10NS, > > + I3C_TSCO_LT_11NS, > > + I3C_TSCO_LT_12NS, > > +}; > what's the meaning of _LT_ ? This I don't remember. I'll drop it in the next version. > > + > > +#endif /* I3C_CCC_H */ > > diff --git a/include/linux/i3c/device.h b/include/linux/i3c/device.h > > new file mode 100644 > > index 000000000000..83958d3a02e2 > > --- /dev/null > > +++ b/include/linux/i3c/device.h > > @@ -0,0 +1,321 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* > > + * Copyright (C) 2017 Cadence Design Systems Inc. > > + * > > + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> > > + */ > > + > > +#ifndef I3C_DEV_H > > +#define I3C_DEV_H > > + > > +#include <linux/device.h> > > +#include <linux/i2c.h> > > +#include <linux/mod_devicetable.h> > > +#include <linux/module.h> > > + > > +/** > > + * enum i3c_hdr_mode - HDR mode ids > > + * @I3C_HDR_DDR: DDR mode > > + * @I3C_HDR_TSP: TSP mode > > + * @I3C_HDR_TSL: TSL mode > > + */ > > +enum i3c_hdr_mode { > > + I3C_HDR_DDR, > > + I3C_HDR_TSP, > > + I3C_HDR_TSL, > > +}; > > + > > +/** > > + * struct i3c_hdr_cmd - I3C HDR command > > + * @mode: HDR mode selected for this command > > + * @code: command opcode > > + * @addr: I3C dynamic address > > + * @ndatawords: number of data words (a word is 16bits wide) > > + * @data: input/output buffer > > + */ > > +struct i3c_hdr_cmd { > > + enum i3c_hdr_mode mode; > > + u8 code; > > + u8 addr; > > + int ndatawords; > > + union { > > + u16 *in; > > + const u16 *out; > > + } data; > > +}; > > + > > +/* Private SDR read transfer */ > > +#define I3C_PRIV_XFER_READ BIT(0) > > +/* > > + * Instruct the controller to issue a STOP after a specific transfer instead > > + * of a REPEATED START. > > + */ > > +#define I3C_PRIV_XFER_STOP BIT(1) > > + > > +/** > > + * struct i3c_priv_xfer - I3C SDR private transfer > > + * @addr: I3C dynamic address > > + * @len: transfer length in bytes of the transfer > > + * @flags: combination of I3C_PRIV_XFER_xxx flags > > + * @data: input/output buffer > > + */ > > +struct i3c_priv_xfer { > > + u8 addr; > > + u16 len; > > + u32 flags; > > + struct { > > + void *in; > > + const void *out; > > + } data; > > +}; > > Same as above, i3c_sdr_max_data_rate to change the bus scl. If I'm understanding the spec correctly, that's not something you want to change on a per-transfer basis. The constraint is on the device itself and should IMO not be part of the i3c_priv_xfer struct. > > > + > > +/** > > + * enum i3c_dcr - I3C DCR values > > + * @I3C_DCR_GENERIC_DEVICE: generic I3C device > > + */ > > +enum i3c_dcr { > > + I3C_DCR_GENERIC_DEVICE = 0, > > +}; > > + > > +#define I3C_PID_MANUF_ID(pid) (((pid) & GENMASK_ULL(47, 33)) >> 33) > > +#define I3C_PID_RND_LOWER_32BITS(pid) (!!((pid) & BIT_ULL(32))) > > +#define I3C_PID_RND_VAL(pid) ((pid) & GENMASK_ULL(31, 0)) > > +#define I3C_PID_PART_ID(pid) (((pid) & GENMASK_ULL(31, 16)) >> 16) > > +#define I3C_PID_INSTANCE_ID(pid) (((pid) & GENMASK_ULL(15, 12)) >> 12) > > +#define I3C_PID_EXTRA_INFO(pid) ((pid) & GENMASK_ULL(11, 0)) > > + > > +#define I3C_BCR_DEVICE_ROLE(bcr) ((bcr) & GENMASK(7, 6)) > > +#define I3C_BCR_I3C_SLAVE (0 << 6) > > +#define I3C_BCR_I3C_MASTER (1 << 6) > > +#define I3C_BCR_HDR_CAP BIT(5) > > +#define I3C_BCR_BRIDGE BIT(4) > > +#define I3C_BCR_OFFLINE_CAP BIT(3) > > +#define I3C_BCR_IBI_PAYLOAD BIT(2) > > +#define I3C_BCR_IBI_REQ_CAP BIT(1) > > +#define I3C_BCR_MAX_DATA_SPEED_LIM BIT(0) > > + > > +/** > > + * struct i3c_device_info - I3C device information > > + * @pid: Provisional ID > > + * @bcr: Bus Characteristic Register > > + * @dcr: Device Characteristic Register > > + * @static_addr: static/I2C address > > + * @dyn_addr: dynamic address > > + * @hdr_cap: supported HDR modes > > + * @max_read_ds: max read speed information > > + * @max_write_ds: max write speed information > > + * @max_ibi_len: max IBI payload length > > + * @max_read_turnaround: max read turn-around time in micro-seconds > > + * @max_read_len: max private SDR read length in bytes > > + * @max_write_len: max private SDR write length in bytes > > + * > > + * These are all basic information that should be advertised by an I3C device. > > + * Some of them are optional depending on the device type and device > > + * capabilities. > > + * For each I3C slave attached to a master with > > + * i3c_master_add_i3c_dev_locked(), the core will send the relevant CCC command > > + * to retrieve these data. > > + */ > > +struct i3c_device_info { > > + u64 pid; > > + u8 bcr; > > + u8 dcr; > > + u8 static_addr; > > + u8 dyn_addr; > > + u8 hdr_cap; > > + u8 max_read_ds; > > + u8 max_write_ds; > > + u8 max_ibi_len; > > + u32 max_read_turnaround; > > + u16 max_read_len; > > + u16 max_write_len; > > +}; > > + > > is this information filled with data provided from CCC commands? Yes, they are. > > > + > > +#endif /* I3C_DEV_H */ > > diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h > > new file mode 100644 > > index 000000000000..7ec9a4821bac > > --- /dev/null > > +++ b/include/linux/i3c/master.h > > @@ -0,0 +1,564 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* > > + * Copyright (C) 2017 Cadence Design Systems Inc. > > + * > > + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> > > + */ > > + > > +#ifndef I3C_MASTER_H > > +#define I3C_MASTER_H > > + > > +#include <linux/i2c.h> > > +#include <linux/i3c/ccc.h> > > +#include <linux/i3c/device.h> > > +#include <linux/spinlock.h> > > + > > +#define I3C_HOT_JOIN_ADDR 0x2 > > +#define I3C_BROADCAST_ADDR 0x7e > > +#define I3C_MAX_ADDR GENMASK(6, 0) > > + > > +struct i3c_master_controller; > > +struct i3c_bus; > > + > > +/** > > + * struct i3c_i2c_dev - I3C/I2C common information > > + * @node: node element used to insert the device into the I2C or I3C device > > + * list > > + * @bus: I3C bus this device is connected to > > + * @master: I3C master that instantiated this device. Will be used to send > > + * I2C/I3C frames on the bus > > + * @master_priv: master private data assigned to the device. Can be used to > > + * add master specific information > > + * > > + * This structure is describing common I3C/I2C dev information. > > + */ > > +struct i3c_i2c_dev { > > + struct list_head node; > > + struct i3c_bus *bus; > > + struct i3c_master_controller *master; > > + void *master_priv; > > +}; > > + > > +#define I3C_LVR_I2C_INDEX_MASK GENMASK(7, 5) > > +#define I3C_LVR_I2C_INDEX(x) ((x) << 5) > > +#define I3C_LVR_I2C_FM_MODE BIT(4) > > + > > +#define I2C_MAX_ADDR GENMASK(9, 0) > > why 10-bit address? > Because some I2C devices have 10-bit addresses. > > + > > +/** > > + * struct i2c_device - I2C device object > > + * @common: inherit common I3C/I2C description > > + * @info: I2C board info used to instantiate the I2C device. If you are > > + * using DT to describe your hardware, this will be filled for you > > + * @client: I2C client object created by the I2C framework. This will only > > + * be valid after i3c_master_register() returns > > + * @lvr: Legacy Virtual Register value as described in the I3C specification > > + * > > + * I2C device object. Note that the real I2C device is represented by > > + * i2c_device->client, but we need extra information to handle the device when > > + * it's connected to an I3C bus, hence the &struct i2c_device wrapper. > > + * > > + * The I2C framework is not impacted by this new representation. > > + */ > > +struct i2c_device { > > + struct i3c_i2c_dev common; > > + struct i2c_board_info info; > > + struct i2c_client *client; > > + u8 lvr; > > +}; > > + > > It is usefull to know the speed limitations of the device. See my previous explanation about I2C and the max frequency. BTW, the FM vs FM+ information is already encoded in the ->lvr field. > > > + > > +/** > > + * enum i3c_addr_slot_status - I3C address slot status > > + * @I3C_ADDR_SLOT_FREE: address is free > > + * @I3C_ADDR_SLOT_RSVD: address is reserved > > + * @I3C_ADDR_SLOT_I2C_DEV: address is assigned to an I2C device > > + * @I3C_ADDR_SLOT_I3C_DEV: address is assigned to an I3C device > > + * @I3C_ADDR_SLOT_STATUS_MASK: address slot mask > > + * > > + * On an I3C bus, addresses are assigned dynamically, and we need to know which > > + * addresses are free to use and which ones are already assigned. > > + * > > + * Addresses marked as reserved are those reserved by the I3C protocol > > + * (broadcast address, ...). > > + */ > > +enum i3c_addr_slot_status { > > + I3C_ADDR_SLOT_FREE, > > + I3C_ADDR_SLOT_RSVD, > > + I3C_ADDR_SLOT_I2C_DEV, > > + I3C_ADDR_SLOT_I3C_DEV, > > + I3C_ADDR_SLOT_STATUS_MASK = 3, > > +}; > > + > > +/** > > + * struct i3c_bus - I3C bus object > > + * @dev: device to be registered to the device-model > > + * @cur_master: I3C master currently driving the bus. Since I3C is multi-master > > + * this can change over the time. Will be used to let a master > > + * know whether it needs to request bus ownership before sending > > + * a frame or not > > + * @id: bus ID. Assigned by the framework when register the bus > > + * @addrslots: a bitmap with 2-bits per-slot to encode the address status and > > + * ease the DAA (Dynamic Address Assignment) procedure (see > > + * &enum i3c_addr_slot_status) > > + * @mode: bus mode (see &enum i3c_bus_mode) > > + * @scl_rate: SCL signal rate for I3C and I2C mode > > + * @devs: 2 lists containing all I3C/I2C devices connected to the bus > > + * @lock: read/write lock on the bus. This is needed to protect against > > + * operations that have an impact on the whole bus and the devices > > + * connected to it. For example, when asking slaves to drop their > > + * dynamic address (RSTDAA CCC), we need to make sure no one is trying > > + * to send I3C frames to these devices. > > + * Note that this lock does not protect against concurrency between > > + * devices: several drivers can send different I3C/I2C frames through > > + * the same master in parallel. This is the responsibility of the > > + * master to guarantee that frames are actually sent sequentially and > > + * not interlaced > > + * > > + * The I3C bus is represented with its own object and not implicitly described > > + * by the I3C master to cope with the multi-master functionality, where one bus > > + * can be shared amongst several masters, each of them requesting bus ownership > > + * when they need to. > > + */ > > +struct i3c_bus { > > + struct device dev; > > + struct i3c_device *cur_master; > > + int id; > > + unsigned long addrslots[((I2C_MAX_ADDR + 1) * 2) / BITS_PER_LONG]; > > + enum i3c_bus_mode mode; > > + struct { > > + unsigned long i3c; > > + unsigned long i2c; > > + } scl_rate; > > + struct { > > + struct list_head i3c; > > + struct list_head i2c; > > + } devs; > > + struct rw_semaphore lock; > > +}; > Can you explain the addrslots[] ? It's a bitmap encoding the status of I3C/I2C addresses: are they assigned, reserved of free, and if they are assigned is it an I3C or I2C device. That's particularly useful to master controller drivers to know which addresses they can assign during DAA. I'll try to clarify it in the kernel-doc header. > > + > > +static inline struct i3c_device *dev_to_i3cdev(struct device *dev) > > +{ > > + return container_of(dev, struct i3c_device, dev); > > +} > > + > > +struct i3c_master_controller; > > + > > +/** > > + * struct i3c_master_controller_ops - I3C master methods > > + * @bus_init: hook responsible for the I3C bus initialization. This > > + * initialization should follow the steps described in the I3C > > + * specification. This hook is called with the bus lock held in > > + * write mode, which means all _locked() helpers can safely be > > + * called from there > > + * @bus_cleanup: cleanup everything done in > > + * &i3c_master_controller_ops->bus_init(). This function is > > + * optional and should only be implemented if > > + * &i3c_master_controller_ops->bus_init() attached private data > > + * to I3C/I2C devices. This hook is called with the bus lock > > + * held in write mode, which means all _locked() helpers can > > + * safely be called from there > > + * @supports_ccc_cmd: should return true if the CCC command is supported, false > > + * otherwise > > + * @send_ccc_cmd: send a CCC command > > + * @send_hdr_cmds: send one or several HDR commands. If there is more than one > > + * command, they should ideally be sent in the same HDR > > + * transaction > > + * @priv_xfers: do one or several private I3C SDR transfers > > + * @i2c_xfers: do one or several I2C transfers > > + * @request_ibi: attach an IBI handler to an I3C device. This implies defining > > + * an IBI handler and the constraints of the IBI (maximum payload > > + * length and number of pre-allocated slots). > > + * Some controllers support less IBI-capable devices than regular > > + * devices, so this method might return -%EBUSY if there's no > > + * more space for an extra IBI registration > > + * @free_ibi: free an IBI previously requested with ->request_ibi(). The IBI > > + * should have been disabled with ->disable_irq() prior to that > > + * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has been called > > + * prior to ->enable_ibi(). The controller should first enable > > + * the IBI on the controller end (for example, unmask the hardware > > + * IRQ) and then send the ENEC CCC command (with the IBI flag set) > > + * to the I3C device > > + * @disable_ibi: disable an IBI. First send the DISEC CCC command with the IBI > > + * flag set and then deactivate the hardware IRQ on the > > + * controller end > > + * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI has been > > + * processed by its handler. The IBI slot should be put back > > + * in the IBI slot pool so that the controller can re-use it > > + * for a future IBI > > + * > > + * One of the most important hooks in these ops is > > + * &i3c_master_controller_ops->bus_init(). Here is a non-exhaustive list of > > + * things that should be done in &i3c_master_controller_ops->bus_init(): > > + * > > + * 1) call i3c_master_set_info() with all information describing the master > > + * 2) ask all slaves to drop their dynamic address by sending the RSTDAA CCC > > + * with i3c_master_rstdaa_locked() > > + * 3) ask all slaves to disable IBIs using i3c_master_disec_locked() > > + * 4) start a DDA procedure by sending the ENTDAA CCC with > > + * i3c_master_entdaa_locked(), or using the internal DAA logic provided by > > + * your controller > You mean SETDASA CCC command? No, I really mean ENTDAA and DAA. By internal DAA logic I mean that some controllers are probably automating the whole DAA procedure, while others may let the SW control every step. Thanks for your review. Boris
On Fri, 23 Feb 2018 16:56:14 +0000 Vitor Soares <Vitor.Soares@synopsys.com> wrote: > > + > > +/** > > + * struct i3c_ccc_setda - payload passed to ENTTM CCC > > + * > > + * @mode: one of the &enum i3c_ccc_test_mode modes > > + * > > + * Information passed to the ENTTM CCC to instruct an I3C device to enter a > > + * specific test mode. Oops, copy&paste error. I'll fix the kernel-doc header. > > + */ > > +struct i3c_ccc_setda { > > + u8 addr; > > +} __packed; > > what do you mean with struct? Maybe setdasa? if so, what is the addr? It's the payload passed to SETDASA and SETNEWDA, hence the generic _setda suffix. addr is the new dynamic address assigned to the device.
Hi Boris Às 8:30 PM de 2/23/2018, Boris Brezillon escreveu: > Hi Vitor, > > On Fri, 23 Feb 2018 16:56:14 +0000 > Vitor Soares <Vitor.Soares@synopsys.com> wrote: > >> Hi Boris, >> >> Às 3:16 PM de 12/14/2017, Boris Brezillon escreveu: >>> + >>> +enum i3c_addr_slot_status i3c_bus_get_addr_slot_status(struct i3c_bus *bus, >>> + u16 addr) >>> +{ >>> + int status, bitpos = addr * 2; >>> + >>> + if (addr > I2C_MAX_ADDR) >>> + return I3C_ADDR_SLOT_RSVD; >>> + >>> + status = bus->addrslots[bitpos / BITS_PER_LONG]; >>> + status >>= bitpos % BITS_PER_LONG; >>> + >>> + return status & I3C_ADDR_SLOT_STATUS_MASK; >>> +} >> I don't understand the size of addr. The I3C only allow 7-bit addresses. >> >> Is the addrslots used to store the addresses and its status? > No, slots are used for both I2C and I3C addresses, and an I2C address > can be 10-bits wide, hence the u16 type. > > > [...] > >>> +/** >>> + * i3c_device_do_priv_xfers() - do I3C SDR private transfers directed to a >>> + * specific device >>> + * >>> + * @dev: device with which the transfers should be done >>> + * @xfers: array of transfers >>> + * @nxfers: number of transfers >>> + * >>> + * Initiate one or several private SDR transfers with @dev. >>> + * >>> + * This function can sleep and thus cannot be called in atomic context. >>> + * >>> + * Return: 0 in case of success, a negative error core otherwise. >>> + */ >>> +int i3c_device_do_priv_xfers(struct i3c_device *dev, >>> + struct i3c_priv_xfer *xfers, >>> + int nxfers) >>> +{ >>> + struct i3c_master_controller *master; >>> + int i, ret; >>> + >>> + master = i3c_device_get_master(dev); >>> + if (!master) >>> + return -EINVAL; >>> + >>> + i3c_bus_normaluse_lock(master->bus); >>> + for (i = 0; i < nxfers; i++) >>> + xfers[i].addr = dev->info.dyn_addr; >>> + >>> + ret = i3c_master_do_priv_xfers_locked(master, xfers, nxfers); >>> + i3c_bus_normaluse_unlock(master->bus); >>> + >>> + return ret; >>> +} >>> +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers); >> The controller should know the speed mode for each xfer. The SDR0 mode >> is used by default but if any device have read or write speed >> limitations the controller can use SDRx. > I might be wrong, but that's not my understanding of the spec. A device > can express a speed limitation for SDR priv transfers, but this > limitation applies to all SDR transfers. > > The speed R/W speed limitation is encoded in the device object, so, if > the controller has to configure that on a per-transfer basis, one > solution would be to pass the device to the ->priv_xfers(). The speed R/W limitation is only for private transfers. Also the device can have a limitation to write and not for read data. This information is obtained with the command GETMXDS which returns the Maximum Sustained Data Rate for non-CCC messages. > >> This could be also applied to i2c transfers. > Not really. The max SCL frequency is something that applies to the > whole bus, because all I2C devices have to decode the address when > messages are sent on the bus to determine if they should ignore or > process the message. > >>> +#endif /* I3C_INTERNAL_H */ >>> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c >>> new file mode 100644 >>> index 000000000000..1c85abac08d5 >>> --- /dev/null >>> +++ b/drivers/i3c/master.c >>> @@ -0,0 +1,1433 @@ >>> +// SPDX-License-Identifier: GPL-2.0 >>> +/* >>> + * Copyright (C) 2017 Cadence Design Systems Inc. >>> + * >>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> >>> + */ >>> + >>> +#include <linux/slab.h> >>> + >>> +#include "internals.h" >>> + >>> +/** >>> + * i3c_master_entdaa_locked() - start a DAA (Dynamic Address Assignment) >>> + * procedure >>> + * @master: master used to send frames on the bus >>> + * >>> + * Send a ENTDAA CCC command to start a DAA procedure. >>> + * >>> + * Note that this function only sends the ENTDAA CCC command, all the logic >>> + * behind dynamic address assignment has to be handled in the I3C master >>> + * driver. >>> + * >>> + * This function must be called with the bus lock held in write mode. >>> + * >>> + * Return: 0 in case of success, a negative error code otherwise. >>> + */ >>> +int i3c_master_entdaa_locked(struct i3c_master_controller *master) >>> +{ >>> + struct i3c_ccc_cmd_dest dest = { }; >>> + struct i3c_ccc_cmd cmd = { }; >>> + int ret; >>> + >>> + dest.addr = I3C_BROADCAST_ADDR; >>> + cmd.dests = &dest; >>> + cmd.ndests = 1; >>> + cmd.rnw = false; >>> + cmd.id = I3C_CCC_ENTDAA; >>> + >>> + ret = i3c_master_send_ccc_cmd_locked(master, &cmd); >>> + if (ret) >>> + return ret; >>> + >>> + return 0; >>> +} >>> +EXPORT_SYMBOL_GPL(i3c_master_entdaa_locked); >> can you explain the process? > Not sure what you mean. The ENTDAA is just a CCC command that is used > to trigger a DAA procedure. What the master controller does when it > sends such a command is likely to be controller dependent, and it might > even be possible that you don't need to call this function in your > controller driver to trigger a DAA. If you want more details about the > bus initialization steps and how the ENTDAA CCC command fits into it I > recommend reading section "5.1.4 Bus Initialization and Dynamic Address > Assignment Mode" > >> the command is only execute once, what if >> there is more devices on the bus? > Again, I'm not sure what you mean. The ENTDAA command is sent every > time a controller wants to discover new devices on the bus, that can be > when initializing the bus, after a Hot Join event or simply triggered > by the user (the last case is not supported yet though). > > Now, if you're interested in what happens after an ENTDAA CCC is sent, > the controller will keep sending RepeatedStart until there's no more > devices acking the request. You can have a look at "B.3 Error Types in > Dynamic Address Arbitration" for more details. My understanding is this command shall be executed once, this mean that only one slave will assign the dynamic address (cmd.ndests = 1) and not trigger the whole process of DAA. Either important is the SETDASA for declared I3C devices. So the DAA process should start by send an SETDASA and them ENTDAA CCC command. >> > + >>> +/** >>> + * i3c_master_defslvs_locked() - send a DEFSLVS CCC command >>> + * @master: master used to send frames on the bus >>> + * >>> + * Send a DEFSLVS CCC command containing all the devices known to the @master. >>> + * This is useful when you have secondary masters on the bus to propagate >>> + * device information. >>> + * >>> + * This should be called after all I3C devices have been discovered (in other >>> + * words, after the DAA procedure has finished) and instantiated in >>> + * i3c_master_controller_ops->bus_init(). >>> + * It should also be called if a master ACKed an Hot-Join request and assigned >>> + * a dynamic address to the device joining the bus. >>> + * >>> + * This function must be called with the bus lock held in write mode. >>> + * >>> + * Return: 0 in case of success, a negative error code otherwise. >>> + */ >>> +int i3c_master_defslvs_locked(struct i3c_master_controller *master) >>> +{ >>> + struct i3c_ccc_cmd_dest dest = { >>> + .addr = I3C_BROADCAST_ADDR, >>> + }; >>> + struct i3c_ccc_cmd cmd = { >>> + .id = I3C_CCC_DEFSLVS, >>> + .dests = &dest, >>> + .ndests = 1, >>> + }; >>> + struct i3c_ccc_defslvs *defslvs; >>> + struct i3c_ccc_dev_desc *desc; >>> + struct i3c_device *i3cdev; >>> + struct i2c_device *i2cdev; >>> + struct i3c_bus *bus; >>> + bool send = false; >>> + int ndevs = 0, ret; >>> + >>> + if (!master) >>> + return -EINVAL; >>> + >>> + bus = i3c_master_get_bus(master); >>> + i3c_bus_for_each_i3cdev(bus, i3cdev) { >>> + ndevs++; >>> + if (I3C_BCR_DEVICE_ROLE(i3cdev->info.bcr) == I3C_BCR_I3C_MASTER) >>> + send = true; >>> + } >>> + >>> + /* No other master on the bus, skip DEFSLVS. */ >>> + if (!send) >>> + return 0; >>> + >>> + i3c_bus_for_each_i2cdev(bus, i2cdev) >>> + ndevs++; >>> + >>> + dest.payload.len = sizeof(*defslvs) + >>> + ((ndevs - 1) * sizeof(struct i3c_ccc_dev_desc)); >>> + defslvs = kzalloc(dest.payload.len, GFP_KERNEL); >>> + if (!defslvs) >>> + return -ENOMEM; >>> + >>> + dest.payload.data = defslvs; >>> + >>> + defslvs->count = ndevs; >>> + defslvs->master.bcr = master->this->info.bcr; >>> + defslvs->master.dcr = master->this->info.dcr; >>> + defslvs->master.dyn_addr = master->this->info.dyn_addr; >>> + defslvs->master.static_addr = I3C_BROADCAST_ADDR; >> Why defslvs->master.static_addr = I3C_BROADCAST_ADDR? > I just follow what's document in "5.1.9.3.7 Define List of Slaves > (DEFSLVS)" yes, that's right. >> > + >>> + desc = defslvs->slaves; >>> + i3c_bus_for_each_i2cdev(bus, i2cdev) { >>> + desc->lvr = i2cdev->lvr; >>> + desc->static_addr = i2cdev->info.addr; >>> + desc++; >>> + } >>> + >>> + i3c_bus_for_each_i3cdev(bus, i3cdev) { >>> + /* Skip the I3C dev representing this master. */ >>> + if (i3cdev == master->this) >>> + continue; >>> + >>> + desc->bcr = i3cdev->info.bcr; >>> + desc->dcr = i3cdev->info.dcr; >>> + desc->dyn_addr = i3cdev->info.dyn_addr; >>> + desc->static_addr = i3cdev->info.static_addr; >>> + desc++; >>> + } >>> + >>> + ret = i3c_master_send_ccc_cmd_locked(master, &cmd); >>> + kfree(defslvs); >>> + >>> + return ret; >>> +} >>> +EXPORT_SYMBOL_GPL(i3c_master_defslvs_locked); >>> + >>> + >>> +static int i3c_master_i2c_adapter_xfer(struct i2c_adapter *adap, >>> + struct i2c_msg *xfers, int nxfers) >>> +{ >>> + struct i3c_master_controller *master = i2c_adapter_to_i3c_master(adap); >>> + int i, ret; >>> + >>> + for (i = 0; i < nxfers; i++) { >>> + enum i3c_addr_slot_status status; >>> + >>> + status = i3c_bus_get_addr_slot_status(master->bus, >>> + xfers[i].addr); >>> + if (status != I3C_ADDR_SLOT_I2C_DEV) >>> + return -EINVAL; >>> + } >>> + >>> + ret = i3c_master_do_i2c_xfers(master, xfers, nxfers); >>> + if (ret) >>> + return ret; >>> + >>> + return nxfers; >>> +} >>> + >>> +static u32 i3c_master_i2c_functionalities(struct i2c_adapter *adap) >>> +{ >>> + return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR; >>> +} >> Is I2C_FUNC_10BIT_ADDR allowed ? > According to "Table 4 I 2 C Features Allowed in I3C Slaves", yes (at > least that my understanding). And the Cadence controller supports it. The table say the oposite. The I2C extended address feature is not used on I3C bus, thus this feature shall be disable. BTW it is optional on I2C devices. > >> > diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig >>> new file mode 100644 >>> index 000000000000..e69de29bb2d1 >>> diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile >>> new file mode 100644 >>> index 000000000000..e69de29bb2d1 >>> diff --git a/include/linux/i3c/ccc.h b/include/linux/i3c/ccc.h >>> new file mode 100644 >>> index 000000000000..ff3e1a3e2c4c >>> --- /dev/null >>> +++ b/include/linux/i3c/ccc.h >>> @@ -0,0 +1,380 @@ >>> +/* SPDX-License-Identifier: GPL-2.0 */ >>> +/* >>> + * Copyright (C) 2017 Cadence Design Systems Inc. >>> + * >>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> >>> + */ >>> + >>> + >>> +/** >>> + * enum i3c_ccc_test_mode - enum listing all available test modes >>> + * >>> + * @I3C_CCC_EXIT_TEST_MODE: exit test mode >>> + * @I3C_CCC_VENDOR_TEST_MODE: enter vendor test mode >>> + */ >>> +enum i3c_ccc_test_mode { >>> + I3C_CCC_EXIT_TEST_MODE, >>> + I3C_CCC_VENDOR_TEST_MODE, >>> +}; >>> + >>> +/** >>> + * struct i3c_ccc_enttm - payload passed to ENTTM CCC >>> + * >>> + * @mode: one of the &enum i3c_ccc_test_mode modes >>> + * >>> + * Information passed to the ENTTM CCC to instruct an I3C device to enter a >>> + * specific test mode. >>> + */ >>> +struct i3c_ccc_enttm { >>> + u8 mode; >>> +} __packed; >>> + >>> +/** >>> + * struct i3c_ccc_setda - payload passed to ENTTM CCC >>> + * >>> + * @mode: one of the &enum i3c_ccc_test_mode modes >>> + * >>> + * Information passed to the ENTTM CCC to instruct an I3C device to enter a >>> + * specific test mode. >>> + */ >>> +struct i3c_ccc_setda { >>> + u8 addr; >>> +} __packed; >> what do you mean with struct? Maybe setdasa? if so, what is the addr? Do you have the function to use this structure? Because one command use the static address and the other use the dynamic address. >> >> > +/** >>> + * enum i3c_sdr_max_data_rate - max data rate values for private SDR transfers >>> + */ >>> +enum i3c_sdr_max_data_rate { >>> + I3C_SDR_DR_FSCL_MAX, >>> + I3C_SDR_DR_FSCL_8MHZ, >>> + I3C_SDR_DR_FSCL_6MHZ, >>> + I3C_SDR_DR_FSCL_4MHZ, >>> + I3C_SDR_DR_FSCL_2MHZ, >>> +}; >> Can you change the names to: >> >> I3C_SDR0_FSCL_MAX, >> I3C_SDR1_FSCL_8MHZ, >> I3C_SDR2_FSCL_6MHZ, >> I3C_SDR3_FSCL_4MHZ, >> I3C_SDR4_FSCL_2MHZ, >> >> thus the data rate isn't repeated. > What's the problem with the name I use? Moreover, I see no mention to > the SDR0,1,2,3,4 modes in the public spec. When you get the GETMXDS information, the maxWr and maxRd came from 0 to 4, so in my opinion I think in this way is easier to have a relationship. > >>> + >>> +/** >>> + * enum i3c_tsco - clock to data turn-around >>> + */ >>> +enum i3c_tsco { >>> + I3C_TSCO_LT_8NS, >>> + I3C_TSCO_LT_9NS, >>> + I3C_TSCO_LT_10NS, >>> + I3C_TSCO_LT_11NS, >>> + I3C_TSCO_LT_12NS, >>> +}; >> what's the meaning of _LT_ ? > This I don't remember. I'll drop it in the next version. > >>> + >>> +#endif /* I3C_CCC_H */ >>> diff --git a/include/linux/i3c/device.h b/include/linux/i3c/device.h >>> new file mode 100644 >>> index 000000000000..83958d3a02e2 >>> --- /dev/null >>> +++ b/include/linux/i3c/device.h >>> @@ -0,0 +1,321 @@ >>> +/* SPDX-License-Identifier: GPL-2.0 */ >>> +/* >>> + * Copyright (C) 2017 Cadence Design Systems Inc. >>> + * >>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> >>> + */ >>> + >>> +#ifndef I3C_DEV_H >>> +#define I3C_DEV_H >>> + >>> +#include <linux/device.h> >>> +#include <linux/i2c.h> >>> +#include <linux/mod_devicetable.h> >>> +#include <linux/module.h> >>> + >>> +/** >>> + * enum i3c_hdr_mode - HDR mode ids >>> + * @I3C_HDR_DDR: DDR mode >>> + * @I3C_HDR_TSP: TSP mode >>> + * @I3C_HDR_TSL: TSL mode >>> + */ >>> +enum i3c_hdr_mode { >>> + I3C_HDR_DDR, >>> + I3C_HDR_TSP, >>> + I3C_HDR_TSL, >>> +}; >>> + >>> +/** >>> + * struct i3c_hdr_cmd - I3C HDR command >>> + * @mode: HDR mode selected for this command >>> + * @code: command opcode >>> + * @addr: I3C dynamic address >>> + * @ndatawords: number of data words (a word is 16bits wide) >>> + * @data: input/output buffer >>> + */ >>> +struct i3c_hdr_cmd { >>> + enum i3c_hdr_mode mode; >>> + u8 code; >>> + u8 addr; >>> + int ndatawords; >>> + union { >>> + u16 *in; >>> + const u16 *out; >>> + } data; >>> +}; Please mention that the @code is what will define if the transfer is read or write. >>> + >>> +/* Private SDR read transfer */ >>> +#define I3C_PRIV_XFER_READ BIT(0) >>> +/* >>> + * Instruct the controller to issue a STOP after a specific transfer instead >>> + * of a REPEATED START. >>> + */ >>> +#define I3C_PRIV_XFER_STOP BIT(1) >>> + >>> +/** >>> + * struct i3c_priv_xfer - I3C SDR private transfer >>> + * @addr: I3C dynamic address >>> + * @len: transfer length in bytes of the transfer >>> + * @flags: combination of I3C_PRIV_XFER_xxx flags >>> + * @data: input/output buffer >>> + */ >>> +struct i3c_priv_xfer { >>> + u8 addr; >>> + u16 len; >>> + u32 flags; >>> + struct { >>> + void *in; >>> + const void *out; >>> + } data; >>> +}; >> Same as above, i3c_sdr_max_data_rate to change the bus scl. > If I'm understanding the spec correctly, that's not something you want > to change on a per-transfer basis. The constraint is on the device > itself and should IMO not be part of the i3c_priv_xfer struct. As mention before this is important. You can do the same as for struct i3c_hdr_cmd and add a enum i3c_sdr_max_data_rate. The @flag only have 2 bits of load, is the rest opened? > >> > + >>> +/** >>> + * enum i3c_dcr - I3C DCR values >>> + * @I3C_DCR_GENERIC_DEVICE: generic I3C device >>> + */ >>> +enum i3c_dcr { >>> + I3C_DCR_GENERIC_DEVICE = 0, >>> +}; >>> + >>> +#define I3C_PID_MANUF_ID(pid) (((pid) & GENMASK_ULL(47, 33)) >> 33) >>> +#define I3C_PID_RND_LOWER_32BITS(pid) (!!((pid) & BIT_ULL(32))) >>> +#define I3C_PID_RND_VAL(pid) ((pid) & GENMASK_ULL(31, 0)) >>> +#define I3C_PID_PART_ID(pid) (((pid) & GENMASK_ULL(31, 16)) >> 16) >>> +#define I3C_PID_INSTANCE_ID(pid) (((pid) & GENMASK_ULL(15, 12)) >> 12) >>> +#define I3C_PID_EXTRA_INFO(pid) ((pid) & GENMASK_ULL(11, 0)) >>> + >>> +#define I3C_BCR_DEVICE_ROLE(bcr) ((bcr) & GENMASK(7, 6)) >>> +#define I3C_BCR_I3C_SLAVE (0 << 6) >>> +#define I3C_BCR_I3C_MASTER (1 << 6) >>> +#define I3C_BCR_HDR_CAP BIT(5) >>> +#define I3C_BCR_BRIDGE BIT(4) >>> +#define I3C_BCR_OFFLINE_CAP BIT(3) >>> +#define I3C_BCR_IBI_PAYLOAD BIT(2) >>> +#define I3C_BCR_IBI_REQ_CAP BIT(1) >>> +#define I3C_BCR_MAX_DATA_SPEED_LIM BIT(0) >>> + >>> +/** >>> + * struct i3c_device_info - I3C device information >>> + * @pid: Provisional ID >>> + * @bcr: Bus Characteristic Register >>> + * @dcr: Device Characteristic Register >>> + * @static_addr: static/I2C address >>> + * @dyn_addr: dynamic address >>> + * @hdr_cap: supported HDR modes >>> + * @max_read_ds: max read speed information >>> + * @max_write_ds: max write speed information >>> + * @max_ibi_len: max IBI payload length >>> + * @max_read_turnaround: max read turn-around time in micro-seconds >>> + * @max_read_len: max private SDR read length in bytes >>> + * @max_write_len: max private SDR write length in bytes >>> + * >>> + * These are all basic information that should be advertised by an I3C device. >>> + * Some of them are optional depending on the device type and device >>> + * capabilities. >>> + * For each I3C slave attached to a master with >>> + * i3c_master_add_i3c_dev_locked(), the core will send the relevant CCC command >>> + * to retrieve these data. >>> + */ >>> +struct i3c_device_info { >>> + u64 pid; >>> + u8 bcr; >>> + u8 dcr; >>> + u8 static_addr; >>> + u8 dyn_addr; >>> + u8 hdr_cap; >>> + u8 max_read_ds; >>> + u8 max_write_ds; >>> + u8 max_ibi_len; >>> + u32 max_read_turnaround; >>> + u16 max_read_len; >>> + u16 max_write_len; >>> +}; >>> + >> is this information filled with data provided from CCC commands? > Yes, they are. Ok, them the intention is to do this on bus_init(), right? > >> > + >>> +#endif /* I3C_DEV_H */ >>> diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h >>> new file mode 100644 >>> index 000000000000..7ec9a4821bac >>> --- /dev/null >>> +++ b/include/linux/i3c/master.h >>> @@ -0,0 +1,564 @@ >>> +/* SPDX-License-Identifier: GPL-2.0 */ >>> +/* >>> + * Copyright (C) 2017 Cadence Design Systems Inc. >>> + * >>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> >>> + */ >>> + >>> +#ifndef I3C_MASTER_H >>> +#define I3C_MASTER_H >>> + >>> +#include <linux/i2c.h> >>> +#include <linux/i3c/ccc.h> >>> +#include <linux/i3c/device.h> >>> +#include <linux/spinlock.h> >>> + >>> +#define I3C_HOT_JOIN_ADDR 0x2 >>> +#define I3C_BROADCAST_ADDR 0x7e >>> +#define I3C_MAX_ADDR GENMASK(6, 0) >>> + >>> +struct i3c_master_controller; >>> +struct i3c_bus; >>> + >>> +/** >>> + * struct i3c_i2c_dev - I3C/I2C common information >>> + * @node: node element used to insert the device into the I2C or I3C device >>> + * list >>> + * @bus: I3C bus this device is connected to >>> + * @master: I3C master that instantiated this device. Will be used to send >>> + * I2C/I3C frames on the bus >>> + * @master_priv: master private data assigned to the device. Can be used to >>> + * add master specific information >>> + * >>> + * This structure is describing common I3C/I2C dev information. >>> + */ >>> +struct i3c_i2c_dev { >>> + struct list_head node; >>> + struct i3c_bus *bus; >>> + struct i3c_master_controller *master; >>> + void *master_priv; >>> +}; >>> + >>> +#define I3C_LVR_I2C_INDEX_MASK GENMASK(7, 5) >>> +#define I3C_LVR_I2C_INDEX(x) ((x) << 5) >>> +#define I3C_LVR_I2C_FM_MODE BIT(4) >>> + >>> +#define I2C_MAX_ADDR GENMASK(9, 0) >> why 10-bit address? >> > Because some I2C devices have 10-bit addresses. > >> > + >>> +/** >>> + * struct i2c_device - I2C device object >>> + * @common: inherit common I3C/I2C description >>> + * @info: I2C board info used to instantiate the I2C device. If you are >>> + * using DT to describe your hardware, this will be filled for you >>> + * @client: I2C client object created by the I2C framework. This will only >>> + * be valid after i3c_master_register() returns >>> + * @lvr: Legacy Virtual Register value as described in the I3C specification >>> + * >>> + * I2C device object. Note that the real I2C device is represented by >>> + * i2c_device->client, but we need extra information to handle the device when >>> + * it's connected to an I3C bus, hence the &struct i2c_device wrapper. >>> + * >>> + * The I2C framework is not impacted by this new representation. >>> + */ >>> +struct i2c_device { >>> + struct i3c_i2c_dev common; >>> + struct i2c_board_info info; >>> + struct i2c_client *client; >>> + u8 lvr; >>> +}; >>> + >> It is usefull to know the speed limitations of the device. > See my previous explanation about I2C and the max frequency. BTW, the > FM vs FM+ information is already encoded in the ->lvr field. you are right. >> > + >>> +/** >>> + * enum i3c_addr_slot_status - I3C address slot status >>> + * @I3C_ADDR_SLOT_FREE: address is free >>> + * @I3C_ADDR_SLOT_RSVD: address is reserved >>> + * @I3C_ADDR_SLOT_I2C_DEV: address is assigned to an I2C device >>> + * @I3C_ADDR_SLOT_I3C_DEV: address is assigned to an I3C device >>> + * @I3C_ADDR_SLOT_STATUS_MASK: address slot mask >>> + * >>> + * On an I3C bus, addresses are assigned dynamically, and we need to know which >>> + * addresses are free to use and which ones are already assigned. >>> + * >>> + * Addresses marked as reserved are those reserved by the I3C protocol >>> + * (broadcast address, ...). >>> + */ >>> +enum i3c_addr_slot_status { >>> + I3C_ADDR_SLOT_FREE, >>> + I3C_ADDR_SLOT_RSVD, >>> + I3C_ADDR_SLOT_I2C_DEV, >>> + I3C_ADDR_SLOT_I3C_DEV, >>> + I3C_ADDR_SLOT_STATUS_MASK = 3, >>> +}; >>> + >>> +/** >>> + * struct i3c_bus - I3C bus object >>> + * @dev: device to be registered to the device-model >>> + * @cur_master: I3C master currently driving the bus. Since I3C is multi-master >>> + * this can change over the time. Will be used to let a master >>> + * know whether it needs to request bus ownership before sending >>> + * a frame or not >>> + * @id: bus ID. Assigned by the framework when register the bus >>> + * @addrslots: a bitmap with 2-bits per-slot to encode the address status and >>> + * ease the DAA (Dynamic Address Assignment) procedure (see >>> + * &enum i3c_addr_slot_status) >>> + * @mode: bus mode (see &enum i3c_bus_mode) >>> + * @scl_rate: SCL signal rate for I3C and I2C mode >>> + * @devs: 2 lists containing all I3C/I2C devices connected to the bus >>> + * @lock: read/write lock on the bus. This is needed to protect against >>> + * operations that have an impact on the whole bus and the devices >>> + * connected to it. For example, when asking slaves to drop their >>> + * dynamic address (RSTDAA CCC), we need to make sure no one is trying >>> + * to send I3C frames to these devices. >>> + * Note that this lock does not protect against concurrency between >>> + * devices: several drivers can send different I3C/I2C frames through >>> + * the same master in parallel. This is the responsibility of the >>> + * master to guarantee that frames are actually sent sequentially and >>> + * not interlaced >>> + * >>> + * The I3C bus is represented with its own object and not implicitly described >>> + * by the I3C master to cope with the multi-master functionality, where one bus >>> + * can be shared amongst several masters, each of them requesting bus ownership >>> + * when they need to. >>> + */ >>> +struct i3c_bus { >>> + struct device dev; >>> + struct i3c_device *cur_master; >>> + int id; >>> + unsigned long addrslots[((I2C_MAX_ADDR + 1) * 2) / BITS_PER_LONG]; >>> + enum i3c_bus_mode mode; >>> + struct { >>> + unsigned long i3c; >>> + unsigned long i2c; >>> + } scl_rate; >>> + struct { >>> + struct list_head i3c; >>> + struct list_head i2c; >>> + } devs; >>> + struct rw_semaphore lock; >>> +}; >> Can you explain the addrslots[] ? > It's a bitmap encoding the status of I3C/I2C addresses: are they > assigned, reserved of free, and if they are assigned is it an I3C or > I2C device. That's particularly useful to master controller drivers > to know which addresses they can assign during DAA. > > I'll try to clarify it in the kernel-doc header. yes please. > >>> + >>> +static inline struct i3c_device *dev_to_i3cdev(struct device *dev) >>> +{ >>> + return container_of(dev, struct i3c_device, dev); >>> +} >>> + >>> +struct i3c_master_controller; >>> + >>> +/** >>> + * struct i3c_master_controller_ops - I3C master methods >>> + * @bus_init: hook responsible for the I3C bus initialization. This >>> + * initialization should follow the steps described in the I3C >>> + * specification. This hook is called with the bus lock held in >>> + * write mode, which means all _locked() helpers can safely be >>> + * called from there >>> + * @bus_cleanup: cleanup everything done in >>> + * &i3c_master_controller_ops->bus_init(). This function is >>> + * optional and should only be implemented if >>> + * &i3c_master_controller_ops->bus_init() attached private data >>> + * to I3C/I2C devices. This hook is called with the bus lock >>> + * held in write mode, which means all _locked() helpers can >>> + * safely be called from there >>> + * @supports_ccc_cmd: should return true if the CCC command is supported, false >>> + * otherwise >>> + * @send_ccc_cmd: send a CCC command >>> + * @send_hdr_cmds: send one or several HDR commands. If there is more than one >>> + * command, they should ideally be sent in the same HDR >>> + * transaction >>> + * @priv_xfers: do one or several private I3C SDR transfers >>> + * @i2c_xfers: do one or several I2C transfers >>> + * @request_ibi: attach an IBI handler to an I3C device. This implies defining >>> + * an IBI handler and the constraints of the IBI (maximum payload >>> + * length and number of pre-allocated slots). >>> + * Some controllers support less IBI-capable devices than regular >>> + * devices, so this method might return -%EBUSY if there's no >>> + * more space for an extra IBI registration >>> + * @free_ibi: free an IBI previously requested with ->request_ibi(). The IBI >>> + * should have been disabled with ->disable_irq() prior to that >>> + * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has been called >>> + * prior to ->enable_ibi(). The controller should first enable >>> + * the IBI on the controller end (for example, unmask the hardware >>> + * IRQ) and then send the ENEC CCC command (with the IBI flag set) >>> + * to the I3C device >>> + * @disable_ibi: disable an IBI. First send the DISEC CCC command with the IBI >>> + * flag set and then deactivate the hardware IRQ on the >>> + * controller end >>> + * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI has been >>> + * processed by its handler. The IBI slot should be put back >>> + * in the IBI slot pool so that the controller can re-use it >>> + * for a future IBI >>> + * >>> + * One of the most important hooks in these ops is >>> + * &i3c_master_controller_ops->bus_init(). Here is a non-exhaustive list of >>> + * things that should be done in &i3c_master_controller_ops->bus_init(): >>> + * >>> + * 1) call i3c_master_set_info() with all information describing the master >>> + * 2) ask all slaves to drop their dynamic address by sending the RSTDAA CCC >>> + * with i3c_master_rstdaa_locked() >>> + * 3) ask all slaves to disable IBIs using i3c_master_disec_locked() >>> + * 4) start a DDA procedure by sending the ENTDAA CCC with >>> + * i3c_master_entdaa_locked(), or using the internal DAA logic provided by >>> + * your controller >> You mean SETDASA CCC command? > No, I really mean ENTDAA and DAA. By internal DAA logic I mean that > some controllers are probably automating the whole DAA procedure, while > others may let the SW control every step. My understanding is that i3c_master_entdaa_locked() will trigger the DAA process and DAA can be done by SETDASA, ENTDAA and later after the bus initialization with SETNEWDA. I think the DAA process should be more generic, right now is only made through the ENTDAA command with (cmd.ndests = 1). I mean, shouldn't this be made by the core? First doing DAA for the devices declared and them try do discover the rest of devices on the bus. > > Thanks for your review. > > Boris > Thank you, Vitor Soares -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Vitor, On Mon, 26 Feb 2018 18:58:15 +0000 Vitor Soares <Vitor.Soares@synopsys.com> wrote: > >>> +/** > >>> + * i3c_device_do_priv_xfers() - do I3C SDR private transfers directed to a > >>> + * specific device > >>> + * > >>> + * @dev: device with which the transfers should be done > >>> + * @xfers: array of transfers > >>> + * @nxfers: number of transfers > >>> + * > >>> + * Initiate one or several private SDR transfers with @dev. > >>> + * > >>> + * This function can sleep and thus cannot be called in atomic context. > >>> + * > >>> + * Return: 0 in case of success, a negative error core otherwise. > >>> + */ > >>> +int i3c_device_do_priv_xfers(struct i3c_device *dev, > >>> + struct i3c_priv_xfer *xfers, > >>> + int nxfers) > >>> +{ > >>> + struct i3c_master_controller *master; > >>> + int i, ret; > >>> + > >>> + master = i3c_device_get_master(dev); > >>> + if (!master) > >>> + return -EINVAL; > >>> + > >>> + i3c_bus_normaluse_lock(master->bus); > >>> + for (i = 0; i < nxfers; i++) > >>> + xfers[i].addr = dev->info.dyn_addr; > >>> + > >>> + ret = i3c_master_do_priv_xfers_locked(master, xfers, nxfers); > >>> + i3c_bus_normaluse_unlock(master->bus); > >>> + > >>> + return ret; > >>> +} > >>> +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers); > >> The controller should know the speed mode for each xfer. The SDR0 mode > >> is used by default but if any device have read or write speed > >> limitations the controller can use SDRx. > > I might be wrong, but that's not my understanding of the spec. A device > > can express a speed limitation for SDR priv transfers, but this > > limitation applies to all SDR transfers. > > > > The speed R/W speed limitation is encoded in the device object, so, if > > the controller has to configure that on a per-transfer basis, one > > solution would be to pass the device to the ->priv_xfers(). > The speed R/W limitation is only for private transfers. Also the device can have > a limitation to write and not for read data. > This information is obtained with the command GETMXDS which returns the Maximum > Sustained Data Rate for non-CCC messages. And that's exactly what I expose in i3c_device_info, which is embedded in i3c_device, so you should have all the information you need to determine the speed in the controller driver if ->priv_xfer() is passed the device attached to those transfers. Would that be okay if we pass an i3c_device object to ->priv_xfers()? > > > >> This could be also applied to i2c transfers. > > Not really. The max SCL frequency is something that applies to the > > whole bus, because all I2C devices have to decode the address when > > messages are sent on the bus to determine if they should ignore or > > process the message. > > > >>> +#endif /* I3C_INTERNAL_H */ > >>> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c > >>> new file mode 100644 > >>> index 000000000000..1c85abac08d5 > >>> --- /dev/null > >>> +++ b/drivers/i3c/master.c > >>> @@ -0,0 +1,1433 @@ > >>> +// SPDX-License-Identifier: GPL-2.0 > >>> +/* > >>> + * Copyright (C) 2017 Cadence Design Systems Inc. > >>> + * > >>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> > >>> + */ > >>> + > >>> +#include <linux/slab.h> > >>> + > >>> +#include "internals.h" > >>> + > >>> +/** > >>> + * i3c_master_entdaa_locked() - start a DAA (Dynamic Address Assignment) > >>> + * procedure > >>> + * @master: master used to send frames on the bus > >>> + * > >>> + * Send a ENTDAA CCC command to start a DAA procedure. > >>> + * > >>> + * Note that this function only sends the ENTDAA CCC command, all the logic > >>> + * behind dynamic address assignment has to be handled in the I3C master > >>> + * driver. > >>> + * > >>> + * This function must be called with the bus lock held in write mode. > >>> + * > >>> + * Return: 0 in case of success, a negative error code otherwise. > >>> + */ > >>> +int i3c_master_entdaa_locked(struct i3c_master_controller *master) > >>> +{ > >>> + struct i3c_ccc_cmd_dest dest = { }; > >>> + struct i3c_ccc_cmd cmd = { }; > >>> + int ret; > >>> + > >>> + dest.addr = I3C_BROADCAST_ADDR; > >>> + cmd.dests = &dest; > >>> + cmd.ndests = 1; > >>> + cmd.rnw = false; > >>> + cmd.id = I3C_CCC_ENTDAA; > >>> + > >>> + ret = i3c_master_send_ccc_cmd_locked(master, &cmd); > >>> + if (ret) > >>> + return ret; > >>> + > >>> + return 0; > >>> +} > >>> +EXPORT_SYMBOL_GPL(i3c_master_entdaa_locked); > >> can you explain the process? > > Not sure what you mean. The ENTDAA is just a CCC command that is used > > to trigger a DAA procedure. What the master controller does when it > > sends such a command is likely to be controller dependent, and it might > > even be possible that you don't need to call this function in your > > controller driver to trigger a DAA. If you want more details about the > > bus initialization steps and how the ENTDAA CCC command fits into it I > > recommend reading section "5.1.4 Bus Initialization and Dynamic Address > > Assignment Mode" > > > >> the command is only execute once, what if > >> there is more devices on the bus? > > Again, I'm not sure what you mean. The ENTDAA command is sent every > > time a controller wants to discover new devices on the bus, that can be > > when initializing the bus, after a Hot Join event or simply triggered > > by the user (the last case is not supported yet though). > > > > Now, if you're interested in what happens after an ENTDAA CCC is sent, > > the controller will keep sending RepeatedStart until there's no more > > devices acking the request. You can have a look at "B.3 Error Types in > > Dynamic Address Arbitration" for more details. > My understanding is this command shall be executed once, this mean that only one > slave will assign the dynamic address (cmd.ndests = 1) and not trigger the whole > process of DAA. No, that's not what happens. The master controller is supposed to continue until no one replies with an Ack on the bus, and by continue I don't mean resend an ENTDAA, but issue a RepeatedStart followed by the broadcast address (0x7e). > Either important is the SETDASA for declared I3C devices. So the DAA process > should start by send an SETDASA and them ENTDAA CCC command. My understanding was that SETDASA was not mandatory, and was only useful when one wants to assign a specific dynamic address to a slave that has a static address (which is again not mandatory). I've tested it, and even devices with a static address participate to the DAA procedure if they've not been assigned a dynamic address yet, so I don't see the need for this SETDASA step if you don't need to assign a particular dynamic address to the device. Could you tell me why you think SETDASA is required? > >>> +static u32 i3c_master_i2c_functionalities(struct i2c_adapter *adap) > >>> +{ > >>> + return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR; > >>> +} > >> Is I2C_FUNC_10BIT_ADDR allowed ? > > According to "Table 4 I 2 C Features Allowed in I3C Slaves", yes (at > > least that my understanding). And the Cadence controller supports it. > The table say the oposite. The I2C extended address feature is not used on I3C > bus, thus this feature shall be disable. Actually, I was wrong when initially mentioning this table: it's about I2C features supported on I3C slaves, so not really what we're looking for. Here, we're wondering if I2C-only devices can have 10-bit addresses. The Cadence controller supports that, so there's probably nothing preventing use of 10-bit addresses for I2C transfers, but maybe not all I3C master controllers support that, so we should probably let the I3C master driver implement this method. > BTW it is optional on I2C devices. You mean I2C controllers? When an I2C device has a 10bit address, the controller has to support this mode to communicate with the device, at least that's my understanding. But we're digressing a bit. The question is not whether I2C devices can optionally use a 10 bit address, but whether I3C master controller can support this mode for I2C transfers to I2C-only devices. > > > > >> > diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig > >>> new file mode 100644 > >>> index 000000000000..e69de29bb2d1 > >>> diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile > >>> new file mode 100644 > >>> index 000000000000..e69de29bb2d1 > >>> diff --git a/include/linux/i3c/ccc.h b/include/linux/i3c/ccc.h > >>> new file mode 100644 > >>> index 000000000000..ff3e1a3e2c4c > >>> --- /dev/null > >>> +++ b/include/linux/i3c/ccc.h > >>> @@ -0,0 +1,380 @@ > >>> +/* SPDX-License-Identifier: GPL-2.0 */ > >>> +/* > >>> + * Copyright (C) 2017 Cadence Design Systems Inc. > >>> + * > >>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> > >>> + */ > >>> + > >>> + > >>> +/** > >>> + * enum i3c_ccc_test_mode - enum listing all available test modes > >>> + * > >>> + * @I3C_CCC_EXIT_TEST_MODE: exit test mode > >>> + * @I3C_CCC_VENDOR_TEST_MODE: enter vendor test mode > >>> + */ > >>> +enum i3c_ccc_test_mode { > >>> + I3C_CCC_EXIT_TEST_MODE, > >>> + I3C_CCC_VENDOR_TEST_MODE, > >>> +}; > >>> + > >>> +/** > >>> + * struct i3c_ccc_enttm - payload passed to ENTTM CCC > >>> + * > >>> + * @mode: one of the &enum i3c_ccc_test_mode modes > >>> + * > >>> + * Information passed to the ENTTM CCC to instruct an I3C device to enter a > >>> + * specific test mode. > >>> + */ > >>> +struct i3c_ccc_enttm { > >>> + u8 mode; > >>> +} __packed; > >>> + > >>> +/** > >>> + * struct i3c_ccc_setda - payload passed to ENTTM CCC > >>> + * > >>> + * @mode: one of the &enum i3c_ccc_test_mode modes > >>> + * > >>> + * Information passed to the ENTTM CCC to instruct an I3C device to enter a > >>> + * specific test mode. > >>> + */ > >>> +struct i3c_ccc_setda { > >>> + u8 addr; > >>> +} __packed; > >> what do you mean with struct? Maybe setdasa? if so, what is the addr? > Do you have the function to use this structure? Because one command use the > static address and the other use the dynamic address. > > >> > >> > +/** > >>> + * enum i3c_sdr_max_data_rate - max data rate values for private SDR transfers > >>> + */ > >>> +enum i3c_sdr_max_data_rate { > >>> + I3C_SDR_DR_FSCL_MAX, > >>> + I3C_SDR_DR_FSCL_8MHZ, > >>> + I3C_SDR_DR_FSCL_6MHZ, > >>> + I3C_SDR_DR_FSCL_4MHZ, > >>> + I3C_SDR_DR_FSCL_2MHZ, > >>> +}; > >> Can you change the names to: > >> > >> I3C_SDR0_FSCL_MAX, > >> I3C_SDR1_FSCL_8MHZ, > >> I3C_SDR2_FSCL_6MHZ, > >> I3C_SDR3_FSCL_4MHZ, > >> I3C_SDR4_FSCL_2MHZ, > >> > >> thus the data rate isn't repeated. > > What's the problem with the name I use? Moreover, I see no mention to > > the SDR0,1,2,3,4 modes in the public spec. > When you get the GETMXDS information, the maxWr and maxRd came from 0 to 4, so > in my opinion I think in this way is easier to have a relationship. It's an emum, and there's no mention of the SDRX modes you're using here in the I3C spec. I guess it's named this way in your I3C controller datasheet. I personally don't see a good reason to add SDRX in the name, but if you insist... > >>> + > >>> +#endif /* I3C_CCC_H */ > >>> diff --git a/include/linux/i3c/device.h b/include/linux/i3c/device.h > >>> new file mode 100644 > >>> index 000000000000..83958d3a02e2 > >>> --- /dev/null > >>> +++ b/include/linux/i3c/device.h > >>> @@ -0,0 +1,321 @@ > >>> +/* SPDX-License-Identifier: GPL-2.0 */ > >>> +/* > >>> + * Copyright (C) 2017 Cadence Design Systems Inc. > >>> + * > >>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> > >>> + */ > >>> + > >>> +#ifndef I3C_DEV_H > >>> +#define I3C_DEV_H > >>> + > >>> +#include <linux/device.h> > >>> +#include <linux/i2c.h> > >>> +#include <linux/mod_devicetable.h> > >>> +#include <linux/module.h> > >>> + > >>> +/** > >>> + * enum i3c_hdr_mode - HDR mode ids > >>> + * @I3C_HDR_DDR: DDR mode > >>> + * @I3C_HDR_TSP: TSP mode > >>> + * @I3C_HDR_TSL: TSL mode > >>> + */ > >>> +enum i3c_hdr_mode { > >>> + I3C_HDR_DDR, > >>> + I3C_HDR_TSP, > >>> + I3C_HDR_TSL, > >>> +}; > >>> + > >>> +/** > >>> + * struct i3c_hdr_cmd - I3C HDR command > >>> + * @mode: HDR mode selected for this command > >>> + * @code: command opcode > >>> + * @addr: I3C dynamic address > >>> + * @ndatawords: number of data words (a word is 16bits wide) > >>> + * @data: input/output buffer > >>> + */ > >>> +struct i3c_hdr_cmd { > >>> + enum i3c_hdr_mode mode; > >>> + u8 code; > >>> + u8 addr; > >>> + int ndatawords; > >>> + union { > >>> + u16 *in; > >>> + const u16 *out; > >>> + } data; > >>> +}; > Please mention that the @code is what will define if the transfer is read or write. Well, I think it's pretty clear in the definition you'll find in the ccc.h file, but I can add a comment here too if you like. > >>> + > >>> +/* Private SDR read transfer */ > >>> +#define I3C_PRIV_XFER_READ BIT(0) > >>> +/* > >>> + * Instruct the controller to issue a STOP after a specific transfer instead > >>> + * of a REPEATED START. > >>> + */ > >>> +#define I3C_PRIV_XFER_STOP BIT(1) > >>> + > >>> +/** > >>> + * struct i3c_priv_xfer - I3C SDR private transfer > >>> + * @addr: I3C dynamic address > >>> + * @len: transfer length in bytes of the transfer > >>> + * @flags: combination of I3C_PRIV_XFER_xxx flags > >>> + * @data: input/output buffer > >>> + */ > >>> +struct i3c_priv_xfer { > >>> + u8 addr; > >>> + u16 len; > >>> + u32 flags; > >>> + struct { > >>> + void *in; > >>> + const void *out; > >>> + } data; > >>> +}; > >> Same as above, i3c_sdr_max_data_rate to change the bus scl. > > If I'm understanding the spec correctly, that's not something you want > > to change on a per-transfer basis. The constraint is on the device > > itself and should IMO not be part of the i3c_priv_xfer struct. > As mention before this is important. > You can do the same as for struct i3c_hdr_cmd and add a enum i3c_sdr_max_data_rate. > > The @flag only have 2 bits of load, is the rest opened? If by open you mean that we can add more flags if we need to, then yes. > > > >> > + > >>> +/** > >>> + * enum i3c_dcr - I3C DCR values > >>> + * @I3C_DCR_GENERIC_DEVICE: generic I3C device > >>> + */ > >>> +enum i3c_dcr { > >>> + I3C_DCR_GENERIC_DEVICE = 0, > >>> +}; > >>> + > >>> +#define I3C_PID_MANUF_ID(pid) (((pid) & GENMASK_ULL(47, 33)) >> 33) > >>> +#define I3C_PID_RND_LOWER_32BITS(pid) (!!((pid) & BIT_ULL(32))) > >>> +#define I3C_PID_RND_VAL(pid) ((pid) & GENMASK_ULL(31, 0)) > >>> +#define I3C_PID_PART_ID(pid) (((pid) & GENMASK_ULL(31, 16)) >> 16) > >>> +#define I3C_PID_INSTANCE_ID(pid) (((pid) & GENMASK_ULL(15, 12)) >> 12) > >>> +#define I3C_PID_EXTRA_INFO(pid) ((pid) & GENMASK_ULL(11, 0)) > >>> + > >>> +#define I3C_BCR_DEVICE_ROLE(bcr) ((bcr) & GENMASK(7, 6)) > >>> +#define I3C_BCR_I3C_SLAVE (0 << 6) > >>> +#define I3C_BCR_I3C_MASTER (1 << 6) > >>> +#define I3C_BCR_HDR_CAP BIT(5) > >>> +#define I3C_BCR_BRIDGE BIT(4) > >>> +#define I3C_BCR_OFFLINE_CAP BIT(3) > >>> +#define I3C_BCR_IBI_PAYLOAD BIT(2) > >>> +#define I3C_BCR_IBI_REQ_CAP BIT(1) > >>> +#define I3C_BCR_MAX_DATA_SPEED_LIM BIT(0) > >>> + > >>> +/** > >>> + * struct i3c_device_info - I3C device information > >>> + * @pid: Provisional ID > >>> + * @bcr: Bus Characteristic Register > >>> + * @dcr: Device Characteristic Register > >>> + * @static_addr: static/I2C address > >>> + * @dyn_addr: dynamic address > >>> + * @hdr_cap: supported HDR modes > >>> + * @max_read_ds: max read speed information > >>> + * @max_write_ds: max write speed information > >>> + * @max_ibi_len: max IBI payload length > >>> + * @max_read_turnaround: max read turn-around time in micro-seconds > >>> + * @max_read_len: max private SDR read length in bytes > >>> + * @max_write_len: max private SDR write length in bytes > >>> + * > >>> + * These are all basic information that should be advertised by an I3C device. > >>> + * Some of them are optional depending on the device type and device > >>> + * capabilities. > >>> + * For each I3C slave attached to a master with > >>> + * i3c_master_add_i3c_dev_locked(), the core will send the relevant CCC command > >>> + * to retrieve these data. > >>> + */ > >>> +struct i3c_device_info { > >>> + u64 pid; > >>> + u8 bcr; > >>> + u8 dcr; > >>> + u8 static_addr; > >>> + u8 dyn_addr; > >>> + u8 hdr_cap; > >>> + u8 max_read_ds; > >>> + u8 max_write_ds; > >>> + u8 max_ibi_len; > >>> + u32 max_read_turnaround; > >>> + u16 max_read_len; > >>> + u16 max_write_len; > >>> +}; > >>> + > >> is this information filled with data provided from CCC commands? > > Yes, they are. > Ok, them the intention is to do this on bus_init(), right? Not only, it can be after a Hot-Join, or after the user has triggered a new DAA. Anyway, these information are retrieved anytime you add a device with i3c_master_add_i3c_dev_locked(), and the core uses CCC commands to do that. > >>> + > >>> +/** > >>> + * struct i3c_master_controller_ops - I3C master methods > >>> + * @bus_init: hook responsible for the I3C bus initialization. This > >>> + * initialization should follow the steps described in the I3C > >>> + * specification. This hook is called with the bus lock held in > >>> + * write mode, which means all _locked() helpers can safely be > >>> + * called from there > >>> + * @bus_cleanup: cleanup everything done in > >>> + * &i3c_master_controller_ops->bus_init(). This function is > >>> + * optional and should only be implemented if > >>> + * &i3c_master_controller_ops->bus_init() attached private data > >>> + * to I3C/I2C devices. This hook is called with the bus lock > >>> + * held in write mode, which means all _locked() helpers can > >>> + * safely be called from there > >>> + * @supports_ccc_cmd: should return true if the CCC command is supported, false > >>> + * otherwise > >>> + * @send_ccc_cmd: send a CCC command > >>> + * @send_hdr_cmds: send one or several HDR commands. If there is more than one > >>> + * command, they should ideally be sent in the same HDR > >>> + * transaction > >>> + * @priv_xfers: do one or several private I3C SDR transfers > >>> + * @i2c_xfers: do one or several I2C transfers > >>> + * @request_ibi: attach an IBI handler to an I3C device. This implies defining > >>> + * an IBI handler and the constraints of the IBI (maximum payload > >>> + * length and number of pre-allocated slots). > >>> + * Some controllers support less IBI-capable devices than regular > >>> + * devices, so this method might return -%EBUSY if there's no > >>> + * more space for an extra IBI registration > >>> + * @free_ibi: free an IBI previously requested with ->request_ibi(). The IBI > >>> + * should have been disabled with ->disable_irq() prior to that > >>> + * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has been called > >>> + * prior to ->enable_ibi(). The controller should first enable > >>> + * the IBI on the controller end (for example, unmask the hardware > >>> + * IRQ) and then send the ENEC CCC command (with the IBI flag set) > >>> + * to the I3C device > >>> + * @disable_ibi: disable an IBI. First send the DISEC CCC command with the IBI > >>> + * flag set and then deactivate the hardware IRQ on the > >>> + * controller end > >>> + * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI has been > >>> + * processed by its handler. The IBI slot should be put back > >>> + * in the IBI slot pool so that the controller can re-use it > >>> + * for a future IBI > >>> + * > >>> + * One of the most important hooks in these ops is > >>> + * &i3c_master_controller_ops->bus_init(). Here is a non-exhaustive list of > >>> + * things that should be done in &i3c_master_controller_ops->bus_init(): > >>> + * > >>> + * 1) call i3c_master_set_info() with all information describing the master > >>> + * 2) ask all slaves to drop their dynamic address by sending the RSTDAA CCC > >>> + * with i3c_master_rstdaa_locked() > >>> + * 3) ask all slaves to disable IBIs using i3c_master_disec_locked() > >>> + * 4) start a DDA procedure by sending the ENTDAA CCC with > >>> + * i3c_master_entdaa_locked(), or using the internal DAA logic provided by > >>> + * your controller > >> You mean SETDASA CCC command? > > No, I really mean ENTDAA and DAA. By internal DAA logic I mean that > > some controllers are probably automating the whole DAA procedure, while > > others may let the SW control every step. > My understanding is that i3c_master_entdaa_locked() will trigger the DAA process > and DAA can be done by SETDASA, ENTDAA and later after the bus initialization > with SETNEWDA. No. Only ENTDAA can trigger a DAA procedure. SETDASA is here to assign a single dynamic address to a device that already has a static address but no dynamic address yet, and SETNEWDA is here to modify the dynamic address of a device that already has one. > > I think the DAA process should be more generic, right now is only made through > the ENTDAA command with (cmd.ndests = 1). > I mean, shouldn't this be made by the core? First doing DAA for the devices > declared and them try do discover the rest of devices on the bus. Can you detail a bit more? If the only part you're complaining about is pre-assignment of dynamic addresses with SETDASA when a device is declared in the DT with a reg and dynamic-address property, then yes, I think I can provide an helper for that. But this helper would still have to be called from the master controller driver (from ->bus_init() or after a Hot-Join). Now, if the question is, is there a way we can automate things even more and completely implement DAA from the core? I doubt it, because the way the core will trigger DAA, expose discovered devices or allow you to declare manually assigned addresses is likely to be controller-dependent. When I designed the framework I took the decision to base my work on the spec rather than focusing on the I3C master controller I had to support (Cadence). This is the reason I decided to keep the interface as simple as possible at the risk of encouraging code-duplication (at first) rather than coming up with an interface that is designed with a single controller in mind and having to break things every time a new controller comes out. Thank you for you comments, but I'd like to know if some of my design choices are blocking you to support your controller. What I've seen so far is a collection of things that might be relevant to fix (though most of them are subject to interpretation and/or a matter of taste), but nothing that should really block you. Can you clarify that, and maybe come back with a list of things that you think are preventing you from properly supporting the Synopsys controller? Thanks, Boris
On Mon, 26 Feb 2018 21:36:07 +0100 Boris Brezillon <boris.brezillon@bootlin.com> wrote: > > >>> + > > >>> +/** > > >>> + * struct i3c_master_controller_ops - I3C master methods > > >>> + * @bus_init: hook responsible for the I3C bus initialization. This > > >>> + * initialization should follow the steps described in the I3C > > >>> + * specification. This hook is called with the bus lock held in > > >>> + * write mode, which means all _locked() helpers can safely be > > >>> + * called from there > > >>> + * @bus_cleanup: cleanup everything done in > > >>> + * &i3c_master_controller_ops->bus_init(). This function is > > >>> + * optional and should only be implemented if > > >>> + * &i3c_master_controller_ops->bus_init() attached private data > > >>> + * to I3C/I2C devices. This hook is called with the bus lock > > >>> + * held in write mode, which means all _locked() helpers can > > >>> + * safely be called from there > > >>> + * @supports_ccc_cmd: should return true if the CCC command is supported, false > > >>> + * otherwise > > >>> + * @send_ccc_cmd: send a CCC command > > >>> + * @send_hdr_cmds: send one or several HDR commands. If there is more than one > > >>> + * command, they should ideally be sent in the same HDR > > >>> + * transaction > > >>> + * @priv_xfers: do one or several private I3C SDR transfers > > >>> + * @i2c_xfers: do one or several I2C transfers > > >>> + * @request_ibi: attach an IBI handler to an I3C device. This implies defining > > >>> + * an IBI handler and the constraints of the IBI (maximum payload > > >>> + * length and number of pre-allocated slots). > > >>> + * Some controllers support less IBI-capable devices than regular > > >>> + * devices, so this method might return -%EBUSY if there's no > > >>> + * more space for an extra IBI registration > > >>> + * @free_ibi: free an IBI previously requested with ->request_ibi(). The IBI > > >>> + * should have been disabled with ->disable_irq() prior to that > > >>> + * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has been called > > >>> + * prior to ->enable_ibi(). The controller should first enable > > >>> + * the IBI on the controller end (for example, unmask the hardware > > >>> + * IRQ) and then send the ENEC CCC command (with the IBI flag set) > > >>> + * to the I3C device > > >>> + * @disable_ibi: disable an IBI. First send the DISEC CCC command with the IBI > > >>> + * flag set and then deactivate the hardware IRQ on the > > >>> + * controller end > > >>> + * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI has been > > >>> + * processed by its handler. The IBI slot should be put back > > >>> + * in the IBI slot pool so that the controller can re-use it > > >>> + * for a future IBI > > >>> + * > > >>> + * One of the most important hooks in these ops is > > >>> + * &i3c_master_controller_ops->bus_init(). Here is a non-exhaustive list of > > >>> + * things that should be done in &i3c_master_controller_ops->bus_init(): > > >>> + * > > >>> + * 1) call i3c_master_set_info() with all information describing the master > > >>> + * 2) ask all slaves to drop their dynamic address by sending the RSTDAA CCC > > >>> + * with i3c_master_rstdaa_locked() > > >>> + * 3) ask all slaves to disable IBIs using i3c_master_disec_locked() > > >>> + * 4) start a DDA procedure by sending the ENTDAA CCC with > > >>> + * i3c_master_entdaa_locked(), or using the internal DAA logic provided by > > >>> + * your controller > > >> You mean SETDASA CCC command? > > > No, I really mean ENTDAA and DAA. By internal DAA logic I mean that > > > some controllers are probably automating the whole DAA procedure, while > > > others may let the SW control every step. > > My understanding is that i3c_master_entdaa_locked() will trigger the DAA process > > and DAA can be done by SETDASA, ENTDAA and later after the bus initialization > > with SETNEWDA. > > No. Only ENTDAA can trigger a DAA procedure. SETDASA is here to assign > a single dynamic address to a device that already has a static address > but no dynamic address yet, and SETNEWDA is here to modify the dynamic > address of a device that already has one. > > > > > I think the DAA process should be more generic, right now is only made through > > the ENTDAA command with (cmd.ndests = 1). > > I mean, shouldn't this be made by the core? First doing DAA for the devices > > declared and them try do discover the rest of devices on the bus. > > Can you detail a bit more? If the only part you're complaining about is > pre-assignment of dynamic addresses with SETDASA when a device is > declared in the DT with a reg and dynamic-address property, then yes, I > think I can provide an helper for that. But this helper would still have > to be called from the master controller driver (from ->bus_init() or > after a Hot-Join). > > Now, if the question is, is there a way we can automate things even more > and completely implement DAA from the core? I doubt it, because the way > the core will trigger DAA, expose discovered devices or allow you to > declare manually assigned addresses is likely to be > controller-dependent. > When I designed the framework I took the decision to base my work on the > spec rather than focusing on the I3C master controller I had to support > (Cadence). This is the reason I decided to keep the interface as simple > as possible at the risk of encouraging code-duplication (at first) > rather than coming up with an interface that is designed with a single > controller in mind and having to break things every time a new > controller comes out. > > Thank you for you comments, but I'd like to know if some of my design > choices are blocking you to support your controller. What I've seen so > far is a collection of things that might be relevant to fix (though > most of them are subject to interpretation and/or a matter of taste), > but nothing that should really block you. Well, that's not entirely true: I agree that something is missing in ->priv_xfers() to let the controller know about the device limitations, and this could be a blocking aspect.
On Mon, 26 Feb 2018 21:40:32 +0100 Boris Brezillon <boris.brezillon@bootlin.com> wrote: > On Mon, 26 Feb 2018 21:36:07 +0100 > Boris Brezillon <boris.brezillon@bootlin.com> wrote: > > > > >>> + > > > >>> +/** > > > >>> + * struct i3c_master_controller_ops - I3C master methods > > > >>> + * @bus_init: hook responsible for the I3C bus initialization. This > > > >>> + * initialization should follow the steps described in the I3C > > > >>> + * specification. This hook is called with the bus lock held in > > > >>> + * write mode, which means all _locked() helpers can safely be > > > >>> + * called from there > > > >>> + * @bus_cleanup: cleanup everything done in > > > >>> + * &i3c_master_controller_ops->bus_init(). This function is > > > >>> + * optional and should only be implemented if > > > >>> + * &i3c_master_controller_ops->bus_init() attached private data > > > >>> + * to I3C/I2C devices. This hook is called with the bus lock > > > >>> + * held in write mode, which means all _locked() helpers can > > > >>> + * safely be called from there > > > >>> + * @supports_ccc_cmd: should return true if the CCC command is supported, false > > > >>> + * otherwise > > > >>> + * @send_ccc_cmd: send a CCC command > > > >>> + * @send_hdr_cmds: send one or several HDR commands. If there is more than one > > > >>> + * command, they should ideally be sent in the same HDR > > > >>> + * transaction > > > >>> + * @priv_xfers: do one or several private I3C SDR transfers > > > >>> + * @i2c_xfers: do one or several I2C transfers > > > >>> + * @request_ibi: attach an IBI handler to an I3C device. This implies defining > > > >>> + * an IBI handler and the constraints of the IBI (maximum payload > > > >>> + * length and number of pre-allocated slots). > > > >>> + * Some controllers support less IBI-capable devices than regular > > > >>> + * devices, so this method might return -%EBUSY if there's no > > > >>> + * more space for an extra IBI registration > > > >>> + * @free_ibi: free an IBI previously requested with ->request_ibi(). The IBI > > > >>> + * should have been disabled with ->disable_irq() prior to that > > > >>> + * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has been called > > > >>> + * prior to ->enable_ibi(). The controller should first enable > > > >>> + * the IBI on the controller end (for example, unmask the hardware > > > >>> + * IRQ) and then send the ENEC CCC command (with the IBI flag set) > > > >>> + * to the I3C device > > > >>> + * @disable_ibi: disable an IBI. First send the DISEC CCC command with the IBI > > > >>> + * flag set and then deactivate the hardware IRQ on the > > > >>> + * controller end > > > >>> + * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI has been > > > >>> + * processed by its handler. The IBI slot should be put back > > > >>> + * in the IBI slot pool so that the controller can re-use it > > > >>> + * for a future IBI > > > >>> + * > > > >>> + * One of the most important hooks in these ops is > > > >>> + * &i3c_master_controller_ops->bus_init(). Here is a non-exhaustive list of > > > >>> + * things that should be done in &i3c_master_controller_ops->bus_init(): > > > >>> + * > > > >>> + * 1) call i3c_master_set_info() with all information describing the master > > > >>> + * 2) ask all slaves to drop their dynamic address by sending the RSTDAA CCC > > > >>> + * with i3c_master_rstdaa_locked() > > > >>> + * 3) ask all slaves to disable IBIs using i3c_master_disec_locked() > > > >>> + * 4) start a DDA procedure by sending the ENTDAA CCC with > > > >>> + * i3c_master_entdaa_locked(), or using the internal DAA logic provided by > > > >>> + * your controller > > > >> You mean SETDASA CCC command? > > > > No, I really mean ENTDAA and DAA. By internal DAA logic I mean that > > > > some controllers are probably automating the whole DAA procedure, while > > > > others may let the SW control every step. > > > My understanding is that i3c_master_entdaa_locked() will trigger the DAA process > > > and DAA can be done by SETDASA, ENTDAA and later after the bus initialization > > > with SETNEWDA. > > > > No. Only ENTDAA can trigger a DAA procedure. SETDASA is here to assign > > a single dynamic address to a device that already has a static address > > but no dynamic address yet, and SETNEWDA is here to modify the dynamic > > address of a device that already has one. > > > > > > > > I think the DAA process should be more generic, right now is only made through > > > the ENTDAA command with (cmd.ndests = 1). > > > I mean, shouldn't this be made by the core? First doing DAA for the devices > > > declared and them try do discover the rest of devices on the bus. > > > > Can you detail a bit more? If the only part you're complaining about is > > pre-assignment of dynamic addresses with SETDASA when a device is > > declared in the DT with a reg and dynamic-address property, then yes, I > > think I can provide an helper for that. But this helper would still have > > to be called from the master controller driver (from ->bus_init() or > > after a Hot-Join). > > > > Now, if the question is, is there a way we can automate things even more > > and completely implement DAA from the core? I doubt it, because the way > > the core will trigger DAA, expose discovered devices or allow you to > > declare manually assigned addresses is likely to be > > controller-dependent. > > When I designed the framework I took the decision to base my work on the > > spec rather than focusing on the I3C master controller I had to support > > (Cadence). This is the reason I decided to keep the interface as simple > > as possible at the risk of encouraging code-duplication (at first) > > rather than coming up with an interface that is designed with a single > > controller in mind and having to break things every time a new > > controller comes out. > > > > Thank you for you comments, but I'd like to know if some of my design > > choices are blocking you to support your controller. What I've seen so > > far is a collection of things that might be relevant to fix (though > > most of them are subject to interpretation and/or a matter of taste), > > but nothing that should really block you. > > Well, that's not entirely true: I agree that something is missing in > ->priv_xfers() to let the controller know about the device limitations, > and this could be a blocking aspect. > And I2C functionalities might differ between I3C master controllers, so that's also something we should transfer to the I3C master driver instead of imposing it in the core.
Hi Boris Às 8:36 PM de 2/26/2018, Boris Brezillon escreveu: > Hi Vitor, > > On Mon, 26 Feb 2018 18:58:15 +0000 > Vitor Soares <Vitor.Soares@synopsys.com> wrote: > >>>>> +/** >>>>> + * i3c_device_do_priv_xfers() - do I3C SDR private transfers directed to a >>>>> + * specific device >>>>> + * >>>>> + * @dev: device with which the transfers should be done >>>>> + * @xfers: array of transfers >>>>> + * @nxfers: number of transfers >>>>> + * >>>>> + * Initiate one or several private SDR transfers with @dev. >>>>> + * >>>>> + * This function can sleep and thus cannot be called in atomic context. >>>>> + * >>>>> + * Return: 0 in case of success, a negative error core otherwise. >>>>> + */ >>>>> +int i3c_device_do_priv_xfers(struct i3c_device *dev, >>>>> + struct i3c_priv_xfer *xfers, >>>>> + int nxfers) >>>>> +{ >>>>> + struct i3c_master_controller *master; >>>>> + int i, ret; >>>>> + >>>>> + master = i3c_device_get_master(dev); >>>>> + if (!master) >>>>> + return -EINVAL; >>>>> + >>>>> + i3c_bus_normaluse_lock(master->bus); >>>>> + for (i = 0; i < nxfers; i++) >>>>> + xfers[i].addr = dev->info.dyn_addr; >>>>> + >>>>> + ret = i3c_master_do_priv_xfers_locked(master, xfers, nxfers); >>>>> + i3c_bus_normaluse_unlock(master->bus); >>>>> + >>>>> + return ret; >>>>> +} >>>>> +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers); >>>> The controller should know the speed mode for each xfer. The SDR0 mode >>>> is used by default but if any device have read or write speed >>>> limitations the controller can use SDRx. >>> I might be wrong, but that's not my understanding of the spec. A device >>> can express a speed limitation for SDR priv transfers, but this >>> limitation applies to all SDR transfers. >>> >>> The speed R/W speed limitation is encoded in the device object, so, if >>> the controller has to configure that on a per-transfer basis, one >>> solution would be to pass the device to the ->priv_xfers(). >> The speed R/W limitation is only for private transfers. Also the device can have >> a limitation to write and not for read data. >> This information is obtained with the command GETMXDS which returns the Maximum >> Sustained Data Rate for non-CCC messages. > And that's exactly what I expose in i3c_device_info, which is embedded > in i3c_device, so you should have all the information you need to > determine the speed in the controller driver if ->priv_xfer() is passed > the device attached to those transfers. Would that be okay if we pass an > i3c_device object to ->priv_xfers()? If you pass the i3c_device to ->priv_xfer(), then you won't need the address too. Maybe someone else can give other point of view. >>> >>>> This could be also applied to i2c transfers. >>> Not really. The max SCL frequency is something that applies to the >>> whole bus, because all I2C devices have to decode the address when >>> messages are sent on the bus to determine if they should ignore or >>> process the message. >>> >>>>> +#endif /* I3C_INTERNAL_H */ >>>>> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c >>>>> new file mode 100644 >>>>> index 000000000000..1c85abac08d5 >>>>> --- /dev/null >>>>> +++ b/drivers/i3c/master.c >>>>> @@ -0,0 +1,1433 @@ >>>>> +// SPDX-License-Identifier: GPL-2.0 >>>>> +/* >>>>> + * Copyright (C) 2017 Cadence Design Systems Inc. >>>>> + * >>>>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> >>>>> + */ >>>>> + >>>>> +#include <linux/slab.h> >>>>> + >>>>> +#include "internals.h" >>>>> + >>>>> +/** >>>>> + * i3c_master_entdaa_locked() - start a DAA (Dynamic Address Assignment) >>>>> + * procedure >>>>> + * @master: master used to send frames on the bus >>>>> + * >>>>> + * Send a ENTDAA CCC command to start a DAA procedure. >>>>> + * >>>>> + * Note that this function only sends the ENTDAA CCC command, all the logic >>>>> + * behind dynamic address assignment has to be handled in the I3C master >>>>> + * driver. >>>>> + * >>>>> + * This function must be called with the bus lock held in write mode. >>>>> + * >>>>> + * Return: 0 in case of success, a negative error code otherwise. >>>>> + */ >>>>> +int i3c_master_entdaa_locked(struct i3c_master_controller *master) >>>>> +{ >>>>> + struct i3c_ccc_cmd_dest dest = { }; >>>>> + struct i3c_ccc_cmd cmd = { }; >>>>> + int ret; >>>>> + >>>>> + dest.addr = I3C_BROADCAST_ADDR; >>>>> + cmd.dests = &dest; >>>>> + cmd.ndests = 1; >>>>> + cmd.rnw = false; >>>>> + cmd.id = I3C_CCC_ENTDAA; >>>>> + >>>>> + ret = i3c_master_send_ccc_cmd_locked(master, &cmd); >>>>> + if (ret) >>>>> + return ret; >>>>> + >>>>> + return 0; >>>>> +} >>>>> +EXPORT_SYMBOL_GPL(i3c_master_entdaa_locked); >>>> can you explain the process? >>> Not sure what you mean. The ENTDAA is just a CCC command that is used >>> to trigger a DAA procedure. What the master controller does when it >>> sends such a command is likely to be controller dependent, and it might >>> even be possible that you don't need to call this function in your >>> controller driver to trigger a DAA. If you want more details about the >>> bus initialization steps and how the ENTDAA CCC command fits into it I >>> recommend reading section "5.1.4 Bus Initialization and Dynamic Address >>> Assignment Mode" >>> >>>> the command is only execute once, what if >>>> there is more devices on the bus? >>> Again, I'm not sure what you mean. The ENTDAA command is sent every >>> time a controller wants to discover new devices on the bus, that can be >>> when initializing the bus, after a Hot Join event or simply triggered >>> by the user (the last case is not supported yet though). >>> >>> Now, if you're interested in what happens after an ENTDAA CCC is sent, >>> the controller will keep sending RepeatedStart until there's no more >>> devices acking the request. You can have a look at "B.3 Error Types in >>> Dynamic Address Arbitration" for more details. >> My understanding is this command shall be executed once, this mean that only one >> slave will assign the dynamic address (cmd.ndests = 1) and not trigger the whole >> process of DAA. > No, that's not what happens. The master controller is supposed to > continue until no one replies with an Ack on the bus, and by continue I > don't mean resend an ENTDAA, but issue a RepeatedStart followed by the > broadcast address (0x7e). I am sorry, you have point here. I misunderstood that the cmd.ndests = 1 is for broadcast commands. >> Either important is the SETDASA for declared I3C devices. So the DAA process >> should start by send an SETDASA and them ENTDAA CCC command. > My understanding was that SETDASA was not mandatory, and was only useful > when one wants to assign a specific dynamic address to a slave that has > a static address (which is again not mandatory). > I've tested it, and even devices with a static address participate to > the DAA procedure if they've not been assigned a dynamic address yet, > so I don't see the need for this SETDASA step if you don't need to > assign a particular dynamic address to the device. > > Could you tell me why you think SETDASA is required? Yes, you are right... But in my opinion it is required as it does part of DAA process. >>>>> +static u32 i3c_master_i2c_functionalities(struct i2c_adapter *adap) >>>>> +{ >>>>> + return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR; >>>>> +} >>>> Is I2C_FUNC_10BIT_ADDR allowed ? >>> According to "Table 4 I 2 C Features Allowed in I3C Slaves", yes (at >>> least that my understanding). And the Cadence controller supports it. >> The table say the oposite. The I2C extended address feature is not used on I3C >> bus, thus this feature shall be disable. > Actually, I was wrong when initially mentioning this table: it's about > I2C features supported on I3C slaves, so not really what we're looking > for. Here, we're wondering if I2C-only devices can have 10-bit > addresses. The Cadence controller supports that, so there's probably > nothing preventing use of 10-bit addresses for I2C transfers, but maybe > not all I3C master controllers support that, so we should probably > let the I3C master driver implement this method. The spec says that is "not used" so it will not interface with I3C bus. >> BTW it is optional on I2C devices. > You mean I2C controllers? When an I2C device has a 10bit address, the > controller has to support this mode to communicate with the device, at > least that's my understanding. But we're digressing a bit. The > question is not whether I2C devices can optionally use a 10 bit > address, but whether I3C master controller can support this mode for > I2C transfers to I2C-only devices. By the i2c spec the 10-bit address is optional, however the 7-bit address is mandatory. >>> >>>> > diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig >>>>> new file mode 100644 >>>>> index 000000000000..e69de29bb2d1 >>>>> diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile >>>>> new file mode 100644 >>>>> index 000000000000..e69de29bb2d1 >>>>> diff --git a/include/linux/i3c/ccc.h b/include/linux/i3c/ccc.h >>>>> new file mode 100644 >>>>> index 000000000000..ff3e1a3e2c4c >>>>> --- /dev/null >>>>> +++ b/include/linux/i3c/ccc.h >>>>> @@ -0,0 +1,380 @@ >>>>> +/* SPDX-License-Identifier: GPL-2.0 */ >>>>> +/* >>>>> + * Copyright (C) 2017 Cadence Design Systems Inc. >>>>> + * >>>>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> >>>>> + */ >>>>> + >>>>> + >>>>> +/** >>>>> + * enum i3c_ccc_test_mode - enum listing all available test modes >>>>> + * >>>>> + * @I3C_CCC_EXIT_TEST_MODE: exit test mode >>>>> + * @I3C_CCC_VENDOR_TEST_MODE: enter vendor test mode >>>>> + */ >>>>> +enum i3c_ccc_test_mode { >>>>> + I3C_CCC_EXIT_TEST_MODE, >>>>> + I3C_CCC_VENDOR_TEST_MODE, >>>>> +}; >>>>> + >>>>> +/** >>>>> + * struct i3c_ccc_enttm - payload passed to ENTTM CCC >>>>> + * >>>>> + * @mode: one of the &enum i3c_ccc_test_mode modes >>>>> + * >>>>> + * Information passed to the ENTTM CCC to instruct an I3C device to enter a >>>>> + * specific test mode. >>>>> + */ >>>>> +struct i3c_ccc_enttm { >>>>> + u8 mode; >>>>> +} __packed; >>>>> + >>>>> +/** >>>>> + * struct i3c_ccc_setda - payload passed to ENTTM CCC >>>>> + * >>>>> + * @mode: one of the &enum i3c_ccc_test_mode modes >>>>> + * >>>>> + * Information passed to the ENTTM CCC to instruct an I3C device to enter a >>>>> + * specific test mode. >>>>> + */ >>>>> +struct i3c_ccc_setda { >>>>> + u8 addr; >>>>> +} __packed; >>>> what do you mean with struct? Maybe setdasa? if so, what is the addr? >> Do you have the function to use this structure? Because one command use the >> static address and the other use the dynamic address. >> >>>> >>>> > +/** >>>>> + * enum i3c_sdr_max_data_rate - max data rate values for private SDR transfers >>>>> + */ >>>>> +enum i3c_sdr_max_data_rate { >>>>> + I3C_SDR_DR_FSCL_MAX, >>>>> + I3C_SDR_DR_FSCL_8MHZ, >>>>> + I3C_SDR_DR_FSCL_6MHZ, >>>>> + I3C_SDR_DR_FSCL_4MHZ, >>>>> + I3C_SDR_DR_FSCL_2MHZ, >>>>> +}; >>>> Can you change the names to: >>>> >>>> I3C_SDR0_FSCL_MAX, >>>> I3C_SDR1_FSCL_8MHZ, >>>> I3C_SDR2_FSCL_6MHZ, >>>> I3C_SDR3_FSCL_4MHZ, >>>> I3C_SDR4_FSCL_2MHZ, >>>> >>>> thus the data rate isn't repeated. >>> What's the problem with the name I use? Moreover, I see no mention to >>> the SDR0,1,2,3,4 modes in the public spec. >> When you get the GETMXDS information, the maxWr and maxRd came from 0 to 4, so >> in my opinion I think in this way is easier to have a relationship. > It's an emum, and there's no mention of the SDRX modes you're using > here in the I3C spec. I guess it's named this way in your I3C > controller datasheet. I personally don't see a good reason to add SDRX > in the name, but if you insist... The idea is to say that it is SDR mode and the value that GETMXDS command return. It is what makes sense to me. >>>>> + >>>>> +#endif /* I3C_CCC_H */ >>>>> diff --git a/include/linux/i3c/device.h b/include/linux/i3c/device.h >>>>> new file mode 100644 >>>>> index 000000000000..83958d3a02e2 >>>>> --- /dev/null >>>>> +++ b/include/linux/i3c/device.h >>>>> @@ -0,0 +1,321 @@ >>>>> +/* SPDX-License-Identifier: GPL-2.0 */ >>>>> +/* >>>>> + * Copyright (C) 2017 Cadence Design Systems Inc. >>>>> + * >>>>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> >>>>> + */ >>>>> + >>>>> +#ifndef I3C_DEV_H >>>>> +#define I3C_DEV_H >>>>> + >>>>> +#include <linux/device.h> >>>>> +#include <linux/i2c.h> >>>>> +#include <linux/mod_devicetable.h> >>>>> +#include <linux/module.h> >>>>> + >>>>> +/** >>>>> + * enum i3c_hdr_mode - HDR mode ids >>>>> + * @I3C_HDR_DDR: DDR mode >>>>> + * @I3C_HDR_TSP: TSP mode >>>>> + * @I3C_HDR_TSL: TSL mode >>>>> + */ >>>>> +enum i3c_hdr_mode { >>>>> + I3C_HDR_DDR, >>>>> + I3C_HDR_TSP, >>>>> + I3C_HDR_TSL, >>>>> +}; >>>>> + >>>>> +/** >>>>> + * struct i3c_hdr_cmd - I3C HDR command >>>>> + * @mode: HDR mode selected for this command >>>>> + * @code: command opcode >>>>> + * @addr: I3C dynamic address >>>>> + * @ndatawords: number of data words (a word is 16bits wide) >>>>> + * @data: input/output buffer >>>>> + */ >>>>> +struct i3c_hdr_cmd { >>>>> + enum i3c_hdr_mode mode; >>>>> + u8 code; >>>>> + u8 addr; >>>>> + int ndatawords; >>>>> + union { >>>>> + u16 *in; >>>>> + const u16 *out; >>>>> + } data; >>>>> +}; >> Please mention that the @code is what will define if the transfer is read or write. > Well, I think it's pretty clear in the definition you'll find in the > ccc.h file, but I can add a comment here too if you like. I don't find it in ccc.h file. Anyway is not good to put this definition there because is not related. >>>>> + >>>>> +/* Private SDR read transfer */ >>>>> +#define I3C_PRIV_XFER_READ BIT(0) >>>>> +/* >>>>> + * Instruct the controller to issue a STOP after a specific transfer instead >>>>> + * of a REPEATED START. >>>>> + */ >>>>> +#define I3C_PRIV_XFER_STOP BIT(1) >>>>> + >>>>> +/** >>>>> + * struct i3c_priv_xfer - I3C SDR private transfer >>>>> + * @addr: I3C dynamic address >>>>> + * @len: transfer length in bytes of the transfer >>>>> + * @flags: combination of I3C_PRIV_XFER_xxx flags >>>>> + * @data: input/output buffer >>>>> + */ >>>>> +struct i3c_priv_xfer { >>>>> + u8 addr; >>>>> + u16 len; >>>>> + u32 flags; >>>>> + struct { >>>>> + void *in; >>>>> + const void *out; >>>>> + } data; >>>>> +}; >>>> Same as above, i3c_sdr_max_data_rate to change the bus scl. >>> If I'm understanding the spec correctly, that's not something you want >>> to change on a per-transfer basis. The constraint is on the device >>> itself and should IMO not be part of the i3c_priv_xfer struct. >> As mention before this is important. >> You can do the same as for struct i3c_hdr_cmd and add a enum i3c_sdr_max_data_rate. >> >> The @flag only have 2 bits of load, is the rest opened? > If by open you mean that we can add more flags if we need to, then yes. > >>> >>>> > + >>>>> +/** >>>>> + * enum i3c_dcr - I3C DCR values >>>>> + * @I3C_DCR_GENERIC_DEVICE: generic I3C device >>>>> + */ >>>>> +enum i3c_dcr { >>>>> + I3C_DCR_GENERIC_DEVICE = 0, >>>>> +}; >>>>> + >>>>> +#define I3C_PID_MANUF_ID(pid) (((pid) & GENMASK_ULL(47, 33)) >> 33) >>>>> +#define I3C_PID_RND_LOWER_32BITS(pid) (!!((pid) & BIT_ULL(32))) >>>>> +#define I3C_PID_RND_VAL(pid) ((pid) & GENMASK_ULL(31, 0)) >>>>> +#define I3C_PID_PART_ID(pid) (((pid) & GENMASK_ULL(31, 16)) >> 16) >>>>> +#define I3C_PID_INSTANCE_ID(pid) (((pid) & GENMASK_ULL(15, 12)) >> 12) >>>>> +#define I3C_PID_EXTRA_INFO(pid) ((pid) & GENMASK_ULL(11, 0)) >>>>> + >>>>> +#define I3C_BCR_DEVICE_ROLE(bcr) ((bcr) & GENMASK(7, 6)) >>>>> +#define I3C_BCR_I3C_SLAVE (0 << 6) >>>>> +#define I3C_BCR_I3C_MASTER (1 << 6) >>>>> +#define I3C_BCR_HDR_CAP BIT(5) >>>>> +#define I3C_BCR_BRIDGE BIT(4) >>>>> +#define I3C_BCR_OFFLINE_CAP BIT(3) >>>>> +#define I3C_BCR_IBI_PAYLOAD BIT(2) >>>>> +#define I3C_BCR_IBI_REQ_CAP BIT(1) >>>>> +#define I3C_BCR_MAX_DATA_SPEED_LIM BIT(0) >>>>> + >>>>> +/** >>>>> + * struct i3c_device_info - I3C device information >>>>> + * @pid: Provisional ID >>>>> + * @bcr: Bus Characteristic Register >>>>> + * @dcr: Device Characteristic Register >>>>> + * @static_addr: static/I2C address >>>>> + * @dyn_addr: dynamic address >>>>> + * @hdr_cap: supported HDR modes >>>>> + * @max_read_ds: max read speed information >>>>> + * @max_write_ds: max write speed information >>>>> + * @max_ibi_len: max IBI payload length >>>>> + * @max_read_turnaround: max read turn-around time in micro-seconds >>>>> + * @max_read_len: max private SDR read length in bytes >>>>> + * @max_write_len: max private SDR write length in bytes >>>>> + * >>>>> + * These are all basic information that should be advertised by an I3C device. >>>>> + * Some of them are optional depending on the device type and device >>>>> + * capabilities. >>>>> + * For each I3C slave attached to a master with >>>>> + * i3c_master_add_i3c_dev_locked(), the core will send the relevant CCC command >>>>> + * to retrieve these data. >>>>> + */ >>>>> +struct i3c_device_info { >>>>> + u64 pid; >>>>> + u8 bcr; >>>>> + u8 dcr; >>>>> + u8 static_addr; >>>>> + u8 dyn_addr; >>>>> + u8 hdr_cap; >>>>> + u8 max_read_ds; >>>>> + u8 max_write_ds; >>>>> + u8 max_ibi_len; >>>>> + u32 max_read_turnaround; >>>>> + u16 max_read_len; >>>>> + u16 max_write_len; >>>>> +}; >>>>> + >>>> is this information filled with data provided from CCC commands? >>> Yes, they are. >> Ok, them the intention is to do this on bus_init(), right? > Not only, it can be after a Hot-Join, or after the user has triggered a > new DAA. Anyway, these information are retrieved anytime you add a > device with i3c_master_add_i3c_dev_locked(), and the core uses CCC > commands to do that. > >>>>> + >>>>> +/** >>>>> + * struct i3c_master_controller_ops - I3C master methods >>>>> + * @bus_init: hook responsible for the I3C bus initialization. This >>>>> + * initialization should follow the steps described in the I3C >>>>> + * specification. This hook is called with the bus lock held in >>>>> + * write mode, which means all _locked() helpers can safely be >>>>> + * called from there >>>>> + * @bus_cleanup: cleanup everything done in >>>>> + * &i3c_master_controller_ops->bus_init(). This function is >>>>> + * optional and should only be implemented if >>>>> + * &i3c_master_controller_ops->bus_init() attached private data >>>>> + * to I3C/I2C devices. This hook is called with the bus lock >>>>> + * held in write mode, which means all _locked() helpers can >>>>> + * safely be called from there >>>>> + * @supports_ccc_cmd: should return true if the CCC command is supported, false >>>>> + * otherwise >>>>> + * @send_ccc_cmd: send a CCC command >>>>> + * @send_hdr_cmds: send one or several HDR commands. If there is more than one >>>>> + * command, they should ideally be sent in the same HDR >>>>> + * transaction >>>>> + * @priv_xfers: do one or several private I3C SDR transfers >>>>> + * @i2c_xfers: do one or several I2C transfers >>>>> + * @request_ibi: attach an IBI handler to an I3C device. This implies defining >>>>> + * an IBI handler and the constraints of the IBI (maximum payload >>>>> + * length and number of pre-allocated slots). >>>>> + * Some controllers support less IBI-capable devices than regular >>>>> + * devices, so this method might return -%EBUSY if there's no >>>>> + * more space for an extra IBI registration >>>>> + * @free_ibi: free an IBI previously requested with ->request_ibi(). The IBI >>>>> + * should have been disabled with ->disable_irq() prior to that >>>>> + * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has been called >>>>> + * prior to ->enable_ibi(). The controller should first enable >>>>> + * the IBI on the controller end (for example, unmask the hardware >>>>> + * IRQ) and then send the ENEC CCC command (with the IBI flag set) >>>>> + * to the I3C device >>>>> + * @disable_ibi: disable an IBI. First send the DISEC CCC command with the IBI >>>>> + * flag set and then deactivate the hardware IRQ on the >>>>> + * controller end >>>>> + * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI has been >>>>> + * processed by its handler. The IBI slot should be put back >>>>> + * in the IBI slot pool so that the controller can re-use it >>>>> + * for a future IBI >>>>> + * >>>>> + * One of the most important hooks in these ops is >>>>> + * &i3c_master_controller_ops->bus_init(). Here is a non-exhaustive list of >>>>> + * things that should be done in &i3c_master_controller_ops->bus_init(): >>>>> + * >>>>> + * 1) call i3c_master_set_info() with all information describing the master >>>>> + * 2) ask all slaves to drop their dynamic address by sending the RSTDAA CCC >>>>> + * with i3c_master_rstdaa_locked() >>>>> + * 3) ask all slaves to disable IBIs using i3c_master_disec_locked() >>>>> + * 4) start a DDA procedure by sending the ENTDAA CCC with >>>>> + * i3c_master_entdaa_locked(), or using the internal DAA logic provided by >>>>> + * your controller >>>> You mean SETDASA CCC command? >>> No, I really mean ENTDAA and DAA. By internal DAA logic I mean that >>> some controllers are probably automating the whole DAA procedure, while >>> others may let the SW control every step. >> My understanding is that i3c_master_entdaa_locked() will trigger the DAA process >> and DAA can be done by SETDASA, ENTDAA and later after the bus initialization >> with SETNEWDA. > No. Only ENTDAA can trigger a DAA procedure. SETDASA is here to assign > a single dynamic address to a device that already has a static address > but no dynamic address yet, and SETNEWDA is here to modify the dynamic > address of a device that already has one. >> I think the DAA process should be more generic, right now is only made through >> the ENTDAA command with (cmd.ndests = 1). >> I mean, shouldn't this be made by the core? First doing DAA for the devices >> declared and them try do discover the rest of devices on the bus. > Can you detail a bit more? If the only part you're complaining about is > pre-assignment of dynamic addresses with SETDASA when a device is > declared in the DT with a reg and dynamic-address property, then yes, I > think I can provide an helper for that. But this helper would still have > to be called from the master controller driver (from ->bus_init() or > after a Hot-Join). > > Now, if the question is, is there a way we can automate things even more > and completely implement DAA from the core? I doubt it, because the way > the core will trigger DAA, expose discovered devices or allow you to > declare manually assigned addresses is likely to be > controller-dependent. Please refer to figure 90 of public specification. As you can see the DAA process should start with SETDASA command. With the current flow of this patch the DAA process is limited to ENTDAA command only. > When I designed the framework I took the decision to base my work on the > spec rather than focusing on the I3C master controller I had to support > (Cadence). This is the reason I decided to keep the interface as simple > as possible at the risk of encouraging code-duplication (at first) > rather than coming up with an interface that is designed with a single > controller in mind and having to break things every time a new > controller comes out. > > Thank you for you comments, but I'd like to know if some of my design > choices are blocking you to support your controller. What I've seen so > far is a collection of things that might be relevant to fix (though > most of them are subject to interpretation and/or a matter of taste), > but nothing that should really block you. > > Can you clarify that, and maybe come back with a list of things that you > think are preventing you from properly supporting the Synopsys > controller? > > Thanks, > > Boris As you can check from my comments my concerns are about the i3c specification without the controller in mind. Best regards, Vitor Soares -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Boris and Vitor Find below my comment on DAA procedure. > -----Original Message----- > From: Vitor Soares [mailto:Vitor.Soares@synopsys.com] > Sent: Tuesday, February 27, 2018 5:04 PM > To: Boris Brezillon <boris.brezillon@bootlin.com>; Vitor Soares > <Vitor.Soares@synopsys.com> > Cc: Boris Brezillon <boris.brezillon@free-electrons.com>; Wolfram Sang > <wsa@the-dreams.de>; linux-i2c@vger.kernel.org; Jonathan Corbet > <corbet@lwn.net>; linux-doc@vger.kernel.org; Greg Kroah-Hartman > <gregkh@linuxfoundation.org>; Arnd Bergmann <arnd@arndb.de>; > Przemyslaw Sroka <psroka@cadence.com>; Arkadiusz Golec > <agolec@cadence.com>; Alan Douglas <adouglas@cadence.com>; Bartosz > Folta <bfolta@cadence.com>; Damian Kos <dkos@cadence.com>; Alicja > Jurasik-Urbaniak <alicja@cadence.com>; Cyprian Wronka > <cwronka@cadence.com>; Suresh Punnoose <sureshp@cadence.com>; > Thomas Petazzoni <thomas.petazzoni@free-electrons.com>; Nishanth > Menon <nm@ti.com>; Rob Herring <robh+dt@kernel.org>; Pawel Moll > <pawel.moll@arm.com>; Mark Rutland <mark.rutland@arm.com>; Ian > Campbell <ijc+devicetree@hellion.org.uk>; Kumar Gala > <galak@codeaurora.org>; devicetree@vger.kernel.org; linux- > kernel@vger.kernel.org; Geert Uytterhoeven <geert@linux-m68k.org>; Linus > Walleij <linus.walleij@linaro.org> > Subject: Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure > > EXTERNAL MAIL > > > Hi Boris > > > Às 8:36 PM de 2/26/2018, Boris Brezillon escreveu: > > Hi Vitor, > > > > On Mon, 26 Feb 2018 18:58:15 +0000 > > Vitor Soares <Vitor.Soares@synopsys.com> wrote: > > > >>>>> +/** > >>>>> + * i3c_device_do_priv_xfers() - do I3C SDR private transfers directed > to a > >>>>> + * specific device > >>>>> + * > >>>>> + * @dev: device with which the transfers should be done > >>>>> + * @xfers: array of transfers > >>>>> + * @nxfers: number of transfers > >>>>> + * > >>>>> + * Initiate one or several private SDR transfers with @dev. > >>>>> + * > >>>>> + * This function can sleep and thus cannot be called in atomic > context. > >>>>> + * > >>>>> + * Return: 0 in case of success, a negative error core otherwise. > >>>>> + */ > >>>>> +int i3c_device_do_priv_xfers(struct i3c_device *dev, > >>>>> + struct i3c_priv_xfer *xfers, > >>>>> + int nxfers) > >>>>> +{ > >>>>> + struct i3c_master_controller *master; > >>>>> + int i, ret; > >>>>> + > >>>>> + master = i3c_device_get_master(dev); > >>>>> + if (!master) > >>>>> + return -EINVAL; > >>>>> + > >>>>> + i3c_bus_normaluse_lock(master->bus); > >>>>> + for (i = 0; i < nxfers; i++) > >>>>> + xfers[i].addr = dev->info.dyn_addr; > >>>>> + > >>>>> + ret = i3c_master_do_priv_xfers_locked(master, xfers, > nxfers); > >>>>> + i3c_bus_normaluse_unlock(master->bus); > >>>>> + > >>>>> + return ret; > >>>>> +} > >>>>> +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers); > >>>> The controller should know the speed mode for each xfer. The SDR0 > >>>> mode is used by default but if any device have read or write speed > >>>> limitations the controller can use SDRx. > >>> I might be wrong, but that's not my understanding of the spec. A > >>> device can express a speed limitation for SDR priv transfers, but > >>> this limitation applies to all SDR transfers. > >>> > >>> The speed R/W speed limitation is encoded in the device object, so, > >>> if the controller has to configure that on a per-transfer basis, one > >>> solution would be to pass the device to the ->priv_xfers(). > >> The speed R/W limitation is only for private transfers. Also the > >> device can have a limitation to write and not for read data. > >> This information is obtained with the command GETMXDS which returns > >> the Maximum Sustained Data Rate for non-CCC messages. > > And that's exactly what I expose in i3c_device_info, which is embedded > > in i3c_device, so you should have all the information you need to > > determine the speed in the controller driver if ->priv_xfer() is > > passed the device attached to those transfers. Would that be okay if > > we pass an i3c_device object to ->priv_xfers()? > > If you pass the i3c_device to ->priv_xfer(), then you won't need the address > too. > > Maybe someone else can give other point of view. > > >>> > >>>> This could be also applied to i2c transfers. > >>> Not really. The max SCL frequency is something that applies to the > >>> whole bus, because all I2C devices have to decode the address when > >>> messages are sent on the bus to determine if they should ignore or > >>> process the message. > >>> > >>>>> +#endif /* I3C_INTERNAL_H */ > >>>>> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c new file > >>>>> mode 100644 index 000000000000..1c85abac08d5 > >>>>> --- /dev/null > >>>>> +++ b/drivers/i3c/master.c > >>>>> @@ -0,0 +1,1433 @@ > >>>>> +// SPDX-License-Identifier: GPL-2.0 > >>>>> +/* > >>>>> + * Copyright (C) 2017 Cadence Design Systems Inc. > >>>>> + * > >>>>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> > >>>>> + */ > >>>>> + > >>>>> +#include <linux/slab.h> > >>>>> + > >>>>> +#include "internals.h" > >>>>> + > >>>>> +/** > >>>>> + * i3c_master_entdaa_locked() - start a DAA (Dynamic Address > Assignment) > >>>>> + * procedure > >>>>> + * @master: master used to send frames on the bus > >>>>> + * > >>>>> + * Send a ENTDAA CCC command to start a DAA procedure. > >>>>> + * > >>>>> + * Note that this function only sends the ENTDAA CCC command, all > >>>>> +the logic > >>>>> + * behind dynamic address assignment has to be handled in the I3C > >>>>> +master > >>>>> + * driver. > >>>>> + * > >>>>> + * This function must be called with the bus lock held in write > mode. > >>>>> + * > >>>>> + * Return: 0 in case of success, a negative error code otherwise. > >>>>> + */ > >>>>> +int i3c_master_entdaa_locked(struct i3c_master_controller > >>>>> +*master) { > >>>>> + struct i3c_ccc_cmd_dest dest = { }; > >>>>> + struct i3c_ccc_cmd cmd = { }; > >>>>> + int ret; > >>>>> + > >>>>> + dest.addr = I3C_BROADCAST_ADDR; > >>>>> + cmd.dests = &dest; > >>>>> + cmd.ndests = 1; > >>>>> + cmd.rnw = false; > >>>>> + cmd.id = I3C_CCC_ENTDAA; > >>>>> + > >>>>> + ret = i3c_master_send_ccc_cmd_locked(master, &cmd); > >>>>> + if (ret) > >>>>> + return ret; > >>>>> + > >>>>> + return 0; > >>>>> +} > >>>>> +EXPORT_SYMBOL_GPL(i3c_master_entdaa_locked); > >>>> can you explain the process? > >>> Not sure what you mean. The ENTDAA is just a CCC command that is > >>> used to trigger a DAA procedure. What the master controller does > >>> when it sends such a command is likely to be controller dependent, > >>> and it might even be possible that you don't need to call this > >>> function in your controller driver to trigger a DAA. If you want > >>> more details about the bus initialization steps and how the ENTDAA > >>> CCC command fits into it I recommend reading section "5.1.4 Bus > >>> Initialization and Dynamic Address Assignment Mode" > >>> > >>>> the command is only execute once, what if there is more devices on > >>>> the bus? > >>> Again, I'm not sure what you mean. The ENTDAA command is sent > every > >>> time a controller wants to discover new devices on the bus, that can > >>> be when initializing the bus, after a Hot Join event or simply > >>> triggered by the user (the last case is not supported yet though). > >>> > >>> Now, if you're interested in what happens after an ENTDAA CCC is > >>> sent, the controller will keep sending RepeatedStart until there's > >>> no more devices acking the request. You can have a look at "B.3 > >>> Error Types in Dynamic Address Arbitration" for more details. > >> My understanding is this command shall be executed once, this mean > >> that only one slave will assign the dynamic address (cmd.ndests = 1) > >> and not trigger the whole process of DAA. > > No, that's not what happens. The master controller is supposed to > > continue until no one replies with an Ack on the bus, and by continue > > I don't mean resend an ENTDAA, but issue a RepeatedStart followed by > > the broadcast address (0x7e). > > I am sorry, you have point here. I misunderstood that the cmd.ndests = 1 is > for broadcast commands. > > >> Either important is the SETDASA for declared I3C devices. So the DAA > >> process should start by send an SETDASA and them ENTDAA CCC > command. > > My understanding was that SETDASA was not mandatory, and was only > > useful when one wants to assign a specific dynamic address to a slave > > that has a static address (which is again not mandatory). > > I've tested it, and even devices with a static address participate to > > the DAA procedure if they've not been assigned a dynamic address yet, > > so I don't see the need for this SETDASA step if you don't need to > > assign a particular dynamic address to the device. > > > > Could you tell me why you think SETDASA is required? > > Yes, you are right... But in my opinion it is required as it does part of DAA > process. SETDASA is simply faster than ENTDAA, but only if there is no need to collect BCR/DCR/PID of such devices. I think most applications would like to have them as an status information so after all ENTDAA can be regarded as an generic approach (unless I'm mistaken). > > >>>>> +static u32 i3c_master_i2c_functionalities(struct i2c_adapter > >>>>> +*adap) { > >>>>> + return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C | > I2C_FUNC_10BIT_ADDR; > >>>>> +} > >>>> Is I2C_FUNC_10BIT_ADDR allowed ? > >>> According to "Table 4 I 2 C Features Allowed in I3C Slaves", yes (at > >>> least that my understanding). And the Cadence controller supports it. > >> The table say the oposite. The I2C extended address feature is not > >> used on I3C bus, thus this feature shall be disable. > > Actually, I was wrong when initially mentioning this table: it's about > > I2C features supported on I3C slaves, so not really what we're looking > > for. Here, we're wondering if I2C-only devices can have 10-bit > > addresses. The Cadence controller supports that, so there's probably > > nothing preventing use of 10-bit addresses for I2C transfers, but > > maybe not all I3C master controllers support that, so we should > > probably let the I3C master driver implement this method. > > The spec says that is "not used" so it will not interface with I3C bus. > > >> BTW it is optional on I2C devices. > > You mean I2C controllers? When an I2C device has a 10bit address, the > > controller has to support this mode to communicate with the device, at > > least that's my understanding. But we're digressing a bit. The > > question is not whether I2C devices can optionally use a 10 bit > > address, but whether I3C master controller can support this mode for > > I2C transfers to I2C-only devices. > > By the i2c spec the 10-bit address is optional, however the 7-bit address is > mandatory. > > >>> > >>>> > diff --git a/drivers/i3c/master/Kconfig > >>>> b/drivers/i3c/master/Kconfig > >>>>> new file mode 100644 > >>>>> index 000000000000..e69de29bb2d1 > >>>>> diff --git a/drivers/i3c/master/Makefile > >>>>> b/drivers/i3c/master/Makefile new file mode 100644 index > >>>>> 000000000000..e69de29bb2d1 diff --git a/include/linux/i3c/ccc.h > >>>>> b/include/linux/i3c/ccc.h new file mode 100644 index > >>>>> 000000000000..ff3e1a3e2c4c > >>>>> --- /dev/null > >>>>> +++ b/include/linux/i3c/ccc.h > >>>>> @@ -0,0 +1,380 @@ > >>>>> +/* SPDX-License-Identifier: GPL-2.0 */ > >>>>> +/* > >>>>> + * Copyright (C) 2017 Cadence Design Systems Inc. > >>>>> + * > >>>>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> > >>>>> + */ > >>>>> + > >>>>> + > >>>>> +/** > >>>>> + * enum i3c_ccc_test_mode - enum listing all available test modes > >>>>> + * > >>>>> + * @I3C_CCC_EXIT_TEST_MODE: exit test mode > >>>>> + * @I3C_CCC_VENDOR_TEST_MODE: enter vendor test mode */ > enum > >>>>> +i3c_ccc_test_mode { > >>>>> + I3C_CCC_EXIT_TEST_MODE, > >>>>> + I3C_CCC_VENDOR_TEST_MODE, > >>>>> +}; > >>>>> + > >>>>> +/** > >>>>> + * struct i3c_ccc_enttm - payload passed to ENTTM CCC > >>>>> + * > >>>>> + * @mode: one of the &enum i3c_ccc_test_mode modes > >>>>> + * > >>>>> + * Information passed to the ENTTM CCC to instruct an I3C device > >>>>> +to enter a > >>>>> + * specific test mode. > >>>>> + */ > >>>>> +struct i3c_ccc_enttm { > >>>>> + u8 mode; > >>>>> +} __packed; > >>>>> + > >>>>> +/** > >>>>> + * struct i3c_ccc_setda - payload passed to ENTTM CCC > >>>>> + * > >>>>> + * @mode: one of the &enum i3c_ccc_test_mode modes > >>>>> + * > >>>>> + * Information passed to the ENTTM CCC to instruct an I3C device > >>>>> +to enter a > >>>>> + * specific test mode. > >>>>> + */ > >>>>> +struct i3c_ccc_setda { > >>>>> + u8 addr; > >>>>> +} __packed; > >>>> what do you mean with struct? Maybe setdasa? if so, what is the > addr? > >> Do you have the function to use this structure? Because one command > >> use the static address and the other use the dynamic address. > >> > >>>> > >>>> > +/** > >>>>> + * enum i3c_sdr_max_data_rate - max data rate values for private > >>>>> +SDR transfers */ enum i3c_sdr_max_data_rate { > >>>>> + I3C_SDR_DR_FSCL_MAX, > >>>>> + I3C_SDR_DR_FSCL_8MHZ, > >>>>> + I3C_SDR_DR_FSCL_6MHZ, > >>>>> + I3C_SDR_DR_FSCL_4MHZ, > >>>>> + I3C_SDR_DR_FSCL_2MHZ, > >>>>> +}; > >>>> Can you change the names to: > >>>> > >>>> I3C_SDR0_FSCL_MAX, > >>>> I3C_SDR1_FSCL_8MHZ, > >>>> I3C_SDR2_FSCL_6MHZ, > >>>> I3C_SDR3_FSCL_4MHZ, > >>>> I3C_SDR4_FSCL_2MHZ, > >>>> > >>>> thus the data rate isn't repeated. > >>> What's the problem with the name I use? Moreover, I see no mention > >>> to the SDR0,1,2,3,4 modes in the public spec. > >> When you get the GETMXDS information, the maxWr and maxRd came > from 0 > >> to 4, so in my opinion I think in this way is easier to have a relationship. > > It's an emum, and there's no mention of the SDRX modes you're using > > here in the I3C spec. I guess it's named this way in your I3C > > controller datasheet. I personally don't see a good reason to add SDRX > > in the name, but if you insist... > > The idea is to say that it is SDR mode and the value that GETMXDS > command return. It is what makes sense to me. > > >>>>> + > >>>>> +#endif /* I3C_CCC_H */ > >>>>> diff --git a/include/linux/i3c/device.h > >>>>> b/include/linux/i3c/device.h new file mode 100644 index > >>>>> 000000000000..83958d3a02e2 > >>>>> --- /dev/null > >>>>> +++ b/include/linux/i3c/device.h > >>>>> @@ -0,0 +1,321 @@ > >>>>> +/* SPDX-License-Identifier: GPL-2.0 */ > >>>>> +/* > >>>>> + * Copyright (C) 2017 Cadence Design Systems Inc. > >>>>> + * > >>>>> + * Author: Boris Brezillon<boris.brezillon@free-electrons.com> > >>>>> + */ > >>>>> + > >>>>> +#ifndef I3C_DEV_H > >>>>> +#define I3C_DEV_H > >>>>> + > >>>>> +#include <linux/device.h> > >>>>> +#include <linux/i2c.h> > >>>>> +#include <linux/mod_devicetable.h> #include <linux/module.h> > >>>>> + > >>>>> +/** > >>>>> + * enum i3c_hdr_mode - HDR mode ids > >>>>> + * @I3C_HDR_DDR: DDR mode > >>>>> + * @I3C_HDR_TSP: TSP mode > >>>>> + * @I3C_HDR_TSL: TSL mode > >>>>> + */ > >>>>> +enum i3c_hdr_mode { > >>>>> + I3C_HDR_DDR, > >>>>> + I3C_HDR_TSP, > >>>>> + I3C_HDR_TSL, > >>>>> +}; > >>>>> + > >>>>> +/** > >>>>> + * struct i3c_hdr_cmd - I3C HDR command > >>>>> + * @mode: HDR mode selected for this command > >>>>> + * @code: command opcode > >>>>> + * @addr: I3C dynamic address > >>>>> + * @ndatawords: number of data words (a word is 16bits wide) > >>>>> + * @data: input/output buffer > >>>>> + */ > >>>>> +struct i3c_hdr_cmd { > >>>>> + enum i3c_hdr_mode mode; > >>>>> + u8 code; > >>>>> + u8 addr; > >>>>> + int ndatawords; > >>>>> + union { > >>>>> + u16 *in; > >>>>> + const u16 *out; > >>>>> + } data; > >>>>> +}; > >> Please mention that the @code is what will define if the transfer is read > or write. > > Well, I think it's pretty clear in the definition you'll find in the > > ccc.h file, but I can add a comment here too if you like. > > I don't find it in ccc.h file. Anyway is not good to put this definition there > because is not related. > > >>>>> + > >>>>> +/* Private SDR read transfer */ > >>>>> +#define I3C_PRIV_XFER_READ BIT(0) > >>>>> +/* > >>>>> + * Instruct the controller to issue a STOP after a specific > >>>>> +transfer instead > >>>>> + * of a REPEATED START. > >>>>> + */ > >>>>> +#define I3C_PRIV_XFER_STOP BIT(1) > >>>>> + > >>>>> +/** > >>>>> + * struct i3c_priv_xfer - I3C SDR private transfer > >>>>> + * @addr: I3C dynamic address > >>>>> + * @len: transfer length in bytes of the transfer > >>>>> + * @flags: combination of I3C_PRIV_XFER_xxx flags > >>>>> + * @data: input/output buffer > >>>>> + */ > >>>>> +struct i3c_priv_xfer { > >>>>> + u8 addr; > >>>>> + u16 len; > >>>>> + u32 flags; > >>>>> + struct { > >>>>> + void *in; > >>>>> + const void *out; > >>>>> + } data; > >>>>> +}; > >>>> Same as above, i3c_sdr_max_data_rate to change the bus scl. > >>> If I'm understanding the spec correctly, that's not something you > >>> want to change on a per-transfer basis. The constraint is on the > >>> device itself and should IMO not be part of the i3c_priv_xfer struct. > >> As mention before this is important. > >> You can do the same as for struct i3c_hdr_cmd and add a enum > i3c_sdr_max_data_rate. > >> > >> The @flag only have 2 bits of load, is the rest opened? > > If by open you mean that we can add more flags if we need to, then yes. > > > >>> > >>>> > + > >>>>> +/** > >>>>> + * enum i3c_dcr - I3C DCR values > >>>>> + * @I3C_DCR_GENERIC_DEVICE: generic I3C device */ enum i3c_dcr > { > >>>>> + I3C_DCR_GENERIC_DEVICE = 0, > >>>>> +}; > >>>>> + > >>>>> +#define I3C_PID_MANUF_ID(pid) (((pid) & > GENMASK_ULL(47, 33)) >> 33) > >>>>> +#define I3C_PID_RND_LOWER_32BITS(pid) (!!((pid) & > BIT_ULL(32))) > >>>>> +#define I3C_PID_RND_VAL(pid) ((pid) & GENMASK_ULL(31, > 0)) > >>>>> +#define I3C_PID_PART_ID(pid) (((pid) & GENMASK_ULL(31, > 16)) >> 16) > >>>>> +#define I3C_PID_INSTANCE_ID(pid) (((pid) & GENMASK_ULL(15, > 12)) >> 12) > >>>>> +#define I3C_PID_EXTRA_INFO(pid) ((pid) & > GENMASK_ULL(11, 0)) > >>>>> + > >>>>> +#define I3C_BCR_DEVICE_ROLE(bcr) ((bcr) & GENMASK(7, 6)) > >>>>> +#define I3C_BCR_I3C_SLAVE (0 << 6) > >>>>> +#define I3C_BCR_I3C_MASTER (1 << 6) > >>>>> +#define I3C_BCR_HDR_CAP BIT(5) > >>>>> +#define I3C_BCR_BRIDGE BIT(4) > >>>>> +#define I3C_BCR_OFFLINE_CAP BIT(3) > >>>>> +#define I3C_BCR_IBI_PAYLOAD BIT(2) > >>>>> +#define I3C_BCR_IBI_REQ_CAP BIT(1) > >>>>> +#define I3C_BCR_MAX_DATA_SPEED_LIM BIT(0) > >>>>> + > >>>>> +/** > >>>>> + * struct i3c_device_info - I3C device information > >>>>> + * @pid: Provisional ID > >>>>> + * @bcr: Bus Characteristic Register > >>>>> + * @dcr: Device Characteristic Register > >>>>> + * @static_addr: static/I2C address > >>>>> + * @dyn_addr: dynamic address > >>>>> + * @hdr_cap: supported HDR modes > >>>>> + * @max_read_ds: max read speed information > >>>>> + * @max_write_ds: max write speed information > >>>>> + * @max_ibi_len: max IBI payload length > >>>>> + * @max_read_turnaround: max read turn-around time in > >>>>> +micro-seconds > >>>>> + * @max_read_len: max private SDR read length in bytes > >>>>> + * @max_write_len: max private SDR write length in bytes > >>>>> + * > >>>>> + * These are all basic information that should be advertised by an > I3C device. > >>>>> + * Some of them are optional depending on the device type and > >>>>> +device > >>>>> + * capabilities. > >>>>> + * For each I3C slave attached to a master with > >>>>> + * i3c_master_add_i3c_dev_locked(), the core will send the > >>>>> +relevant CCC command > >>>>> + * to retrieve these data. > >>>>> + */ > >>>>> +struct i3c_device_info { > >>>>> + u64 pid; > >>>>> + u8 bcr; > >>>>> + u8 dcr; > >>>>> + u8 static_addr; > >>>>> + u8 dyn_addr; > >>>>> + u8 hdr_cap; > >>>>> + u8 max_read_ds; > >>>>> + u8 max_write_ds; > >>>>> + u8 max_ibi_len; > >>>>> + u32 max_read_turnaround; > >>>>> + u16 max_read_len; > >>>>> + u16 max_write_len; > >>>>> +}; > >>>>> + > >>>> is this information filled with data provided from CCC commands? > >>> Yes, they are. > >> Ok, them the intention is to do this on bus_init(), right? > > Not only, it can be after a Hot-Join, or after the user has triggered > > a new DAA. Anyway, these information are retrieved anytime you add a > > device with i3c_master_add_i3c_dev_locked(), and the core uses CCC > > commands to do that. > > > >>>>> + > >>>>> +/** > >>>>> + * struct i3c_master_controller_ops - I3C master methods > >>>>> + * @bus_init: hook responsible for the I3C bus initialization. This > >>>>> + * initialization should follow the steps described in the I3C > >>>>> + * specification. This hook is called with the bus lock held > in > >>>>> + * write mode, which means all _locked() helpers can safely > be > >>>>> + * called from there > >>>>> + * @bus_cleanup: cleanup everything done in > >>>>> + * &i3c_master_controller_ops->bus_init(). This > function is > >>>>> + * optional and should only be implemented if > >>>>> + * &i3c_master_controller_ops->bus_init() attached > private data > >>>>> + * to I3C/I2C devices. This hook is called with the bus > lock > >>>>> + * held in write mode, which means all _locked() > helpers can > >>>>> + * safely be called from there > >>>>> + * @supports_ccc_cmd: should return true if the CCC command is > supported, false > >>>>> + * otherwise > >>>>> + * @send_ccc_cmd: send a CCC command > >>>>> + * @send_hdr_cmds: send one or several HDR commands. If there is > more than one > >>>>> + * command, they should ideally be sent in the same > HDR > >>>>> + * transaction > >>>>> + * @priv_xfers: do one or several private I3C SDR transfers > >>>>> + * @i2c_xfers: do one or several I2C transfers > >>>>> + * @request_ibi: attach an IBI handler to an I3C device. This implies > defining > >>>>> + * an IBI handler and the constraints of the IBI > (maximum payload > >>>>> + * length and number of pre-allocated slots). > >>>>> + * Some controllers support less IBI-capable devices > than regular > >>>>> + * devices, so this method might return -%EBUSY if > there's no > >>>>> + * more space for an extra IBI registration > >>>>> + * @free_ibi: free an IBI previously requested with ->request_ibi(). > The IBI > >>>>> + * should have been disabled with ->disable_irq() prior to > that > >>>>> + * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has been > called > >>>>> + * prior to ->enable_ibi(). The controller should first > enable > >>>>> + * the IBI on the controller end (for example, unmask > the hardware > >>>>> + * IRQ) and then send the ENEC CCC command (with > the IBI flag set) > >>>>> + * to the I3C device > >>>>> + * @disable_ibi: disable an IBI. First send the DISEC CCC command > with the IBI > >>>>> + * flag set and then deactivate the hardware IRQ on > the > >>>>> + * controller end > >>>>> + * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI has > been > >>>>> + * processed by its handler. The IBI slot should be > put back > >>>>> + * in the IBI slot pool so that the controller can re- > use it > >>>>> + * for a future IBI > >>>>> + * > >>>>> + * One of the most important hooks in these ops is > >>>>> + * &i3c_master_controller_ops->bus_init(). Here is a > >>>>> +non-exhaustive list of > >>>>> + * things that should be done in &i3c_master_controller_ops- > >bus_init(): > >>>>> + * > >>>>> + * 1) call i3c_master_set_info() with all information describing > >>>>> +the master > >>>>> + * 2) ask all slaves to drop their dynamic address by sending the > RSTDAA CCC > >>>>> + * with i3c_master_rstdaa_locked() > >>>>> + * 3) ask all slaves to disable IBIs using > >>>>> +i3c_master_disec_locked() > >>>>> + * 4) start a DDA procedure by sending the ENTDAA CCC with > >>>>> + * i3c_master_entdaa_locked(), or using the internal DAA logic > provided by > >>>>> + * your controller > >>>> You mean SETDASA CCC command? > >>> No, I really mean ENTDAA and DAA. By internal DAA logic I mean that > >>> some controllers are probably automating the whole DAA procedure, > >>> while others may let the SW control every step. > >> My understanding is that i3c_master_entdaa_locked() will trigger the > >> DAA process and DAA can be done by SETDASA, ENTDAA and later after > >> the bus initialization with SETNEWDA. > > No. Only ENTDAA can trigger a DAA procedure. SETDASA is here to assign > > a single dynamic address to a device that already has a static address > > but no dynamic address yet, and SETNEWDA is here to modify the > dynamic > > address of a device that already has one. > > >> I think the DAA process should be more generic, right now is only > >> made through the ENTDAA command with (cmd.ndests = 1). > >> I mean, shouldn't this be made by the core? First doing DAA for the > >> devices declared and them try do discover the rest of devices on the bus. > > Can you detail a bit more? If the only part you're complaining about > > is pre-assignment of dynamic addresses with SETDASA when a device is > > declared in the DT with a reg and dynamic-address property, then yes, > > I think I can provide an helper for that. But this helper would still > > have to be called from the master controller driver (from ->bus_init() > > or after a Hot-Join). > > > > Now, if the question is, is there a way we can automate things even > > more and completely implement DAA from the core? I doubt it, because > > the way the core will trigger DAA, expose discovered devices or allow > > you to declare manually assigned addresses is likely to be > > controller-dependent. > > Please refer to figure 90 of public specification. As you can see the DAA > process should start with SETDASA command. > > With the current flow of this patch the DAA process is limited to ENTDAA > command only. > > > When I designed the framework I took the decision to base my work on > > the spec rather than focusing on the I3C master controller I had to > > support (Cadence). This is the reason I decided to keep the interface > > as simple as possible at the risk of encouraging code-duplication (at > > first) rather than coming up with an interface that is designed with a > > single controller in mind and having to break things every time a new > > controller comes out. > > > > Thank you for you comments, but I'd like to know if some of my design > > choices are blocking you to support your controller. What I've seen so > > far is a collection of things that might be relevant to fix (though > > most of them are subject to interpretation and/or a matter of taste), > > but nothing that should really block you. > > > > Can you clarify that, and maybe come back with a list of things that > > you think are preventing you from properly supporting the Synopsys > > controller? > > > > Thanks, > > > > Boris > > As you can check from my comments my concerns are about the i3c > specification without the controller in mind. > > Best regards, > Vitor Soares >
Hi Vitor, On Tue, 27 Feb 2018 16:03:58 +0000 Vitor Soares <Vitor.Soares@synopsys.com> wrote: > >>> > >>> The speed R/W speed limitation is encoded in the device object, so, if > >>> the controller has to configure that on a per-transfer basis, one > >>> solution would be to pass the device to the ->priv_xfers(). > >> The speed R/W limitation is only for private transfers. Also the device can have > >> a limitation to write and not for read data. > >> This information is obtained with the command GETMXDS which returns the Maximum > >> Sustained Data Rate for non-CCC messages. > > And that's exactly what I expose in i3c_device_info, which is embedded > > in i3c_device, so you should have all the information you need to > > determine the speed in the controller driver if ->priv_xfer() is passed > > the device attached to those transfers. Would that be okay if we pass an > > i3c_device object to ->priv_xfers()? > > If you pass the i3c_device to ->priv_xfer(), then you won't need the address too. That's true. So how about we pass the i3c_device to ->priv_xfer() and drop the address field in i3c_priv_xfer. Or we could remove the address field add an i3c_device pointer in i3c_priv_xfer, this way, if we ever need to do cross-device sequence we'll be able to support it. > > Maybe someone else can give other point of view. That'd be great, but I'd like to hear your opinion, because it's not clear to me what you think of my suggestion. > >> Either important is the SETDASA for declared I3C devices. So the DAA process > >> should start by send an SETDASA and them ENTDAA CCC command. > > My understanding was that SETDASA was not mandatory, and was only useful > > when one wants to assign a specific dynamic address to a slave that has > > a static address (which is again not mandatory). > > I've tested it, and even devices with a static address participate to > > the DAA procedure if they've not been assigned a dynamic address yet, > > so I don't see the need for this SETDASA step if you don't need to > > assign a particular dynamic address to the device. > > > > Could you tell me why you think SETDASA is required? > > Yes, you are right... But in my opinion it is required as it does part of DAA > process. As Przemek said in his reply, I don't think it's required, at least not for the initial implementation. I'm definitely not saying we should never support the feature, but it can easily be added afterwards. BTW, can you give me a scenario where you'll want to assign a specific dynamic address to a device before DAA takes place (by DAA, I mean what happens after ENTDAA, which AIUI is what DAA describes)? I know it's described in the spec, and might become useful at some point, but right now, for a general purpose OS like Linux, I don't see a good reason to assign a dynamic address using SETDASA. > > >>>>> +static u32 i3c_master_i2c_functionalities(struct i2c_adapter *adap) > >>>>> +{ > >>>>> + return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR; > >>>>> +} > >>>> Is I2C_FUNC_10BIT_ADDR allowed ? > >>> According to "Table 4 I 2 C Features Allowed in I3C Slaves", yes (at > >>> least that my understanding). And the Cadence controller supports it. > >> The table say the oposite. The I2C extended address feature is not used on I3C > >> bus, thus this feature shall be disable. > > Actually, I was wrong when initially mentioning this table: it's about > > I2C features supported on I3C slaves, so not really what we're looking > > for. Here, we're wondering if I2C-only devices can have 10-bit > > addresses. The Cadence controller supports that, so there's probably > > nothing preventing use of 10-bit addresses for I2C transfers, but maybe > > not all I3C master controllers support that, so we should probably > > let the I3C master driver implement this method. > > The spec says that is "not used" so it will not interface with I3C bus. Again, I should not have pointed you to this chapter, because it does not describe what the I3C bus accept, but what I3C slave acting like I2C devices accept (basically what they accept before being assigned a dynamic address). If you see in the I3C spec that I2C transfers using 10-bit addresses is forbidden, could you tell me where it's stated, because I didn't find it. > > >> BTW it is optional on I2C devices. > > You mean I2C controllers? When an I2C device has a 10bit address, the > > controller has to support this mode to communicate with the device, at > > least that's my understanding. But we're digressing a bit. The > > question is not whether I2C devices can optionally use a 10 bit > > address, but whether I3C master controller can support this mode for > > I2C transfers to I2C-only devices. > > By the i2c spec the 10-bit address is optional, however the 7-bit address is > mandatory. The controller is not forced to support this feature, I think I already said I agree on this aspect. But if you have a device with a 10-bit address, it has to be connected to a controller that supports this feature otherwise it won't work. So, let's sum-up: I3C controllers can support I2C transfers with 10bit addresses, but this feature should be optional. I think we might also want to support optimized smbus methods, so maybe we should just let I3C controllers fill the i2c_adapter object as they wish. > >>>>> +/** > >>>>> + * struct i3c_ccc_setda - payload passed to ENTTM CCC > >>>>> + * > >>>>> + * @mode: one of the &enum i3c_ccc_test_mode modes > >>>>> + * > >>>>> + * Information passed to the ENTTM CCC to instruct an I3C device to enter a > >>>>> + * specific test mode. > >>>>> + */ > >>>>> +struct i3c_ccc_setda { > >>>>> + u8 addr; > >>>>> +} __packed; > >>>> what do you mean with struct? Maybe setdasa? if so, what is the addr? > >> Do you have the function to use this structure? Because one command use the > >> static address and the other use the dynamic address. Forgot to answer this one in my previous reply. Unicast CCC commands are always passed the destination in i3c_ccc_cmd->dest[x].addr, so, in case of SETDASA, i3c_ccc_cmd->dest[x].addr will be the static address, and in case of SETNEWDA i3c_ccc_cmd->dest[x].addr will be the old dynamic address. In both cases, the payload will be a single byte describing the new dynamic address, hence the common i3c_ccc_setda struct. > >> > >>>> > >>>> > +/** > >>>>> + * enum i3c_sdr_max_data_rate - max data rate values for private SDR transfers > >>>>> + */ > >>>>> +enum i3c_sdr_max_data_rate { > >>>>> + I3C_SDR_DR_FSCL_MAX, > >>>>> + I3C_SDR_DR_FSCL_8MHZ, > >>>>> + I3C_SDR_DR_FSCL_6MHZ, > >>>>> + I3C_SDR_DR_FSCL_4MHZ, > >>>>> + I3C_SDR_DR_FSCL_2MHZ, > >>>>> +}; > >>>> Can you change the names to: > >>>> > >>>> I3C_SDR0_FSCL_MAX, > >>>> I3C_SDR1_FSCL_8MHZ, > >>>> I3C_SDR2_FSCL_6MHZ, > >>>> I3C_SDR3_FSCL_4MHZ, > >>>> I3C_SDR4_FSCL_2MHZ, > >>>> > >>>> thus the data rate isn't repeated. > >>> What's the problem with the name I use? Moreover, I see no mention to > >>> the SDR0,1,2,3,4 modes in the public spec. > >> When you get the GETMXDS information, the maxWr and maxRd came from 0 to 4, so > >> in my opinion I think in this way is easier to have a relationship. > > It's an emum, and there's no mention of the SDRX modes you're using > > here in the I3C spec. I guess it's named this way in your I3C > > controller datasheet. I personally don't see a good reason to add SDRX > > in the name, but if you insist... > > The idea is to say that it is SDR mode and the value that GETMXDS command > return. It is what makes sense to me. Still don't see why this is needed, since what we care about here is the actual max SCL frequency, which is given in the enum name. But I don't want to argue more on this minor aspect, so, if everyone is okay, I'll switch to your solution. > >>>>> + > >>>>> +/** > >>>>> + * struct i3c_hdr_cmd - I3C HDR command > >>>>> + * @mode: HDR mode selected for this command > >>>>> + * @code: command opcode > >>>>> + * @addr: I3C dynamic address > >>>>> + * @ndatawords: number of data words (a word is 16bits wide) > >>>>> + * @data: input/output buffer > >>>>> + */ > >>>>> +struct i3c_hdr_cmd { > >>>>> + enum i3c_hdr_mode mode; > >>>>> + u8 code; > >>>>> + u8 addr; > >>>>> + int ndatawords; > >>>>> + union { > >>>>> + u16 *in; > >>>>> + const u16 *out; > >>>>> + } data; > >>>>> +}; > >> Please mention that the @code is what will define if the transfer is read or write. > > Well, I think it's pretty clear in the definition you'll find in the > > ccc.h file, but I can add a comment here too if you like. > > I don't find it in ccc.h file. Anyway is not good to put this definition there > because is not related. Oops! Sorry, I mixed the CCC and HDR stuff. It's indeed not clear that @code defines the transfer direction. I'll clarify this aspect. > >> I think the DAA process should be more generic, right now is only made through > >> the ENTDAA command with (cmd.ndests = 1). > >> I mean, shouldn't this be made by the core? First doing DAA for the devices > >> declared and them try do discover the rest of devices on the bus. > > Can you detail a bit more? If the only part you're complaining about is > > pre-assignment of dynamic addresses with SETDASA when a device is > > declared in the DT with a reg and dynamic-address property, then yes, I > > think I can provide an helper for that. But this helper would still have > > to be called from the master controller driver (from ->bus_init() or > > after a Hot-Join). > > > > Now, if the question is, is there a way we can automate things even more > > and completely implement DAA from the core? I doubt it, because the way > > the core will trigger DAA, expose discovered devices or allow you to > > declare manually assigned addresses is likely to be > > controller-dependent. > > Please refer to figure 90 of public specification. As you can see the DAA > process should start with SETDASA command. Only if devices with a static address needs to be assigned a specific dynamic address. At least, that's my understanding. Are there plans to create devices that would only reply to SETDASA commands but ignore ENTDAA ones? > > With the current flow of this patch the DAA process is limited to ENTDAA command > only. As a first step, yes. But again, nothing is set in stone, and the SETDASA step can be added afterwards. As said above, I fail to see a use case where it's really required (note that I said required, not useful). > > > When I designed the framework I took the decision to base my work on the > > spec rather than focusing on the I3C master controller I had to support > > (Cadence). This is the reason I decided to keep the interface as simple > > as possible at the risk of encouraging code-duplication (at first) > > rather than coming up with an interface that is designed with a single > > controller in mind and having to break things every time a new > > controller comes out. > > > > Thank you for you comments, but I'd like to know if some of my design > > choices are blocking you to support your controller. What I've seen so > > far is a collection of things that might be relevant to fix (though > > most of them are subject to interpretation and/or a matter of taste), > > but nothing that should really block you. > > > > Can you clarify that, and maybe come back with a list of things that you > > think are preventing you from properly supporting the Synopsys > > controller? > > > > Thanks, > > > > Boris > > As you can check from my comments my concerns are about the i3c specification > without the controller in mind. Okay, then we're on the same page. Regards, Boris
Hi Przemek, On Tue, 27 Feb 2018 16:43:27 +0000 Przemyslaw Sroka <psroka@cadence.com> wrote: > > > > >> Either important is the SETDASA for declared I3C devices. So the DAA > > >> process should start by send an SETDASA and them ENTDAA CCC > > command. > > > My understanding was that SETDASA was not mandatory, and was only > > > useful when one wants to assign a specific dynamic address to a slave > > > that has a static address (which is again not mandatory). > > > I've tested it, and even devices with a static address participate to > > > the DAA procedure if they've not been assigned a dynamic address yet, > > > so I don't see the need for this SETDASA step if you don't need to > > > assign a particular dynamic address to the device. > > > > > > Could you tell me why you think SETDASA is required? > > > > Yes, you are right... But in my opinion it is required as it does part of DAA > > process. > > SETDASA is simply faster than ENTDAA, but only if there is no need to > collect BCR/DCR/PID of such devices. I think most applications would > like to have them as an status information so after all ENTDAA can > be regarded as an generic approach (unless I'm mistaken). Actually, we could retrieve BCR/DCR/PID (and all other relevant information, like MAXDS) even with the SETDASA approach. We just need to send the according CCC commands after SETDASA. But that's also my understanding that ENTDAA should always work, and SETDASA usage is only needed if you want to reserve a dynamic address and assign it to a device before DAA takes place. This way you can enforce the device priority (WRT IBIs). But honestly, that's the only use case I can think of, and to me, it sounds like an advanced feature we may want to support at some point, but don't need in the initial implementation.
Hi Boris > -----Original Message----- > From: Boris Brezillon [mailto:boris.brezillon@bootlin.com] > Sent: Tuesday, February 27, 2018 9:13 PM > To: Przemyslaw Sroka <psroka@cadence.com> > Cc: Vitor Soares <Vitor.Soares@synopsys.com>; Boris Brezillon > <boris.brezillon@free-electrons.com>; Wolfram Sang <wsa@the- > dreams.de>; linux-i2c@vger.kernel.org; Jonathan Corbet <corbet@lwn.net>; > linux-doc@vger.kernel.org; Greg Kroah-Hartman > <gregkh@linuxfoundation.org>; Arnd Bergmann <arnd@arndb.de>; > Arkadiusz Golec <agolec@cadence.com>; Alan Douglas > <adouglas@cadence.com>; Bartosz Folta <bfolta@cadence.com>; Damian > Kos <dkos@cadence.com>; Alicja Jurasik-Urbaniak <alicja@cadence.com>; > Cyprian Wronka <cwronka@cadence.com>; Suresh Punnoose > <sureshp@cadence.com>; Thomas Petazzoni <thomas.petazzoni@free- > electrons.com>; Nishanth Menon <nm@ti.com>; Rob Herring > <robh+dt@kernel.org>; Pawel Moll <pawel.moll@arm.com>; Mark Rutland > <mark.rutland@arm.com>; Ian Campbell <ijc+devicetree@hellion.org.uk>; > Kumar Gala <galak@codeaurora.org>; devicetree@vger.kernel.org; linux- > kernel@vger.kernel.org; Geert Uytterhoeven <geert@linux-m68k.org>; Linus > Walleij <linus.walleij@linaro.org> > Subject: Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure > > EXTERNAL MAIL > > > Hi Przemek, > > On Tue, 27 Feb 2018 16:43:27 +0000 > Przemyslaw Sroka <psroka@cadence.com> wrote: > > > > > > > >> Either important is the SETDASA for declared I3C devices. So the > > > >> DAA process should start by send an SETDASA and them ENTDAA > CCC > > > command. > > > > My understanding was that SETDASA was not mandatory, and was > only > > > > useful when one wants to assign a specific dynamic address to a > > > > slave that has a static address (which is again not mandatory). > > > > I've tested it, and even devices with a static address participate > > > > to the DAA procedure if they've not been assigned a dynamic > > > > address yet, so I don't see the need for this SETDASA step if you > > > > don't need to assign a particular dynamic address to the device. > > > > > > > > Could you tell me why you think SETDASA is required? > > > > > > Yes, you are right... But in my opinion it is required as it does > > > part of DAA process. > > > > SETDASA is simply faster than ENTDAA, but only if there is no need to > > collect BCR/DCR/PID of such devices. I think most applications would > > like to have them as an status information so after all ENTDAA can be > > regarded as an generic approach (unless I'm mistaken). > > Actually, we could retrieve BCR/DCR/PID (and all other relevant > information, like MAXDS) even with the SETDASA approach. We just need to > send the according CCC commands after SETDASA. > I agree, what I meant by "SETDASA is simply faster than ENTDAA, but only if there is no need to collect BCR/DCR/PID of such devices." Is that it is faster than DAA but only if not followed by GET CCC commands to gather BCR/DCR/PID. I think we are on the same page here. > But that's also my understanding that ENTDAA should always work, and > SETDASA usage is only needed if you want to reserve a dynamic address > and assign it to a device before DAA takes place. This way you can enforce > the device priority (WRT IBIs). But honestly, that's the only use case I can > think of, and to me, it sounds like an advanced feature we may want to > support at some point, but don't need in the initial implementation. > Still ENTDAA seems to be sufficient for IBI prioritization but I can imagine some use cases where people would like to use it for such purposes. Note that SETDASA is applicable only for devices with SA so it is self-explanatory that it cannot be considered as utility to define priorities for all devices before ENTDAA. > -- > Boris Brezillon, Bootlin (formerly Free Electrons) Embedded Linux and > Kernel engineering https://urldefense.proofpoint.com/v2/url?u=https- > 3A__bootlin.com&d=DwICAg&c=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3G > Z-_haXqY&r=b0WPdqYyu0KH4-vSatt-ViJE1riZ603zdXl3hHHp_TU&m=wM54- > BGcSfHEklVRsw02O-bnyNkLTe9c0RyBP_ExzPA&s=pxQrogG- > Nq4XOMU7SPZ2FZNbgnbnjdERtMm_h7ZcdCE&e= Regards, Przemek -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Przemek, On Tue, 27 Feb 2018 17:06:37 +0000 Przemyslaw Sroka <psroka@cadence.com> wrote: > > > > > > > > Could you tell me why you think SETDASA is required? > > > > > > Yes, you are right... But in my opinion it is required as it does part > > > of DAA process. > > > > SETDASA is simply faster than ENTDAA, but only if there is no need to > > collect BCR/DCR/PID of such devices. I think most applications would like to > > have them as an status information so after all ENTDAA can be regarded as > > an generic approach (unless I'm mistaken). > > Below are 2 examples on how DAA can be executed: > 1st: > A1) SETDASA to devices with SA I'm not even sure all devices with a static address needs to be assigned a dynamic address with SETDASA (actually, I'm almost sure it's not the case, since, according to section "5.1.9.3 CCC Command Definitions" of the spec, all I3C slaves have to support ENTDAA). To me, it looks like you'd want to do that only is you really need to reserve a specific dynamic address and prevent the DAA step from assigning it to another device. > B1) DAA to remaining devices > C1) GET BCR/DCR/PID to devices that initially had SA > NOTES: C1 is optional and order of B1 and C1 can be changed While that's true in principle, in Linux we'll always retrieve BCR/DCR/PID (and more, like MAXDS), no matter how the device obtained its dynamic address. > > 2nd: > A2) DAA to all devices > NOTES: no need for any follow up steps as all information is collected during DAA As said above, that's not exactly how the Linux implementation works. Right now I'm ignoring the information retrieved during DAA and forcing a GETPID/GETBCR/GETDCR for every discovered device. This approach is generating a bit more traffic on the bus, but it also makes the implementation more generic, because we have a single function to add an I3C device, no matter how it's been assigned a dynamic address. > > As we can see 2nd approach is more generic and do not see any reason to add special handling for SETDASA unless there is any reasonable reason to do otherwise. I agree on one thing: as long as you don't have to reserve a specific dynamic address, SETDASA is not required. At least, that's my understanding. Regards, Boris
On Tue, 27 Feb 2018 20:24:43 +0000 Przemyslaw Sroka <psroka@cadence.com> wrote: > > > SETDASA is simply faster than ENTDAA, but only if there is no > > > need to collect BCR/DCR/PID of such devices. I think most > > > applications would like to have them as an status information so > > > after all ENTDAA can be regarded as an generic approach (unless > > > I'm mistaken). > > > > Actually, we could retrieve BCR/DCR/PID (and all other relevant > > information, like MAXDS) even with the SETDASA approach. We just > > need to send the according CCC commands after SETDASA. > > > I agree, what I meant by "SETDASA is simply faster than ENTDAA, but > only if there is no need to collect BCR/DCR/PID of such devices." Is > that it is faster than DAA but only if not followed by GET CCC > commands to gather BCR/DCR/PID. I think we are on the same page here. Yes, but right now it's not the case, see my other reply ;-). > > > But that's also my understanding that ENTDAA should always work, and > > SETDASA usage is only needed if you want to reserve a dynamic > > address and assign it to a device before DAA takes place. This way > > you can enforce the device priority (WRT IBIs). But honestly, > > that's the only use case I can think of, and to me, it sounds like > > an advanced feature we may want to support at some point, but don't > > need in the initial implementation. > Still ENTDAA seems to be sufficient for IBI prioritization but I can > imagine some use cases where people would like to use it for such > purposes. Note that SETDASA is applicable only for devices with SA so > it is self-explanatory that it cannot be considered as utility to > define priorities for all devices before ENTDAA. We have SETNEWDA for other use cases: say you want one of your device to have an higher priority, you can just manually set a new dynamic address that is lower than any other devices on the bus (I plan to expose that through sysfs, by making the address file writable).