Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1589767
| From | Lars-Peter Clausen <lars@metafoo.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2 2/3] spi: allocate spi_board_info entries one by one |
| Date | 2017-02-28 22:00 +0100 |
| Message-ID | <tfX2h-15p-19@gated-at.bofh.it> (permalink) |
| References | <tfHAd-7Cn-3@gated-at.bofh.it> <tfHAe-7Cn-7@gated-at.bofh.it> <tfM6S-2qh-17@gated-at.bofh.it> <tfWfU-NX-21@gated-at.bofh.it> <tfWfU-NX-19@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 02/28/2017 07:54 PM, Mark Brown wrote: > On Tue, Feb 28, 2017 at 10:24:17AM -0800, Dmitry Torokhov wrote: >> On Tue, Feb 28, 2017 at 09:16:50AM +0000, Mark Brown wrote: >>> On Mon, Feb 27, 2017 at 08:18:56PM -0800, Dmitry Torokhov wrote: >>>> Lists of spi_board_info entries registered with spi_register_board_info() >>>> can be quite long; instead of forcing memory allocator find contagious > >>> Do you have numbers on that? > >> Hm, so the largest array seems to be in >> arch/blackfin/mach-bf537/boards/stamp.c at max of 43 entries. The new >> board info is ether 60 or 72 bytes, so we get 2 or 3K table. Not above >> page, but still could be packed I think. > > Oh wow, that's impressively large. Still not sure the optimization is > particularly worth it though, it's small change in the grand scheme of > things. OTOH it's a small change. The Blackfin machine files shouldn't be used as valid example. While in theory it is possible to build a kernel with that many entries nobody is ever going to do that. What the Blackfin machine files do is basically a poor man's overlays from the days before overlays existed. Most of the entries in the table use the same chip-select pins, it wouldn't be possible to use use a setup where more than two or three of the entries is enabled at the same time.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v2 2/3] spi: allocate spi_board_info entries one by one Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-02-28 05:30 +0100
Re: [PATCH v2 2/3] spi: allocate spi_board_info entries one by one Mark Brown <broonie@kernel.org> - 2017-02-28 10:20 +0100
Re: [PATCH v2 2/3] spi: allocate spi_board_info entries one by one Mark Brown <broonie@kernel.org> - 2017-02-28 21:10 +0100
Re: [PATCH v2 2/3] spi: allocate spi_board_info entries one by one Geert Uytterhoeven <geert@linux-m68k.org> - 2017-02-28 21:20 +0100
Re: [PATCH v2 2/3] spi: allocate spi_board_info entries one by one Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-02-28 23:20 +0100
Re: [PATCH v2 2/3] spi: allocate spi_board_info entries one by one Lars-Peter Clausen <lars@metafoo.de> - 2017-02-28 22:00 +0100
Re: [PATCH v2 2/3] spi: allocate spi_board_info entries one by one Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-03-01 03:20 +0100
csiph-web