[PATCH v4 0/5] bcm2835: auxiliar device support for spi

Martin Sperl kernel at martin.sperl.org
Tue Sep 15 22:23:55 PDT 2015

> On 16.09.2015, at 06:11, Stephen Warren <swarren at wwwdotorg.org> wrote:
> Sorry for the slow response; I'm travelling at the moment and working
> rather long hours.

I guess you have not read the latest patch-sets for auxiliary spi and uart.

> I believe it's legitimate for a compatible property to include a
> particular value (e.g. ns16550) if and only if a driver that knows
> solely about that compatible value (i.e. just the 16550 standard
> registers) can operate the HW without issue. I don't believe that's true
> in this case since the aux enable HW bit must be programmed and does not
> exist in standard 16550 HW block.
> So, you'd need to do one of:
> a) Not put ns16550 in the compatible property. Make a driver that binds
> to bcrm,bcm2835-aux-uart. This driver can then hopefully simply
> instantiate the standard NS16550 driver to avoid duplicating anything
> (e.g. it could create a new child struct {platform_,}device to do this
> perhaps).
> b) Make the aux node in DT a parent that contains a "standard" ns16550
> child node. The parent would fiddle with the aux bits before enumerating
> the child nodes (like a bus). The child could then have
> compatible="ns16550" just fine, and need no custom driver.

it is really just the following in the UART patch-set:
                uart1: uart at 7e215040 {
                        compatible = "ns16550";
                        reg = <0x7e215040 0x40>;
                        reg-shift = <2>;
                        interrupts = <1 29>;
                        status = "disabled";
                        clocks = <&aux_clocks BCM2835_AUX_CLOCK_UART>;

When enabling the clock implemented by Erics’s aux clock driver
then the clock gate is also enabled and this enables the HW block.

The only thing that remains is that the uart1 does use an internal
divider of 8 and not 16, which gives us twice the requested
clock - see the second patchset for uart for that.

More information about the linux-rpi-kernel mailing list