Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1603652
| From | "M'boumba Cedric Madianga" <cedric.madianga@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver |
| Date | 2017-03-17 23:50 +0100 |
| Message-ID | <tm8R4-5cW-7@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <tlXCi-535-17@gated-at.bofh.it> <tm0Aa-7ex-27@gated-at.bofh.it> <tm1we-80O-27@gated-at.bofh.it> <tm28W-76-17@gated-at.bofh.it> <tm2si-kO-29@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi Neil, >> As, I2C rise/fall time have some impacts in I2C timings value, the >> question is: it is very relevant to let customer control these >> parameters ? > > Actually, you could specify a different rise time in DT if it's relevant for > a specific design, this is why you have the following DT attributes : > - i2c-scl-falling-time-ns > - i2c-scl-internal-delay-ns > - i2c-scl-rising-time-ns > - i2c-sda-falling-time-ns > >> If the answer is NO, I agree with you, it is better to use your >> formula and remove this property from DT. >> If the answer is YES, I think we should keep ST tool. > > Note that the ST tool calculations are tied to the clock source frequency, so either > you provide a table for all the possible clock source frequencies or calculate dynamically. > Having a single parameter for a single frequency is, from my point of view, not acceptable. > > And, I don't think it's a military secret to have (at least) a simplified algorithm from ST... > since you have very detailed explanations in the public manuals ! OK. I will do some trials with your algorithm and push it in the V2. Thanks > > OK, but I think the I2C and DT maintainers are also involved in these kind of decisions. > They should also give their advice. I already upstream an I2C driver with this approach: "i2c-stm32f4". I don't think that Wolfram or Rob will change the philosophy for this driver. Then, I also don't think that the machine code for F0/F1/L0/L4 will be pushed in the mainline as it will be completely useless to port a linux kernel for this kind of chip. BR, Cedric
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 0/5] Add support for the STM32F7 I2C M'boumba Cedric Madianga <cedric.madianga@gmail.com> - 2017-03-17 11:10 +0100
[PATCH 1/5] dt-bindings: i2c-stm32: Document the STM32F7 I2C bindings M'boumba Cedric Madianga <cedric.madianga@gmail.com> - 2017-03-17 11:10 +0100
Re: [PATCH 1/5] dt-bindings: i2c-stm32: Document the STM32F7 I2C bindings Rob Herring <robh@kernel.org> - 2017-03-24 14:50 +0100
[PATCH 3/5] i2c: i2c-stm32f7: add driver M'boumba Cedric Madianga <cedric.madianga@gmail.com> - 2017-03-17 11:10 +0100
Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver Neil Armstrong <narmstrong@baylibre.com> - 2017-03-17 11:50 +0100
Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver "M'boumba Cedric Madianga" <cedric.madianga@gmail.com> - 2017-03-17 15:00 +0100
Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver Neil Armstrong <narmstrong@baylibre.com> - 2017-03-17 16:00 +0100
Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver "M'boumba Cedric Madianga" <cedric.madianga@gmail.com> - 2017-03-17 16:40 +0100
Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver Neil Armstrong <narmstrong@baylibre.com> - 2017-03-17 17:00 +0100
Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver "M'boumba Cedric Madianga" <cedric.madianga@gmail.com> - 2017-03-17 23:50 +0100
Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver Wolfram Sang <wsa@the-dreams.de> - 2017-03-23 21:20 +0100
Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver "M'boumba Cedric Madianga" <cedric.madianga@gmail.com> - 2017-03-23 21:50 +0100
Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver Wolfram Sang <wsa@the-dreams.de> - 2017-03-23 21:50 +0100
csiph-web