On Tue, Jul 19, 2022 at 12:54:18AM +0200, Linus Walleij wrote:
> On Mon, Jul 18, 2022 at 10:22 PM Uwe Kleine-König
> <u.kleine-koenig@xxxxxxxxxxxxxx> wrote:
>
> > we have a customer board here that uses two 8 port latches to drive
> > LEDs. The setup looks as follows:
>
> Very nice drawing!
>
> > So to change output 2 of latch #1 you have to apply the changed level on
> > IN2, apply the previous level on the other inputs (to keep the other
> > outputs constant) and toggle CLK1 once.
> >
> > This way you can drive 16 LEDs (or in general outputs) using only 10
> > GPIOs. (And with a higher number of latches the proportion becomes a bit
> > more useful.)
> >
> > Actually this construct is a general GPO (no input :-) controller, and I
> > wonder if you would accept a driver that models it as a gpio controller.
>
> In my opinion, yes.
ok, fine.
> > The dt binding could look as follows:
> >
> > latch-gpo {
> > compatible = "latch-gpo";
> > pinctrl-0 = <...>;
> > pinctrl-names = <...>;
> >
> > clk-gpios = /* CLK0 */ <...>, /* CLK1 */ <...>;
> > data-gpios = /* IN0 */ <...>, /* IN1 */ <...>, ...;
> > };
> >
> > What do you think?
>
> I would use the actual 74xx numbers for the TTL circuits in the compatible.
To be actually useful I need at least two latches. In my case their
name is SN74LS273. (https://www.ti.com/lit/ds/symlink/sn74ls273.pdf)
So I hesitate to call this "ti,sn74ls273" because that would suggest a
single such chip?!
> I have actually merged this placeholder (without bindings nor driver):
>
> /*
> * 74HC4094 which is used as a rudimentary GPIO expander
> * FIXME:
> * - Create device tree bindings for this as GPIO expander
> * - Write a pure DT GPIO driver using these bindings
> * - Support cascading in the style of gpio-74x164.c (cannot
> be reused, very different)
> */
> gpio_74: gpio-74hc4094 {
> compatible = "nxp,74hc4094";
> cp-gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
> d-gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
> str-gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
> /* oe-gpios is optional */
> gpio-controller;
> #gpio-cells = <2>;
> /* We are not cascaded */
> registers-number = <1>;
> gpio-line-names = "CONTROL_HSS0_CLK_INT",
> "CONTROL_HSS1_CLK_INT", "CONTROL_HSS0_DTR_N",
> "CONTROL_HSS1_DTR_N", "CONTROL_EXT",
> "CONTROL_AUTO_RESET",
> "CONTROL_PCI_RESET_N", "CONTROL_EEPROM_WC_N";
> };
This is different (as Andy pointed out): With this chip you have to
clock in the $n values serially while with my approach you have a
parallel input.
I think for the serial approach you don't even need to consider a
register-number. IIUC a cascade just behaves like a single chip with
more stages, right? Then I'd not specify a "registers-number" but a
number of stages. And then that's just (as Andy pointed out) a spi
device. I would represent that as follows:
spi {
compatible = "spi-gpio";
#address-cells = <0x1>;
#size-cells = <0x0>;
sck-gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
//miso-gpios = ??
mosi-gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
cs-gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
num-chipselects = <1>;
gpio-74hc4094 {
compatible = "nxp,74hc4094";
reg = <0>;
oe-gpios = <...>; /* optional */
num-stages = <8>; /* = default value */
gpio-controller;
#gpio-cells = <2>;
gpio-line-names = ...;
};
}
(And if you have a "native" spi bus, even better.) This way the
nxp,74hc4094 driver becomes way easier.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature
