Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp3142778imm; Fri, 24 Aug 2018 11:17:52 -0700 (PDT) X-Google-Smtp-Source: ANB0VdY1hYROUzAmRJRyNM+IBVilxHlEb4rvxsRNttskRZvOziUcITZRU/W9nADF7X77njXhuxc8 X-Received: by 2002:a17:902:b189:: with SMTP id s9-v6mr2684632plr.188.1535134672507; Fri, 24 Aug 2018 11:17:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535134672; cv=none; d=google.com; s=arc-20160816; b=hShxlX9Pm7JvwGYWeImxIf9x+ZEHRRIXzbyVT4wjbeehQg/rNhnXdne8hhsmcCyx/W RW4Thlri6a4DNpuzf4TxDRgdGkVN3cMtaVqUAN3UvoD58nGFLQQqF3iG6ovHtbucszy9 dX1ce+GHUtCxOQmP5Xjay45XpA9FDvDenIvImcDJLy3erGwvvOGQmLB3XAp10eLjVe2d RtfU8tHU13FB6qZ/1OCS0SeOlf2MauCfwZioHRYRmfxuZC84PPDbpaBRtrzs9uHy72qY BA6k6UQeLTtGkalGt781hlB8G5AcSmUSXscgbggDD9wEBI8TxoWmVZQxDMmnavWExuzX ZX1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=qrG2q11FsqBVeiaMd16MtwXczuuaoEqCdzf/aZnXEWo=; b=M9EnYVpa1lNiUNMAyDWPHKr47FTSW4t8iWcmVilnxu45C53vM4MYLSQdUP5SKJC0Q/ PZqwnSLKpgISydLX7q3M31RJ4uGrL2QCXuWF3PlIc1B/saZ9cX4oeMDSrISLyGuXPr0q u9gUVGzGLdfRUHbD6nkiUs/Yx3WpyPfcxPj6rdrxfnEnEeRwRS0BPN9GxPx989Pqqlv1 PXcepRa/xLVpAY5SAtiDBhiyy4fJV68rOwTg9AeBHQdK+Qq7o4/9A780Fd9vhFiY510i Nm7rbu1mb79W55OQpoqWzdnhsFjHva3q6Gaq+WEXvOMcc4EW7orm/rk2cVzzdxU0oV+d CxxQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x19-v6si2618786pln.336.2018.08.24.11.17.36; Fri, 24 Aug 2018 11:17:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727547AbeHXVvr (ORCPT + 99 others); Fri, 24 Aug 2018 17:51:47 -0400 Received: from mail.bootlin.com ([62.4.15.54]:60548 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726801AbeHXVvr (ORCPT ); Fri, 24 Aug 2018 17:51:47 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 4B3D620877; Fri, 24 Aug 2018 20:16:03 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0 Received: from bbrezillon (unknown [91.160.177.164]) by mail.bootlin.com (Postfix) with ESMTPSA id 80DB2206FF; Fri, 24 Aug 2018 20:16:02 +0200 (CEST) Date: Fri, 24 Aug 2018 20:16:00 +0200 From: Boris Brezillon To: vitor Cc: , Sekhar Nori , Wolfram Sang , , "Jonathan Corbet" , , Greg Kroah-Hartman , Arnd Bergmann , Przemyslaw Sroka , Arkadiusz Golec , Alan Douglas , Bartosz Folta , Damian Kos , Alicja Jurasik-Urbaniak , "Cyprian Wronka" , Suresh Punnoose , "Rafal Ciepiela" , Thomas Petazzoni , Nishanth Menon , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , "Kumar Gala" , , , Geert Uytterhoeven , Linus Walleij , Xiang Lin , Przemyslaw Gaj , Peter Rosin Subject: Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure Message-ID: <20180824201600.7d80bca9@bbrezillon> In-Reply-To: References: <20180719152930.3715-1-boris.brezillon@bootlin.com> <20180719152930.3715-2-boris.brezillon@bootlin.com> <20180824143934.6d6b6487@bbrezillon> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vitor, On Fri, 24 Aug 2018 18:52:52 +0100 vitor wrote: > Hi Boris, > > > On 24-08-2018 13:39, Boris Brezillon wrote: > > Hi Vitor, > > > > On Wed, 22 Aug 2018 17:43:34 +0100 > > vitor wrote: > > > >> Hi Boris, > >> > >> > >> On 19-07-2018 16:29, Boris Brezillon wrote: > >>> +int i3c_bus_register(struct i3c_bus *i3cbus) > >>> +{ > >>> + struct i2c_dev_desc *desc; > >>> + > >>> + i3c_bus_for_each_i2cdev(i3cbus, desc) { > >>> + switch (desc->boardinfo->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); > >>> +} > >> During the tests of the bus with i2c devices I found the i2c_dev_desc > >> objects aren't allocated before this function. This cause i3cbus->mode = > >> I3C_BUS_MODE_PURE. > > I just checked and DT parsing (+ I2C descs creation) is done before > > i3c_bus_register() is called, so we should be good. How did you declare > > your I2C devices (right now, only DT declaration is supported). > During the DT parsing, you create the i2c_dev_boardinfo. the > i2c_dev_desc is created in i3c_master_bus_init() which is after the > i3c_mater_create_bus(). Oops, you're right. > One possible way to fix this is to pass master > also to i3c_bus_register and iterate over i2c_dev_board_info list. Yes, that's the proper fix. I'll do that in v7. > > >> I want to do something for the slave and secondary master, do you > >> already have infrastructure that you can share? > > What do you mean? > > > > Regards, > > > > Boris > > I want start to add the secondary master functionality but it is also > necessary to add the infrastructure to the subsystem. > So, to avoid duplicated work can you share your plans for the secondary > master? Well, before even considering supporting secondary master registration, we need to handle mastership handover. As for the DAA operation, it's likely to be host specific, so we'll have to add a new hook to the i3c_master_controller_ops struct. Once you've done that, we'll have trigger a mastership handover everytime an I3C driver tries to send a frame on the bus, and the master this frame should do through is not in control of the bus. That should be pretty easy for the nominal case, but error cases are likely to be hard to deal with. Note that I have a ->cur_master field in the i3c_bus object which stores allows us to track whose the currently active master. If master->this != master->bus->cur_master that means you need to start a mastership handover procedure. That's all I thought about for now, and we'll probably face other problems when implementing it. Let me know if you have other questions, and don't hesitate to share your code early during the development phase. Also note that the bus representation is likely to change based on Arnd's feedback, so you might have to rework your implementation a bit at some point. Regards, Boris