Re: MTD EEPROM support and driver integration

Re: MTD EEPROM support and driver integration

[Arnd Bergmann]

On Saturday 06 July 2013 14:01:12 Maxime Ripard wrote:
> I'm not exactly sure on what happened to the previous mail that has been
> sent empty, but anyway:
> 
> On Sat, Jul 06, 2013 at 11:18:00AM +0200, Arnd Bergmann wrote:
> > On Saturday 06 July 2013 10:28:04 Maxime Ripard wrote:
> > > > a) like interrupts, regs, dmas, clocks, pinctrl, reset, pwm: fixed property names
> > > > 
> > > >       regmap = <&at25 0xstart 0xlen>;
> > > >       regmap-names = "mac-address";
> > > > 
> > > > b) like gpio, regulator: variable property names
> > > > 
> > > >       mac-storage = <&at25 0xstart 0xlen>;
> > > > 
> > > > It's unfortunate that we already have examples of both. They are largely
> > > > equivalent, but the tendency is towards the first.
> > > 
> > > I don't have a strong feeling for one against another, so whatever works
> > > best. Both solutions will be a huge improvement anyway 
> > > 
> > > Just out of curiosity, is there any advantages besides having a fixed
> > > property name to the first solution?
> > 
> > I think it's mostly for consistency: trying to get most subsystems to
> > do it the same way to make it easier for people to write dts files.
> > 
> > A lesser point is that it simplifies the driver code if you don't
> > have to pass a name.
> 
> So that leave us with mainly one path to achieve this goal:
>   - Add a regmap-mtd backend
>   - Add DT parsing code for regmap
>   - Move the EEPROM drivers from misc to mtd

Yes, I think that would be good. For the last step, we definitely need
buy-in from Wolfgand and Jean, as they are maintaining the current eeprom
drivers.

> What other option would we have?
> 
> I also thought about writing an EEPROM framework of its own, but the
> line is really thin between a large EEPROM and say a small SPI
> dataflash, which would make it pretty hard to choose between such a
> framework and MTD.

Isn't flash by definition block based, while EEPROM can be written
in byte or word units? I think that is a significant difference, although
it doesn't necessarily mean that we can't use MTD for both.

We also have a bunch of OTP drivers spread around the kernel, it probably
makes sense to consolidate them at the same time, at least on the DT binding
side if not the device drivers.

	Arnd

Re: MTD EEPROM support and driver integration

[Jean Delvare]

On Sat, 06 Jul 2013 21:06:49 +0200, Arnd Bergmann wrote:
> On Saturday 06 July 2013 14:01:12 Maxime Ripard wrote:
> > So that leave us with mainly one path to achieve this goal:
> >   - Add a regmap-mtd backend
> >   - Add DT parsing code for regmap
> >   - Move the EEPROM drivers from misc to mtd
> 
> Yes, I think that would be good. For the last step, we definitely need
> buy-in from Wolfgand and Jean, as they are maintaining the current eeprom
> drivers.

I am maintaining the legacy eeprom driver, which nobody should be using
in conjunction with DT. So you don't need my approval for anything.

-- 
Jean Delvare

Re: MTD EEPROM support and driver integration

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1920 bytes --]

On Sat, Jul 06, 2013 at 09:06:49PM +0200, Arnd Bergmann wrote:
> On Saturday 06 July 2013 14:01:12 Maxime Ripard wrote:
> > What other option would we have?
> > 
> > I also thought about writing an EEPROM framework of its own, but the
> > line is really thin between a large EEPROM and say a small SPI
> > dataflash, which would make it pretty hard to choose between such a
> > framework and MTD.
> 
> Isn't flash by definition block based, while EEPROM can be written
> in byte or word units? I think that is a significant difference, although
> it doesn't necessarily mean that we can't use MTD for both.

Ah, right.

> We also have a bunch of OTP drivers spread around the kernel, it probably
> makes sense to consolidate them at the same time, at least on the DT binding
> side if not the device drivers.

From a quick grep, the only one I've seen so far are:
  - imx6q, that has a hook at machine start to poke into its OCOTP to
    retrieve some frequency scaling parameters it seems. I'm not sure
    how the current solution could improve the situation for this
    use-case, but the DT bindings of the OCOTP is just a DT node, with
    no clients, so we have nothing to worry about here.
  - imx28, that has a hook at machine start to look up the MAC address
    values and patch the ethernet controller nodes to add the right
    local-mac-address property. This one could benefit from the new
    bindings, but we already mentionned it, and I intended to develop
    with an imx28 board anyway.
  - picoxcell-pc3x3 DTSI has a node for a OTP device, but they don't
    seem to be doing anything with it, nor do they seem to have a driver
    for it. So I guess we don't care about migrating for this one
    either.

Did you have other cases in mind?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: MTD EEPROM support and driver integration

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]

On Sun, Jul 07, 2013 at 09:15:01AM +0200, Maxime Ripard wrote:
> On Sat, Jul 06, 2013 at 09:06:49PM +0200, Arnd Bergmann wrote:

> > We also have a bunch of OTP drivers spread around the kernel, it probably
> > makes sense to consolidate them at the same time, at least on the DT binding
> > side if not the device drivers.

> From a quick grep, the only one I've seen so far are:
>   - imx6q, that has a hook at machine start to poke into its OCOTP to
>     retrieve some frequency scaling parameters it seems. I'm not sure
>     how the current solution could improve the situation for this
>     use-case, but the DT bindings of the OCOTP is just a DT node, with
>     no clients, so we have nothing to worry about here.
>   - imx28, that has a hook at machine start to look up the MAC address
>     values and patch the ethernet controller nodes to add the right
>     local-mac-address property. This one could benefit from the new
>     bindings, but we already mentionned it, and I intended to develop
>     with an imx28 board anyway.
>   - picoxcell-pc3x3 DTSI has a node for a OTP device, but they don't
>     seem to be doing anything with it, nor do they seem to have a driver
>     for it. So I guess we don't care about migrating for this one
>     either.

> Did you have other cases in mind?

We have some OTP support in the ab8500 and wm831x MFD drivers too but
they just expose the data.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: MTD EEPROM support and driver integration

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1746 bytes --]

On Mon, Jul 08, 2013 at 09:36:14AM +0100, Mark Brown wrote:
> On Sun, Jul 07, 2013 at 09:15:01AM +0200, Maxime Ripard wrote:
> > On Sat, Jul 06, 2013 at 09:06:49PM +0200, Arnd Bergmann wrote:
> 
> > > We also have a bunch of OTP drivers spread around the kernel, it probably
> > > makes sense to consolidate them at the same time, at least on the DT binding
> > > side if not the device drivers.
> 
> > From a quick grep, the only one I've seen so far are:
> >   - imx6q, that has a hook at machine start to poke into its OCOTP to
> >     retrieve some frequency scaling parameters it seems. I'm not sure
> >     how the current solution could improve the situation for this
> >     use-case, but the DT bindings of the OCOTP is just a DT node, with
> >     no clients, so we have nothing to worry about here.
> >   - imx28, that has a hook at machine start to look up the MAC address
> >     values and patch the ethernet controller nodes to add the right
> >     local-mac-address property. This one could benefit from the new
> >     bindings, but we already mentionned it, and I intended to develop
> >     with an imx28 board anyway.
> >   - picoxcell-pc3x3 DTSI has a node for a OTP device, but they don't
> >     seem to be doing anything with it, nor do they seem to have a driver
> >     for it. So I guess we don't care about migrating for this one
> >     either.
> 
> > Did you have other cases in mind?
> 
> We have some OTP support in the ab8500 and wm831x MFD drivers too but
> they just expose the data.

I guess you mean ab8100, right?

Anyway, thanks for pointing this out

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: MTD EEPROM support and driver integration

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2424 bytes --]

On Sat, Jul 06, 2013 at 09:06:49PM +0200, Arnd Bergmann wrote:
> On Saturday 06 July 2013 14:01:12 Maxime Ripard wrote:

> > > > > a) like interrupts, regs, dmas, clocks, pinctrl, reset, pwm: fixed property names

> > > > >       regmap = <&at25 0xstart 0xlen>;
> > > > >       regmap-names = "mac-address";

> > > > > b) like gpio, regulator: variable property names

> > > > >       mac-storage = <&at25 0xstart 0xlen>;

> > > > > It's unfortunate that we already have examples of both. They are largely
> > > > > equivalent, but the tendency is towards the first.

> > > > I don't have a strong feeling for one against another, so whatever works
> > > > best. Both solutions will be a huge improvement anyway 

> > > > Just out of curiosity, is there any advantages besides having a fixed
> > > > property name to the first solution?

> > > I think it's mostly for consistency: trying to get most subsystems to
> > > do it the same way to make it easier for people to write dts files.

> > > A lesser point is that it simplifies the driver code if you don't
> > > have to pass a name.

On the other hand something with human readable names is much more
legible if humans ever have to read or write the DT bindings.  This
mostly applies when there are many instances of the property (for
example, many devices have lots of power supplies) or when some
instances of the property are optional (for example, many devices can
use GPIOs for many different functions but usually not all of them are
connected and there's no particular order in which they might get
connected).

> > So that leave us with mainly one path to achieve this goal:
> >   - Add a regmap-mtd backend
> >   - Add DT parsing code for regmap
> >   - Move the EEPROM drivers from misc to mtd

> Yes, I think that would be good. For the last step, we definitely need
> buy-in from Wolfgand and Jean, as they are maintaining the current eeprom
> drivers.

I'd really like to see more discussion of this "DT parsing code for
regmap" idea...  I've missed almost all the context here.

> We also have a bunch of OTP drivers spread around the kernel, it probably
> makes sense to consolidate them at the same time, at least on the DT binding
> side if not the device drivers.

I'm not sure how viable this is, the OTP interfaces aren't that
consistent and are frequently embedded in random PMICs or whatever.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: MTD EEPROM support and driver integration

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3669 bytes --]

On Mon, Jul 08, 2013 at 09:34:26AM +0100, Mark Brown wrote:
> On Sat, Jul 06, 2013 at 09:06:49PM +0200, Arnd Bergmann wrote:
> > On Saturday 06 July 2013 14:01:12 Maxime Ripard wrote:
> 
> > > > > > a) like interrupts, regs, dmas, clocks, pinctrl, reset, pwm: fixed property names
> 
> > > > > >       regmap = <&at25 0xstart 0xlen>;
> > > > > >       regmap-names = "mac-address";
> 
> > > > > > b) like gpio, regulator: variable property names
> 
> > > > > >       mac-storage = <&at25 0xstart 0xlen>;
> 
> > > > > > It's unfortunate that we already have examples of both. They are largely
> > > > > > equivalent, but the tendency is towards the first.
> 
> > > > > I don't have a strong feeling for one against another, so whatever works
> > > > > best. Both solutions will be a huge improvement anyway 
> 
> > > > > Just out of curiosity, is there any advantages besides having a fixed
> > > > > property name to the first solution?
> 
> > > > I think it's mostly for consistency: trying to get most subsystems to
> > > > do it the same way to make it easier for people to write dts files.
> 
> > > > A lesser point is that it simplifies the driver code if you don't
> > > > have to pass a name.
> 
> On the other hand something with human readable names is much more
> legible if humans ever have to read or write the DT bindings.  This
> mostly applies when there are many instances of the property (for
> example, many devices have lots of power supplies) or when some
> instances of the property are optional (for example, many devices can
> use GPIOs for many different functions but usually not all of them are
> connected and there's no particular order in which they might get
> connected).

I guess we would have only a few of these in our cases, so it doesn't
really qualify for the "many instances" I guess, but I do find the
GPIO/regulator-like properties more intuitive and more readable as
well.

> > > So that leave us with mainly one path to achieve this goal:
> > >   - Add a regmap-mtd backend
> > >   - Add DT parsing code for regmap
> > >   - Move the EEPROM drivers from misc to mtd
> 
> > Yes, I think that would be good. For the last step, we definitely need
> > buy-in from Wolfgand and Jean, as they are maintaining the current eeprom
> > drivers.
> 
> I'd really like to see more discussion of this "DT parsing code for
> regmap" idea...  I've missed almost all the context here.

The context was that I found we lack a way to simply express the need
for one driver to get a value from an EEPROM-like device, for example to
get a MAC Address, or a serial number, in a generic way, without having
to poke directly with some custom function that would be exported by the
EEPROM driver.

And the lack of infrastructure/framework to handle the EEPROM right now
only make the thing a bit harder.

What we've been discussing so far is that:
  - To have a common framework we could base our work on, we could move
    the EEPROM drivers from drivers/misc/eeprom to MTD
  - To declare the ranges that needed to be used by a driver that was
    needing a value from one of those MTD drivers, we would use regmap
    with a MTD backend
  - And since we actually need to declare which ranges and in which
    device one driver would have to retrieve this value from, we were
    actually in need of DT bindings.

This is pretty much the only context involved, and we are at the early
stage of the discussion, so any comment is very welcome :)

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: MTD EEPROM support and driver integration

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1825 bytes --]

On Mon, Jul 08, 2013 at 10:25:38PM +0200, Maxime Ripard wrote:
> On Mon, Jul 08, 2013 at 09:34:26AM +0100, Mark Brown wrote:

> > I'd really like to see more discussion of this "DT parsing code for
> > regmap" idea...  I've missed almost all the context here.

> The context was that I found we lack a way to simply express the need
> for one driver to get a value from an EEPROM-like device, for example to
> get a MAC Address, or a serial number, in a generic way, without having
> to poke directly with some custom function that would be exported by the
> EEPROM driver.

This sort of information is often stored in places like flash partitions
too.  Are we sure that regmap is a good place to be hooking in here?
The use case is sane, and being able to use regmap to do some of it
seems sensible (I've seen people use OTP in PMICs for similar purposes)
but perhaps an additional layer of abstraction on top makes sense.

> What we've been discussing so far is that:
>   - To have a common framework we could base our work on, we could move
>     the EEPROM drivers from drivers/misc/eeprom to MTD
>   - To declare the ranges that needed to be used by a driver that was
>     needing a value from one of those MTD drivers, we would use regmap
>     with a MTD backend
>   - And since we actually need to declare which ranges and in which
>     device one driver would have to retrieve this value from, we were
>     actually in need of DT bindings.

> This is pretty much the only context involved, and we are at the early
> stage of the discussion, so any comment is very welcome :)

If this stuff is being represented in MTD doesn't MTD already have
adequate abstractions for saying "this region in flash".  But otherwise
this seems fine, it's not a generic regmap DT binding but instead rather
more specific than that.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: MTD EEPROM support and driver integration

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2602 bytes --]

Hi Mark,

On Tue, Jul 09, 2013 at 03:55:10PM +0100, Mark Brown wrote:
> On Mon, Jul 08, 2013 at 10:25:38PM +0200, Maxime Ripard wrote:
> > On Mon, Jul 08, 2013 at 09:34:26AM +0100, Mark Brown wrote:
> 
> > > I'd really like to see more discussion of this "DT parsing code for
> > > regmap" idea...  I've missed almost all the context here.
> 
> > The context was that I found we lack a way to simply express the need
> > for one driver to get a value from an EEPROM-like device, for example to
> > get a MAC Address, or a serial number, in a generic way, without having
> > to poke directly with some custom function that would be exported by the
> > EEPROM driver.
> 
> This sort of information is often stored in places like flash partitions
> too.  Are we sure that regmap is a good place to be hooking in here?
> The use case is sane, and being able to use regmap to do some of it
> seems sensible (I've seen people use OTP in PMICs for similar purposes)
> but perhaps an additional layer of abstraction on top makes sense.

Ah, I didn't thought it could be stored into a partition. Ok, so using
an intermediate abstraction for this makes sense (probably using regmap
for all the accesses that are relevant, like i2c, spi or mmio)

> > What we've been discussing so far is that:
> >   - To have a common framework we could base our work on, we could move
> >     the EEPROM drivers from drivers/misc/eeprom to MTD
> >   - To declare the ranges that needed to be used by a driver that was
> >     needing a value from one of those MTD drivers, we would use regmap
> >     with a MTD backend
> >   - And since we actually need to declare which ranges and in which
> >     device one driver would have to retrieve this value from, we were
> >     actually in need of DT bindings.
> 
> > This is pretty much the only context involved, and we are at the early
> > stage of the discussion, so any comment is very welcome :)
> 
> If this stuff is being represented in MTD doesn't MTD already have
> adequate abstractions for saying "this region in flash".  But otherwise
> this seems fine, it's not a generic regmap DT binding but instead rather
> more specific than that.

Yes, since we seem to be going to a point where regmap will be a
convenience in this case, we probably won't need a generic regmap
binding, but rather a generic way to define a range and offset into a
referenced device.

Arnd, the others, is this ok for you?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]