Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1603652

Re: [PATCH 3/5] i2c: i2c-stm32f7: add driver

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

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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