On 06/22/2015 09:26 AM, Martin Sperl wrote: >> On 22.06.2015, at 16:55, Jakub Kiciński <moorray3@xxxxx> 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. > >> 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. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
