Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts
On 10/23/2012 4:49 AM, Jon Hunter wrote: > Therefore, I believe it will improve search time and hence, boot time if > we have interrupt-parent defined in each node. I strongly suspect (based on many years of performance tuning, with special focus on boot time) that the time difference will be completely insignificant. The total extra time for walking up the interrupt tree for every interrupt in a large system is comparable to the time it takes to send a few characters out a UART. So you can get more improvement from eliminating a single printk() than from globally adding per-node interrupt-parent. Furthermore, the cost of processing all of the interrupt-parent properties is probably similar to the cost of the avoided tree walks. CPU cycles are very fast compared to I/O register accesses, say a factor of 100. Now consider that many modern devices contain embedded microcontrollers (SD cards, network interface modules, USB hubs and devices, ...), and those devices usually require various delays measured in milliseconds, to ensure that the microcontroller is ready for the next initialization step. Those delays are extremely long compared to CPU cycles. Obviously, some of that can be overlapped by careful multithreading, but that isn't free either. The bottom line is that I'm pretty sure that adding per-node interrupt-parent would not be worthwhile from the standpoint of speeding up boot time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On 10/23/2012 12:03 AM, Felipe Balbi wrote: > Hi, > > I much prefer having drivers explicitly manage all their resources, > which would mean that pinctrl calls need to be done on probe() and, if > necessary, during suspend()/resume(). Per-driver resource management is certainly convenient when you are dealing with a single system, but it becomes difficult to maintain for drivers that are shared among many platforms. The industry trend for many years has been consolidation around a single programming model per class of device. For example, SDHCI, EHCI, ATA. This trend will only accelerate, as the cost of developing controller IP and associated drivers increases. Such drivers need to be as platform-agnostic as possible. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Perhaps I misunderstood what you were suggesting. I thought that, when you said "explicitly manage all their resources", you meant that the driver should know the platform-specific details about clocks and power domains. That is one possible interpretation of the word "explicit". Now I see that you meant that the driver should explicitly call abstracted functions. On 10/23/2012 7:20 AM, Felipe Balbi wrote: > HI, > > On Tue, Oct 23, 2012 at 07:02:09AM -1000, Mitch Bradley wrote: >> On 10/23/2012 12:03 AM, Felipe Balbi wrote: >>> Hi, >>> >>> I much prefer having drivers explicitly manage all their resources, >>> which would mean that pinctrl calls need to be done on probe() and, if >>> necessary, during suspend()/resume(). >> >> >> Per-driver resource management is certainly convenient when you are >> dealing with a single system, but it becomes difficult to maintain for >> drivers that are shared among many platforms. > > why ? look at drivers/usb/dwc3/, we're using that on OMAP, exynos, PCIe > and a couple of different FPGA implementations inside TI. Not to mention > what other licensees of that IP core might have internally. > > So far no problesm with resources at all. > > We have frameworks exactly to hide the differences. > >> The industry trend for many years has been consolidation around a single >> programming model per class of device. For example, SDHCI, EHCI, ATA. >> This trend will only accelerate, as the cost of developing controller IP >> and associated drivers increases. Such drivers need to be as >> platform-agnostic as possible. > > that's why we have pinctrl framework to abstract the details about pin > muxing. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts
On 10/23/2012 1:15 PM, Jon Hunter wrote: > Hi Mitch, > > On 10/23/2012 11:55 AM, Mitch Bradley wrote: >> On 10/23/2012 4:49 AM, Jon Hunter wrote: >> >>> Therefore, I believe it will improve search time and hence, boot time if >>> we have interrupt-parent defined in each node. >> >> I strongly suspect (based on many years of performance tuning, with >> special focus on boot time) that the time difference will be completely >> insignificant. The total extra time for walking up the interrupt tree >> for every interrupt in a large system is comparable to the time it takes >> to send a few characters out a UART. So you can get more improvement >> from eliminating a single printk() than from globally adding per-node >> interrupt-parent. >> >> Furthermore, the cost of processing all of the interrupt-parent >> properties is probably similar to the cost of the avoided tree walks. >> >> CPU cycles are very fast compared to I/O register accesses, say a factor >> of 100. Now consider that many modern devices contain embedded >> microcontrollers (SD cards, network interface modules, USB hubs and >> devices, ...), and those devices usually require various delays measured >> in milliseconds, to ensure that the microcontroller is ready for the >> next initialization step. Those delays are extremely long compared to >> CPU cycles. Obviously, some of that can be overlapped by careful >> multithreading, but that isn't free either. >> >> The bottom line is that I'm pretty sure that adding per-node >> interrupt-parent would not be worthwhile from the standpoint of speeding >> up boot time. > > Absolutely, I don't expect this to miraculously improve the boot time or > suggest that this is a major contributor to boot time, but what is the > best approach in general in terms of efficiency (memory and time). In > other words, is there a best practice? And from your feedback, I > understand that adding a global interrupt-parent is a good practice. >From a maintenance standpoint, "saying it once" is best practice. Time that you don't spend doing unnecessary maintenance can be spent looking for other, higher value, improvements. And when you do need to optimize something, it's much easier if the function is centralized. Pushing the interrupt parent up the tree to the appropriate point can make the next platform easier, opening the possibility of changing just one thing instead of several dozen. There have been several cases when I have violated good factoring in order to save a little time, only to have to undo it later when the next system was enough different that the de-factored version didn't work. So, while there are certainly cases where you are forced to do otherwise, I generally like the "don't repeat yourself" mantra. > > For a bit of fun, I took an omap4430 board and benchmarked the time > taken by the of_irq_find_parent() when interrupt-parent was defined for > each node using interrupts and without. > > There were a total of 47 device nodes using interrupts. Adding the > interrupt-parent to all 47 nodes increased the dtb from 13211 bytes to > 13963 bytes. > > On boot-up I saw 117 calls to of_irq_find_parent() for this platform > (there appears to be multiple calls for a given device). Without > interrupt-parent defined for each node total time spent in > of_irq_find_parent() was 1.028 ms where as with interrupt-parent defined > for each node the total time was 0.4032 ms. This was done using a > 38.4MHz timer and the overhead of reading the timer 117 times was about > 36 us. That sounds about right. The savings of 600 us is 6 characters at 115200 baud. > > I understand that this does not provide the full picture, but I wanted > to get a better handle on the times here. So yes the overall overhead > here is not significant for us to worry about. Big ticket items for boot time improvement are time spent waiting for peripheral devices to become ready and time spent spewing diagnostic messages. But in the final analysis, you just have to measure what is happening and see what you can do to improve it. In my experience, CPU cycles are rarely problematic, unless they are artificially slowed down due to caches being off or due to direct execution from slow memory like ROMs. I once shaved an hour off the startup time for a PowerPC system by moving some critical code into cache. This was on a prototype "chip" that was being emulated by arrays of FPGAs. On the first generation OLPC XO-1 machine we were really interested in super-fast wakeup from suspend. I tuned that firmware code path to the nth degree, finally getting stuck at 2 ms because you had to wait that long before ac
Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
On 7/31/2012 6:56 PM, Thierry Reding wrote:
> On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
>> On 07/31/2012 07:45 AM, Stephen Warren wrote:
>>> I wonder if using the same structure/array as input and output would
>>> simplify the API; the platform data would fill in the fields mentioned
>>> above, and power_seq_build() would parse those, then set other fields in
>>> the same structs to the looked-up handle values?
>>
>> The thing is that I am not sure what happens to the platform data
>> once probe() is done. Isn't it customary to mark it with __devinit
>> and have it freed after probing is successful?
>
> No, platform data should stay around forever. Otherwise, consider what
> would happen if your driver is built as a module and you unload and load
> it again.
>
>> More generally, I think it is a good practice to have data
>> structures tailored right for what they need to do - code with
>> members that are meaningful only at given points of an instance's
>> life tends to be more confusing.
>
> I agree. Furthermore the driver unload/reload would be another reason
> not to reuse platform data as the output of the build() function.
>
> But maybe what Stephen meant was more like filling a structure with data
> taken from the platform data and pass that to a resolve() function which
> would fill in the missing pieces like pointers to actual resources. I
> imagine a managed interface would become a little trickier to do using
> such an approach.
>
>>> If the nodes have a unit address (i.e. end in "@n"), which they will
>>> have to if all named "step" and there's more than one of them, then they
>>> will need a matching reg property. Equally, the parent node will need
>>> #address-cells and #size-cells too. So, the last couple lines would be:
>>>
>>> power-on-sequence {
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>> step@0 {
>>> reg = <0>;
>>
>> That's precisely what I would like to avoid - I don't need the steps
>> to be numbered and I certainly have no use for a reg property. Isn't
>> there a way to make it simpler?
>
> It's not technically valid to not have the reg property. Or
> #address-cells and #size-cells properties for that matter.
I'm not keen on this representation where individual steps are nodes.
That seems like it could end up being too "heavyweight" for a long sequence.
>
> Thierry
>
>
>
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
On 7/31/2012 8:38 PM, Thierry Reding wrote:
> On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote:
>> On 7/31/2012 6:56 PM, Thierry Reding wrote:
>>> On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
>>>> On 07/31/2012 07:45 AM, Stephen Warren wrote:
>>>>> I wonder if using the same structure/array as input and output would
>>>>> simplify the API; the platform data would fill in the fields mentioned
>>>>> above, and power_seq_build() would parse those, then set other fields in
>>>>> the same structs to the looked-up handle values?
>>>>
>>>> The thing is that I am not sure what happens to the platform data
>>>> once probe() is done. Isn't it customary to mark it with __devinit
>>>> and have it freed after probing is successful?
>>>
>>> No, platform data should stay around forever. Otherwise, consider what
>>> would happen if your driver is built as a module and you unload and load
>>> it again.
>>>
>>>> More generally, I think it is a good practice to have data
>>>> structures tailored right for what they need to do - code with
>>>> members that are meaningful only at given points of an instance's
>>>> life tends to be more confusing.
>>>
>>> I agree. Furthermore the driver unload/reload would be another reason
>>> not to reuse platform data as the output of the build() function.
>>>
>>> But maybe what Stephen meant was more like filling a structure with data
>>> taken from the platform data and pass that to a resolve() function which
>>> would fill in the missing pieces like pointers to actual resources. I
>>> imagine a managed interface would become a little trickier to do using
>>> such an approach.
>>>
>>>>> If the nodes have a unit address (i.e. end in "@n"), which they will
>>>>> have to if all named "step" and there's more than one of them, then they
>>>>> will need a matching reg property. Equally, the parent node will need
>>>>> #address-cells and #size-cells too. So, the last couple lines would be:
>>>>>
>>>>> power-on-sequence {
>>>>> #address-cells = <1>;
>>>>> #size-cells = <0>;
>>>>> step@0 {
>>>>> reg = <0>;
>>>>
>>>> That's precisely what I would like to avoid - I don't need the steps
>>>> to be numbered and I certainly have no use for a reg property. Isn't
>>>> there a way to make it simpler?
>>>
>>> It's not technically valid to not have the reg property. Or
>>> #address-cells and #size-cells properties for that matter.
>>
>> I'm not keen on this representation where individual steps are nodes.
>> That seems like it could end up being too "heavyweight" for a long sequence.
>
> The other alternative would involve using a single property to encode
> one sequence. I think that was the initial proposal, though using proper
> phandle encoding it could probably be enhanced a bit. However anything
> that involves a single property has the problem that we need to encode
> the type of resource as an integer, and that makes things very hard to
> read.
>
> So it would look something like this:
>
> power-on = <1 &gpio 6 01
> 0 1
> 2 ® 1
> 3 &pwm 0 500 1>;
>
> power-off = <3 &pwm 0 500 0
>2 ® 0
>0 1
>1 &gpio 6 00>;
>
> So the first cell would encode the type:
> 0: delay
> 1: gpio
> 2: regulator
> 3: PWM
>
> The next n cells would be the phandle and the specifier, while the last
> cell would encode a resource-specific parameter:
> delay: time in microseconds
> gpio: set level (0: low, 1: high)
> regulator: 0: disable, 1: enable
> pwm: 0: disable, 1: enable
>
> I guess this would be more compact, but it is also very hard to read. Is
> that something you would be happier with? Perhaps you were thinking of
> something completely different?
Perhaps a compact/flexible encoding could be designed, with a textual
encoding that is easy to read. A separate tool could convert the text
encoding to the integer format, annotated with comments containing
the "source text". A file containing that output could be #included
into the dts file.
>
> Thierry
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: dtc: import latest upstream dtc
On 10/9/2012 11:16 AM, Stephen Warren wrote:
> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>>>
>>> What more do you think needs discussion re: dtc+cpp?
>>
>> How not to abuse the ever-loving shit out of it? :-)
>
> Perhaps we can just handle this through the regular patch review
> process; I think it may be difficult to define and agree upon exactly
> what "abuse" means ahead of time, but it's probably going to be easy
> enough to recognize it when one sees it?
One of the ways it could get out of hand would be via "include
dependency hell". People will be tempted to reuse existing .h files
containing pin definitions, which, if history is a guide, will end up
depending on all sorts of other .h files.
Another problem I often face with symbolic names is the difficulty of
figuring out what the numerical values really are (for debugging),
especially when .h files are in different subtrees from the files that
use the definitions, and when they use multiple macro levels and fancy
features like concatenation. Sometimes I think it's clearer just to
write the number and use a comment to say what it is.
>
> I imagine the most common usage will simply be a bunch of:
>
> #define TEGRA_GPIO_PB0 32
> #define TEGRA_GPIO_INT_LEVEL_LOW 8
>
> / {
> xxx {
> interrupts = ;
>
> and similarly, simple math:
>
> something = <((FOO << XXX_SHIFT) | (BAR << YYY_SHIFT))>;
>
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: dtc: import latest upstream dtc
On 10/10/2012 7:09 AM, Rob Herring wrote:
> On 10/09/2012 04:16 PM, Stephen Warren wrote:
>> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
What more do you think needs discussion re: dtc+cpp?
>>>
>>> How not to abuse the ever-loving shit out of it? :-)
>>
>> Perhaps we can just handle this through the regular patch review
>> process; I think it may be difficult to define and agree upon exactly
>> what "abuse" means ahead of time, but it's probably going to be easy
>> enough to recognize it when one sees it?
>
> Rather than repeating things over and over in reviews, we should
> document at least rules we can easily agree on and then add to it when
> people get "creative." Also, I can't keep up with every single binding
> review as is, and this could just add another level of complexity to the
> review. A few off the top of my head and from the thread discussion:
>
> - Headers must be self contained with no outside (i.e. libc, kernel,
> etc.) header dependencies.
> - No kernel kconfig option usage
> - No gcc built-in define usage
> - No unused items (i.e. externs, structs, etc.)
> - No macro concatenation
> - No macros for strings or property names
Instead of making a bunch of rules about how you can only use a small
subset of cpp, why not just add a "define name value" command to DTC?
One of the things I like least about C is that the language itself is
incomplete; in order to actually program in C, you have to deal with not
only with the C syntactic structure, but also cpp, with its different
rules, and also make, with fundamentally different linguistic structure,
and then you end up wrapping that in something like KConfig, with yet
another linguistic framework, and the makefile contains embedded shell
commands, which is yet another syntax.
Rather than open Pandora's box by grafting on cpp, why not solve the
actual problem?
>
> Do we further restrict things to say defines are only numbers? One could
> start to define complex macros to build the nodes themselves. If each
> platform does this slightly differently, it will become difficult to
> review and maintain. Then we will be doing dts consolidation. The fact
> that we have some fixed structure and each SOC is not free to do things
> their own way makes things easier to maintain. You don't have that in
> the kernel across platforms. For example, look how register defines and
> static mappings or platform device creation are done. They are all
> similar, but yet slightly different. That makes doing changes across
> platforms more difficult.
>
>> I imagine the most common usage will simply be a bunch of:
>>
>> #define TEGRA_GPIO_PB0 32
>> #define TEGRA_GPIO_INT_LEVEL_LOW 8
>>
>> / {
>> xxx {
>> interrupts = ;
>>
>> and similarly, simple math:
>>
>> something = <((FOO << XXX_SHIFT) | (BAR << YYY_SHIFT))>;
>>
>
> These are all perfectly fine and sane use, but if we don't restrict
> things then the next step is this:
>
> #define PROP_SOMETHING(v) (something = <(v)>)
>
> Rob
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: dtc: import latest upstream dtc
On 10/10/2012 8:40 AM, Stephen Warren wrote: > On 10/10/2012 11:09 AM, Rob Herring wrote: >> On 10/09/2012 04:16 PM, Stephen Warren wrote: >>> On 10/01/2012 12:39 PM, Jon Loeliger wrote: > > What more do you think needs discussion re: dtc+cpp? How not to abuse the ever-loving shit out of it? :-) >>> >>> Perhaps we can just handle this through the regular patch review >>> process; I think it may be difficult to define and agree upon exactly >>> what "abuse" means ahead of time, but it's probably going to be easy >>> enough to recognize it when one sees it? >> >> Rather than repeating things over and over in reviews, we should >> document at least rules we can easily agree on and then add to it when >> people get "creative." Also, I can't keep up with every single binding >> review as is, and this could just add another level of complexity to the >> review. A few off the top of my head and from the thread discussion: >> >> - Headers must be self contained with no outside (i.e. libc, kernel, >> etc.) header dependencies. >> - No kernel kconfig option usage >> - No gcc built-in define usage >> - No unused items (i.e. externs, structs, etc.) > >> - No macro concatenation > > That seems to be potentially a very useful feature; I have no idea why > we would ban that; it isn't banned in C code in the kernel is it? It's used in the kernel. It is useful, but it has an unexpected side effect that can be extremely annoying - it can make it extremely difficult to find a definition with grep. All the grep hits will be for the fully-expanded uses of a symbol, while the definition is "hidden" by virtue of being synthesized by concatenation. Maybe it's not a big deal in a small project, but in a code base the size of the Linux kernel, where you don't know a priori where something is defined, it can make you want to tear your hair out. > >> - No macros for strings or property names > > Property names I can understand. Property values - I can perhaps see a > use-case for... > > ___ > devicetree-discuss mailing list > devicetree-disc...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dtc: import latest upstream dtc
On 10/10/2012 8:45 AM, Stephen Warren wrote: > On 10/10/2012 12:23 PM, Mitch Bradley wrote: >> On 10/10/2012 7:09 AM, Rob Herring wrote: >>> On 10/09/2012 04:16 PM, Stephen Warren wrote: >>>> On 10/01/2012 12:39 PM, Jon Loeliger wrote: >>>>>> >>>>>> What more do you think needs discussion re: dtc+cpp? >>>>> >>>>> How not to abuse the ever-loving shit out of it? :-) >>>> >>>> Perhaps we can just handle this through the regular patch review >>>> process; I think it may be difficult to define and agree upon exactly >>>> what "abuse" means ahead of time, but it's probably going to be easy >>>> enough to recognize it when one sees it? >>> >>> Rather than repeating things over and over in reviews, we should >>> document at least rules we can easily agree on and then add to it when >>> people get "creative." Also, I can't keep up with every single binding >>> review as is, and this could just add another level of complexity to the >>> review. A few off the top of my head and from the thread discussion: >>> >>> - Headers must be self contained with no outside (i.e. libc, kernel, >>> etc.) header dependencies. >>> - No kernel kconfig option usage >>> - No gcc built-in define usage >>> - No unused items (i.e. externs, structs, etc.) >>> - No macro concatenation >>> - No macros for strings or property names >> >> Instead of making a bunch of rules about how you can only use a small >> subset of cpp, why not just add a "define name value" command to DTC? > > I implemented a patch to do exactly that, and it was rejected because it > only solved part of the problem (named constants) and not the reset (a > completely generic macro language/... within dtc). The argument was that > defining just the named constant syntax on its own without knowing what > the unspecified future macro language will look like might result in the > named constant syntax not fitting into it. > > That all said, I now think that using cpp is actually a much better > solution that adding yet more dtc-specific syntax. The *huge* benefit > here is that it allows you to share .h files between *.dts and C code, > so you don't have to write out the same set of #defines once in dtc > syntax and once in cpp syntax. ... and it imposes an equally *huge* restriction that you have to restrict the .h file to avoid avoid C constructs. That can be done, but I've personally experienced a lot of headaches when trying to share .h files between different languages. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dtc: import latest upstream dtc
On 10/10/2012 1:16 PM, David Gibson wrote: > On Wed, Oct 10, 2012 at 10:33:31AM -0500, Rob Herring wrote: >> On 10/10/2012 10:16 AM, Stephen Warren wrote: >>> On 10/10/2012 01:24 AM, David Gibson wrote: On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote: > On Oct 9, 2012, at 6:04 PM, Scott Wood wrote: > [snip] >>> That's probably a reasonable idea, although I imagined that people would >>> actually split out the portions of any header file they wanted to use >>> with dtc, so that any headers included by *.dts would only include >>> #defines. Those headers could be used by both dtc and other .h files (or >>> .c files). >> >> Used by what other files? kernel files? We ultimately want to split out >> dts files from the kernel, so whatever we add needs to be self >> contained. I don't see this as a huge issue though because the whole >> point of the DT data is to move that information out of the kernel. If >> it is needed in both places, then something is wrong. > > People get very hung up on this idea of having the DT move device > information out of the kernel, but that was never really the > motivation behind it. Or at least, not the only or foremost > motivation. > > The DT provides a consistent, flexible way of describing device > information. That allows the core runtime the kernel to operate the > same way, regardless of how the DT information was obtained. The DT > could come from firmware, but it could also come from an intermediate > bootloader or from early kernel code. All are perfectly acceptable > options depending on the constraints of the platform. > > The idea of firmware supplying the DT is much touted, but while it's a > theoretically nice idea, I think it's frequently a bad idea for > practical reasons. Those being, in essence that a) firmware usually > sucks, b) it's usually harder (or at least no easier) to replace > firmware with a fixed version than the kernel/bootwrapper and c) > firmware usually *really* sucks. > Gee, it sounds like you want firmware to suck. Beating on the "firmware sucks" drum is sort of a self-fulfilling prophecy, discouraging talented programmers from doing firmware. Who would want to work on something that "everyone knows sucks"? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
It seems to me that this capebus discussion is missing an important point. The name capebus suggests that it is a bus, so there should be a parent node to represent that bus. It should have a driver whose API implements all of the system-interface functions a cape needs. If you look at the way that interrupt specifiers work, the default case is that a child device implicitly delegates the mapping to its parent. The use of phandles to break out of the tree structure was intended for use within the "hardwired motherboard domain", not for plug-in devices. The "new" phandle-based GPIO and clock mechanisms don't have that parent-delegation feature, but they should, because hierarchical hardware is a good thing when it exists. One fix would be to designate a reserved phandle value - for example 0 or -1 - to mean "my parent". t The parent node would contain some translator to resolve the actual target node, similarly to interrupts and addresses. If done correctly, capebus "overlays" would then just be proper child nodes of the capebus bus node and there would no need to refer to "global" information like non-parent phandles. If something about the design of capebus makes that impossible, I respectfully suggest that its design should be reviewed, taking into account the many years of industry experience about modularity. Mitch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On 11/13/2012 8:29 AM, Stephen Warren wrote: > On 11/13/2012 11:10 AM, Mitch Bradley wrote: >> It seems to me that this capebus discussion is missing an important >> point. The name capebus suggests that it is a bus, so there should be a >> parent node to represent that bus. It should have a driver whose API >> implements all of the system-interface functions a cape needs. > > It was discussed earlier that capebus isn't actually a bus. It's simply > a collection of a bunch of pins from the SoC hooked up to connectors. > I'd agree that it's mis-named. > Nevertheless, to the extent that the set of pins is finite and well-defined, it should be possible to define a set of software interfaces to support the functionality represented by those pins. It might depend on the underlying SoC, but even so, it would still be best to encapsulate the interface set. I hear all these use cases that presuppose a wide variety of user skill sets. If one really wants to support such users well, it's important to define a coherent single point of interface. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On 11/6/2012 12:37 PM, Stephen Warren wrote:
> On 11/05/2012 01:40 PM, Grant Likely wrote:
>> Hey folks,
>>
>> As promised, here is my early draft to try and capture what device
>> tree overlays need to do and how to get there. Comments and
>> suggestions greatly appreciated.
>
> Interesting. This just came up internally at NVIDIA within the last
> couple weeks, and was discussed on the U-Boot mailing list very recently
> too:
>
> http://lists.denx.de/pipermail/u-boot/2012-October/thread.html#138227
> (it spills into the November archive too)
>
>> For these cases it is proposed to implement an overlay feature for the
>> so that the initial device tree data can be modified by userspace at
>
> I don't know if you're maintaining this as a document and taking patches
> to it, but if so:
>
> "for the so" split across those two lines.
>
>> Jane solves this problem by storing an FDT overlay for each cape in the
>> root filesystem. When the kernel detects that a cape is installed it
>> reads the cape's eeprom to identify it and uses request_firmware() to
>> obtain the appropriate overlay. Userspace passes the overlay to the
>> kernel in the normal way. If the cape doesn't have an eeprom, then the
>> kernel will still use firmware_request(), but userspace needs to already
>> know which cape is installed.
>
> As mentioned by Pantelis, multiple versions of a board is also very
> common. We already have the following .dts files in the kernel where
> this applies, for the main board even:
>
> arch/arm/boot/dts/tegra30-cardhu.dtsi
> arch/arm/boot/dts/tegra30-cardhu-a02.dts
> arch/arm/boot/dts/tegra30-cardhu-a04.dts
>
>> Summary points:
>
>> - SHOULD reliably handle changes between different underlying overlays
>> (ie. what happens to existing .dtb overly files if the structure of
>> the dtb it is layered over changes. If not possible, then SHALL
>> detect when the base tree doesn't match and refuse to apply the
>> overlay.
>
> Perhaps use (versioned) DT bindings to represent the interface between
> the two .dts files? See the links to the U-Boot mailing list discussions
> below?
>
>> - What is the model for overlays?
>> - Can an overlay modify existing properties?
>> - Can an overlay add new properties to existing nodes?
>> - Can an overlay delete existing nodes/properties?
>
> This proposal is very oriented at an overlay-based approach. I'm not
> totally convinced that a pure overlay approach (as in how dtc does
> overlayed DT nodes) will be flexible enough, but would love to be
> persuaded. Again see below.
An overlay approach will not be powerful enough to solve the sorts of
problems that occur when a product goes into full production, becomes a
family, and starts to evolve. Issues like second-source parts that
aren't quite compatible and need to be detected and reported,
board-stuff options for different customer profiles, speed grades of
parts that aren't properly probeable but instead need to be identified
by some subterfuge, the list of tedious issues goes on and on.
It's nice to pretend that the world fits into a few coherent simple
use cases, but 30 years of experience shipping computer product families
proves otherwise. You need a programming language to solve the full
set of problems - which I why the device tree is designed so it can
be generated and modified by a program.
>
>> It may be sufficient to solve it by making the phandle values less
>> volatile. Right now dtc generates phandles linearly. Generated phandles
>> could be overridden with explicit phandle properties, but it isn't a
>> fantastic solution. Perhaps generating the phandle from a hash of the
>> node name would be sufficient.
>
> Node names don't have to be unique though right; perhaps hash the
> path-name instead of the node-name? But then, why not just reference by
> path name; similar to <{&/path/to/node}> rather than <&label>?
>
>> This handles many of the use cases, but it assumes that an overlay is
>> board specific. If it ever is required to support multiple base boards
>> with a single overlay file then there is a problem. The .dtb overlays
>> generated in this manor cannot handle different phandles or nodes that
>> are in a different place. On the other hand, the overlay source files
>> should have no problem being compiled for multiple targets.
>
> s/manor/manner/
>
> I do rather suspect this use-case is quite common. NVIDIA certainly has
> a bunch of development boards with pluggable
> PMIC/audio/WiFi/display/..., and I believe there's some ability to
> re-use the pluggable components with a variety of base-boards.
>
> Given people within NVIDIA started talking about this recently, I asked
> them to enumerate all the boards we have that support pluggable
> components, and how common it is that some boards support being plugged
> into different main boards. I don't know when that enumeration will
> complete (or even start) but hopefully I can provide some feedback on
> how common the
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On 11/8/2012 3:28 AM, Koen Kooi wrote: > > Op 7 nov. 2012, om 23:35 heeft Ryan Mallon het volgende > geschreven: > >> On 06/11/12 08:40, Tabi Timur-B04825 wrote: >>> On Mon, Nov 5, 2012 at 2:40 PM, Grant Likely >>> wrote: >>> Jane is building custom BeagleBone expansion boards called 'capes'. She can boot the system with a stock BeagleBoard device tree, but additional data is needed before a cape can be used. She could replace the FDT file used by U-Boot with one that contains the extra data, but she uses the same Linux system image regardless of the cape, and it is inconvenient to have to select a different device tree at boot time depending on the cape. >>> >>> What's wrong with having the boot loader detect the presence of the >>> Cape and update the device tree accordingly? We do this all the time >>> in U-Boot. Doing stuff like reading EEPROMs and testing for the >>> presence of hardware is easier in U-Boot than in Linux. >> >> This is probably okay for some hardware, but doesn't work in the general >> case. Not all hardware is detectable, for example a cape which just adds >> a set of LEDs for GPIO pins. Also, some hardware might not easily be >> detectable without adding additional complexity to the boot loader. > > And as Pantelis mentioned before, I really don't want my users to change the > bootloader whenever they add a new LED. Touching the bootloader is just too > accident prone, we had a ton of RMA requests for older versions of the > beagleboard from people trying to upgrade u-boot. One possibility for dynamic device tree mods would be to run Open Firmware from u-boot and have it generate the device tree and possibly modify it either interactively or from a script loaded from a file or the network. OFW could then either load Linux directly or return to u-boot, which would proceed with loading. > > Apart from the above I'd like to have fewer points of failure. Right now I > need to keep uImage and foo.dtb in sync and I hate to add u-boot to that > equasion as well. > > regards, > > Koen > ___ > devicetree-discuss mailing list > devicetree-disc...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] serial: tegra: add serial driver
On 12/17/2012 11:36 AM, Stephen Warren wrote: > On 12/17/2012 05:10 AM, Laxman Dewangan wrote: >> Nvidia's Tegra has multiple uart controller which supports: >> - APB dma based controller fifo read/write. >> - End Of Data interrupt in incoming data to know whether end >> of frame achieve or not. >> - Hw controlled RTS and CTS flow control to reduce SW overhead. > >> diff --git >> a/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt >> b/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt > >> +NVIDIA Tegra20/Tegra30 high speed (dma based) UART controller driver. >> + >> +Required properties: >> +- compatible : should be "nvidia,tegra20-hsuart", "nvidia,tegra30-hsuart". > > One question that isn't addressed here is: > > Tegra has 5 UARTs. All of them can use the existing 8250.c by specifying > compatible = "nvidia,tegra20-uart". The way it is supposed to work is that the compatible property should list "nvidia,tegra30-hsuart" first, followed by a fallback name that refers to the generic 8250 compatibility. Having the 8250.c driver bind to the more-specific tegra30-hsuart name is wrong. However, the 8250.c driver doesn't > support the DMA features of this driver. This driver is an alternate > driver for the same HW that allows DMA to be used with it, etc. > > Since DT is supposed to describe the HW, modifying the DT to change the > compatible value in order to select a different driver in Linux doesn't > seem correct, or is it? Is there any kind of precedent for how to select > different drivers for the same HW at run-time? I'd wondered about using > the sysfs bind/unbind "methods" from user-space as the driver selection > mechanism... > ___ > devicetree-discuss mailing list > devicetree-disc...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] serial: tegra: add serial driver
On 12/17/2012 12:04 PM, Stephen Warren wrote: > On 12/17/2012 02:58 PM, Mitch Bradley wrote: >> On 12/17/2012 11:36 AM, Stephen Warren wrote: >>> On 12/17/2012 05:10 AM, Laxman Dewangan wrote: >>>> Nvidia's Tegra has multiple uart controller which supports: >>>> - APB dma based controller fifo read/write. >>>> - End Of Data interrupt in incoming data to know whether end >>>> of frame achieve or not. >>>> - Hw controlled RTS and CTS flow control to reduce SW overhead. >>> >>>> diff --git >>>> a/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt >>>> b/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt >>> >>>> +NVIDIA Tegra20/Tegra30 high speed (dma based) UART controller driver. >>>> + >>>> +Required properties: >>>> +- compatible : should be "nvidia,tegra20-hsuart", "nvidia,tegra30-hsuart". >>> >>> One question that isn't addressed here is: >>> >>> Tegra has 5 UARTs. All of them can use the existing 8250.c by specifying >>> compatible = "nvidia,tegra20-uart". >> >> The way it is supposed to work is that the compatible property should >> list "nvidia,tegra30-hsuart" first, followed by a fallback name that >> refers to the generic 8250 compatibility. Having the 8250.c driver bind >> to the more-specific tegra30-hsuart name is wrong. > > 8250.c binds to nvidia,tegra20-uart, so that aspect is fine. > > However, the real issue is that we probably want 4 of the 5 ports to use > the plain old 8250.c (so as not to use up too many DMA channels), but > just 1 of the ports to use the DMA-capable high-performance driver (e.g. > the one that a particular board has hooked up to a Bluetooth radio). The > only way to do that with DT that I know of would be to specify different > subsets of legal compatible values for each UART in the per-board .dts file. That's an okay way to do it. The whole purpose of the compatible property is to support driver binding. The mantra to "describe the hardware" is good, but shouldn't be taken to extremes. It would be a good idea to comment the .dts file to explain why the compatible property differs between the otherwise-identical nodes. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
On 8/1/2012 9:47 AM, Alex Courbot wrote:
> On 07/31/2012 09:55 PM, Mitch Bradley wrote:
>> On 7/31/2012 8:38 PM, Thierry Reding wrote:
>>> On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote:
>>>> On 7/31/2012 6:56 PM, Thierry Reding wrote:
>>>>> On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
>>>>>> On 07/31/2012 07:45 AM, Stephen Warren wrote:
>>>>>>> I wonder if using the same structure/array as input and output would
>>>>>>> simplify the API; the platform data would fill in the fields mentioned
>>>>>>> above, and power_seq_build() would parse those, then set other fields in
>>>>>>> the same structs to the looked-up handle values?
>>>>>>
>>>>>> The thing is that I am not sure what happens to the platform data
>>>>>> once probe() is done. Isn't it customary to mark it with __devinit
>>>>>> and have it freed after probing is successful?
>>>>>
>>>>> No, platform data should stay around forever. Otherwise, consider what
>>>>> would happen if your driver is built as a module and you unload and load
>>>>> it again.
>>>>>
>>>>>> More generally, I think it is a good practice to have data
>>>>>> structures tailored right for what they need to do - code with
>>>>>> members that are meaningful only at given points of an instance's
>>>>>> life tends to be more confusing.
>>>>>
>>>>> I agree. Furthermore the driver unload/reload would be another reason
>>>>> not to reuse platform data as the output of the build() function.
>>>>>
>>>>> But maybe what Stephen meant was more like filling a structure with data
>>>>> taken from the platform data and pass that to a resolve() function which
>>>>> would fill in the missing pieces like pointers to actual resources. I
>>>>> imagine a managed interface would become a little trickier to do using
>>>>> such an approach.
>>>>>
>>>>>>> If the nodes have a unit address (i.e. end in "@n"), which they will
>>>>>>> have to if all named "step" and there's more than one of them, then they
>>>>>>> will need a matching reg property. Equally, the parent node will need
>>>>>>> #address-cells and #size-cells too. So, the last couple lines would be:
>>>>>>>
>>>>>>> power-on-sequence {
>>>>>>> #address-cells = <1>;
>>>>>>> #size-cells = <0>;
>>>>>>> step@0 {
>>>>>>> reg = <0>;
>>>>>>
>>>>>> That's precisely what I would like to avoid - I don't need the steps
>>>>>> to be numbered and I certainly have no use for a reg property. Isn't
>>>>>> there a way to make it simpler?
>>>>>
>>>>> It's not technically valid to not have the reg property. Or
>>>>> #address-cells and #size-cells properties for that matter.
>>>>
>>>> I'm not keen on this representation where individual steps are nodes.
>>>> That seems like it could end up being too "heavyweight" for a long
>>>> sequence.
>>>
>>> The other alternative would involve using a single property to encode
>>> one sequence. I think that was the initial proposal, though using proper
>>> phandle encoding it could probably be enhanced a bit. However anything
>>> that involves a single property has the problem that we need to encode
>>> the type of resource as an integer, and that makes things very hard to
>>> read.
>>>
>>> So it would look something like this:
>>>
>>> power-on = <1 &gpio 6 01
>>> 0 1
>>> 2 ® 1
>>> 3 &pwm 0 500 1>;
>>>
>>> power-off = <3 &pwm 0 500 0
>>> 2 ® 0
>>> 0 1
>>> 1 &gpio 6 00>;
>>>
>>> So the first cell would encode the type:
>>>0: delay
>>>1: gpio
>&
Re: DT GPIO numbering?
On 8/6/2012 5:58 PM, Johannes Stezenbach wrote: > On Mon, Aug 06, 2012 at 08:35:51AM +0200, Linus Walleij wrote: >> On Mon, Aug 6, 2012 at 4:18 AM, Stephen Warren wrote: >> >>> I can't comment on the sysfs-vs-dev interface location, but I don't >>> think it addresses Johannes' issue; finding out which GPIO IDs are >>> provided by which devices. >>> >>> Perhaps in each device's sysfs node, there should be some information >>> re: which GPIO range it provides. Right now, perhaps a text file with >>> the GPIO base it it. >> >> Yes that could work ... > > The method used by the gpio-mxs.c driver (of_alias_get_id) > would also work. The question is which method is preferable. > > Ideally I would like to use DT attributes to identify my GPIOs > in the same way as they appear in the schematics. E.g. > one device may have GPIOs called PORT_A.0 to PORT_A.7, > another one may be EXT.0 to EXT.15. But a single integer ID > is good enough since GPIO usage is platform specific anyway. > However, the mapping must be static and not depend e.g. on > module load order like now if you use pl061 and some i2c GPIO. > Software must be able to rely on that e.g. GPIO ID 11 > always refers to EXT.3. There is precedence for a "slot-names" property that correlates specific hardware entities with physical labels. It has been applied to PCI plug-in slots and to other devices. See, for example, http://www.openfirmware.org/1275/proposals/Closed/Accepted/381-it.txt > > >>> With the new /dev interface you mention above, >>> perhaps a symlink to the /dev file, or a file containing the /dev file's >>> major/minor number. Or, is there such a thing already (other than >>> debugfs's gpio file). >> >> Nothing I know of, but yes the day we come up with something, >> it needs to be backward-compatible some way. >> >> The problem is that there is really no reference userspace >> like "lsgpio" or so. Maybe the first step could be to create that. > > I don't know much about OpenWrt, but I've seen they have > something: > https://dev.openwrt.org/browser/trunk/target/linux/generic/files/drivers/char/gpio_dev.c > https://dev.openwrt.org/browser/trunk/target/linux/generic/files/include/linux/gpio_dev.h > https://dev.openwrt.org/browser/trunk/package/gpioctl/src/main.c > > > Johannes > ___ > devicetree-discuss mailing list > devicetree-disc...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/3] Runtime Interpreted Power Sequences
On 8/16/2012 8:38 AM, Stephen Warren wrote:
> On 08/16/2012 12:08 AM, Alexandre Courbot wrote:
>> Some device drivers (panel backlights especially) need to follow precise
>> sequences for powering on and off, involving gpios, regulators, PWMs
>> with a precise powering order and delays to respect between each steps.
>> These sequences are board-specific, and do not belong to a particular
>> driver - therefore they have been performed by board-specific hook
>> functions to far.
>>
>> With the advent of the device tree and of ARM kernels that are not
>> board-tied, we cannot rely on these board-specific hooks anymore but
>> need a way to implement these sequences in a portable manner. This patch
>> introduces a simple interpreter that can execute such power sequences
>> encoded either as platform data or within the device tree.
>
>> diff --git a/Documentation/devicetree/bindings/power_seq/power_seq.txt
>> b/Documentation/devicetree/bindings/power_seq/power_seq.txt
>
>> +Specifying Power Sequences in the Device Tree
>> +=
>> +In the device tree, power sequences are specified as sub-nodes of the device
>> +node and reference resources declared by that device.
>> +
>> +For an introduction about runtime interpreted power sequences, see
>> +Documentation/power/power_seq.txt and include/linux/power_seq.h.
>
> Device tree bindings shouldn't reference Linux documentation; the
> bindings are supposed to be OS-agnostic.
While it is true that bindings should try to be OS-agnostic, there is
the practical matter of where to put documentation so that it is widely
accessible. The Linux source tree is one of the most accessible things
there is, considering how widely it is replicated.
As the original instigator of the policy that the device tree should
describe the hardware "OS-neutrally", I personally don't have a problem
with bindings referring to Linux documentation. I wouldn't like
references to proprietary and inaccessible documentation.
>
>> +Power Sequences Structure
>> +-
>> +Power sequences are sub-nodes that are named such as the device driver can
>> find
>> +them. The driver's documentation should list the sequence names it
>> recognizes.
>
> That's a little roundabout. That might be better as simply:
>
> Valid power sequence names are defined by each device's binding. For a
> power sequence named "foo", a node named "foo-power-sequence" defines
> that sequence.
>
>> +Inside a power sequence node are sub-nodes that describe the different steps
>> +of the sequence. Each step must be named sequentially, with the first step
>> +named step0, the second step1, etc. Failure to follow this rule will result
>> in a
>> +parsing error.
>
> Node names shouldn't be interpreted by the code; nodes should all be
> named after the type of object the represent. Hence, every step should
> be named just "step" for example.
>
> The node's unit address (@0) should be used to distinguish the nodes.
> This requires reg properties within each node to match the unit address,
> and hence #address-cells and #size-cells properties in the power
> sequence itself.
>
> Note that this somewhat conflicts with accessing the top-level power
> sequence by name too; perhaps that should be re-thought too. I must
> admit this DT rule kinda sucks.
>
>> +Power Sequences Steps
>> +-
>> +Every step of a sequence describes an action to be performed on a resource.
>> It
>> +generally includes a property named after the resource type, and which value
>> +references the resource to be used. Depending on the resource type,
>> additional
>> +properties can be defined to control the action to be performed.
>
> I think you need to add a property that indicates what type of resource
> each step applies to. Sure, this is implicit in that if a "gpio"
> property exists, the step is a GPIO step, but in order to make that
> work, you'd have to search each node for each possible resource type's
> property name. It'd be far better to read a single type="gpio" property,
> then parse the step based on that.
>
>> +Example
>> +---
>> +Here are example sequences declared within a backlight device that use all
>> the
>> +supported resources types:
>> +
>> +backlight {
>> +compatible = "pwm-backlight";
>> +...
>> +
>> +/* resources used by the sequences */
>> +pwms = <&pwm 2 500>;
>> +pwm-names = "backlight";
>> +power-supply = <&backlight_reg>;
>> +enable-gpio = <&gpio 28 0>;
>> +
>> +power-on-sequence {
>> +step0 {
>> +regulator = "power";
>> +enable;
>> +};
>> +step1 {
>> +delay = <1>;
>> +};
>> +step2 {
>> +pwm = "backlight";
>> +
Re: [Techteam] [RFC PATCH] x86-32: Start out eflags and cr4 clean
On 1/18/2013 2:42 PM, H. Peter Anvin wrote: > On 01/18/2013 04:40 PM, Andres Salomon wrote: >> Bad news on this patch; I've been told that it breaks booting on an >> XO-1.5. Does anyone from OLPC know why yet? > > What are the settings of CR0 and CR4 on kernel entry on XO-1.5? CR0 is 0x8011 CR4 is 0x10 > > -hpa > > > ___ > Techteam mailing list > techt...@lists.laptop.org > http://lists.laptop.org/listinfo/techteam > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Techteam] [RFC PATCH] x86-32: Start out eflags and cr4 clean
On 1/18/2013 4:35 PM, H. Peter Anvin wrote: > On 01/18/2013 05:05 PM, Mitch Bradley wrote: >> >> >> On 1/18/2013 2:42 PM, H. Peter Anvin wrote: >>> On 01/18/2013 04:40 PM, Andres Salomon wrote: >>>> Bad news on this patch; I've been told that it breaks booting on an >>>> XO-1.5. Does anyone from OLPC know why yet? >>> >>> What are the settings of CR0 and CR4 on kernel entry on XO-1.5? >> >> >> CR0 is 0x8011 >> CR4 is 0x10 >> > > OK, that makes sense... the kernel doesn't enable the PSE bit yet and I > bet that's what you're using for the non-stolen page tables. Indeed, we are using 4M pages to map the firmware into high virtual addresses. > > Can we simply disable paging before mucking with CR4? The other option > that I can see is to always enable PSE and PGE, since they are simply > features opt-ins that don't do any harm if unused. At the same time, > though, entering the kernel through the default_entry path with paging > enabled is definitely not anything the kernel expects. > > Does this patch work for you? Since we have ditched 386 support, we can > mimic x86-64 (yay, one more difference gone!) and just use a predefined > value for %cr0 (the FPU flags need to change if we are on an FPU-less > chip, but that happens during FPU probing.) > > Does this patch work for you? We will test it and get back to you. > > -hpa > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Open Firmware device tree virtual filesystem
Request for comments. This patch creates a virtual filesystem that represents an Open Firmware device tree. It has been tested on an OLPC x86 system, but the code is not processor-specific (apart from its current location under arch/i386). It requires an Open Firmware implementation that can stay resident during Linux startup. It is similar in some respect to fs/proc/proc_devtree.c , but does not use procfs, nor does it require an intermediate layer of code to create a flattened representation of the device tree. The patch applies cleanly against the current version of git://dev.laptop.org/olpc-2.6 . (commit 5b9429be6056864b938ff6f39e5df3cecbbfcf4b). Please cc me (Mitch Bradley <[EMAIL PROTECTED]>) on comments. OLPC users will need to upgrade their firmware to http://wiki.laptop.org/go/OLPC_Firmware_Q2B14 to use this. diff --git a/.config b/.config index 6087ae7..f15900f 100644 --- a/.config +++ b/.config @@ -246,6 +246,7 @@ # CONFIG_MCA is not set # CONFIG_SCx200 is not set CONFIG_OLPC=y CONFIG_OLPC_PM=y +CONFIG_OFW_FS=y # # PCCARD (PCMCIA/CardBus) support diff --git a/Documentation/filesystems/ofwfs.txt b/Documentation/filesystems/ofwfs.txt new file mode 100644 index 000..9dd94de --- /dev/null +++ b/Documentation/filesystems/ofwfs.txt @@ -0,0 +1,115 @@ + ofwfs - Open Firmware File System + +ofwfs makes the Open Firmware device tree available to Linux as +a mountable virtual filesystem. + +== Introduction == + +Open Firmware (OFW) is boot firmware as defined by IEEE Standard +1275-1994*. It is common on SPARC (where it is called "Open Boot", a +Sun trademark) and PowerPC processors, and is available for several +other processors. In the x86 realm, the highest profile platform that +uses Open Firmware is the One Laptop Per Child system. Open source +implemenations can be found at openbios.org. + +The Open Firmware device tree is a hierarchical description of the +system hardware, plus a few other bits of information about the +firmware itself. The root of the device tree represents the main +system bus. There are child nodes for bridges to subordinate buses, +for individual peripheral devices, and for "pseudo devices" representing +other useful information. + +Each device tree node contains a set of properties that describe the +object in question. They specify such things as the name and type of +the device, its address ranges within the address space of its parent +bus, the interrupts that it uses, clock frequencies, and other +information that is useful for device identification and configuration. + +== Filesystem Representation == + +ofwfs exports the OFW device tree as a Linux filesystem. Filesystem +directories correspond to a device tree nodes, with the directory name +being the fully-qualifed ([EMAIL PROTECTED]) node name. Regular files +correspond to properties, with file name being the same as the property name +and the file contents being the verbatim property value. + +== Property Value Encoding == + +OFW property values are encoded using a well-defined format that is the +concatenation of some number of items, each encoded in a platform-independent +manner according to its type. For example, a 32-bit integer is encoded +as 4 binary bytes in big-endian order (i.e. network byte order), whereas +a text string is encoded as a null-terminated sequence of bytes. There +is no padding between concatenated items; each item within a composite +property value begins immediately after the preceding item, without regard +to any alignment restrictions that may exist on a particular processor. + +Composite property values that contain mixed types (e.g. a 32-bit integer +followed by several strings) exist, but are rare. Most property values +are either a single item (e.g. a string or a number) or an array of similar +items (e.g. a list of numbers). + +A regular file in ofwfs contains the exact byte sequence that comprises the +OFW property value. Properties are not reformatted into text form, so numeric +property values appear as binary integers. While this is inconvenient +for viewing, it is generally easier for programs that read property values, +and it means that Open Firmware documentation about property values applies +directly, without having to separately document an ASCII transformation +(which would have to separately specified for different kinds of properties). + +== Environment Assumptions == + +The ofwfs code assumes that the Open Firmware client interface callback +can be executed during Linux kernel startup (specifically, at "core_initcall" +time). When ofwfs is initialized, it copies out the property values, so that +subsequent accesses to the tree do not require callbacks into OFW. + +After initialization, ofwfs can be used by kernel components such as drivers, +and it can be mounted so that userspace applications can access it. + +== Recommended Mount Point == + +The recommended mount point for ofwfs
Re: [PATCH] Open Firmware device tree virtual filesystem
David Miller wrote:
...
Can we please not have N different interfaces to the open-firmware
calls so that perhaps powerpc and Sparc have a chance of using this
code too?
The base interface function is callofw(), which is effectively identical
to call_prom_ret() in arch/powerpc/kernel/prom_init.c . So it seems
that PowerPC could use it. I suppose I could change the name of
callofw() to call_prom_ret(), thus making the base interface identical
to PowerPC's. All it does is argument marshalling, translating between
C varargs argument lists and the OFW argarray format.
SPARC should be able to use that same base interface function directly.
It is written to the standard OFW client interface. The x86 client
interface that I tested it on is essentially the same code that is in
OBP. It wouldn't work on ancient Sun machines with the sunmon romvec
interface, but Sun stopped making such machines something like 16 years ago.
On sparc and powerpc, we even build an in-kernel data structure of the
entire open-firmware device tree that code like your's could use if
you make a simple setup layer for i386 as well. We have interfaces for
modifying property values at run time too.
I would strongly suggest looking at things like
arch/{sparc,sparc64,powerpc}/kernel/prom.c and
include/asm-{sparc,sparc64,powerpc}/prom.h and
arch/{sparc,sparc64,powerpc}/kernel/of_device.c and
include/asm-{sparc,sparc64,powerpc}/of_device.h
since we've already invested a lot of thought and
infrastructure into providing interfaces to this information
on powerpc and the two sparc platforms.
I did look at those files, until my eyes glazed over. In powerpc land,
the files that are the underlayer for proc_devtree.c comprise 4700 lines
of code (the files you list plus prom_init.c). In sparc land, it is
only 3200 lines (the files you list plus the prom interface library).
On top of that, proc_devtree.c is 233 lines.
In contrast, ofw_fs.c is 261 lines, and the base interface function
callofw() is 97 lines (half of them comments).
Admittedly, this is something of an apples-to-oranges comparison,
because ofw_fs only exports a read-only device tree and nothing else.
But in the case where that is all you need, a direct interface to OFW
that avoids the middleman seems like a good choice.
I did consider first creating a memory data structure identical to the
powerpc/sparc one, but that looked like it was going to be essentially
twice as much code for no extra capability. The code to traverse the
device tree and create the memory data structure is roughly the same as
the code to create the filesystem structure. I just didn't see the
value of an intermediate representation for systems that don't otherwise
need it. (A setup layer would have let me use proc_devtree.c directly,
so the total amount of new code would have been the same, but many
people told me that if I even suggested using procfs the kernel gurus
would blow me out of the water without bothering to blink.)
In the SPARC and PowerPC spaces, Open Firmware is widespread, so it
makes sense for those kernels to use OFW extensively. In x86 land, OFW
is far from being the dominant firmware, so the x86 kernel is unlikely
to depend on OFW services at a deep level. That being the case, the
deep-integration features of the sparc and powerpc OFW interfaces are
not needed in x86 land. But a lightweight interface to the device tree
is certainly useful for the platforms that do have OFW. It might be
useful for other processors as well, especially on platforms that don't
need the deep configurability that drove the OFW design.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Open Firmware device tree virtual filesystem
I made all the changes Pekka suggested, except:
+ security = strncmp(propname, "security-", 9) == 0;
+ len = 0;
Redundant assignment, no?
+ if (!security)
+ (void)callofw("getproplen", 2, 1, node,
propname, &len);
That assignment turns out not to be redundant. If a security variable
is recognized, you want the length to be 0 so as not to expose the
password. In that case the following "getproplen" call won't be executed.
That logic was adapted from the existing file fs/proc/devtree.c . It
turns out that the code there has a bug: You really want to look for
just "security-password" ; there is no need to, and good reasons not to,
suppress the length of "security-mode" and "security-#badlogins". (Good
OFW implementations won't leak the password length anyway, so check is
only needed as a workaround).
I have rewritten the code for clarity and correctness thusly:
if (strcmp(propname, "security-password") == 0) {
len = 0;/* Don't leak password length */
} else {
callofw("getproplen", 2, 1, node, propname, &len);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Open Firmware device tree virtual filesystem
David Miller wrote: We don't generally export binary representation files out of /proc or /sys, in fact this rule I believe is layed our precisely somewhere at least in the sysfs case. pci-sysfs exports PCI config space in binary. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Open Firmware device tree virtual filesystem
We could of course have the interface work either on a copy of the tree or on a real OF (though that means changing things like get_property on powerpc and fixing the gazillions of users) but I tend to think that working on a copy always is more efficient. The patch that I posted creates a copy in the virtual filesystem domain. So the efficiency issue is moot. The filesystem domain copy is smaller than the in-memory tree, as it omits a lot of unnecessary fields. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Open Firmware device tree virtual filesystem
Segher has a modification to the devtree patch that creates a lower level ops vector that can be implemented with callback or non-callback. It is still being tested. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
