On Thu, Jun 27, 2013 at 8:30 AM, Luciano Coelho <coelho@xxxxxx> wrote: > On Thu, 2013-06-27 at 08:23 -0500, Nishanth Menon wrote: >> On 06/27/2013 08:19 AM, Luciano Coelho wrote: >> > On Thu, 2013-06-27 at 08:15 -0500, Nishanth Menon wrote: >> >> On Thu, Jun 27, 2013 at 7:58 AM, Luciano Coelho <coelho@xxxxxx> wrote: >> >>> For the actual DTS files, I could add a wilink.dtsi with enumerations >> >>> for these values so they could be used in the node definitions. But I'm >> >>> not sure it's going to be that valuable in the end. >> >> The way GPIO HIGH was defined might help to provide guidance I think :) >> > >> > Where? As far as I can see, the GPIO flags are defined in a bitmap. >> >> include/dt-bindings/gpio/gpio.h > > Thanks! I don't see these macros used anywhere, though. umm... I'd think you have'nt looked deep enough / lists :) > >> And corresponding kernel header: >> include/linux/of_gpio.h > > This seems to be a completely different thing. This is the header that > contains the helper functions to get GPIO-related device tree nodes, > isn't it? That is true, but it also contains the flag for level which needs to be in sync with the gpio.h dts header. >> just a hint. not saying frequencies were defined in header. for systems >> that define frequencies - example cpufreq OPPs, clock node usage, we do >> not use indexing to frequency, instead, that is the responsibility of >> driver to convert frequency back to required index. >> git grep frequency Documentation/devicetree/bindings gives you how the >> precedence looks like. >> >> Personally, if given a choice, I'd go with actual frequencies rather >> than indexes. > > If I do that, I need to add also a separate flag to define whether the > XTAL clock is used or not. For instance, we have 26MHz and 26MHz > crystal; and 38.4MHz and 38.4MHz crystal... Yes, you would have to. at the same time, it is easy for module maker to provide dtsi corresponding to exact h/w representation on his module using wilink chip without being worried about weird index value whose meaning is hidden in binding On the flip side, It also allows driver to reject frequencies / configurations that are not supported by the corresponding chip. As I said, just my 2 cents. Personally, I'd like dts files to be as readable as c files without having to dig through bindings document. Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
