Re: [PATCH v6 01/24] i2c-mux: add common data for every i2c-mux instance

* Re: [PATCH v6 01/24] i2c-mux: add common data for every i2c-mux instance
@ 2016-04-15 15:52 Peter Rosin
  0 siblings, 0 replies; 5+ messages in thread
From: Peter Rosin @ 2016-04-15 15:52 UTC (permalink / raw)
  To: Wolfram Sang, Peter Rosin
  Cc: linux-kernel, Jonathan Corbet, Peter Korsgaard, Guenter Roeck,
	Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
	Peter Meerwald, Antti Palosaari, Mauro Carvalho Chehab,
	Rob Herring, Frank Rowand, Grant Likely, Andrew Morton,
	Greg Kroah-Hartman, David S. Miller, Kalle Valo, Joe Perches,
	Jiri Slaby, Daniel Baluta, Adriana Reus, Lucas De Marchi,
	Matt Ranostay, Krzysztof Kozlowski, Terry Heo, Hans Verkuil,
	Arnd Bergmann, Tommi Rantala, linux-i2c, linux-doc, linux-iio,
	linux-media, devicetree

Wolfram Sang wrote:
> > > wonder even more if we couldn't supply num_adapters to i2c_mux_alloc()
> > > and reserve the memory statically. i2c busses are not
> > > dynamic/hot-pluggable so that should be good enough?
> > 
> > Yes, that would work, but it would take some restructuring in some of
> > the drivers that currently don't know how many child adapters they
> > are going to need when they call i2c_mux_alloc.
> 
> Which ones?

If you look at i2c-mux-reg.c, it currently allocates its private
struct regmux, then fills it with various platform things and then
when it knows how many children it needs it allocates them. After
v6 it first allocates a mux core and private struct regmux in one go
using i2c_mux_alloc, then continues in much the same way as before.

If the number of children is needed for the i2c_mux_alloc call, then
this is certainly doable, and it would probably not be all that bad,
but the simplest approach would probably be to allocate the private
struct regmux first, then dig through the platform data, then allocate
the mux core when the number of children is known. Which would still
be two allocations separated by the platform data dig.

So, your suggestion would basically move the mux core allocation
from generally being done early together with other private data to
later when the driver has figured out how many children it's going
to create.

The restructuring I thought about is needed if the intention of this
was to reduce number of allocations, but maybe you just wanted
what I described above? Because what I did in v6 and what you are
suggesting is quite similar in complexity, but your version has the
advantage of not having the need for realloc.

So, I have made this change locally (and the adapters->num_adapters
change) and I like it. I haven't even compile-tested it yet though,
but I'll get back when I have done some testing.

> > Because you thought about removing i2c_mux_reserve_adapters completely,
> > and not provide any means of adding more adapters than specified in
> > the i2c_mux_alloc call, right?
> 
> Yes. I assumed I2C to be static enough that such information is known in
> advance.
> 
> > > Ignoring the 80 char limit here makes the code more readable.
> > 
> > That is only true if you actually have more than 80 characters, so I don't
> > agree. Are you adamant about it? (I'm not)
> 
> No. Keep it if you prefer it.
> 
> > >> +EXPORT_SYMBOL_GPL(i2c_mux_one_adapter);
> > > 
> > > Are you sure the above function pays off? Its argument list is very
> > > complex and it doesn't save a lot of code. Having seperate calls is
> > > probably more understandable in drivers? Then again, I assume it makes
> > > the conversion of existing drivers easier.
> > 
> > I added it in v4, you can check earlier versions if you like. Without
> > it most gate-muxes (i.e. typically the muxes in drivers/media) grew
> > since the i2c_add_mux_adapter call got replaced by two calls, i.e.
> > i2c_mux_alloc followed by i2c_max_add_adapter, and coupled with
> > error checks made it look more complex than before. So, this wasn't
> > much of a cleanup from the point of those drivers.
> 
> Hmm, v3 didn't have the driver patches posted with it. Can you push it
> to your branch? I am also not too strong with this one, but having a
> look how it looks without would be nice.

Although I'm not sure what you meant by "driver patches", I have pushed
mux-core-and-locking-2 and mux-core-and-locking-3 to
https://github.com/peda-r/i2c-mux/ (note that these are the branches as
they where when I posted v2 and v3 to the list, i.e. w/o fixups)

Those early versions updated all drivers with each change, making each
patch big, so if that was what you meant by missing "driver patches" then
there simply were no driver patches.

If you meant the follow-up patches to relax locking in the media drivers
etc, I only compile-tested them using throwaway branches back then (if I
even had branches). So, I don't have anything ready to push, sorry.

Cheers,
Peter

^ permalink raw reply	[flat|nested] 5+ messages in thread