Hi Jonathan, all.
I am resending this as I don't think I found the mail from lore. I wrote
this using my phone so maybe it was sent as HTML and stuck to some
filters. If you receive this twice - I am sorry...
la 16. maalisk. 2024 klo 15.40 Jonathan Cameron <jic23@xxxxxxxxxx
<mailto:jic23@xxxxxxxxxx>> kirjoitti:
> On Fri, 15 Mar 2024 15:49:10 -0500
> Chenyuan Yang <chenyuan0y@xxxxxxxxx <mailto:chenyuan0y@xxxxxxxxx>>
> wrote:
>
> > Hi Matti,
> >
> > Thanks for your reply!
> >
> > > I think the suggested-by tag is a bit of an overkill :) I don't feel
> > > like taking the credit - you spotted the problem and fixed it!
> >
> > You did help me figure out the real issue here and how to fix it :)
> >
> > > Do you think you could fix the removal of the duplicates too?
> >
> > Sure, I can help to implement the deduplication logic.
> > Here is a potential patch for it based on your help.
> > Besides, I changed the stop condition in the inner loop to `j < idx`
> > since the current last index should be `idx - 1`.
>
> Matti, I didn't follow why duplicates are a problem?
The function here builds the tables for available integration times.
These are shown to users via sysfs (if I'm not mistaken) - and while the
user-space algorithms may tolerate dublicates, they are ugly (in my
opinon) when available times are manually listed.
> Sure the code is less efficient, but do we end up with a wrong
> answer as a result (I've not checked logic, but I'd expect either
> first or last of repeating values to be used depending on the alg).
If we discuss completely omitting duplicated times from the driver
(which was one thing I referred in my previous mail) - then we are
likely to face problems as there can be register values, which then
can't be translated to times, read from a HW.
Eg, we need to have everything described in driver tables used for
driver's computations - but (in my opinion) we should drop duplicates
from these tables which we hand over via sysfs.
Yours,
-- Matti
