From: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> To: Martin Sperl <martin-d5rIkyn9cnPYtjvyW6yDsg@public.gmane.org> Cc: Heiner Kallweit <hkallweit1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, "linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> Subject: Re: RfC: Handle SPI controller limitations like maximum message length Date: Sat, 21 Nov 2015 13:49:46 +0000 [thread overview] Message-ID: <20151121134946.GI26072@sirena.org.uk> (raw) In-Reply-To: <08871ECD-52DF-4CBF-AF3D-4C3A442C008A-d5rIkyn9cnPYtjvyW6yDsg@public.gmane.org> [-- Attachment #1: Type: text/plain, Size: 2223 bytes --] On Fri, Nov 20, 2015 at 01:56:13PM +0100, Martin Sperl wrote: > > Every line of code that's in a driver that could be in the core is a > > maintainence burden, people will want to start doing things like > > combining functions in fun ways and if we want to try to do things like > > figure out if we can coalesce adjacent transfers in the core (which we > > really ought to) it won't know what the limitations that exist are. > this “colaesce” of transfers into one could be one of those > “transformation” I am talking about - and this one would be implemented > in core making certain assumptions (like starting on a page, ...) Why would we want to force that assumption? It massively reduces the utility for DMA controllers that don't have such limitations. > >> I wonder if such a variant-construct does not create more headaches in > >> the long run as each spi_driver wanting to do something “something” > >> special would then need to get updated for any additional constraint… > > I'm sorry but I don't understand what you mean here. However we > > implement things anything that wants to know about constraints is going > > to need to be updated to use them. > That is what I want to avoid if possible - the one thing that may come > handy (at least from my perspective) could be to give some hints to > make optimal use of the HW > Say: > * preferred alignment on X byte boundry > * preferred max spi_transfer.length > All the other possible constraints parameters should be opaque to > a spi_device driver, so I would not want to include those inside the > spi_master structure, as _then_ these get used. You're conflating two unrelated design decisions here. Yes, it's unfortunate that the SPI API was written to allow client drivers to see the master structure but that doesn't mean that converting data into code is a good idea, that's still a bad pattern independently of the visibility issue. > Also the “restrictions” on the spi HW need to get defined inside the > driver, so there will not be a new “restriction” that applies to > an existing piece of HW just because we incorporate new options. That's what I was saying? [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 473 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org> To: Martin Sperl <martin@sperl.org> Cc: Heiner Kallweit <hkallweit1@gmail.com>, Brian Norris <computersforpeace@gmail.com>, linux-mtd@lists.infradead.org, "linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org> Subject: Re: RfC: Handle SPI controller limitations like maximum message length Date: Sat, 21 Nov 2015 13:49:46 +0000 [thread overview] Message-ID: <20151121134946.GI26072@sirena.org.uk> (raw) In-Reply-To: <08871ECD-52DF-4CBF-AF3D-4C3A442C008A@sperl.org> [-- Attachment #1: Type: text/plain, Size: 2223 bytes --] On Fri, Nov 20, 2015 at 01:56:13PM +0100, Martin Sperl wrote: > > Every line of code that's in a driver that could be in the core is a > > maintainence burden, people will want to start doing things like > > combining functions in fun ways and if we want to try to do things like > > figure out if we can coalesce adjacent transfers in the core (which we > > really ought to) it won't know what the limitations that exist are. > this “colaesce” of transfers into one could be one of those > “transformation” I am talking about - and this one would be implemented > in core making certain assumptions (like starting on a page, ...) Why would we want to force that assumption? It massively reduces the utility for DMA controllers that don't have such limitations. > >> I wonder if such a variant-construct does not create more headaches in > >> the long run as each spi_driver wanting to do something “something” > >> special would then need to get updated for any additional constraint… > > I'm sorry but I don't understand what you mean here. However we > > implement things anything that wants to know about constraints is going > > to need to be updated to use them. > That is what I want to avoid if possible - the one thing that may come > handy (at least from my perspective) could be to give some hints to > make optimal use of the HW > Say: > * preferred alignment on X byte boundry > * preferred max spi_transfer.length > All the other possible constraints parameters should be opaque to > a spi_device driver, so I would not want to include those inside the > spi_master structure, as _then_ these get used. You're conflating two unrelated design decisions here. Yes, it's unfortunate that the SPI API was written to allow client drivers to see the master structure but that doesn't mean that converting data into code is a good idea, that's still a bad pattern independently of the visibility issue. > Also the “restrictions” on the spi HW need to get defined inside the > driver, so there will not be a new “restriction” that applies to > an existing piece of HW just because we incorporate new options. That's what I was saying? [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2015-11-21 13:49 UTC|newest] Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-11-18 21:19 RfC: Handle SPI controller limitations like maximum message length Heiner Kallweit 2015-11-18 21:19 ` Heiner Kallweit [not found] ` <564CEB61.2000601-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2015-11-18 21:57 ` Mark Brown 2015-11-18 21:57 ` Mark Brown [not found] ` <20151118215755.GL31303-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2015-11-18 22:50 ` Heiner Kallweit 2015-11-18 22:50 ` Heiner Kallweit [not found] ` <564D0098.4030107-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2015-11-19 11:40 ` Mark Brown 2015-11-19 11:40 ` Mark Brown [not found] ` <20151119114057.GN31303-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2015-11-19 15:00 ` Martin Sperl 2015-11-19 15:00 ` Martin Sperl [not found] ` <F224F5F3-FAD5-47FE-9419-39E53BCBB8C6-d5rIkyn9cnPYtjvyW6yDsg@public.gmane.org> 2015-11-19 17:15 ` Mark Brown 2015-11-19 17:15 ` Mark Brown [not found] ` <20151119171538.GO31303-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2015-11-20 0:07 ` Brian Norris 2015-11-20 0:07 ` Brian Norris [not found] ` <20151120000746.GQ64635-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2015-11-20 11:06 ` Mark Brown 2015-11-20 11:06 ` Mark Brown [not found] ` <20151120110616.GR31303-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2015-11-20 11:16 ` Martin Sperl 2015-11-20 11:16 ` Martin Sperl 2015-11-20 10:18 ` Martin Sperl 2015-11-20 10:18 ` Martin Sperl [not found] ` <9CDADBED-FD18-4635-82A9-5AB14C9ABCAE-d5rIkyn9cnPYtjvyW6yDsg@public.gmane.org> 2015-11-20 12:05 ` Mark Brown 2015-11-20 12:05 ` Mark Brown [not found] ` <20151120120502.GT31303-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2015-11-20 12:56 ` Martin Sperl 2015-11-20 12:56 ` Martin Sperl [not found] ` <08871ECD-52DF-4CBF-AF3D-4C3A442C008A-d5rIkyn9cnPYtjvyW6yDsg@public.gmane.org> 2015-11-21 13:49 ` Mark Brown [this message] 2015-11-21 13:49 ` Mark Brown [not found] ` <20151121134946.GI26072-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2015-11-21 14:10 ` Heiner Kallweit 2015-11-21 14:10 ` Heiner Kallweit [not found] ` <56507B3B.4080608-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2015-11-21 15:57 ` Michal Suchanek 2015-11-21 15:57 ` Michal Suchanek [not found] ` <CAOMqctR=UDEPbgJDY3YvxpbVEEp4t6ajkyv=cVAZp2fLBNBanA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-11-21 22:59 ` [PATCH 0/3] spi: mtd: Handle HW message length restrictions Heiner Kallweit 2015-11-21 22:59 ` Heiner Kallweit 2015-11-21 23:01 ` [PATCH 1/3] spi: core: add max_msg_size to spi_master Heiner Kallweit 2015-11-21 23:01 ` Heiner Kallweit [not found] ` <5650F7D4.1090209-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2015-11-22 13:16 ` Mark Brown 2015-11-22 13:16 ` Mark Brown [not found] ` <20151122131626.GN26072-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2015-11-22 16:15 ` Heiner Kallweit 2015-11-22 16:15 ` Heiner Kallweit [not found] ` <5651EA08.5090400-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2015-11-23 11:38 ` Mark Brown 2015-11-23 11:38 ` Mark Brown [not found] ` <20151123113846.GH1929-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2015-11-27 19:26 ` Heiner Kallweit 2015-11-27 19:26 ` Heiner Kallweit [not found] ` <5658AE7C.3050507-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2015-11-30 16:42 ` Mark Brown 2015-11-30 16:42 ` Mark Brown [not found] ` <20151130164223.GE1929-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2015-11-30 20:15 ` Heiner Kallweit 2015-11-30 20:15 ` Heiner Kallweit 2015-11-21 23:08 ` [PATCH 2/3] mtd: m25p80: handle HW message size restrictions Heiner Kallweit 2015-11-21 23:08 ` Heiner Kallweit [not found] ` <5650F952.2060409-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2015-11-22 12:51 ` Michal Suchanek 2015-11-22 12:51 ` Michal Suchanek 2015-11-21 23:11 ` [PATCH 3/3] spi: fsl-espi: make use of max_msg_size in spi_master to handle HW restrictions Heiner Kallweit 2015-11-21 23:11 ` Heiner Kallweit 2015-11-30 20:24 ` [PATCH v2 1/2] spi: core: add max_msg_size to spi_master Heiner Kallweit 2015-11-30 20:24 ` Heiner Kallweit 2015-11-30 20:25 ` [PATCH resubmit 2/2] spi: fsl-espi: make use of max_msg_size in spi_master to handle HW restrictions Heiner Kallweit 2015-11-30 20:25 ` Heiner Kallweit [not found] ` <565CB0C0.9060104-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2015-12-01 14:19 ` Mark Brown 2015-12-01 14:19 ` Mark Brown [not found] ` <20151201141923.GJ1929-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2015-12-01 18:53 ` Heiner Kallweit 2015-12-01 18:53 ` Heiner Kallweit 2015-11-22 13:19 ` RfC: Handle SPI controller limitations like maximum message length Mark Brown 2015-11-22 13:19 ` Mark Brown 2015-11-20 0:02 ` Brian Norris 2015-11-20 0:02 ` Brian Norris [not found] ` <20151120000226.GP64635-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2015-11-20 6:59 ` Heiner Kallweit 2015-11-20 6:59 ` Heiner Kallweit [not found] ` <564EC4E0.90602-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2015-11-20 10:06 ` Heiner Kallweit 2015-11-20 10:06 ` Heiner Kallweit [not found] ` <CAFSsGVsJBi6yPin7X9MCS8LD6nygjynfgDgFicjojkm0rOJSJw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-11-20 12:35 ` Mark Brown 2015-11-20 12:35 ` Mark Brown [not found] ` <20151120123540.GC1929-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2015-11-20 18:59 ` Heiner Kallweit 2015-11-20 18:59 ` Heiner Kallweit [not found] ` <564F6D99.8090203-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2015-11-20 19:05 ` Michal Suchanek 2015-11-20 19:05 ` Michal Suchanek [not found] ` <CAOMqctTt=78C4m2jjMb9mRBOkoZ5uZ4neVm0NS39iNO8otn=dA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-11-20 19:21 ` Mark Brown 2015-11-20 19:21 ` Mark Brown [not found] ` <20151120192157.GF1929-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2015-11-20 19:44 ` Michal Suchanek 2015-11-20 19:44 ` Michal Suchanek 2015-11-20 23:22 ` Brian Norris 2015-11-20 23:22 ` Brian Norris [not found] ` <20151120232211.GA64635-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2015-11-21 22:53 ` Heiner Kallweit 2015-11-21 22:53 ` Heiner Kallweit 2015-11-20 19:18 ` Mark Brown 2015-11-20 19:18 ` Mark Brown [not found] ` <20151120191842.GE1929-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2015-11-20 19:37 ` Heiner Kallweit 2015-11-20 19:37 ` Heiner Kallweit 2015-11-20 12:31 ` Mark Brown 2015-11-20 12:31 ` Mark Brown 2015-11-20 12:56 ` Michal Suchanek 2015-11-20 12:56 ` Michal Suchanek [not found] ` <CAOMqctQo58yCfzU3u=u3N0zNfhQph2Pw2vnrxsVvAEXi5n2HRw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-11-20 23:07 ` Brian Norris 2015-11-20 23:07 ` Brian Norris
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=20151121134946.GI26072@sirena.org.uk \ --to=broonie-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \ --cc=computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=hkallweit1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=martin-d5rIkyn9cnPYtjvyW6yDsg@public.gmane.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: linkBe 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.