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: Wed, 22 Feb 2023 10:31:18 +0000 [thread overview]
Message-ID: <SEZPR06MB52696835ED8E2709D6A454DAF2AA9@SEZPR06MB5269.apcprd06.prod.outlook.com> (raw)
In-Reply-To: <94238c42-1250-4d51-86e5-0a960dea0ffc@linaro.org>
Hello Krzysztof,
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Wednesday, February 22, 2023 4:26 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 03:59, Ryan Chen wrote:
> > Hello Krzysztof,
> >
> >> -----Original Message-----
> >> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> >> Sent: Tuesday, February 21, 2023 7:05 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 21/02/2023 11:42, Ryan Chen wrote:
> >>>>>>> + type: boolean
> >>>>>>> + description: Enable i2c bus timeout for master/slave (35ms)
> >>>>>>
> >>>>>> Why this is property for DT? It's for sure not bool, but proper
> >>>>>> type coming from units.
> >>>>> This is i2c controller feature for enable slave mode inactive
> >>>>> timeout and also master mode sda/scl auto release timeout.
> >>>>> So I will modify to
> >>>>> aspeed,timeout:
> >>>>> type: boolean
> >>>>> description: I2C bus timeout enable for master/slave mode
> >>>>
> >>>> This does not answer my concerns. Why this is board specific?
> >>> Sorry, can’t catch your point.
> >>> It is not board specific. It is controller feature.
> >>> ASPEED SOC chip is server product, master connect may have
> >>> fingerprint connect to another board. And also support hotplug.
> >>> For example I2C controller as slave mode, and suddenly disconnected.
> >>> Slave state machine will keep waiting for master clock in for rx/tx transfer.
> >>> So it need timeout setting to enable timeout unlock controller state.
> >>> And in another side. As master mode, slave is clock stretching.
> >>> The master will be keep waiting, until slave release cll stretching.
> >>
> >> OK, thanks for describing the feature. I still do not see how this is DT
> related.
> >
> > Let me draw more about the board-specific.
> > The following is an example about i2c layout in board.
> > Board A
> Board B
> > --------------------------------------------------------
> --------------------------------------------------------
> > | i2c bus#1(master/slave) <--------------------> fingerprint.(can be unplug)
> <--------------------> i2c bus#x (master/slave) |
> > | i2c bus#2(master) -> tmp i2c device |
> | |
> > | i2c bus#3(master) -> adc i2c device | |
> |
> > --------------------------------------------------------
> --------------------------------------------------------
> > In this case i2c bus#1 need enable timeout, avoid suddenly unplug the
> 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.
> >
> >>>
> >>> So in those reason add this timeout design in controller.
> >>
> >> You need to justify why DT is correct place for this property. DT is
> >> not for configuring OS, but to describe hardware. I gave you one
> >> possibility
> >> - why different boards would like to set this property. You said it
> >> is not board specific, thus all boards will have it (or none of them).
> >> Without any other reason, this is not a DT property. Drop.
> >>
> >>>>
> >>>>>
> >>>>>>> +
> >>>>>>> + byte-mode:
> >>>>>>> + type: boolean
> >>>>>>> + description: Force i2c driver use byte mode transmit
> >>>>>>
> >>>>>> Drop, not a DT property.
> >>>>>>
> >>>>>>> +
> >>>>>>> + buff-mode:
> >>>>>>> + type: boolean
> >>>>>>> + description: Force i2c driver use buffer mode transmit
> >>>>>>
> >>>>>> Drop, not a DT property.
> >>>>>>
> >>>>> The controller support 3 different for transfer.
> >>>>> Byte mode: it means step by step to issue transfer.
> >>>>> Example i2c read, each step will issue interrupt then enable next step.
> >>>>> Sr (start read) | D | D | D | P
> >>>>> Buffer mode: it means, the data can prepare into buffer register,
> >>>>> then Trigger transfer. So Sr D D D P, only have only 1 interrupt handling.
> >>>>> The DMA mode most like with buffer mode, The differ is data
> >>>>> prepare in DRAM, than trigger transfer.
> >>>>>
> >>>>> So, should I modify to
> >>>>> aspeed,byte:
> >>>>> type: boolean
> >>>>> description: Enable i2c controller transfer with byte mode
> >>>>>
> >>>>> aspeed,buff:
> >>>>> type: boolean
> >>>>> description: Enable i2c controller transfer with buff mode
> >>>>
> >>>> 1. No, these are not bools but enum in such case.
> >>>
> >>> Thanks, will modify following.
> >>> aspeed,xfer_mode:
> >>> enum: [0, 1, 2]
> >>> description:
> >>> 0: byte mode, 1: buff_mode, 2: dma_mode
> >>
> >> Just keep it text - byte, buffered, dma
> >>
> >>>
> >>>> 2. And why exactly this is board-specific?
> >>>
> >>> No, it not depends on board design. It is only for register control
> >>> for
> >> controller transfer behave.
> >>> The controller support 3 different trigger mode for transfer.
> >>> Assign bus#1 ~ 3 : dma tranfer and assign bus#4 ~ 6 : buffer mode
> >>> transfer, That can reduce the dram usage.
> >>
> >> Then anyway it does not look like property for Devicetree. DT
> >> describes hardware, not OS 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.
Best regards,
Ryan
next prev parent reply other threads:[~2023-02-22 10:32 UTC|newest]
Thread overview: 19+ 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 ` [PATCH v5 1/2] dt-bindings: i2c: Add support for ASPEED i2Cv2 Ryan Chen
2023-02-20 8:28 ` Jeremy Kerr
2023-02-20 9:50 ` Ryan Chen
2023-02-20 11:24 ` Jeremy Kerr
2023-02-21 3:32 ` Ryan Chen
2023-02-22 1:14 ` Dhananjay Phadke
2023-02-22 1:30 ` Jeremy Kerr
[not found] ` <676c7777-635c-cc1f-b919-d33e84a45442@linaro.org>
2023-02-21 2:43 ` Ryan Chen
[not found] ` <80d873d4-d813-6c25-8f47-f5ff9af718ec@linaro.org>
2023-02-21 10:42 ` Ryan Chen
[not found] ` <c0ac0ab3-87fc-e74a-b4e2-3cf1b3a8a5e2@linaro.org>
2023-02-22 2:59 ` Ryan Chen
[not found] ` <94238c42-1250-4d51-86e5-0a960dea0ffc@linaro.org>
2023-02-22 10:31 ` Ryan Chen [this message]
[not found] ` <b7ca24ea-a265-81cb-3da6-19f938b35878@linaro.org>
2023-02-22 10:47 ` Ryan Chen
[not found] ` <5c255eb3-ec9e-d66f-4a2b-ccc32edf5672@linaro.org>
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
[not found] ` <63986fb1-f8d4-f348-bae9-72e08369213b@linaro.org>
2023-02-22 3:36 ` Ryan Chen
[not found] ` <77480142-a2c0-f6da-af0e-d3f01f72ac53@linaro.org>
2023-02-23 0:58 ` Ryan Chen
[not found] ` <54ef0dee-30dc-3ba9-d2f7-8270204b5505@linaro.org>
2023-02-20 9:56 ` [PATCH v5 0/2] Add ASPEED AST2600 I2Cv2 controller driver Ryan Chen
[not found] ` <abec828b-9b34-fc5a-cd36-8be6f20dfd25@linaro.org>
2023-02-21 1:12 ` Ryan Chen
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=SEZPR06MB52696835ED8E2709D6A454DAF2AA9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).