PCA9555 Driver: Replace the signalling logic with a simple callback using the new definitons of ioexpander.h. This repartitioning of functionality is necessary because (1) the I/O expander driver is the lower-lower part of any driver that uses GPIOs (include the GPIO driver itself) and should not be interacting directly with the much higher level application layer. And (2) in order to be compatible with the GPIO driver (and any arbitrary upper half driver), the PCA9555 should not directly signal, but should call back into the upper half. The upper half driver that interacts directly with the application is the appropriate place to be generating signal.
1) asin[f l]() use Newton’s method to converge on a solution. But Newton’s method converges very slowly (> 500,000 iterations) for values of x close to 1.0; and, in the case of asinl(), sometimes fails to converge (loops forever). The attached patch uses an trig identity for values of x > sqrt(2). The resultant functions converge in no more than 5 iterations, 6 for asinl().
2) The NuttX erf[f l]() functions are based on Chebyshev fitting to a good guess. The problem there’s a bug in the implementation that causes the functions to blow up with x near -3.0. This patch fixes that problem. It should be noted that this method returns the error function erf(x) with fractional error less than 1.2E-07 and that’s fine for the float version erff(), but the same method is used for double and long double version which will yield only slightly better precision. This patch doesn't address the issue of lower precision for erf() and erfl().
3) a faster version of copysignf() for floats is included.
In the menuconfig target, the context dependency was executed before kconfig-mconf. That was necessary because the link at apps/platform/board needed to be set up before creating the apps/Kconfig file. Otherwise, the platform Kconfig files would not be included. But this introduces the chicken-and-egg problem in some configurations.
In particular: (1) An NX graphics configuration is used that requires auto-generation of source files using cpp, (2) the configuration is set for Linux, but (3) we are running under Cygwin with (4) a Windows native toolchain. In this case, POSIX-style symbolic links are set up but the Windows native toolchain cannot follow them.
The reason we are running 'make menuconfig' is to change from Linux to Cygwin, but the target fails. During the context phase, NX runs CPP to generate source files but that fails because the Windows native toolchain cannot follow the links. Checkmate.
This was fixed by changing all of the make menuconfig (and related) targets. They no long depend on context being run. Instead, they depend only on the dirlinks target. The dirlinks target only sets up the directory links but does not try to run all of the context setup; the compiler is never invoked; no code is autogeneraed; and things work.
The scsi thread was waiting for the wrong condition.
However, this was masked by the fact that the code creating the scsi thread
was also holding usbmsc_scsi_lock(priv) while initializing data, hence this
lock synchronized the scsi thread start with init completion.
