I'm using a DTS file for a Duovero Parlor board. To this board I've added some SPI devices. My first (a display) works perfectly so I have that entry correct at least. I want to add an entry to support the SPI connected NXP SC16IS752 UART controller. (There's been a patches on lkml recently I want to try).

This is my entry:

clocks {
        clk14m: oscillator {
                #clock-cells = <0>;
                compatible = "fixed-clock";
                clock-frequency = <14745600>;

&mcspi4 {
        sc16is752: sc16is752@0 {
                compatible = "nxp,sc16is752";
                reg = <0>;
                spi-max-frequency = <4000000>;
                clocks = <&clk14m>;
                interrupt-parent = <&gpio4>;
                interrupt = <15 IRQ_TYPE_EDGE_FALLING>;
                #gpio-cells = <2>;

It looks vaguely right. The SPI bus is 4MHz, mode 0. Interrupt is GPIO 111 which is <&GPIO 4 15>. My problem is specifying the clock. It's a standalone crystal oscillator connected directly to the chip. So is that clocks but right?

Because the clock is standalone I've no idea where to place it so "clocks" sound right but I'm totally guessing. When I compile the dts it fails with a syntax error though so something is wrong somewhere.

I'm not sure if the #gpio-cells is correct either. Does that mean the gpio numbering will start at 200 and go up?

  • I've moved the clk14m stanza inside the sc16is752 stanza and it compiles! That's something I suppose.
    – carveone
    Jun 14 '15 at 11:26
  • It compiles but a call to devm_clk_get fails and the driver goes into a probe deferral. So it's a mess...
    – carveone
    Jun 14 '15 at 15:40
  • I gave up. I had to use kernel 3.6 so I backported sc16is7xx to 3.6 and converted the driver to SPI. Works. Well. It works once you request the gpio before converting it to an irq! Imagine. This is easier than DTS. Bah...
    – carveone
    Jun 20 '15 at 15:53

The issue with your clocks, is that clocks declared outside the TI clock domains are not parsed and set up correctly in 3.17. This issue is resolved in kernel version 4.0.5.

The required changes occurred in the function omap_clk_init at the end of /arch/arm/mach-omap2/io.c, there is an extra call there to of_clk_init(NULL) which doesn't exist in 3.17.

Some relevant discussion here, http://patchwork.ozlabs.org/patch/375753/

  • A bug! Argh! Thanks very much allsey87. I've successfully backported to 3.6 and across to SPI but that kernel is a bit old and I would have been forced forward real soon. My hardware would not have worked. It's a relief to know it will now.
    – carveone
    Jun 21 '15 at 10:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.