All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Adrian Fiergolski <adrian.fiergolski@fastree3d.com>
Cc: Lukas Wunner <lukas@wunner.de>, Mark Brown <broonie@kernel.org>,
	kernel test robot <lkp@intel.com>,
	Rob Herring <robh+dt@kernel.org>,
	linux-spi <linux-spi@vger.kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] spi: Add the SPI daisy chain support.
Date: Mon, 6 Jul 2020 21:57:53 +0200	[thread overview]
Message-ID: <CAMuHMdXK92qO8KB6ejc6LLmfFsy=dZY18vNJGh+CKRZBAov-JA@mail.gmail.com> (raw)
In-Reply-To: <20200706161810.GB6176@sirena.org.uk>

Hi Adrian,

On Mon, Jul 6, 2020 at 6:18 PM Mark Brown <broonie@kernel.org> wrote:
> On Mon, Jul 06, 2020 at 11:22:43AM +0200, Adrian Fiergolski wrote:
> > The implementation is transparent for the SPI devices and doesn't require
> > their modifications. It is based on a virtual SPI device (spi-daisy_chain)
> > and defines two required device tree properties ('spi-daisy-chain-len' and
> > 'spi-daisy-chain-noop') and one optional
>
> It would really help to have an example of how a client device will use
> this, right now it's a bit hard to follow.  Overall it feels like this
> should be better abstracted, right now there's lots of ifdefs throughout
> the code which make things unclear and also seem like they're going to
> be fragile long term since realistically very few systems will be using
> this.

Can't the ifdefs be avoided by implementing this as a new SPI controller?
I.e. the daisy chain driver will operate as a slave of the parent SPI
controller,
but will expose a new SPI bus to the daisy-chained slaves.

> Perhaps this needs to be a library for devices that can daisy
> chain?  It does feel like the instances should be aware of each other
> since half the point with building the hardware like this is that it
> enables operations on multiple devices to happen in sync.

Indeed. Exposing that functionality is the interesting, but hard part.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

  reply	other threads:[~2020-07-06 19:58 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-03 14:12 [PATCH 1/2] spi: Add the SPI daisy chain support Adrian Fiergolski
2020-07-03 14:12 ` [PATCH 2/2] dt-bindings: Add documentation for SPI daisy chain driver Adrian Fiergolski
2020-07-03 22:32 ` [PATCH 1/2] spi: Add the SPI daisy chain support kernel test robot
2020-07-03 22:32   ` kernel test robot
2020-07-04  0:18 ` kernel test robot
2020-07-04  0:18   ` kernel test robot
2020-07-06  9:22   ` [PATCH v2 " Adrian Fiergolski
2020-07-06  9:22     ` [PATCH v2 2/2] dt-bindings: Add documentation for SPI daisy chain driver Adrian Fiergolski
2020-07-06 15:10       ` Geert Uytterhoeven
2020-07-06 15:19         ` Adrian Fiergolski
2020-07-06 15:32           ` Geert Uytterhoeven
2020-07-06 16:22             ` Mark Brown
2020-07-07  9:55               ` Adrian Fiergolski
2020-07-06 16:18     ` [PATCH v2 1/2] spi: Add the SPI daisy chain support Mark Brown
2020-07-06 19:57       ` Geert Uytterhoeven [this message]
2020-07-07 10:25         ` Mark Brown
2020-07-07 11:06           ` Adrian Fiergolski
2020-07-07 10:53       ` Adrian Fiergolski
2020-07-07 11:21         ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMuHMdXK92qO8KB6ejc6LLmfFsy=dZY18vNJGh+CKRZBAov-JA@mail.gmail.com' \
    --to=geert@linux-m68k.org \
    --cc=adrian.fiergolski@fastree3d.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=lukas@wunner.de \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.