Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220721093422.2173982-1-marcus.folkesson@gmail.com>
 <CAHp75VddBhc9peHXfNfTyTNni246kC8CyLqCrMFadn67LGDarQ@mail.gmail.com>
 <CACRpkdaczrU1tM5Yt7P-Q2h+ge8STOi6HvvYeTM-g+JwS8_gZw@mail.gmail.com> <CAHp75VfaExrFYto7LWa5Vnbm6JbiAqtutKmk0HzfeHmmi3PwOg@mail.gmail.com>
In-Reply-To: <CAHp75VfaExrFYto7LWa5Vnbm6JbiAqtutKmk0HzfeHmmi3PwOg@mail.gmail.com>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Tue, 26 Jul 2022 00:22:17 +0200
Message-ID: <CACRpkdYHgD-fmt_2PWJrmyGY=AOP0Z+4jTkH=n3wJ+a0aApqcg@mail.gmail.com>
Subject: Re: [PATCH 1/2] gpio: gpio-74x164: add support for CDx4HC4094
To:     Andy Shevchenko <andy.shevchenko@gmail.com>
Cc:     Marcus Folkesson <marcus.folkesson@gmail.com>,
        Bartosz Golaszewski <brgl@bgdev.pl>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Maxime Ripard <mripard@kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
        devicetree <devicetree@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Jul 25, 2022 at 10:49 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Mon, Jul 25, 2022 at 3:54 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Mon, Jul 25, 2022 at 11:32 AM Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> > > On Thu, Jul 21, 2022 at 11:32 AM Marcus Folkesson
> > > <marcus.folkesson@gmail.com> wrote:
>
> ...
>
> > > Sorry for my absence of understanding, but why?
> > > SPI has MOSI, CLK, CS, where the last one is exactly for that. No?
> >
> > Forgive me if I misunderstand, but if you use CS that
> > way, the way that the SPI framework works is to assert
> > CS then transfer a few chunks over SPI (MOSI/CLK)
> > then de-assert CS.
>
> No, CS here is used exactly for what it is designed for ("tell that
> this message is *for me*"). Yes, hardware implementation here is a
> latch register. Because otherwise ALL messages are "for me" which is
> wrong. Is it wrong interpretation of the hardware and SPI?

I was under the impression that the shift register has no idea
if the message is "for me", and that there can only be one shift register
on the bus if using ordinary SPI to control it.

I look at this data sheet:
https://www.farnell.com/datasheets/2030250.pdf

IIUC what you say is CS == STR?

> > If CS is used for strobe, it is constantly asserted
> > during transfer and the sequence will be latched
> > out immediately as you write the SPI transfers and
> > the data is clocked through the register, making the
> > whole train of zeroes and ones flash across the
> > output pins before they stabilize after the SPI
> > transfer is finished.
>
> I'm not sure I understand the stabilization issue here. It's how SPI
> normally works and we have a lot of delays here and there related to
> the phase of the CS in comparison to clock and data. We have a lot of
> time to stabilize the outputs of the shift register before latching
> it. Did I miss anything?

STR (strobe) is latching out the data, and how is that happening
when you connect it to CS? CS is asserted throughout the whole
transaction...

STR is supposed to be used like in the patch: to be toggled after
the transfer is complete. CS does not behave like this at all.

> > If you first do the SPI transfer, then strobe after
> > finished, this will not happen.
>
> I have hardware, I have tested it and I understand what you mean by
> "stabilizing", but finishing transfer _is_ CS toggling for _this_
> chip. No?

Well it will work, because all values come out, however *during*
the transfer, not *after* the transfer as intended with the
STR signal.

> > Then it should be a separate pin, so this doesn't
> > happen, right?
>
> I think no, you don't need it. I.o.w. either I'm missing something
> very interesting about both this kind of chips and SPI basics (shame
> on me in this case) or...?

SPI will assert CS, then make the transfer i.e. toggle the clock
a few times with new data on MOSI each clock cycle, then
de-assert CS.

STR is supposed to be toggled after all this happened to latch
out the data to the outputs, just like the patch does.

What happens if STR is connected to CS is that you will see
the shift register contents change on the output. It will be
fast so it will look fine if it is e.g. a LED. But if it is something
more sensitive, there will be chaos.

At least how I see it ...?

Yours,
Linus Walleij