Re: [PATCH 1/2] spi: bcm2835: add spi-bcm2835aux driver for the auxiliar spi1 and spi2

On 06/22/2015 09:26 AM, Martin Sperl wrote:

quoted

On 22.06.2015, at 16:55, Jakub Kiciński [off-list ref] wrote:
As mentioned by Noralf UART1 is quite commonly used on Compute Modules.
Proper driver - perhaps modelled as a bus - seems like a prerequisite
for this work.  You are also not using IRQ mux in DT binding example
which is very misleading.

Well - there is no support far for uart1 in upstream as of now.
And I am not even sure if the compute module is supported as there
is no device tree available in upstream for that...

IIRC I've run the CM with the RPi B DT. I've been meaning to upstream
explicit DTs for all the various RPi models, but haven't manage to get
around to that yet.

So I have taken the simple route of using shared interrupts and providing
a minimal framework to enable the spi1/spi2 hw blocks with proper locking.
And I have mentioned that it would need to get modified when uart1 support
comes along.

If you know of a better solution how to control this and that also
incorporates a patch to enable uart1, then please share it!

I haven't looked at the registers to be sure of the structure and hence
if this is good advice, but creating an IRQ controller driver for the
aux registers (as Mark intimated) sounds like a good idea.

Just modify the bcm2835aux_spi_enable/disable to use a different framework
than just bcm2835_aux_modify_enable.

The patch Noralf mentions only applies downstream and only sets the
enable-register during the boot sequence, so it would not impact the
solution as is.

quoted

Do we have any indication weather this AUX hardware is available on
RPi2 as well?  IIRC bcm2836 differs only in CPU cores, peripherals
remain identical.  Perhaps this driver could be used on RPi2 and
naming it 283x would be more appropriate?

I have not checked, but I would guess that it exists.

As for naming: I have asked around and bcm2835aux seemed fine.
Also if we go that route we should start renaming ALL driver instances that
contain 2835.

I'd suggest leaving named after the "first" chip the driver supports, in
a similar fashion to how DT compatible values work. There's zero benefit
from renaming existing drivers, and having new drivers continue with the
existing naming convention would leave everything nice and consistent.


_______________________________________________
linux-rpi-kernel mailing list
linux-rpi-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel