Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3261368yba; Tue, 16 Apr 2019 07:53:55 -0700 (PDT) X-Google-Smtp-Source: APXvYqwNfnA/EixqmCogVnXmfpxGIBkDzLp8jC2l8oR+Wh0cIUhEJj3kZr6FKTU6vCVtBEq56pNb X-Received: by 2002:a17:902:6bc7:: with SMTP id m7mr34861141plt.146.1555426435849; Tue, 16 Apr 2019 07:53:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555426435; cv=none; d=google.com; s=arc-20160816; b=ClkYHjXYvoImo3cksemJfq/ybCSc6I3BDY46xnaQdzwtVMYTH3ELMNeNQbloYy8pGz pcjHB2Cejxpi2RVOhl4bAeCdPvpnaBFJvNuB2KhianDxcG4312AABpl2jUfAzhJ3E0mb 2NhBmd6UcbW2M9fFae8kVOcN08hrJCQA7i2dYCny+U2tYSwcF/i5RhlcYTNi7+pkuJbR l5e3io9jehaoEpvLDxiCkjwXV06qGRn9KknVZP51duXEvWe0bP2EWXsINHY+8WEbxR0H AOIwaz2F6FiskixnkAHvWBERsSyUvdEjClhLSpL3fs44kqK4mIkn7hRr3ubCVnf3Un/d /5yw== 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 :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=psvvrJjJcLxzNiTe6PPJoRcdnh2wdDLcUvFFuXPax98=; b=zu7xm3XSGSuJ9j6AyiSLseouTXrfztwMBoMgXwG3XRzuAtQD10HqG3X56KDq04Mlpa URLdIMo6kp6If6hTlSkUkgGi6N8518VUbNDeCckOi6xhickbGMuV80R7MoYNh6AR77FH iL6uycqYX7CX4ogfFI8u0u2J29X2LJiu9/7hEitiYcAEjsRdBj2lnCrcic4+vEkRzmmr jKAIcnYdjEo38THimXFNkM/0/5FHXh+irfPBozJxq1VAXPmNf1abgGIXcsmZ3SVpX02W aEF/kD63G/npi0EOiHu2BSWG/N+jfjhvdUXHgr1YXHqsK5NRQa4xrPXgXWOZ2kj+68SV CJqQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w71si38958672pgd.470.2019.04.16.07.53.39; Tue, 16 Apr 2019 07:53:55 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729638AbfDPOwz (ORCPT + 99 others); Tue, 16 Apr 2019 10:52:55 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:50954 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726215AbfDPOwz (ORCPT ); Tue, 16 Apr 2019 10:52:55 -0400 Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bbrezillon) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 848F3281040; Tue, 16 Apr 2019 15:52:53 +0100 (BST) Date: Tue, 16 Apr 2019 16:52:50 +0200 From: Boris Brezillon To: Vitor Soares Cc: "linux-i3c@lists.infradead.org" , "joao.pinto@synopsys.com" , Boris Brezillon , "stable@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 1/3] i3c: fix i2c and i3c scl rate by bus mode Message-ID: <20190416165250.0606e5a2@collabora.com> In-Reply-To: <13D59CF9CEBAF94592A12E8AE55501350A61596D@DE02WEMBXB.internal.synopsys.com> References: <05fdeea79db83970e9ecb0d7045b4dd98f206f06.1555350118.git.vitor.soares@synopsys.com> <20190416075041.22f8e849@collabora.com> <13D59CF9CEBAF94592A12E8AE55501350A61596D@DE02WEMBXB.internal.synopsys.com> Organization: Collabora X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-redhat-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 On Tue, 16 Apr 2019 14:24:57 +0000 Vitor Soares wrote: > Hi Boris, > > From: Boris Brezillon > Date: Tue, Apr 16, 2019 at 06:50:41 > > > On Mon, 15 Apr 2019 20:46:41 +0200 > > Vitor Soares wrote: > > > > > Currently in case of mixed slow bus topologie and all i2c devices > > > support FM+ speed, the i3c subsystem limite the SCL to FM speed. > > > > I will it replace with your message below. > > > " > > Currently the I3C framework limits SCL frequency to FM speed when > > dealing with a mixed slow bus, even if all I2C devices are FM+ capable. > > " > > > > > Also in case on mixed slow bus mode the max speed for both > > > i2c or i3c transfers is FM or FM+. > > > > Looks like you're basically repeating what you said above. > > What I meant was that I3C framework isn't limiting the I3C speed in case > of mixed slow bus. Oh, okay, then maybe something like " The core was also not accounting for I3C speed limitations when operating in mixed slow mode and was erroneously using FM+ speed as the max I2C speed when operating in mixed fast mode. " > > > > > > > > > This patch fix the definition of i2c and i3c scl rate based on bus > > > > ^fixes on the bus > > > > > topologie and LVR[4] if no user input. > > > > ^topology ^if the rate is not already specified by the user. > > > > > In case of mixed slow mode the i3c scl rate is overridden. > > > > ^ with the max > > I2C rate. > > > > > > > > Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") > > > Signed-off-by: Vitor Soares > > > Cc: Boris Brezillon > > > Cc: > > > Cc: > > > --- > > > drivers/i3c/master.c | 39 +++++++++++++++++++++++++-------------- > > > 1 file changed, 25 insertions(+), 14 deletions(-) > > > > > > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c > > > index 909c2ad..1c4a86a 100644 > > > --- a/drivers/i3c/master.c > > > +++ b/drivers/i3c/master.c > > > @@ -564,20 +564,30 @@ static const struct device_type i3c_masterdev_type = { > > > .groups = i3c_masterdev_groups, > > > }; > > > > > > -int i3c_bus_set_mode(struct i3c_bus *i3cbus, enum i3c_bus_mode mode) > > > +int i3c_bus_set_mode(struct i3c_bus *i3cbus, enum i3c_bus_mode mode, > > > + unsigned long i2c_scl_rate) > > > > > > Can we rename the last arg into max_i2c_scl_rate? > > The i2c_scl_rate is base on LVR[4] bit and the user can set a higher scl > rate, this is reason I didn't named it to max_i2c_scl_rate. > But if you think that make more sense I'm ok with that. In this context it does encode the maximum rate allowed by the spec (based on LVR parsing), so max_i2c_rate sounds like a correct name to me. > > > > > > { > > > i3cbus->mode = mode; > > > > > > - 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; > > > + switch (i3cbus->mode) { > > > + case I3C_BUS_MODE_PURE: > > > + if (!i3cbus->scl_rate.i3c) > > > + i3cbus->scl_rate.i3c = I3C_BUS_TYP_I3C_SCL_RATE; > > > + break; > > > + case I3C_BUS_MODE_MIXED_FAST: > > > + if (!i3cbus->scl_rate.i3c) > > > + i3cbus->scl_rate.i3c = I3C_BUS_TYP_I3C_SCL_RATE; > > > + if (!i3cbus->scl_rate.i2c) > > > + i3cbus->scl_rate.i2c = i2c_scl_rate; > > > + break; > > > + case I3C_BUS_MODE_MIXED_SLOW: > > > + if (!i3cbus->scl_rate.i2c) > > > + i3cbus->scl_rate.i2c = i2c_scl_rate; > > > + i3cbus->scl_rate.i3c = i3cbus->scl_rate.i2c; > > > > Maybe we should do > > > > if (!i3cbus->scl_rate.i3c || > > i3cbus->scl_rate.i3c > i3cbus->scl_rate.i2c) > > i3cbus->scl_rate.i3c = i3cbus->scl_rate.i2c; > > > > Just in case the I3C rate forced by the user is lower than the max I2C > > rate. > > That was something that I considered but TBH it isn't a real use case. Add a WARN_ON() to at least catch such inconsistencies. And maybe we should add a dev_warn() when the user-defined rates do not match the mode/LVR constraints. It's easy to do a mistake when writing a dts.