User avatar
procount
Posts: 1969
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Separating a Device tree

Wed Nov 27, 2019 10:19 pm

Some time ago, I wrote a DTS overlay for the Pimoroni Hyperpixel which combined the touchscreen, i2c interface, backlight and LCD initialisation.
I'm now trying to separate the touchscreen interface out to just leave the other screen descriptions.

So far it is still working, but I hung the SPI bitbang interface ([email protected]) off the touchscreen i2c description ([email protected]), and I want to remove the I2C interface and the 5d register defintiion. I'm having trouble doing this, so what can I hang [email protected] off instead and still get the hyperpixel driver to load with its parameters?

Code: Select all

/*
 * Device tree overlay for Pimoroni Hyperpixel4 LCD init
 * V2
 *
 * Compile:
 * dtc [email protected] -I dts -O dtb -o pimhyp4.dtbo pimhyp4-overlay.dts
 */

#include <dt-bindings/gpio/gpio.h>

/dts-v1/;
/plugin/;
/ {
    /* Identify the RPi models this is compatible with (is this sufficient?) */
    compatible = "brcm,bcm2708";

    [email protected] {
        target = <&leds>;
        __overlay__ {
            pinctrl-names = "default";
            pinctrl-0 = <&dpi18_pins>;
        };
    };

    /* Define a group of pins to be configured by the GPIO driver as function 6 = ALT2 = DPI mode */
    [email protected] {
        target = <&gpio>;
        __overlay__ {
            dpi18_pins: dpi18_pins {
                brcm,pins = <0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9    0xc 0xd 0xe 0xf 0x10 0x11     0x14 0x15 0x16 0x17 0x18 0x19>;
                brcm,function = <0x6>;
                brcm,pull = <0x0>;
            };
        };
    };

    [email protected] {
        target-path = "/";
        __overlay__ {
            i2c_gpio: [email protected] {
                #address-cells = <1>;
                #size-cells = <0>;
                compatible = "i2c-gpio";
                gpios = <&gpio 10 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN) /* sda */ 
                         &gpio 11 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN) /* scl */
                        >;
                i2c-gpio,delay-us = <4>;        /* ~100 kHz */
            };
        };
    };

    [email protected] {
        target = <&i2c_gpio>;
        __overlay__ {
            /* needed to avoid dtc warning */
            #address-cells = <1>;
            #size-cells = <0>;
            hyperpixel4: [email protected] {
                reg = <0x5d>;
                compatible = "pimoroni,hyperpixel4";
                irq-gpios  = <&gpio 27 0>; // specify  GPIO27 as the irq line from the TS controller, SPI CLK from LCD
                mosi-gpios = <&gpio 26 0>; // specify  GPIO26 as the SPI mosi line from the LCD controller
                cs-gpios   = <&gpio 18 0>; // specify  GPIO27 as the SPI cs line from the LCD controller
            };
        };
    };

    [email protected] {
        target-path = "/";
        __overlay__ {
            rpi_backlight: rpi_backlight {
                compatible = "gpio-backlight";
                gpios = <&gpio 19 0>;
                default-on;
            };
        };
    };
};

PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2577
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Separating a Device tree

Wed Nov 27, 2019 10:32 pm

Why not put the hyperpixel node in the root, just like fragments 2 and 4?

Please use "brcm,bcm2835" as a compatible string for the overlay - although nothing is checking (except a validation script), I'm trying to standardise on that and "brcm,bcm2711" for Pi4.

User avatar
procount
Posts: 1969
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: Separating a Device tree

Wed Nov 27, 2019 11:26 pm

Well, I've tried this, but the hyperpixel driver doesn't load in this case.

Code: Select all

/*
 * Device tree overlay for Pimoroni Hyperpixel4 LCD init
 * V2
 *
 * Compile:
 * dtc [email protected] -I dts -O dtb -o pimhyp4.dtbo pimhyp4-overlay.dts
 */

#include <dt-bindings/gpio/gpio.h>

/dts-v1/;
/plugin/;
/ {
    /* Identify the RPi models this is compatible with (is this sufficient?) */
    compatible = "brcm,bcm2835";

    [email protected] {
        target = <&leds>;
        __overlay__ {
            pinctrl-names = "default";
            pinctrl-0 = <&dpi18_pins>;
        };
    };

    /* Define a group of pins to be configured by the GPIO driver as function 6 = ALT2 = DPI mode */
    [email protected] {
        target = <&gpio>;
        __overlay__ {
            dpi18_pins: dpi18_pins {
                brcm,pins = <0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9    0xc 0xd 0xe 0xf 0x10 0x11     0x14 0x15 0x16 0x17 0x18 0x19>;
                brcm,function = <0x6>;
                brcm,pull = <0x0>;
            };
        };
    };

    [email protected] {
        target-path = "/";
        __overlay__ {
            hyperpixel4: [email protected] {
                compatible = "pimoroni,hyperpixel4";
                irq-gpios  = <&gpio 27 0>; // specify  GPIO27 as the irq line from the TS controller, SPI CLK from LCD
                mosi-gpios = <&gpio 26 0>; // specify  GPIO26 as the SPI mosi line from the LCD controller
                cs-gpios   = <&gpio 18 0>; // specify  GPIO27 as the SPI cs line from the LCD controller
            };
        };
    };

    [email protected] {
        target-path = "/";
        __overlay__ {
            rpi_backlight: rpi_backlight {
                compatible = "gpio-backlight";
                gpios = <&gpio 19 0>;
                default-on;
            };
        };
    };
};
EDIT: In fact, just changing "target=<i&2c-gpio>" to "target-path="/";" stops the driver loading.
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

User avatar
procount
Posts: 1969
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: Separating a Device tree

Thu Nov 28, 2019 12:30 am

Ah, I think it's because my driver is still an i2c-client, so it only works under an i2c node. I'll have to adapt it somehow...

Maybe it should be a platform driver instead.
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2577
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Separating a Device tree

Thu Nov 28, 2019 8:49 am

Yes - that's what I would have said if you hadn't already reached the same conclusion. Without the usual platform driver hooks your driver won't be probed.

User avatar
procount
Posts: 1969
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: Separating a Device tree

Thu Nov 28, 2019 9:46 am

Thanks - I'm slowly getting to understand the linux device driver model and architecture.
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

User avatar
procount
Posts: 1969
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: Separating a Device tree

Thu Nov 28, 2019 9:59 am

Originally this driver was multifunction and I put it in the input/touchscreen folder, because that was it's main purpose.
But this part is now just going to initialise the Pimoroni Hyperpixel LCD controller (and then exit).
So where should this driver fit into the linux driver folder hierarchy?
video?
video/fbdev?
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2577
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Separating a Device tree

Thu Nov 28, 2019 10:08 am

I think video/fbdev sounds closest.

Are you rolling your own bitbanged SPI? Why not use the standard one (drivers/spi/spi-bitbang.c), in which case this would be a regular SPI device driver?

User avatar
procount
Posts: 1969
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: Separating a Device tree

Thu Nov 28, 2019 10:19 am

1. It's already written and works
2. I was looking at spi-gpio (?) and the kernel notes mentioned something about performance not being that good (but it's probably ok for this application anyway)
3. I don't yet have any idea how to write a driver (or DTS file) that layers on top of the spi-bitbang driver.
4. I had already considered it as a next step, but the previous points led me to stick with what I have for the time being.
5. Do you know of a specific example or tutorial that would help me write an spi driver?

EDIT: So what's the difference between spi-bitbang.c and spi-gpio.c? Is one better than the other?
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2577
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Separating a Device tree

Thu Nov 28, 2019 10:28 am

If you ignore the I2C half (although the comparison might be helpful), drivers/rtc/rtc-ds3232.c is fairly simple. Also look at drivers/gpio/gpio-max7301.c, although it isn't a complete driver.

User avatar
procount
Posts: 1969
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: Separating a Device tree

Thu Nov 28, 2019 10:54 am

Thanks. They look useful.
The rtc-ds3232.c nicely shows the differences between the i2c, spi and platform interfaces, so it should be a great help.
It has entries for:

MODULE_DEVICE_TABLE(i2c, ds3232_id);
MODULE_DEVICE_TABLE(of, ds3232_of_match);

but I also expected one for

MODULE_DEVICE_TABLE(spi, ...);

like in the gpio-max7301.c driver. How does it work without it?
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2577
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Separating a Device tree

Thu Nov 28, 2019 11:03 am

It assumes one will be using Device Tree compatible strings to locate the driver. The macro parameter determines the type of udev alias which is generated - have a play with modinfo and different configurations to see the effect.

User avatar
procount
Posts: 1969
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: Separating a Device tree

Thu Nov 28, 2019 11:18 am

Oh ok. I had misunderstood the use of MODULE_DEVICE_TABLE. I thought it was registering it with the appropriate bus, but that's done elsewhere. My mindset is corrected ;)
I think I'll continue to convert it to a platform device for now, and then look at the spi driver as a second step. It's all about the journey!
Thanks.
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

User avatar
procount
Posts: 1969
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: Separating a Device tree

Thu Nov 28, 2019 12:05 pm

Yay! - it now works as a platform driver without reference to i2c.
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

User avatar
procount
Posts: 1969
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: Separating a Device tree

Thu Nov 28, 2019 12:26 pm

@PhilE - whilst I have your attention...

Now that I've separated the drivers, is it possible to co-ordinate them?
What I would like to do is have the LCD init driver initially disabled/dormant or whatever.
Then, when the touchscreen driver's probe function detects the appropriate hardware and installs itself, can it then also re-enable the LCD init driver based on the outcome of the hardware detection being successful?
If so, would the method used change if the LCD init driver was built-in or modular?
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2577
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Separating a Device tree

Thu Nov 28, 2019 12:43 pm

You're at the limits of my knowledge (and time) now. To answer the easy question ("If so, would the method used change if the LCD init driver was built-in or modular?") first, modularity should make no difference provided the filesystem is available.

The standard (though ugly, IMHO) way to manage driver probe ordering is for drivers to return -EPROBE_DEFER if a resource is unavailable. When new devices are added to the system, the deferred probes are retried until eventually they succeed (or it stops trying). If you can think of a test the LCD driver can use to detect the touchscreen's readiness then you're in business.

User avatar
procount
Posts: 1969
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: Separating a Device tree

Thu Nov 28, 2019 12:51 pm

Cheers, That might work.
Many thanks for all your help
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

Return to “Device Tree”