All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ryan Chen <ryan_chen@aspeedtech.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Joel Stanley <joel@jms.id.au>, Andrew Jeffery <andrew@aj.id.au>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v5 1/2] dt-bindings: i2c: Add support for ASPEED i2Cv2
Date: Thu, 23 Feb 2023 10:25:56 +0000	[thread overview]
Message-ID: <SEZPR06MB52697747528490B1A16AF87FF2AB9@SEZPR06MB5269.apcprd06.prod.outlook.com> (raw)
In-Reply-To: <5c255eb3-ec9e-d66f-4a2b-ccc32edf5672@linaro.org>

Hello Krzysztof,

> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Thursday, February 23, 2023 5:29 PM
> To: Ryan Chen <ryan_chen@aspeedtech.com>; Rob Herring
> <robh+dt@kernel.org>; Krzysztof Kozlowski
> <krzysztof.kozlowski+dt@linaro.org>; Joel Stanley <joel@jms.id.au>; Andrew
> Jeffery <andrew@aj.id.au>; Philipp Zabel <p.zabel@pengutronix.de>;
> openbmc@lists.ozlabs.org; linux-arm-kernel@lists.infradead.org;
> linux-aspeed@lists.ozlabs.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v5 1/2] dt-bindings: i2c: Add support for ASPEED i2Cv2
> 
> On 22/02/2023 11:47, Ryan Chen wrote:
> >>>> connector. That slave will keep state to drive clock stretching.
> >>>>> So it is specific enable in i2c bus#1. Others is not needed enable
> timeout.
> >>>>> Does this draw is more clear in scenario?
> >>>>
> >>>> I2C bus #1 works in slave mode? So you always need it for slave work?
> >>>
> >>> Yes, it is both slave/master mode. It is always dual role. Slave
> >>> must always
> >> work.
> >>> Due to another board master will send.
> >>
> >> I meant that you need this property when it works in slave mode? It
> >> would be then redundant to have in DT as it is implied by the mode.
> >
> > But timeout feature is also apply in master. It for avoid suddenly
> > slave miss(un-plug) Master can timeout and release the SDA/SCL, return.
> 
> OK, yet the property should describe the hardware, not the register feature you
> want to program. You need to properly model it in DT binding to represent
> hardware setup, not your desired Linux driver behavior.
> 
> >>>>> The same draw, in this case, i2c bus#1 that is multi-master
> >>>>> transfer
> >>>> architecture.
> >>>>> Both will inactive with trunk data. That cane enable i2c#1 use DMA
> >>>>> transfer
> >>>> to reduce CPU utilized.
> >>>>> Others (bus#2/3) can keep byte/buff mode.
> >>>>
> >>>> Isn't then current bus configuration for I2C#1 known to the driver?
> >>>> Jeremy asked few other questions around here...
> >>>
> >>> No, The driver don't know currently board configuration.
> >>
> >> It knows whether it is working in multi-master/slave mode.
> >
> > But in DT can decide which i2c bus number can use dma or buffer mode
> transfer.
> > If in another i2c bus support master only, also can use dma to transfer trunk
> data to another slave.
> 
> and none of these were explained in commit msg or device description.
> 
Thanks your guidance. I will add all those discussion in next patches cover-letter.
Best regards,
Ryan Chen.

WARNING: multiple messages have this Message-ID (diff)
From: Ryan Chen <ryan_chen@aspeedtech.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Joel Stanley <joel@jms.id.au>, Andrew Jeffery <andrew@aj.id.au>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v5 1/2] dt-bindings: i2c: Add support for ASPEED i2Cv2
Date: Thu, 23 Feb 2023 10:25:56 +0000	[thread overview]
Message-ID: <SEZPR06MB52697747528490B1A16AF87FF2AB9@SEZPR06MB5269.apcprd06.prod.outlook.com> (raw)
In-Reply-To: <5c255eb3-ec9e-d66f-4a2b-ccc32edf5672@linaro.org>

Hello Krzysztof,

> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Thursday, February 23, 2023 5:29 PM
> To: Ryan Chen <ryan_chen@aspeedtech.com>; Rob Herring
> <robh+dt@kernel.org>; Krzysztof Kozlowski
> <krzysztof.kozlowski+dt@linaro.org>; Joel Stanley <joel@jms.id.au>; Andrew
> Jeffery <andrew@aj.id.au>; Philipp Zabel <p.zabel@pengutronix.de>;
> openbmc@lists.ozlabs.org; linux-arm-kernel@lists.infradead.org;
> linux-aspeed@lists.ozlabs.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v5 1/2] dt-bindings: i2c: Add support for ASPEED i2Cv2
> 
> On 22/02/2023 11:47, Ryan Chen wrote:
> >>>> connector. That slave will keep state to drive clock stretching.
> >>>>> So it is specific enable in i2c bus#1. Others is not needed enable
> timeout.
> >>>>> Does this draw is more clear in scenario?
> >>>>
> >>>> I2C bus #1 works in slave mode? So you always need it for slave work?
> >>>
> >>> Yes, it is both slave/master mode. It is always dual role. Slave
> >>> must always
> >> work.
> >>> Due to another board master will send.
> >>
> >> I meant that you need this property when it works in slave mode? It
> >> would be then redundant to have in DT as it is implied by the mode.
> >
> > But timeout feature is also apply in master. It for avoid suddenly
> > slave miss(un-plug) Master can timeout and release the SDA/SCL, return.
> 
> OK, yet the property should describe the hardware, not the register feature you
> want to program. You need to properly model it in DT binding to represent
> hardware setup, not your desired Linux driver behavior.
> 
> >>>>> The same draw, in this case, i2c bus#1 that is multi-master
> >>>>> transfer
> >>>> architecture.
> >>>>> Both will inactive with trunk data. That cane enable i2c#1 use DMA
> >>>>> transfer
> >>>> to reduce CPU utilized.
> >>>>> Others (bus#2/3) can keep byte/buff mode.
> >>>>
> >>>> Isn't then current bus configuration for I2C#1 known to the driver?
> >>>> Jeremy asked few other questions around here...
> >>>
> >>> No, The driver don't know currently board configuration.
> >>
> >> It knows whether it is working in multi-master/slave mode.
> >
> > But in DT can decide which i2c bus number can use dma or buffer mode
> transfer.
> > If in another i2c bus support master only, also can use dma to transfer trunk
> data to another slave.
> 
> and none of these were explained in commit msg or device description.
> 
Thanks your guidance. I will add all those discussion in next patches cover-letter.
Best regards,
Ryan Chen.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-02-23 10:26 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-20  6:17 [PATCH v5 0/2] Add ASPEED AST2600 I2Cv2 controller driver Ryan Chen
2023-02-20  6:17 ` Ryan Chen
2023-02-20  6:17 ` [PATCH v5 1/2] dt-bindings: i2c: Add support for ASPEED i2Cv2 Ryan Chen
2023-02-20  6:17   ` Ryan Chen
2023-02-20  8:28   ` Jeremy Kerr
2023-02-20  8:28     ` Jeremy Kerr
2023-02-20  9:50     ` Ryan Chen
2023-02-20  9:50       ` Ryan Chen
2023-02-20 10:43       ` Krzysztof Kozlowski
2023-02-20 10:43         ` Krzysztof Kozlowski
2023-02-20 11:24       ` Jeremy Kerr
2023-02-20 11:24         ` Jeremy Kerr
2023-02-21  3:32         ` Ryan Chen
2023-02-21  3:32           ` Ryan Chen
2023-02-21  9:43           ` Krzysztof Kozlowski
2023-02-21  9:43             ` Krzysztof Kozlowski
2023-02-22  1:14           ` Dhananjay Phadke
2023-02-22  1:14             ` Dhananjay Phadke
2023-02-22  1:30           ` Jeremy Kerr
2023-02-22  1:30             ` Jeremy Kerr
2023-02-20  8:35   ` Krzysztof Kozlowski
2023-02-20  8:35     ` Krzysztof Kozlowski
2023-02-21  2:43     ` Ryan Chen
2023-02-21  2:43       ` Ryan Chen
2023-02-21  9:40       ` Krzysztof Kozlowski
2023-02-21  9:40         ` Krzysztof Kozlowski
2023-02-21 10:42         ` Ryan Chen
2023-02-21 10:42           ` Ryan Chen
2023-02-21 11:04           ` Krzysztof Kozlowski
2023-02-21 11:04             ` Krzysztof Kozlowski
2023-02-22  2:59             ` Ryan Chen
2023-02-22  2:59               ` Ryan Chen
2023-02-22  8:25               ` Krzysztof Kozlowski
2023-02-22  8:25                 ` Krzysztof Kozlowski
2023-02-22 10:31                 ` Ryan Chen
2023-02-22 10:31                   ` Ryan Chen
2023-02-22 10:35                   ` Krzysztof Kozlowski
2023-02-22 10:35                     ` Krzysztof Kozlowski
2023-02-22 10:47                     ` Ryan Chen
2023-02-22 10:47                       ` Ryan Chen
2023-02-23  9:28                       ` Krzysztof Kozlowski
2023-02-23  9:28                         ` Krzysztof Kozlowski
2023-02-23 10:25                         ` Ryan Chen [this message]
2023-02-23 10:25                           ` Ryan Chen
2023-02-20  6:17 ` [PATCH v5 2/2] i2c: aspeed: support ast2600 i2cv2 new register mode driver Ryan Chen
2023-02-20  6:17   ` Ryan Chen
2023-02-20  8:43   ` Krzysztof Kozlowski
2023-02-20  8:43     ` Krzysztof Kozlowski
2023-02-20 10:44     ` Krzysztof Kozlowski
2023-02-20 10:44       ` Krzysztof Kozlowski
2023-02-22  3:36     ` Ryan Chen
2023-02-22  3:36       ` Ryan Chen
2023-02-22  8:28       ` Krzysztof Kozlowski
2023-02-22  8:28         ` Krzysztof Kozlowski
2023-02-23  0:58         ` Ryan Chen
2023-02-23  0:58           ` Ryan Chen
2023-02-23  9:30           ` Krzysztof Kozlowski
2023-02-23  9:30             ` Krzysztof Kozlowski
2023-02-20  8:30 ` [PATCH v5 0/2] Add ASPEED AST2600 I2Cv2 controller driver Krzysztof Kozlowski
2023-02-20  8:30   ` Krzysztof Kozlowski
2023-02-20  9:56   ` Ryan Chen
2023-02-20  9:56     ` Ryan Chen
2023-02-20 10:35     ` Krzysztof Kozlowski
2023-02-20 10:35       ` Krzysztof Kozlowski
2023-02-21  1:12       ` Ryan Chen
2023-02-21  1:12         ` Ryan Chen
2023-02-21  9:38         ` Krzysztof Kozlowski
2023-02-21  9:38           ` Krzysztof Kozlowski

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=SEZPR06MB52697747528490B1A16AF87FF2AB9@SEZPR06MB5269.apcprd06.prod.outlook.com \
    --to=ryan_chen@aspeedtech.com \
    --cc=andrew@aj.id.au \
    --cc=joel@jms.id.au \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-aspeed@lists.ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=openbmc@lists.ozlabs.org \
    --cc=p.zabel@pengutronix.de \
    --cc=robh+dt@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.