lkml.org 
[lkml]   [2015]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v4 04/10] eeprom: Add a simple EEPROM framework for eeprom consumers
    On Tue, May 05, 2015 at 12:46:32PM +0100, Srinivas Kandagatla wrote:
    > Hi Stephen,
    >
    > Sorry I took so long to reply.
    >
    >
    > On 09/04/15 15:45, Stephen Boyd wrote:
    > >On 04/07, Srinivas Kandagatla wrote:
    > >>On 07/04/15 19:45, Stephen Boyd wrote:
    > >>>On 03/30, Srinivas Kandagatla wrote:
    > >>>
    > >>>Do you have an overview of how to use these APIs? Maybe some
    > >>>Documentation/ is in order? I'm mostly interested in how the
    > >>>blocks array is supposed to work and how this hooks up to drivers
    > >>>that are using DT.
    > >>
    > >>Only doc ATM is function level kernel doc in c file.
    > >>May be I can explain you for now and I will try to add some
    > >>documentation with some usage examples in next version.
    > >
    > >Thanks.
    > >
    > >>
    > >>eeprom block array is just another way intended to get hold of
    > >>eeprom content for non-DT providers/consumers, but DT
    > >>consumers/providers can also use it. As of today SOC/mach level code
    > >>could use it as well.
    > >>
    > >>In eeprom_cell_get() case the lookup of provider is done based on
    > >>provider name, this provider name is generally supplied by all the
    > >>providers (both DT/non DT).
    > >>
    > >>for example in qfprom case,
    > >>provider is registered from DT with eeprom config containing a unique name:
    > >>static struct eeprom_config econfig = {
    > >> .name = "qfprom",
    > >> .id = 0,
    > >>};
    > >>
    > >>In the consumer case, the tsens driver could do some like in non DT way:
    > >>
    > >> struct eeprom_block blocks[4] ={
    > >> {
    > >> .offset = 0x404,
    > >> .count = 0x4,
    > >> },
    > >> {
    > >> .offset = 0x408,
    > >> .count = 0x4,
    > >> },
    > >> {
    > >> .offset = 0x40c,
    > >> .count = 0x4,
    > >> },
    > >> {
    > >> .offset = 0x410,
    > >> .count = 0x4,
    > >> },
    > >> };
    > >> calib_cell = eeprom_cell_get("qfprom0", blocks, 4);
    > >>
    > >>
    > >>Or in DT way
    > >>calib_cell = of_eeprom_cell_get(np, "calib");
    > >>
    > >
    > >Ok. I guess I was hoping for a more device centric approach like
    > >we have for clks/regulators/etc. That way a driver doesn't need
    > >to know it's using DT or not to figure out which API to call.
    >
    > That would be the best. Its easy to wrap up whats in eeprom core to
    > eeprom_get_cell(dev, "cell-name") for both DT and non-dt cases, if I
    > remove the nasty global name space thing.
    >
    > Only thing which is limiting it is the existing bindings which are
    > just phandle based. For eeprom to be more of device centric we need
    > more
    > generic bindings/property names like
    >
    > nvrom-cell = <&abc>, <&edf>
    > nvrom-cell-names = "cell1", "cell2";
    >
    > Also we can have name associated to each eeprom cell which would
    > help for non-dt cases. So they can just lookup by the cell name.
    >
    >
    > Sacha, Are you ok with such binding? As this can provide a single
    > interface for dt and non-dt. I remember you requested for changing
    > from generic properties to specific property names.

    Yes, I am fine with such a binding. The same type of binding is used for
    clocks and other stuff already, so it has proven good and people are
    famliar with it.

    Sascha

    --
    Pengutronix e.K. | |
    Industrial Linux Solutions | http://www.pengutronix.de/ |
    Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
    Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |


    \
     
     \ /
      Last update: 2015-05-08 07:41    [W:2.357 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site