Messages in this thread | | | From | Ryan Chen <> | Subject | RE: [PATCH v5 1/2] dt-bindings: i2c: Add support for ASPEED i2Cv2 | Date | Wed, 22 Feb 2023 10:31:18 +0000 |
| |
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
| |