diff for duplicates of <20150311174316.GD5264@atomide.com> diff --git a/a/1.txt b/N1/1.txt index 4be1a9c..231f531 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -15,12 +15,12 @@ > >> Maybe I have not completely understood your proposal. > >> > >> Do you mean to go back to have big parameter tables for each device/battery -> >> combination in the driver code and the compatible flag (e.g. compatible = “board17”) +> >> combination in the driver code and the compatible flag (e.g. compatible = ?board17?) > >> chooses the right data set for the charging map and channels? > > > > If you can somehow group them, then yes. > -> I don’t see how to group them. Could you make a proposal? +> I don?t see how to group them. Could you make a proposal? Sorry no idea about that :) I though you may have some ideas based on dealing with the driver. @@ -32,33 +32,33 @@ dealing with the driver. > > new device tree properties. The device tree properties introduced > > should be generic where possible. > -> Yes, that was discussed for a while for this driver’s bindings leading to v4. +> Yes, that was discussed for a while for this driver?s bindings leading to v4. > > Which ones do you think are not generic enough? It seems maps is the only one then, assuming the cpacity-uah can be made Linux generic. -> >> And batteries have very different characteristics and vary between devices… +> >> And batteries have very different characteristics and vary between devices? > > > > Right. Maybe that has been already agreed on to use capacity-uah for > > batteries in general? > -> Ah, do you mean with generic/not generic the distinction between a “ti,” prefix +> Ah, do you mean with generic/not generic the distinction between a ?ti,? prefix > and no prefix? > -> Well, I don’t know if there is such an agreement and I would have no argument -> against calling it “ti,capacity-uah”. +> Well, I don?t know if there is such an agreement and I would have no argument +> against calling it ?ti,capacity-uah?. No no, "capacity-uah" is what we should use, but you need an ack from the battery and device tree people that this is OK. Let's not add -"ti,capacity-uah” as that can obviously be a generic property. +"ti,capacity-uah? as that can obviously be a generic property. > > In that case I have not problem with that as -> > it’s a generic property :) +> > it?s a generic property :) > > Well, many batteries and systems have a fuel gauge chip (e.g. bq27000). This -> chip “knows” the capacity. But therefore it is not needed to specify +> chip ?knows? the capacity. But therefore it is not needed to specify > it anywhere because it can be read out (usually in uAh). > > This driver is to solve the issue that there is no such factory-programmed @@ -72,7 +72,7 @@ OK > >> The charging maps are depending on the battery type connected to the twl4030 > >> and which madc channel is which value is also a little hardware dependent -> >> (although the twl4030 doesn’t give much choice). +> >> (although the twl4030 doesn?t give much choice). > > > > Just to consider alternatives before introducing driver specific > > property for the maps.. Maybe here you could have few different type @@ -102,7 +102,7 @@ OK > And therefore they had been introduced exactly this way into the old > platform_data driver. > -> So if you want to see a “ti," prefix to the capacity property I would be +> So if you want to see a ?ti," prefix to the capacity property I would be > fine. Oh if they are battery spicific, then ideally we'd have generic batery @@ -117,7 +117,3 @@ long run. Regards, Tony --- -To unsubscribe from this list: send the line "unsubscribe linux-omap" in -the body of a message to majordomo@vger.kernel.org -More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index 5f1f405..9c2a1bf 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -4,25 +4,10 @@ "ref\0844740CD-C95B-4411-A2C8-4906F58DBEE8@goldelico.com\0" "ref\020150311164442.GA5264@atomide.com\0" "ref\0F7BA143D-5CF9-42E3-AFA8-B83B149EF77E@goldelico.com\0" - "From\0Tony Lindgren <tony@atomide.com>\0" - "Subject\0Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings\0" + "From\0tony@atomide.com (Tony Lindgren)\0" + "Subject\0[PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings\0" "Date\0Wed, 11 Mar 2015 10:43:17 -0700\0" - "To\0Dr. H. Nikolaus Schaller <hns@goldelico.com>\0" - "Cc\0Marek Belisko <marek@goldelico.com>" - Benoit Cousson <bcousson@baylibre.com> - Sebastian Reichel <sre@kernel.org> - Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> - David Woodhouse <dwmw2@infradead.org> - Rob Herring <robh+dt@kernel.org> - Pawel Moll <pawel.moll@arm.com> - Mark Rutland <mark.rutland@arm.com> - Ian Campbell <ijc+devicetree@hellion.org.uk> - Kumar Gala <galak@codeaurora.org> - devicetree@vger.kernel.org - LKML <linux-kernel@vger.kernel.org> - linux-omap@vger.kernel.org - linux-arm-kernel <linux-arm-kernel@lists.infradead.org> - " linux-pm@vger.kernel.org\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "* Dr. H. Nikolaus Schaller <hns@goldelico.com> [150311 10:13]:\n" @@ -42,12 +27,12 @@ "> >> Maybe I have not completely understood your proposal.\n" "> >> \n" "> >> Do you mean to go back to have big parameter tables for each device/battery\n" - "> >> combination in the driver code and the compatible flag (e.g. compatible = \342\200\234board17\342\200\235)\n" + "> >> combination in the driver code and the compatible flag (e.g. compatible = ?board17?)\n" "> >> chooses the right data set for the charging map and channels?\n" "> > \n" "> > If you can somehow group them, then yes.\n" "> \n" - "> I don\342\200\231t see how to group them. Could you make a proposal?\n" + "> I don?t see how to group them. Could you make a proposal?\n" "\n" "Sorry no idea about that :) I though you may have some ideas based on\n" "dealing with the driver.\n" @@ -59,33 +44,33 @@ "> > new device tree properties. The device tree properties introduced\n" "> > should be generic where possible.\n" "> \n" - "> Yes, that was discussed for a while for this driver\342\200\231s bindings leading to v4.\n" + "> Yes, that was discussed for a while for this driver?s bindings leading to v4.\n" "> \n" "> Which ones do you think are not generic enough?\n" "\n" "It seems maps is the only one then, assuming the cpacity-uah can be made\n" "Linux generic. \n" "\n" - "> >> And batteries have very different characteristics and vary between devices\342\200\246\n" + "> >> And batteries have very different characteristics and vary between devices?\n" "> > \n" "> > Right. Maybe that has been already agreed on to use capacity-uah for\n" "> > batteries in general?\n" "> \n" - "> Ah, do you mean with generic/not generic the distinction between a \342\200\234ti,\342\200\235 prefix\n" + "> Ah, do you mean with generic/not generic the distinction between a ?ti,? prefix\n" "> and no prefix?\n" "> \n" - "> Well, I don\342\200\231t know if there is such an agreement and I would have no argument\n" - "> against calling it \342\200\234ti,capacity-uah\342\200\235.\n" + "> Well, I don?t know if there is such an agreement and I would have no argument\n" + "> against calling it ?ti,capacity-uah?.\n" "\n" "No no, \"capacity-uah\" is what we should use, but you need an ack from\n" "the battery and device tree people that this is OK. Let's not add\n" - "\"ti,capacity-uah\342\200\235 as that can obviously be a generic property.\n" + "\"ti,capacity-uah? as that can obviously be a generic property.\n" " \n" "> > In that case I have not problem with that as\n" - "> > it\342\200\231s a generic property :)\n" + "> > it?s a generic property :)\n" "> \n" "> Well, many batteries and systems have a fuel gauge chip (e.g. bq27000). This\n" - "> chip \342\200\234knows\342\200\235 the capacity. But therefore it is not needed to specify\n" + "> chip ?knows? the capacity. But therefore it is not needed to specify\n" "> it anywhere because it can be read out (usually in uAh).\n" "> \n" "> This driver is to solve the issue that there is no such factory-programmed\n" @@ -99,7 +84,7 @@ " \n" "> >> The charging maps are depending on the battery type connected to the twl4030\n" "> >> and which madc channel is which value is also a little hardware dependent\n" - "> >> (although the twl4030 doesn\342\200\231t give much choice).\n" + "> >> (although the twl4030 doesn?t give much choice).\n" "> > \n" "> > Just to consider alternatives before introducing driver specific\n" "> > property for the maps.. Maybe here you could have few different type\n" @@ -129,7 +114,7 @@ "> And therefore they had been introduced exactly this way into the old\n" "> platform_data driver.\n" "> \n" - "> So if you want to see a \342\200\234ti,\" prefix to the capacity property I would be\n" + "> So if you want to see a ?ti,\" prefix to the capacity property I would be\n" "> fine.\n" "\n" "Oh if they are battery spicific, then ideally we'd have generic batery\n" @@ -143,10 +128,6 @@ "\n" "Regards,\n" "\n" - "Tony\n" - "--\n" - "To unsubscribe from this list: send the line \"unsubscribe linux-omap\" in\n" - "the body of a message to majordomo@vger.kernel.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + Tony -64069e488790cb39323bd86bc2af726137cea7b51866cad3cff9d3eaba07906c +68bf4ff3e818f139cd0708a7ff2332cbf9213131c1ec86b28e52fad4bc04cee9
diff --git a/a/1.txt b/N2/1.txt index 4be1a9c..0b3a00c 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -117,7 +117,3 @@ long run. Regards, Tony --- -To unsubscribe from this list: send the line "unsubscribe linux-omap" in -the body of a message to majordomo@vger.kernel.org -More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N2/content_digest index 5f1f405..d2d3a1b 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -143,10 +143,6 @@ "\n" "Regards,\n" "\n" - "Tony\n" - "--\n" - "To unsubscribe from this list: send the line \"unsubscribe linux-omap\" in\n" - "the body of a message to majordomo@vger.kernel.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + Tony -64069e488790cb39323bd86bc2af726137cea7b51866cad3cff9d3eaba07906c +adad46786c771d95a1e5c5099926f5f624ca3a33969fe140948708252779738f
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.