Message ID | 20191114055155.20446-1-pgaj@cadence.com (mailing list archive) |
---|---|
Headers | show |
Series | Add data hold delay support | expand |
Hi, From: Przemyslaw Gaj <pgaj@cadence.com> Date: Thu, Nov 14, 2019 at 05:51:52 > Add THD_DEL (Data Hold Delay) support. After testing different scenarios, > on various systems, sometimes there is a need to delay SDA_OUT propagation. > > Adding support which allows to configure that delay using the device > tree parameter. > > Przemyslaw Gaj (3): > i3c: master: add data hold delay support > dt-bindings: i3c: Document data hold delay feature > MAINTAINERS: add myself as maintainer of Cadence I3C master controller > driver > > Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt | 6 ++++++ > MAINTAINERS | 6 ++++++ > drivers/i3c/master/i3c-master-cdns.c | 5 ++++- > 3 files changed, 16 insertions(+), 1 deletion(-) > > -- > 2.14.0 I'm trying to understand this implementation and the use case but I'm not understanding. Could you please elaborate? Best regards, Vitor Soares
Hi Vitor, The 11/14/2019 11:58, Vitor Soares wrote: > > Hi, > > From: Przemyslaw Gaj <pgaj@cadence.com> > Date: Thu, Nov 14, 2019 at 05:51:52 > > > Add THD_DEL (Data Hold Delay) support. After testing different scenarios, > > on various systems, sometimes there is a need to delay SDA_OUT propagation. > > > > Adding support which allows to configure that delay using the device > > tree parameter. > > > > Przemyslaw Gaj (3): > > i3c: master: add data hold delay support > > dt-bindings: i3c: Document data hold delay feature > > MAINTAINERS: add myself as maintainer of Cadence I3C master controller > > driver > > > > Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt | 6 ++++++ > > MAINTAINERS | 6 ++++++ > > drivers/i3c/master/i3c-master-cdns.c | 5 ++++- > > 3 files changed, 16 insertions(+), 1 deletion(-) > > > > -- > > 2.14.0 > > I'm trying to understand this implementation and the use case but I'm not > understanding. > > Could you please elaborate? There is new controller functionality which allows to meet SDA to SCL propagation time. Baisically, you can delay SDA propagation using this functionality to meet I3C MIPI spec timing. This is very useful for some SoC designs. From Spec: Table 75 of MIPI I3C Specification 1.0 (page 142) defines non-zero minimal tHD_PP timing on master output (Fig 65). This setting allows to meet this timing on master's soc outputs, regardless of PCB balancing. > > Best regards, > Vitor Soares
Hi, From: Przemyslaw Gaj <pgaj@cadence.com> Date: Thu, Nov 14, 2019 at 12:48:56 > > There is new controller functionality which allows to meet SDA to SCL > propagation time. Baisically, you can delay SDA propagation using this > functionality to meet I3C MIPI spec timing. This is very useful for some > SoC designs. > > From Spec: > Table 75 of MIPI I3C Specification 1.0 (page 142) defines non-zero > minimal tHD_PP timing on master output (Fig 65). This setting allows to > meet this timing on master's soc outputs, regardless of PCB balancing. > > > > > Best regards, > > Vitor Soares > > -- > -- > Przemyslaw Gaj Thanks for pointing me the right place to read about it. I would suggest you to put that info in the patch as well. Best regards, Vitor Soares
On Thu, 14 Nov 2019 13:31:33 +0000 Vitor Soares <Vitor.Soares@synopsys.com> wrote: > Hi, > > From: Przemyslaw Gaj <pgaj@cadence.com> > Date: Thu, Nov 14, 2019 at 12:48:56 > > > > There is new controller functionality which allows to meet SDA to SCL > > propagation time. Baisically, you can delay SDA propagation using this > > functionality to meet I3C MIPI spec timing. This is very useful for some > > SoC designs. > > > > From Spec: > > Table 75 of MIPI I3C Specification 1.0 (page 142) defines non-zero > > minimal tHD_PP timing on master output (Fig 65). This setting allows to > > meet this timing on master's soc outputs, regardless of PCB balancing. > > > > > > > > Best regards, > > > Vitor Soares > > > > -- > > -- > > Przemyslaw Gaj > > Thanks for pointing me the right place to read about it. > I would suggest you to put that info in the patch as well. I agree. The spec details should be mentioned in the commit message and in the code as well (in a comment).