| Message ID | 20191002120611.26121-1-t-kristo@ti.com |
|---|---|
| Headers | show |
| Series | clk: ti: re-work divider clock support | expand |
On 02/10/2019 15:06, Tero Kristo wrote: > Hi, > > The existing divider clock support appears to have an inherent bug > because of the bit field width implementation and limitation of divider > values based on this. The limitation by bit field only is not enough, > as we can have divider settings which accept only certain range of > dividers within the full range of the bit-field. > > Because of this, the divider clock is re-implemented to use min,max,mask > values instead of just the bit-field. Queued this up for 5.4 fixes, thanks. Tony, do you have anything against the DT patch going in with the rest of this or should it be dropped? -Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
* Tero Kristo <t-kristo@ti.com> [191024 08:04]: > On 02/10/2019 15:06, Tero Kristo wrote: > > Hi, > > > > The existing divider clock support appears to have an inherent bug > > because of the bit field width implementation and limitation of divider > > values based on this. The limitation by bit field only is not enough, > > as we can have divider settings which accept only certain range of > > dividers within the full range of the bit-field. > > > > Because of this, the divider clock is re-implemented to use min,max,mask > > values instead of just the bit-field. > > Queued this up for 5.4 fixes, thanks. > > Tony, do you have anything against the DT patch going in with the rest of > this or should it be dropped? No that won't cause merge conflicts so please merge the dts change along with the rest of the series. So for the dts change: Acked-by: Tony Lindgren <tony@atomide.com>
Quoting Tero Kristo (2019-10-24 01:03:20) > On 02/10/2019 15:06, Tero Kristo wrote: > > Hi, > > > > The existing divider clock support appears to have an inherent bug > > because of the bit field width implementation and limitation of divider > > values based on this. The limitation by bit field only is not enough, > > as we can have divider settings which accept only certain range of > > dividers within the full range of the bit-field. > > > > Because of this, the divider clock is re-implemented to use min,max,mask > > values instead of just the bit-field. > > Queued this up for 5.4 fixes, thanks. Is this a regression in 5.4-rc series? Please only send fixes for code that is broken by code that went into the merge window, or is super annoying and broken but we somehow didn't notice. If not, just let it sit in -next until the next merge window and it may still be backported to stable trees anyway.
On 28/10/2019 11:59, Stephen Boyd wrote: > Quoting Tero Kristo (2019-10-24 01:03:20) >> On 02/10/2019 15:06, Tero Kristo wrote: >>> Hi, >>> >>> The existing divider clock support appears to have an inherent bug >>> because of the bit field width implementation and limitation of divider >>> values based on this. The limitation by bit field only is not enough, >>> as we can have divider settings which accept only certain range of >>> dividers within the full range of the bit-field. >>> >>> Because of this, the divider clock is re-implemented to use min,max,mask >>> values instead of just the bit-field. >> >> Queued this up for 5.4 fixes, thanks. > > Is this a regression in 5.4-rc series? Please only send fixes for code > that is broken by code that went into the merge window, or is super > annoying and broken but we somehow didn't notice. If not, just let it > sit in -next until the next merge window and it may still be backported > to stable trees anyway. Tony/Tomi, how much do you care which one this hits into? -Tero -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 28/10/2019 12:23, Tero Kristo wrote: > On 28/10/2019 11:59, Stephen Boyd wrote: >> Quoting Tero Kristo (2019-10-24 01:03:20) >>> On 02/10/2019 15:06, Tero Kristo wrote: >>>> Hi, >>>> >>>> The existing divider clock support appears to have an inherent bug >>>> because of the bit field width implementation and limitation of divider >>>> values based on this. The limitation by bit field only is not enough, >>>> as we can have divider settings which accept only certain range of >>>> dividers within the full range of the bit-field. >>>> >>>> Because of this, the divider clock is re-implemented to use >>>> min,max,mask >>>> values instead of just the bit-field. >>> >>> Queued this up for 5.4 fixes, thanks. >> >> Is this a regression in 5.4-rc series? Please only send fixes for code >> that is broken by code that went into the merge window, or is super >> annoying and broken but we somehow didn't notice. If not, just let it >> sit in -next until the next merge window and it may still be backported >> to stable trees anyway. > > Tony/Tomi, how much do you care which one this hits into? Probably no hurry with this one, as the DSS side patch is enough to avoid the bad divider. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
* Tomi Valkeinen <tomi.valkeinen@ti.com> [191028 11:37]: > On 28/10/2019 12:23, Tero Kristo wrote: > > On 28/10/2019 11:59, Stephen Boyd wrote: > > > Quoting Tero Kristo (2019-10-24 01:03:20) > > > > On 02/10/2019 15:06, Tero Kristo wrote: > > > > > Hi, > > > > > > > > > > The existing divider clock support appears to have an inherent bug > > > > > because of the bit field width implementation and limitation of divider > > > > > values based on this. The limitation by bit field only is not enough, > > > > > as we can have divider settings which accept only certain range of > > > > > dividers within the full range of the bit-field. > > > > > > > > > > Because of this, the divider clock is re-implemented to use > > > > > min,max,mask > > > > > values instead of just the bit-field. > > > > > > > > Queued this up for 5.4 fixes, thanks. > > > > > > Is this a regression in 5.4-rc series? Please only send fixes for code > > > that is broken by code that went into the merge window, or is super > > > annoying and broken but we somehow didn't notice. If not, just let it > > > sit in -next until the next merge window and it may still be backported > > > to stable trees anyway. > > > > Tony/Tomi, how much do you care which one this hits into? > > Probably no hurry with this one, as the DSS side patch is enough to avoid > the bad divider. OK good to hear. Yes I too think we can wait for the clock divider changes to trickle down to next. While they are regression fixes, this has clearly been broken for many years. However, the following patch should be merged during -rc as without it sometimes devices can fail: clk: ti: clkctrl: Fix failed to enable error with double udelay timeout: Regards, Tony