All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Vitor Soares <Vitor.Soares@synopsys.com>
Cc: "linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>,
	"joao.pinto@synopsys.com" <Joao.Pinto@synopsys.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	Boris Brezillon <bbrezillon@kernel.org>
Subject: Re: [PATCH 1/3] i3c: fix i2c and i3c scl rate by bus mode
Date: Mon, 22 Apr 2019 18:07:15 +0200	[thread overview]
Message-ID: <20190422180715.40abe1b9@collabora.com> (raw)
In-Reply-To: <13D59CF9CEBAF94592A12E8AE55501350A61B3B4@DE02WEMBXB.internal.synopsys.com>

On Mon, 22 Apr 2019 15:54:33 +0000
Vitor Soares <Vitor.Soares@synopsys.com> wrote:


> > > >     
> > > > >  {
> > > > >  	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.  
> 
> I think the WARN_ON() is too evasive on the screen and won't provide the 
> information we want.
> The dev_warn() should work perfectly here.
> 
> 		if (i3cbus->scl_rate.i3c < i3cbus->scl_rate.i2c)
> 			dev_warn(&i3cbus->cur_master->dev->dev,
> 				     "%s: i3c-scl-hz lower then i2c-scl-hz\n",  __func__);

Using dev_warn() sounds good, though I don't think you need the
__func__ here. Also, please print the i2c/i3c rates in the message, and
align the second line on the open parens.

> 		if (i3cbus->scl_rate.i2c != I3C_BUS_I2C_FM_SCL_RATE ||
> 		    i3cbus->scl_rate.i2c != I3C_BUS_I2C_FM_PLUS_SCL_RATE)
> 			dev_warn(&i3cbus->cur_master->dev->dev,
> 				     "%s: i2c-scl-hz not defined according MIPI I3C spec\n", 
> 				     __func__);

Is that really a problem? Having an i2c rate that is less than FM speed
sounds like a valid case to me.

> 
> Maybe it make more sense to do this check on of_populate_i3c_bus(), what 
> do you think?
> 

No, we really want to have this check here, because we might support
other HW description formats at some point (board-files, ACPI, ...).

_______________________________________________
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Vitor Soares <Vitor.Soares@synopsys.com>
Cc: "linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>,
	"joao.pinto@synopsys.com" <Joao.Pinto@synopsys.com>,
	Boris Brezillon <bbrezillon@kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] i3c: fix i2c and i3c scl rate by bus mode
Date: Mon, 22 Apr 2019 18:07:15 +0200	[thread overview]
Message-ID: <20190422180715.40abe1b9@collabora.com> (raw)
In-Reply-To: <13D59CF9CEBAF94592A12E8AE55501350A61B3B4@DE02WEMBXB.internal.synopsys.com>

On Mon, 22 Apr 2019 15:54:33 +0000
Vitor Soares <Vitor.Soares@synopsys.com> wrote:


> > > >     
> > > > >  {
> > > > >  	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.  
> 
> I think the WARN_ON() is too evasive on the screen and won't provide the 
> information we want.
> The dev_warn() should work perfectly here.
> 
> 		if (i3cbus->scl_rate.i3c < i3cbus->scl_rate.i2c)
> 			dev_warn(&i3cbus->cur_master->dev->dev,
> 				     "%s: i3c-scl-hz lower then i2c-scl-hz\n",  __func__);

Using dev_warn() sounds good, though I don't think you need the
__func__ here. Also, please print the i2c/i3c rates in the message, and
align the second line on the open parens.

> 		if (i3cbus->scl_rate.i2c != I3C_BUS_I2C_FM_SCL_RATE ||
> 		    i3cbus->scl_rate.i2c != I3C_BUS_I2C_FM_PLUS_SCL_RATE)
> 			dev_warn(&i3cbus->cur_master->dev->dev,
> 				     "%s: i2c-scl-hz not defined according MIPI I3C spec\n", 
> 				     __func__);

Is that really a problem? Having an i2c rate that is less than FM speed
sounds like a valid case to me.

> 
> Maybe it make more sense to do this check on of_populate_i3c_bus(), what 
> do you think?
> 

No, we really want to have this check here, because we might support
other HW description formats at some point (board-files, ACPI, ...).

  reply	other threads:[~2019-04-22 16:07 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-15 18:46 [PATCH 0/3] Fix i2c and i3c scl rate according bus mode Vitor Soares
2019-04-15 18:42 ` [PATCH 1/3] i3c: fix i2c and i3c scl rate by " Vitor Soares
2019-04-15 18:46   ` Vitor Soares
2019-04-15 18:46   ` Vitor Soares
2019-04-16  5:50   ` Boris Brezillon
2019-04-16  5:50     ` Boris Brezillon
2019-04-16 14:24     ` Vitor Soares
2019-04-16 14:24       ` Vitor Soares
2019-04-16 14:52       ` Boris Brezillon
2019-04-16 14:52         ` Boris Brezillon
2019-04-22 15:54         ` Vitor Soares
2019-04-22 15:54           ` Vitor Soares
2019-04-22 16:07           ` Boris Brezillon [this message]
2019-04-22 16:07             ` Boris Brezillon
2019-04-22 17:54             ` Vitor Soares
2019-04-22 17:54               ` Vitor Soares
2019-04-22 18:27               ` Boris Brezillon
2019-04-22 18:27                 ` Boris Brezillon
2019-04-22 19:59                 ` Vitor Soares
2019-04-22 19:59                   ` Vitor Soares
2019-04-15 18:42 ` [PATCH 2/3] i3c: add mixed limited " Vitor Soares
2019-04-15 18:46   ` Vitor Soares
2019-04-15 18:46   ` Vitor Soares
2019-04-16  6:00   ` Boris Brezillon
2019-04-16  6:00     ` Boris Brezillon
2019-04-16 14:27     ` Vitor Soares
2019-04-16 14:27       ` Vitor Soares
2019-04-15 18:42 ` [PATCH 3/3] i3c: dw: Add limited bus mode support Vitor Soares
2019-04-15 18:46   ` Vitor Soares
2019-04-15 18:46   ` Vitor Soares
2019-04-16  6:09   ` Boris Brezillon
2019-04-16  6:09     ` Boris Brezillon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190422180715.40abe1b9@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=Joao.Pinto@synopsys.com \
    --cc=Vitor.Soares@synopsys.com \
    --cc=bbrezillon@kernel.org \
    --cc=linux-i3c@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.