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:

quoted

On 04/07, Srinivas Kandagatla wrote:

quoted

On 07/04/15 19:45, Stephen Boyd wrote:

quoted

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.

quoted

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 |