Hello,
I am looking for an advice regarding board code that needs to call
driver upper half after the device is registered.
As far as I understand it, the usual code flow is like this:
- board code calls lower_half_register function, provides filesystem
path and other parameters
- lower half calls upper_half_register function
- upper half calls register_driver
- only integer status is returned to board code, the only information
available is therefore the filesystem path and the configuration given
To be specific - I am attempting to implement byte reordering in WS2812
RGB LED upper half driver. These LEDs receive their data in
green-red-blue order and that is what lower halves take care of when
they receive RGB data from userspace. Upper half just passes data back
and forth. However, I encountered a variant of these LEDs which for some
reason wants the data in red-green-blue order.
The reordering could be done in (every) lower half but it seems to me
that this is a job for common code. I have an initial implementation
ready and working, it adds some fields to ws2812_dev_s and based on
settings in those fields, the upper half optionally reorders the data.
The question is, how to configure this.
It seems to me that this should be done by upper half code since the
functionality is isolated in upper half. Let's say like this
- board code calls lower_half_register, the call chain happens as
mentioned above
- board code calls something like upper_half_configure
However, I found no way to obtain any handle for the driver instance
that could be used for the upper half call
This somewhat looks like a job for ioctl but I want to avoid that one
since I don't think this should be exposed to the userspace. The board
code knows what LEDs are connected to it after all, it's not the job for
the application to deal with that in my opinion.
Another (fallback) option is to provide the needed configuration to the
lower_half_register but I would like it if it was possible to implement
without the need to change all the lower halves and all of their call
sites (ie. to made it available for all board code easily)
Any pointers/ideas are appreciated
If anyone wants to look at what I am trying to achieve, initial
implementation is available in my "nuttx.git" repository at
git.kerogit.eu accessible through HTTP/S. The relevant branch is named
avrdx_ws2812_upstream_v2 - last two patches (the other patches are for
the AVR driver lower half itself and for support infrastructure - to be
merged hopefully but not merged yet, waiting in PR queue for 2nd
review.)