* Re: MTD EEPROM support and driver integration [not found] ` <20130706120112.GA11069@lukather> @ 2013-07-06 19:06 ` Arnd Bergmann 2013-07-06 19:55 ` Jean Delvare ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Arnd Bergmann @ 2013-07-06 19:06 UTC (permalink / raw) To: Maxime Ripard Cc: Greg Kroah-Hartman, David Woodhouse, Artem Bityutskiy, Shawn Guo, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, oliver-dxLnbx3+1qmEVqv0pETR8A, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Wolfram Sang, Jean Delvare, linux-i2c-u79uwXL29TY76Z2rM5mHXA 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MTD EEPROM support and driver integration 2013-07-06 19:06 ` MTD EEPROM support and driver integration Arnd Bergmann @ 2013-07-06 19:55 ` Jean Delvare 2013-07-07 7:15 ` Maxime Ripard 2013-07-08 8:34 ` Mark Brown 2 siblings, 0 replies; 9+ messages in thread From: Jean Delvare @ 2013-07-06 19:55 UTC (permalink / raw) To: Arnd Bergmann Cc: Maxime Ripard, Greg Kroah-Hartman, David Woodhouse, Artem Bityutskiy, Shawn Guo, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, oliver-dxLnbx3+1qmEVqv0pETR8A, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MTD EEPROM support and driver integration 2013-07-06 19:06 ` MTD EEPROM support and driver integration Arnd Bergmann 2013-07-06 19:55 ` Jean Delvare @ 2013-07-07 7:15 ` Maxime Ripard 2013-07-08 8:36 ` Mark Brown 2013-07-08 8:34 ` Mark Brown 2 siblings, 1 reply; 9+ messages in thread From: Maxime Ripard @ 2013-07-07 7:15 UTC (permalink / raw) To: Arnd Bergmann Cc: Greg Kroah-Hartman, David Woodhouse, Artem Bityutskiy, Shawn Guo, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, oliver-dxLnbx3+1qmEVqv0pETR8A, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Wolfram Sang, Jean Delvare, linux-i2c-u79uwXL29TY76Z2rM5mHXA [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MTD EEPROM support and driver integration 2013-07-07 7:15 ` Maxime Ripard @ 2013-07-08 8:36 ` Mark Brown [not found] ` <20130708083614.GP27646-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 0 siblings, 1 reply; 9+ messages in thread From: Mark Brown @ 2013-07-08 8:36 UTC (permalink / raw) To: Maxime Ripard Cc: Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Artem Bityutskiy, Shawn Guo, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, oliver-dxLnbx3+1qmEVqv0pETR8A, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Wolfram Sang, Jean Delvare, linux-i2c-u79uwXL29TY76Z2rM5mHXA [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <20130708083614.GP27646-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>]
* Re: MTD EEPROM support and driver integration [not found] ` <20130708083614.GP27646-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> @ 2013-07-08 21:04 ` Maxime Ripard 0 siblings, 0 replies; 9+ messages in thread From: Maxime Ripard @ 2013-07-08 21:04 UTC (permalink / raw) To: Mark Brown Cc: Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Artem Bityutskiy, Shawn Guo, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, oliver-dxLnbx3+1qmEVqv0pETR8A, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Wolfram Sang, Jean Delvare, linux-i2c-u79uwXL29TY76Z2rM5mHXA [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MTD EEPROM support and driver integration 2013-07-06 19:06 ` MTD EEPROM support and driver integration Arnd Bergmann 2013-07-06 19:55 ` Jean Delvare 2013-07-07 7:15 ` Maxime Ripard @ 2013-07-08 8:34 ` Mark Brown [not found] ` <20130708083426.GO27646-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 2 siblings, 1 reply; 9+ messages in thread From: Mark Brown @ 2013-07-08 8:34 UTC (permalink / raw) To: Arnd Bergmann Cc: Maxime Ripard, Greg Kroah-Hartman, David Woodhouse, Artem Bityutskiy, Shawn Guo, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, oliver-dxLnbx3+1qmEVqv0pETR8A, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Wolfram Sang, Jean Delvare, linux-i2c-u79uwXL29TY76Z2rM5mHXA [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <20130708083426.GO27646-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>]
* Re: MTD EEPROM support and driver integration [not found] ` <20130708083426.GO27646-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> @ 2013-07-08 20:25 ` Maxime Ripard 2013-07-09 14:55 ` Mark Brown 0 siblings, 1 reply; 9+ messages in thread From: Maxime Ripard @ 2013-07-08 20:25 UTC (permalink / raw) To: Mark Brown Cc: Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Artem Bityutskiy, Shawn Guo, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, oliver-dxLnbx3+1qmEVqv0pETR8A, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Wolfram Sang, Jean Delvare, linux-i2c-u79uwXL29TY76Z2rM5mHXA [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: MTD EEPROM support and driver integration 2013-07-08 20:25 ` Maxime Ripard @ 2013-07-09 14:55 ` Mark Brown [not found] ` <20130709145510.GZ27646-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> 0 siblings, 1 reply; 9+ messages in thread From: Mark Brown @ 2013-07-09 14:55 UTC (permalink / raw) To: Maxime Ripard Cc: Arnd Bergmann, Artem Bityutskiy, oliver, Greg Kroah-Hartman, Wolfram Sang, linux-kernel, linux-mtd, linux-i2c, Jean Delvare, Shawn Guo, David Woodhouse, linux-arm-kernel [-- 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <20130709145510.GZ27646-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>]
* Re: MTD EEPROM support and driver integration [not found] ` <20130709145510.GZ27646-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> @ 2013-07-11 17:05 ` Maxime Ripard 0 siblings, 0 replies; 9+ messages in thread From: Maxime Ripard @ 2013-07-11 17:05 UTC (permalink / raw) To: Mark Brown Cc: Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Artem Bityutskiy, Shawn Guo, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, oliver-dxLnbx3+1qmEVqv0pETR8A, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Wolfram Sang, Jean Delvare, linux-i2c-u79uwXL29TY76Z2rM5mHXA [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-07-11 17:05 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20130705201118.GM2959@lukather>
[not found] ` <5811519.oHVuMujf0I@wuerfel>
[not found] ` <20130706120112.GA11069@lukather>
2013-07-06 19:06 ` MTD EEPROM support and driver integration Arnd Bergmann
2013-07-06 19:55 ` Jean Delvare
2013-07-07 7:15 ` Maxime Ripard
2013-07-08 8:36 ` Mark Brown
[not found] ` <20130708083614.GP27646-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2013-07-08 21:04 ` Maxime Ripard
2013-07-08 8:34 ` Mark Brown
[not found] ` <20130708083426.GO27646-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2013-07-08 20:25 ` Maxime Ripard
2013-07-09 14:55 ` Mark Brown
[not found] ` <20130709145510.GZ27646-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2013-07-11 17:05 ` Maxime Ripard
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).