From: srinivas.kandagatla@linaro.org (Srinivas Kandagatla)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 1/3] eeprom: Add a simple EEPROM framework
Date: Tue, 24 Feb 2015 07:08:40 +0000 [thread overview]
Message-ID: <54EC2378.5040202@linaro.org> (raw)
In-Reply-To: <54EBB3AC.30000@codeaurora.org>
Thanks Stephen for the comments.
On 23/02/15 23:11, Stephen Boyd wrote:
> On 02/22/15 16:57, Rob Herring wrote:
>> On Sun, Feb 22, 2015 at 8:32 AM, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>>> On Fri, Feb 20, 2015 at 04:01:55PM -0600, Rob Herring wrote:
>>>> [...]
>>>>
>>>>>>> += Data consumers =
>>>>>>> +
>>>>>>> +Required properties:
>>>>>>> +
>>>>>>> +eeproms: List of phandle and data cell specifier triplet, one triplet
>>>>>>> + for each data cell the device might be interested in. The
>>>>>>> + triplet consists of the phandle to the eeprom provider, then
>>>>>>> + the offset in byte within that storage device, and the length
>>>>>>> + in byte of the data we care about.
>>>>>>
>>>>>> The problem with this is it assumes you know who the consumer is and
>>>>>> that it is a DT node. For example, how would you describe a serial
>>>>>> number?
>>>>> Correct me if I miss understood.
>>>>> Is serial number any different?
>>>>> Am hoping that the eeprom consumer would be aware of offset and size of
>>>>> serial number in the eeprom
>>>>>
>>>>> Cant the consumer do:
>>>>>
>>>>> eeprom-consumer {
>>>>> eeproms = <&at24 0 4>;
>>>>> eeprom-names = "device-serial-number";
>>>> Yes, but who is "eeprom-consumer"?
>>> Any device that should lookup values in one of the EEPROM.
>>>
>>>> DT nodes generally describe a h/w block, but it this case, the
>>>> consumer depends on the OS, not the h/w.
>>> Not really, or at least, not more than any similar binding we
>>> currently have.
>>>
>>> The fact that a MAC-address for the first ethernet chip is stored at a
>>> given offset in a given eeprom has nothing to do with the OS.
>> So MAC address would be a valid use to link to a h/w device, but there
>> are certainly cases that don't correspond to a device.
>>
>>>> I'm not saying you can't describe where things are, but I don't
>>>> think you should imply who is the consumer and doing so is
>>>> unnecessarily complicated.
>>> If you only take the case of a serial number, indeed. If you take
>>> other usage into account, you can't really do without it.
>>>
>>>> Also, the layout of EEPROM is likely very much platform specific.
>>> Indeed, which is why it should be in the DT.
>> Agreed. I'm not saying the layout should not be.
>>
>>>> Some could have a more complex structure perhaps with key ids and
>>>> linked list structure.
>>> Then just request the size of the whole list, and parse it afterwards
>>> in your driver?
>>>
>>>> I would do something more simple that is just a list of keys and their
>>>> location like this:
>>>>
>>>> device-serial-number = <start size>;
>>>> key1 = <start size>;
>>>> key2 = <start size>;
>>> I'm sorry, but what's the difference?
>> It can describe the layout completely whether the fields are tied to a
>> h/w device or not.
>>
>> What I would like to see here is the entire layout described covering
>> both types of fields.
>>
>
> I was thinking the DT might be like this on the provider side:
>
> qfprom at 1000000 {
> reg = <0x1000000 0x1000>;
> ranges = <0 0x1000000 0x1000>;
> compatible = "qcom,qfprom-msm8960"
>
> pvs-data: pvs-data at 40 {
> compatible = "qcom,pvs-a";
These compatibles could be optional. As it might not be required for
devices which are simple and do not require any special interpretation
of eeprom data.
> reg = <0x40 0x20>,
> #eeprom-cells = <0>;
Do we still need eeprom-cells if we are moving to use reg property here?
> };
>
> tsens-data: tmdata at 10 {
> compatible = "qcom,tsens-data-msm8960";
> reg = <0x10 4>, <0x16 4>;
> #eeprom-cells = <0>;
>
> };
>
> serial-number: serial at 50 {
> compatible = "qcom,serial-msm8960";
> reg = <0x50 4>, <0x60 4>;
> #eeprom-cells = <0>;
>
> };
> };
>
> and then on the consumer side:
>
> device {
> eeproms = <&serial-number>;
> eeprom-names = "soc-rev-id";
> };
>
Yes, this looks good, and Sasha was also recommending something on these
lines too. Also this addresses the use cases like serial number too.
>
> This would solve a problem where the consumer device is some standard
> off-the-shelf IP block that needs to get some SoC specific calibration
> data from the eeprom. I may want to interpret the bits differently
> depending on which eeprom is connected to my SoC. Sometimes that data
> format may be the same across many variations of the SoC (e.g. the
> qcom,pvs-a node) or it may be completely different for a given SoC (e.g.
> qcom,serial-msm8960 node). I imagine for other SoCs out there it could
> be different depending on which eeprom the board manufacturer decides to
> wire onto their board and how they choose to program the data.
>
> So this is where I think the eeprom-cells and offset + length starts to
> fall apart. It forces us to make up a bunch of different compatible
> strings for our consumer device just so that we can parse the eeprom
> that we decided to use for some SoC/board specific data. Instead I'd
> like to see some framework that expresses exactly which eeprom is on my
> board and how to interpret the bits in a way that doesn't require me to
> keep refining the compatible string for my generic IP block.
>
> I worry that if we put all those details in DT we'll end up having to
> describe individual bits like serial-number-bit-2, serial-number-bit-3,
> etc. because sometimes these pieces of data are scattered all around the
> eeprom and aren't contiguous or aligned on a byte boundary. It may be
> easier to just have a way to express that this is an eeprom with this
> specific layout and my device has data stored in there. Then the driver
> can be told what layout it is (via compatible or some other string based
> means if we're not using DT?) and match that up with some driver data if
> it needs to know how to understand the bits it can read with the
> eeprom_read() API.
Yes this sounds more sensible to let the consumer driver interpret the
eeprom data than the eeprom framework itself.
--srini
>
next prev parent reply other threads:[~2015-02-24 7:08 UTC|newest]
Thread overview: 153+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-19 17:07 [RFC PATCH 0/3] Add simple EEPROM Framework via regmap Srinivas Kandagatla
2015-02-19 17:08 ` [RFC PATCH 1/3] eeprom: Add a simple EEPROM framework Srinivas Kandagatla
2015-02-19 18:12 ` Andrew Lunn
2015-02-20 8:27 ` Srinivas Kandagatla
2015-02-20 2:36 ` Stephen Boyd
2015-02-20 8:14 ` Srinivas Kandagatla
2015-02-20 10:24 ` Srinivas Kandagatla
2015-02-20 17:21 ` Rob Herring
2015-02-20 19:25 ` Srinivas Kandagatla
2015-02-20 22:01 ` Rob Herring
2015-02-21 11:31 ` Srinivas Kandagatla
2015-02-22 14:34 ` Maxime Ripard
2015-02-22 14:32 ` Maxime Ripard
2015-02-23 0:57 ` Rob Herring
2015-02-23 23:11 ` Stephen Boyd
2015-02-24 7:08 ` Srinivas Kandagatla [this message]
2015-02-24 9:21 ` Maxime Ripard
2015-02-25 1:30 ` Stephen Boyd
2015-02-26 9:16 ` Srinivas Kandagatla
2015-02-26 13:21 ` Maxime Ripard
2015-02-26 14:56 ` Srinivas Kandagatla
2015-02-26 13:18 ` Maxime Ripard
2015-02-23 9:15 ` Sascha Hauer
2015-02-20 17:46 ` Russell King - ARM Linux
2015-02-20 19:00 ` Srinivas Kandagatla
2015-02-23 15:04 ` Mark Brown
2015-02-23 15:38 ` Srinivas Kandagatla
2015-02-19 17:08 ` [RFC PATCH 2/3] eeprom: sunxi: Move the SID driver to the eeprom framework Srinivas Kandagatla
2015-02-20 17:47 ` Russell King - ARM Linux
2015-02-19 17:08 ` [RFC PATCH 3/3] eeprom: qfprom: Add Qualcomm QFPROM support Srinivas Kandagatla
2015-02-20 17:48 ` Russell King - ARM Linux
2015-03-05 9:44 ` [PATCH v1 0/6] Add simple EEPROM Framework via regmap Srinivas Kandagatla
2015-03-05 9:45 ` [PATCH v1 1/6] eeprom: Add a simple EEPROM framework for eeprom providers Srinivas Kandagatla
2015-03-05 10:23 ` Paul Bolle
2015-03-05 10:35 ` Srinivas Kandagatla
2015-03-07 15:00 ` Mark Brown
2015-03-09 7:13 ` Srinivas Kandagatla
2015-03-05 9:45 ` [PATCH v1 2/6] eeprom: Add a simple EEPROM framework for eeprom consumers Srinivas Kandagatla
2015-03-05 9:46 ` [PATCH v1 3/6] eeprom: Add bindings for simple eeprom framework Srinivas Kandagatla
2015-03-05 20:11 ` Rob Herring
2015-03-05 22:34 ` Srinivas Kandagatla
2015-03-05 9:46 ` [PATCH v1 4/6] eeprom: sunxi: Move the SID driver to the " Srinivas Kandagatla
2015-03-05 10:15 ` Paul Bolle
2015-03-05 18:36 ` Maxime Ripard
2015-03-05 9:46 ` [PATCH v1 5/6] eeprom: qfprom: Add Qualcomm QFPROM support Srinivas Kandagatla
2015-03-05 10:02 ` Paul Bolle
2015-03-05 10:10 ` Srinivas Kandagatla
2015-03-05 9:46 ` [PATCH v1 6/6] eeprom: Add to MAINTAINERS for eeprom framework Srinivas Kandagatla
2015-03-13 9:49 ` [PATCH v2 0/7] Add simple EEPROM Framework via regmap Srinivas Kandagatla
2015-03-13 9:50 ` [PATCH v2 1/7] eeprom: Add a simple EEPROM framework for eeprom providers Srinivas Kandagatla
2015-03-23 21:09 ` Mark Brown
2015-03-23 22:05 ` Srinivas Kandagatla
2015-03-24 9:18 ` Srinivas Kandagatla
2015-03-24 17:23 ` Mark Brown
2015-03-24 18:34 ` Srinivas Kandagatla
2015-03-24 19:02 ` Mark Brown
2015-03-24 19:26 ` Srinivas Kandagatla
2015-03-24 20:55 ` Mark Brown
2015-03-13 9:50 ` [PATCH v2 2/7] eeprom: Add a simple EEPROM framework for eeprom consumers Srinivas Kandagatla
2015-03-13 9:50 ` [PATCH v2 3/7] eeprom: Add bindings for simple eeprom framework Srinivas Kandagatla
2015-03-13 9:50 ` [PATCH v2 4/7] eeprom: sunxi: Move the SID driver to the " Srinivas Kandagatla
2015-03-13 9:50 ` [PATCH v2 5/7] eeprom: qfprom: Add Qualcomm QFPROM support Srinivas Kandagatla
2015-03-13 9:50 ` [PATCH v2 6/7] eeprom: qfprom: Add bindings for qfprom Srinivas Kandagatla
2015-03-13 9:51 ` [PATCH v2 7/7] eeprom: Add to MAINTAINERS for eeprom framework Srinivas Kandagatla
2015-03-24 22:28 ` [PATCH v3 0/9] Add simple EEPROM Framework via regmap Srinivas Kandagatla
2015-03-24 22:29 ` [PATCH v3 1/9] regmap: Introduce regmap_get_max_register Srinivas Kandagatla
2015-03-24 22:36 ` Mark Brown
2015-03-24 23:05 ` Srinivas Kandagatla
2015-03-24 23:23 ` Joe Perches
2015-03-24 22:30 ` [PATCH v3 2/9] regmap: Introduce regmap_get_reg_stride Srinivas Kandagatla
2015-03-24 22:37 ` Mark Brown
2015-03-24 23:07 ` Srinivas Kandagatla
2015-03-24 22:30 ` [PATCH v3 3/9] eeprom: Add a simple EEPROM framework for eeprom providers Srinivas Kandagatla
2015-03-24 22:53 ` Mark Brown
2015-03-26 16:23 ` Srinivas Kandagatla
2015-03-24 22:30 ` [PATCH v3 4/9] eeprom: Add a simple EEPROM framework for eeprom consumers Srinivas Kandagatla
2015-03-25 7:16 ` Sascha Hauer
2015-03-25 12:29 ` Srinivas Kandagatla
2015-03-24 22:30 ` [PATCH v3 5/9] eeprom: Add bindings for simple eeprom framework Srinivas Kandagatla
2015-03-25 7:10 ` Sascha Hauer
2015-03-25 16:40 ` Maxime Ripard
2015-03-24 22:30 ` [PATCH v3 6/9] eeprom: sunxi: Move the SID driver to the " Srinivas Kandagatla
2015-03-24 22:30 ` [PATCH v3 7/9] eeprom: qfprom: Add Qualcomm QFPROM support Srinivas Kandagatla
2015-03-24 22:31 ` [PATCH v3 8/9] eeprom: qfprom: Add bindings for qfprom Srinivas Kandagatla
2015-03-25 0:28 ` Bjorn Andersson
2015-03-24 22:31 ` [PATCH v3 9/9] eeprom: Add to MAINTAINERS for eeprom framework Srinivas Kandagatla
2015-03-30 21:54 ` [PATCH v4 00/10] Add simple EEPROM Framework via regmap Srinivas Kandagatla
2015-03-30 21:56 ` [PATCH v4 01/10] regmap: Introduce regmap_get_max_register Srinivas Kandagatla
2015-05-04 12:05 ` Mark Brown
2015-03-30 21:57 ` [PATCH v4 02/10] regmap: Introduce regmap_get_reg_stride Srinivas Kandagatla
2015-03-30 21:57 ` [PATCH v4 03/10] eeprom: Add a simple EEPROM framework for eeprom providers Srinivas Kandagatla
2015-03-30 21:57 ` [PATCH v4 04/10] eeprom: Add a simple EEPROM framework for eeprom consumers Srinivas Kandagatla
2015-04-07 18:45 ` Stephen Boyd
2015-04-07 20:09 ` Srinivas Kandagatla
2015-04-09 14:45 ` Stephen Boyd
2015-04-10 11:45 ` Maxime Ripard
2015-05-05 11:46 ` Srinivas Kandagatla
2015-05-08 5:23 ` Sascha Hauer
2015-05-06 17:28 ` Mark Brown
2015-03-30 21:57 ` [PATCH v4 05/10] eeprom: Add bindings for simple eeprom framework Srinivas Kandagatla
2015-04-06 13:32 ` Matt Porter
2015-04-06 14:11 ` Rob Herring
2015-04-06 15:04 ` Matt Porter
2015-04-07 17:35 ` Srinivas Kandagatla
2015-04-07 17:46 ` Mark Brown
2015-04-07 18:03 ` Srinivas Kandagatla
2015-04-07 19:46 ` Matt Porter
2015-04-08 9:24 ` Srinivas Kandagatla
2015-03-30 21:58 ` [PATCH v4 06/10] eeprom: Add simple eeprom-mmio consumer helper functions Srinivas Kandagatla
2015-03-30 21:58 ` [PATCH v4 07/10] eeprom: qfprom: Add Qualcomm QFPROM support Srinivas Kandagatla
2015-03-30 21:58 ` [PATCH v4 08/10] eeprom: qfprom: Add bindings for qfprom Srinivas Kandagatla
2015-03-30 21:58 ` [PATCH v4 09/10] eeprom: sunxi: Move the SID driver to the eeprom framework Srinivas Kandagatla
2015-03-30 21:58 ` [PATCH v4 10/10] eeprom: Add to MAINTAINERS for " Srinivas Kandagatla
2015-05-21 16:42 ` [PATCH v5 00/11] Add simple NVMEM Framework via regmap Srinivas Kandagatla
2015-05-21 16:42 ` [PATCH v5 01/11] regmap: Introduce regmap_get_max_register Srinivas Kandagatla
2015-05-22 11:18 ` Mark Brown
2015-05-21 16:42 ` [PATCH v5 02/11] regmap: Introduce regmap_get_reg_stride Srinivas Kandagatla
2015-05-22 11:19 ` Mark Brown
2015-05-21 16:43 ` [PATCH v5 03/11] nvmem: Add a simple NVMEM framework for nvmem providers Srinivas Kandagatla
2015-06-16 22:43 ` Stephen Boyd
2015-06-18 12:46 ` Srinivas Kandagatla
2015-06-24 0:24 ` Stephen Boyd
2015-06-24 10:05 ` Srinivas Kandagatla
2015-05-21 16:43 ` [PATCH v5 04/11] nvmem: Add a simple NVMEM framework for consumers Srinivas Kandagatla
2015-06-16 22:29 ` Stephen Boyd
2015-06-17 8:00 ` Sascha Hauer
2015-06-18 12:56 ` Srinivas Kandagatla
2015-05-21 16:43 ` [PATCH v5 05/11] nvmem: Add nvmem_device based consumer apis Srinivas Kandagatla
2015-06-16 22:49 ` Stephen Boyd
2015-06-18 12:57 ` Srinivas Kandagatla
2015-05-21 16:44 ` [PATCH v5 06/11] nvmem: Add bindings for simple nvmem framework Srinivas Kandagatla
2015-06-16 22:53 ` Stephen Boyd
2015-06-18 13:01 ` Srinivas Kandagatla
2015-06-19 10:36 ` maitysanchayan at gmail.com
2015-06-19 10:59 ` Srinivas Kandagatla
2015-05-21 16:44 ` [PATCH v5 07/11] nvmem: Add simple nvmem-mmio consumer helper functions Srinivas Kandagatla
2015-06-16 22:58 ` Stephen Boyd
2015-06-18 13:08 ` Srinivas Kandagatla
2015-05-21 16:44 ` [PATCH v5 08/11] nvmem: qfprom: Add Qualcomm QFPROM support Srinivas Kandagatla
2015-06-16 23:00 ` Stephen Boyd
2015-06-18 13:22 ` Srinivas Kandagatla
2015-05-21 16:44 ` [PATCH v5 09/11] nvmem: qfprom: Add bindings for qfprom Srinivas Kandagatla
2015-06-16 23:01 ` Stephen Boyd
2015-05-21 16:45 ` [PATCH v5 11/11] nvmem: Add to MAINTAINERS for nvmem framework Srinivas Kandagatla
2015-05-21 16:45 ` [PATCH v5 10/11] nvmem: sunxi: Move the SID driver to the " Srinivas Kandagatla
2015-06-16 23:04 ` Stephen Boyd
2015-06-18 13:09 ` Srinivas Kandagatla
2015-05-25 16:51 ` [PATCH v5 00/11] Add simple NVMEM Framework via regmap Pantelis Antoniou
2015-05-26 9:12 ` Srinivas Kandagatla
2015-05-26 17:54 ` Pantelis Antoniou
2015-05-29 1:20 ` Dan Williams
2015-05-29 7:09 ` Srinivas Kandagatla
2015-05-29 21:44 ` Dan Williams
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=54EC2378.5040202@linaro.org \
--to=srinivas.kandagatla@linaro.org \
--cc=linux-arm-kernel@lists.infradead.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).