On 8/28/2024 9:43 AM, raiden00pl wrote:
I don't know what was the initial intention about `drivers/`, only Greg can
answer this question.
All directories except for arch/ and board/ should have only generic
code that can be built with all all compilers and for any target. That
is true for almost all directories, including drivers/. This naming is
identical to the naming and usage in Linux: generic drivers are under
drivers/, architecture-specific drivers are under arch/. It is done
that way almost universally.
But what I see now is that `drivers/` implement `upper-half` drivers, and
arch specific drivers implement "lower-half" drivers (there are probably a
few exceptions
to this rule).
For this reason, polluting `drivers/` with "lower-half" implementations
seems bad for me
and I think arch specific 'lower-half' drivers should be somewhere in
`arch/` (`arch/common/<chip_name>`,
`arch/drivers/<chip_name>` ?)
Exactly
Currently in the code base we have a similar case where arch-specific
drivers
were needed and they were NOT placed in `drivers/`.
I'm talking about `boards/arm/cxd56xx/drivers` which holds Spresense
specific drivers.
I don't remember the discussions and arguments about it, but they ended up
in `boards/` not `drivers/cxd56xx`.
drivers/ should have only generic driver code (which includes shareable
upper half drivers as well as standalone drivers for USB, 16550 uart,
etc. that have interfaces controlled by standards or specifications.
If the driver is common to all spresense boards and specific to the
spresense MCU, then boards/arm/cxd56xx/drivers will work but is not
ideal. (drivers/ will not workd unless the build system is reworked a
little because it explictly prevents access to many architecture
specific header files).
Architecture-specific drivers are not generally share-able. There are
some cases where two MCUs use common IP which are are almost the same
(differing in things like DMA, clocking, etc). The only real case I now
where two different CPUs would benefit by having the same
architecture-specific driver is when the special function register space
is shared in an asymmetric multi-core architecture. That might even be
as simple as it seems without a lot conditional compilation.
