On Wed, Sep 18, 2019 at 12:54 AM Christian Mauderer <l...@c-mauderer.de> wrote:
> > > Hi, > > I followed the error and figured out that the reason for the error was a > > call to > > `rtems_task_wake_after` which was coming from the `udelay()` call in > bbb-i2c > > in function `am335x_i2c_reset`. For now, commenting out the udelay calls > > work > > without error and I can also see the lvgl example working. > > > > What is the use of udelay there? Can it be removed? if not, what's the > > better way > > to make a delay at system initialization than `rtems_task_wake_after`? > > I agree that it is quite likely that udelay doesn't work correctly when > the system isn't booted yet. Most likely that's the reason for the error. > > I'm not entirely sure whether the udelay has been there before I updated > the driver or whether I took it over from the FreeBSD driver. But it's > not really relevant. Most likely the times are either required by the > manual or they had been necessary during some tests. > > The am335x_i2c_reset is only called during initialization (in that case > during am335x_i2c_bus_register). So it shouldn't be a problem to replace > them with a busy wait. You can use the rtems_counter_delay_nanoseconds() > for that. > > > This worked. I have posted a patch and started a discussion here: https://lists.rtems.org/pipermail/devel/2019-September/027748.html
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel