Re: [PATCH v6 0/4] Runtime Interpreted Power Sequences
On 10/03/2012 02:24 AM, Alex Courbot wrote: > On 09/14/2012 12:24 AM, Stephen Warren wrote: >> On 09/13/2012 01:29 AM, Mark Brown wrote: >>> On Thu, Sep 13, 2012 at 04:26:34PM +0900, Alex Courbot wrote: On Thursday 13 September 2012 15:19:30 Mark Brown wrote: >> On Thursday 13 September 2012 14:25:53 Mark Brown wrote: >>> It would be sensible to make sure that the framework is done in >>> such a >>> way that drivers can use it - there will be drivers (perhaps not >>> display >>> ones) that have a known power sequence and which could benefit >>> from the >>> ability to use library code to implement it based on the user simply >>> supplying named resources. >>> >> Not sure I understand what you mean, but things should be working >> this way >> already - regulators and PWMs are acquired by name using the standard >> regulator_get() and pwm_get() functions. GPIOs do not, AFAIK, have >> a way >> to be referenced by name so their number is used instead. >>> > Right, but the sequencing for enabling them is currently open coded in > each driver. >>> Mmm then I'm afraid I don't see what you wanted to say initially - could you elaborate? >>> >>> The driver knows the power sequence. Having to type the same sequence >>> into the DT or platform data for each board using the device wouuld be >>> retarded so we need the drivers to be able to give the sequence to the >>> library if they're going to be able to reuse it (which is a lot of what >>> Tomi is talking about). >> >> I believe that's trivial to implement. The relevant function is: >> >> struct power_seq_set *devm_power_seq_set_build(struct device *dev, >>struct platform_power_seq_set *pseq); >> >> It's up to the driver whether pseq comes from platform data or is >> hard-coded into the driver (or not provided at all, for the DT case). >> So, the only change needed to convert a "hard-coded" driver to this API >> is to convert the current custom data structure (or code) that describes >> the sequence into a struct platform_power_seq_set. > > If we go this way (which looks good IMO!), then maybe we should abandon > that "platform" denomination and merge platform_power_seq* structures > with the currently private power_seq*, and also replace the "building" > step with a resources acquisition one. Calling these structures > "platform" implies they are for platform data while they can be used to > perform more flexible things as Mark mentioned. That all seems reasonable. > Also making the resolved > resource visible would allow drivers to "patch" generic sequences with > the proper GPIO numbers at runtime. That doesn't sound like a great idea to me, but we can simply avoid doing this even though it's technically possible. > We would also avoid a few memory > copies and both design and usage would be simplified, at the cost of > having more things exposed. How does that sound? Sounds fine to me at least. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On 09/14/2012 12:24 AM, Stephen Warren wrote: On 09/13/2012 01:29 AM, Mark Brown wrote: On Thu, Sep 13, 2012 at 04:26:34PM +0900, Alex Courbot wrote: On Thursday 13 September 2012 15:19:30 Mark Brown wrote: On Thursday 13 September 2012 14:25:53 Mark Brown wrote: It would be sensible to make sure that the framework is done in such a way that drivers can use it - there will be drivers (perhaps not display ones) that have a known power sequence and which could benefit from the ability to use library code to implement it based on the user simply supplying named resources. Not sure I understand what you mean, but things should be working this way already - regulators and PWMs are acquired by name using the standard regulator_get() and pwm_get() functions. GPIOs do not, AFAIK, have a way to be referenced by name so their number is used instead. Right, but the sequencing for enabling them is currently open coded in each driver. Mmm then I'm afraid I don't see what you wanted to say initially - could you elaborate? The driver knows the power sequence. Having to type the same sequence into the DT or platform data for each board using the device wouuld be retarded so we need the drivers to be able to give the sequence to the library if they're going to be able to reuse it (which is a lot of what Tomi is talking about). I believe that's trivial to implement. The relevant function is: struct power_seq_set *devm_power_seq_set_build(struct device *dev, struct platform_power_seq_set *pseq); It's up to the driver whether pseq comes from platform data or is hard-coded into the driver (or not provided at all, for the DT case). So, the only change needed to convert a "hard-coded" driver to this API is to convert the current custom data structure (or code) that describes the sequence into a struct platform_power_seq_set. If we go this way (which looks good IMO!), then maybe we should abandon that "platform" denomination and merge platform_power_seq* structures with the currently private power_seq*, and also replace the "building" step with a resources acquisition one. Calling these structures "platform" implies they are for platform data while they can be used to perform more flexible things as Mark mentioned. Also making the resolved resource visible would allow drivers to "patch" generic sequences with the proper GPIO numbers at runtime. We would also avoid a few memory copies and both design and usage would be simplified, at the cost of having more things exposed. How does that sound? Alex. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On 09/14/2012 12:24 AM, Stephen Warren wrote: On 09/13/2012 01:29 AM, Mark Brown wrote: On Thu, Sep 13, 2012 at 04:26:34PM +0900, Alex Courbot wrote: On Thursday 13 September 2012 15:19:30 Mark Brown wrote: On Thursday 13 September 2012 14:25:53 Mark Brown wrote: It would be sensible to make sure that the framework is done in such a way that drivers can use it - there will be drivers (perhaps not display ones) that have a known power sequence and which could benefit from the ability to use library code to implement it based on the user simply supplying named resources. Not sure I understand what you mean, but things should be working this way already - regulators and PWMs are acquired by name using the standard regulator_get() and pwm_get() functions. GPIOs do not, AFAIK, have a way to be referenced by name so their number is used instead. Right, but the sequencing for enabling them is currently open coded in each driver. Mmm then I'm afraid I don't see what you wanted to say initially - could you elaborate? The driver knows the power sequence. Having to type the same sequence into the DT or platform data for each board using the device wouuld be retarded so we need the drivers to be able to give the sequence to the library if they're going to be able to reuse it (which is a lot of what Tomi is talking about). I believe that's trivial to implement. The relevant function is: struct power_seq_set *devm_power_seq_set_build(struct device *dev, struct platform_power_seq_set *pseq); It's up to the driver whether pseq comes from platform data or is hard-coded into the driver (or not provided at all, for the DT case). So, the only change needed to convert a hard-coded driver to this API is to convert the current custom data structure (or code) that describes the sequence into a struct platform_power_seq_set. If we go this way (which looks good IMO!), then maybe we should abandon that platform denomination and merge platform_power_seq* structures with the currently private power_seq*, and also replace the building step with a resources acquisition one. Calling these structures platform implies they are for platform data while they can be used to perform more flexible things as Mark mentioned. Also making the resolved resource visible would allow drivers to patch generic sequences with the proper GPIO numbers at runtime. We would also avoid a few memory copies and both design and usage would be simplified, at the cost of having more things exposed. How does that sound? Alex. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On 10/03/2012 02:24 AM, Alex Courbot wrote: On 09/14/2012 12:24 AM, Stephen Warren wrote: On 09/13/2012 01:29 AM, Mark Brown wrote: On Thu, Sep 13, 2012 at 04:26:34PM +0900, Alex Courbot wrote: On Thursday 13 September 2012 15:19:30 Mark Brown wrote: On Thursday 13 September 2012 14:25:53 Mark Brown wrote: It would be sensible to make sure that the framework is done in such a way that drivers can use it - there will be drivers (perhaps not display ones) that have a known power sequence and which could benefit from the ability to use library code to implement it based on the user simply supplying named resources. Not sure I understand what you mean, but things should be working this way already - regulators and PWMs are acquired by name using the standard regulator_get() and pwm_get() functions. GPIOs do not, AFAIK, have a way to be referenced by name so their number is used instead. Right, but the sequencing for enabling them is currently open coded in each driver. Mmm then I'm afraid I don't see what you wanted to say initially - could you elaborate? The driver knows the power sequence. Having to type the same sequence into the DT or platform data for each board using the device wouuld be retarded so we need the drivers to be able to give the sequence to the library if they're going to be able to reuse it (which is a lot of what Tomi is talking about). I believe that's trivial to implement. The relevant function is: struct power_seq_set *devm_power_seq_set_build(struct device *dev, struct platform_power_seq_set *pseq); It's up to the driver whether pseq comes from platform data or is hard-coded into the driver (or not provided at all, for the DT case). So, the only change needed to convert a hard-coded driver to this API is to convert the current custom data structure (or code) that describes the sequence into a struct platform_power_seq_set. If we go this way (which looks good IMO!), then maybe we should abandon that platform denomination and merge platform_power_seq* structures with the currently private power_seq*, and also replace the building step with a resources acquisition one. Calling these structures platform implies they are for platform data while they can be used to perform more flexible things as Mark mentioned. That all seems reasonable. Also making the resolved resource visible would allow drivers to patch generic sequences with the proper GPIO numbers at runtime. That doesn't sound like a great idea to me, but we can simply avoid doing this even though it's technically possible. We would also avoid a few memory copies and both design and usage would be simplified, at the cost of having more things exposed. How does that sound? Sounds fine to me at least. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On Thu, Sep 13, 2012 at 09:24:53AM -0600, Stephen Warren wrote: > On 09/13/2012 01:29 AM, Mark Brown wrote: > > The driver knows the power sequence. Having to type the same sequence > > into the DT or platform data for each board using the device wouuld be > > retarded so we need the drivers to be able to give the sequence to the > > library if they're going to be able to reuse it (which is a lot of what > > Tomi is talking about). > I believe that's trivial to implement. The relevant function is: Right, that's what I'm saying - the code is mostly there now. > It's up to the driver whether pseq comes from platform data or is > hard-coded into the driver (or not provided at all, for the DT case). > So, the only change needed to convert a "hard-coded" driver to this API > is to convert the current custom data structure (or code) that describes > the sequence into a struct platform_power_seq_set. The framework could still help by providing ways to avoid having to copy the structure and fill in the blanks for GPIO numbers (and anything else that is numbered rather than named) by hand. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On Thu, Sep 13, 2012 at 09:24:53AM -0600, Stephen Warren wrote: On 09/13/2012 01:29 AM, Mark Brown wrote: The driver knows the power sequence. Having to type the same sequence into the DT or platform data for each board using the device wouuld be retarded so we need the drivers to be able to give the sequence to the library if they're going to be able to reuse it (which is a lot of what Tomi is talking about). I believe that's trivial to implement. The relevant function is: Right, that's what I'm saying - the code is mostly there now. It's up to the driver whether pseq comes from platform data or is hard-coded into the driver (or not provided at all, for the DT case). So, the only change needed to convert a hard-coded driver to this API is to convert the current custom data structure (or code) that describes the sequence into a struct platform_power_seq_set. The framework could still help by providing ways to avoid having to copy the structure and fill in the blanks for GPIO numbers (and anything else that is numbered rather than named) by hand. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On 09/13/2012 01:29 AM, Mark Brown wrote: > On Thu, Sep 13, 2012 at 04:26:34PM +0900, Alex Courbot wrote: >> On Thursday 13 September 2012 15:19:30 Mark Brown wrote: On Thursday 13 September 2012 14:25:53 Mark Brown wrote: > It would be sensible to make sure that the framework is done in such a > way that drivers can use it - there will be drivers (perhaps not display > ones) that have a known power sequence and which could benefit from the > ability to use library code to implement it based on the user simply > supplying named resources. > Not sure I understand what you mean, but things should be working this way already - regulators and PWMs are acquired by name using the standard regulator_get() and pwm_get() functions. GPIOs do not, AFAIK, have a way to be referenced by name so their number is used instead. > >>> Right, but the sequencing for enabling them is currently open coded in >>> each driver. > >> Mmm then I'm afraid I don't see what you wanted to say initially - could you >> elaborate? > > The driver knows the power sequence. Having to type the same sequence > into the DT or platform data for each board using the device wouuld be > retarded so we need the drivers to be able to give the sequence to the > library if they're going to be able to reuse it (which is a lot of what > Tomi is talking about). I believe that's trivial to implement. The relevant function is: struct power_seq_set *devm_power_seq_set_build(struct device *dev, struct platform_power_seq_set *pseq); It's up to the driver whether pseq comes from platform data or is hard-coded into the driver (or not provided at all, for the DT case). So, the only change needed to convert a "hard-coded" driver to this API is to convert the current custom data structure (or code) that describes the sequence into a struct platform_power_seq_set. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On Thu, Sep 13, 2012 at 04:26:34PM +0900, Alex Courbot wrote: > On Thursday 13 September 2012 15:19:30 Mark Brown wrote: > > > On Thursday 13 September 2012 14:25:53 Mark Brown wrote: > > > > It would be sensible to make sure that the framework is done in such a > > > > way that drivers can use it - there will be drivers (perhaps not display > > > > ones) that have a known power sequence and which could benefit from the > > > > ability to use library code to implement it based on the user simply > > > > supplying named resources. > > > Not sure I understand what you mean, but things should be working this way > > > already - regulators and PWMs are acquired by name using the standard > > > regulator_get() and pwm_get() functions. GPIOs do not, AFAIK, have a way > > > to be referenced by name so their number is used instead. > > Right, but the sequencing for enabling them is currently open coded in > > each driver. > Mmm then I'm afraid I don't see what you wanted to say initially - could you > elaborate? The driver knows the power sequence. Having to type the same sequence into the DT or platform data for each board using the device wouuld be retarded so we need the drivers to be able to give the sequence to the library if they're going to be able to reuse it (which is a lot of what Tomi is talking about). -- 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 v6 0/4] Runtime Interpreted Power Sequences
On Thursday 13 September 2012 15:19:30 Mark Brown wrote: > On Thu, Sep 13, 2012 at 03:42:11PM +0900, Alex Courbot wrote: > > On Thursday 13 September 2012 14:25:53 Mark Brown wrote: > > > It would be sensible to make sure that the framework is done in such a > > > way that drivers can use it - there will be drivers (perhaps not display > > > ones) that have a known power sequence and which could benefit from the > > > ability to use library code to implement it based on the user simply > > > supplying named resources. > > > > Not sure I understand what you mean, but things should be working this way > > already - regulators and PWMs are acquired by name using the standard > > regulator_get() and pwm_get() functions. GPIOs do not, AFAIK, have a way > > to be referenced by name so their number is used instead. > > Right, but the sequencing for enabling them is currently open coded in > each driver. Mmm then I'm afraid I don't see what you wanted to say initially - could you elaborate? Alex. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On Thu, Sep 13, 2012 at 03:42:11PM +0900, Alex Courbot wrote: > On Thursday 13 September 2012 14:25:53 Mark Brown wrote: > > It would be sensible to make sure that the framework is done in such a > > way that drivers can use it - there will be drivers (perhaps not display > > ones) that have a known power sequence and which could benefit from the > > ability to use library code to implement it based on the user simply > > supplying named resources. > Not sure I understand what you mean, but things should be working this way > already - regulators and PWMs are acquired by name using the standard > regulator_get() and pwm_get() functions. GPIOs do not, AFAIK, have a way to > be > referenced by name so their number is used instead. Right, but the sequencing for enabling them is currently open coded in each driver. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On Thu, 2012-09-13 at 15:23 +0900, Alex Courbot wrote: > DT support is actually the main point of power sequences, as outside of the > DT > we can always work the old way and use callbacks. If we were to remove DT > support, I am not sure this work would still be worth being merged. Ah, I guess you meant hooks in the driver, not hooks to board files? Yes, that would work, but if all the hooks do essentially the same things with just minor modifications like sleep-time, it makes more sense to have just one piece of code which gets the sequence as data. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v6 0/4] Runtime Interpreted Power Sequences
On Thu, 2012-09-13 at 15:23 +0900, Alex Courbot wrote: > On Thursday 13 September 2012 13:50:47 Tomi Valkeinen wrote: > > I want to reiterate my opinion that I think power sequences in DT data > > is the wrong way to go. Powering sequences are device specific issues > > and should be handled in the device driver. But I also think that power > > sequences inside the drivers would probably be useful. > > I understand the logic behind handling powering sequences in the device > driver, but as we discussed for some classes of devices this might just not > scale. I don't know how many different panels (each with different powering > sequences) are relying on pwm_backlight, but the alternative of embedding > support for all of them into the kernel (and bloating the kernel image) or > having a 3 kilometers list in the kernel configuration to individually chose > which panel to support (which would be cumbersome and make the kernel less > portable across boards) does not look much appealing to me. With power > sequences encoded in the DT, we could have one .dtsi file per panel that > would > be included from the board's .dts file - no bloat, no drivers explosion, > portability preserved. Yes, I see that side of the argument also. And to be honest, I don't know what kind of data is DT supposed to contain (or if there even is a strict definition for that). I have my opinion because I think that's how things should be: DT tells us what devices there are and how they connect, and the driver handles the rest. I may be a perfectionist, though, which is not good =). As for the kernel bloat, it's a valid issue, but I wonder if it would be an issue in practice. I don't know how many different supported devices we'd have, and how many bytes the data for each device would consume. I'm not even sure what amount of bytes would be acceptable. But I'm guessing that we wouldn't have very many devices, and if the per device data is made compact there wouldn't be that many bytes per device. And with non-hotpluggable platform devices the unused device data could be discarded after init. Anyway, having the power sequences doesn't affect me if I don't use them, so I have nothing against them =). > DT support is actually the main point of power sequences, as outside of the > DT > we can always work the old way and use callbacks. If we were to remove DT > support, I am not sure this work would still be worth being merged. We can't use board callbacks when running with a DT enabled kernel. What I meant is that the driver could contain a power sequence for the device (or multiple supported devices). So it'd essentially be the same as getting the power sequence from the DT data. But I haven't looked at the power sequence data structures, so I'm not sure if they are geared for DT use. If so, they would probably need tuning to be good for in-kernel use. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v6 0/4] Runtime Interpreted Power Sequences
On Thursday 13 September 2012 14:25:53 Mark Brown wrote: > On Thu, Sep 13, 2012 at 03:23:06PM +0900, Alex Courbot wrote: > > I understand the logic behind handling powering sequences in the device > > driver, but as we discussed for some classes of devices this might just > > not > > scale. I don't know how many different panels (each with different > > powering > > It would be sensible to make sure that the framework is done in such a > way that drivers can use it - there will be drivers (perhaps not display > ones) that have a known power sequence and which could benefit from the > ability to use library code to implement it based on the user simply > supplying named resources. Not sure I understand what you mean, but things should be working this way already - regulators and PWMs are acquired by name using the standard regulator_get() and pwm_get() functions. GPIOs do not, AFAIK, have a way to be referenced by name so their number is used instead. Alex. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On Thu, Sep 13, 2012 at 03:23:06PM +0900, Alex Courbot wrote: > I understand the logic behind handling powering sequences in the device > driver, but as we discussed for some classes of devices this might just not > scale. I don't know how many different panels (each with different powering It would be sensible to make sure that the framework is done in such a way that drivers can use it - there will be drivers (perhaps not display ones) that have a known power sequence and which could benefit from the ability to use library code to implement it based on the user simply supplying named resources. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On Thursday 13 September 2012 13:50:47 Tomi Valkeinen wrote: > * PGP Signed by an unknown key > > On Wed, 2012-09-12 at 18:57 +0900, Alexandre Courbot wrote: > > > New revision of the power sequences, taking as usual the feedback that > > was > > kindly provided about the last version. > > > > I think now is a good time to discuss integrating this and to start > > looking for a maintainer who would be willing to merge this into his/her > > tree (I am especially thinking about the power framework maintainers, > > since this is where the code is right now. The second patch in this > > series enables the pwm_backlight driver to be used with the device tree, > > without relying on board-dependent callbacks to support complex power > > sequences. We also plan to use power sequences in other Tegra drivers, > > and other people have expressed interest in this work during earlier > > reviews. See for instance > > > > https://lists.ozlabs.org/pipermail/devicetree-discuss/2012- August/018532.html > > and > > > > https://lkml.org/lkml/2012/9/6/270 > > > > There is probably some more details to fix and improve, but the current > > shape should be enough to know if we want this and where - therefore any > > sign from a maintainer would be greatly appreciated! > > > I want to reiterate my opinion that I think power sequences in DT data > is the wrong way to go. Powering sequences are device specific issues > and should be handled in the device driver. But I also think that power > sequences inside the drivers would probably be useful. I understand the logic behind handling powering sequences in the device driver, but as we discussed for some classes of devices this might just not scale. I don't know how many different panels (each with different powering sequences) are relying on pwm_backlight, but the alternative of embedding support for all of them into the kernel (and bloating the kernel image) or having a 3 kilometers list in the kernel configuration to individually chose which panel to support (which would be cumbersome and make the kernel less portable across boards) does not look much appealing to me. With power sequences encoded in the DT, we could have one .dtsi file per panel that would be included from the board's .dts file - no bloat, no drivers explosion, portability preserved. DT support is actually the main point of power sequences, as outside of the DT we can always work the old way and use callbacks. If we were to remove DT support, I am not sure this work would still be worth being merged. Alex. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On Thursday 13 September 2012 13:50:47 Tomi Valkeinen wrote: * PGP Signed by an unknown key On Wed, 2012-09-12 at 18:57 +0900, Alexandre Courbot wrote: New revision of the power sequences, taking as usual the feedback that was kindly provided about the last version. I think now is a good time to discuss integrating this and to start looking for a maintainer who would be willing to merge this into his/her tree (I am especially thinking about the power framework maintainers, since this is where the code is right now. The second patch in this series enables the pwm_backlight driver to be used with the device tree, without relying on board-dependent callbacks to support complex power sequences. We also plan to use power sequences in other Tegra drivers, and other people have expressed interest in this work during earlier reviews. See for instance https://lists.ozlabs.org/pipermail/devicetree-discuss/2012- August/018532.html and https://lkml.org/lkml/2012/9/6/270 There is probably some more details to fix and improve, but the current shape should be enough to know if we want this and where - therefore any sign from a maintainer would be greatly appreciated! I want to reiterate my opinion that I think power sequences in DT data is the wrong way to go. Powering sequences are device specific issues and should be handled in the device driver. But I also think that power sequences inside the drivers would probably be useful. I understand the logic behind handling powering sequences in the device driver, but as we discussed for some classes of devices this might just not scale. I don't know how many different panels (each with different powering sequences) are relying on pwm_backlight, but the alternative of embedding support for all of them into the kernel (and bloating the kernel image) or having a 3 kilometers list in the kernel configuration to individually chose which panel to support (which would be cumbersome and make the kernel less portable across boards) does not look much appealing to me. With power sequences encoded in the DT, we could have one .dtsi file per panel that would be included from the board's .dts file - no bloat, no drivers explosion, portability preserved. DT support is actually the main point of power sequences, as outside of the DT we can always work the old way and use callbacks. If we were to remove DT support, I am not sure this work would still be worth being merged. Alex. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On Thu, Sep 13, 2012 at 03:23:06PM +0900, Alex Courbot wrote: I understand the logic behind handling powering sequences in the device driver, but as we discussed for some classes of devices this might just not scale. I don't know how many different panels (each with different powering It would be sensible to make sure that the framework is done in such a way that drivers can use it - there will be drivers (perhaps not display ones) that have a known power sequence and which could benefit from the ability to use library code to implement it based on the user simply supplying named resources. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On Thursday 13 September 2012 14:25:53 Mark Brown wrote: On Thu, Sep 13, 2012 at 03:23:06PM +0900, Alex Courbot wrote: I understand the logic behind handling powering sequences in the device driver, but as we discussed for some classes of devices this might just not scale. I don't know how many different panels (each with different powering It would be sensible to make sure that the framework is done in such a way that drivers can use it - there will be drivers (perhaps not display ones) that have a known power sequence and which could benefit from the ability to use library code to implement it based on the user simply supplying named resources. Not sure I understand what you mean, but things should be working this way already - regulators and PWMs are acquired by name using the standard regulator_get() and pwm_get() functions. GPIOs do not, AFAIK, have a way to be referenced by name so their number is used instead. Alex. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On Thu, 2012-09-13 at 15:23 +0900, Alex Courbot wrote: On Thursday 13 September 2012 13:50:47 Tomi Valkeinen wrote: I want to reiterate my opinion that I think power sequences in DT data is the wrong way to go. Powering sequences are device specific issues and should be handled in the device driver. But I also think that power sequences inside the drivers would probably be useful. I understand the logic behind handling powering sequences in the device driver, but as we discussed for some classes of devices this might just not scale. I don't know how many different panels (each with different powering sequences) are relying on pwm_backlight, but the alternative of embedding support for all of them into the kernel (and bloating the kernel image) or having a 3 kilometers list in the kernel configuration to individually chose which panel to support (which would be cumbersome and make the kernel less portable across boards) does not look much appealing to me. With power sequences encoded in the DT, we could have one .dtsi file per panel that would be included from the board's .dts file - no bloat, no drivers explosion, portability preserved. Yes, I see that side of the argument also. And to be honest, I don't know what kind of data is DT supposed to contain (or if there even is a strict definition for that). I have my opinion because I think that's how things should be: DT tells us what devices there are and how they connect, and the driver handles the rest. I may be a perfectionist, though, which is not good =). As for the kernel bloat, it's a valid issue, but I wonder if it would be an issue in practice. I don't know how many different supported devices we'd have, and how many bytes the data for each device would consume. I'm not even sure what amount of bytes would be acceptable. But I'm guessing that we wouldn't have very many devices, and if the per device data is made compact there wouldn't be that many bytes per device. And with non-hotpluggable platform devices the unused device data could be discarded after init. Anyway, having the power sequences doesn't affect me if I don't use them, so I have nothing against them =). DT support is actually the main point of power sequences, as outside of the DT we can always work the old way and use callbacks. If we were to remove DT support, I am not sure this work would still be worth being merged. We can't use board callbacks when running with a DT enabled kernel. What I meant is that the driver could contain a power sequence for the device (or multiple supported devices). So it'd essentially be the same as getting the power sequence from the DT data. But I haven't looked at the power sequence data structures, so I'm not sure if they are geared for DT use. If so, they would probably need tuning to be good for in-kernel use. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v6 0/4] Runtime Interpreted Power Sequences
On Thu, 2012-09-13 at 15:23 +0900, Alex Courbot wrote: DT support is actually the main point of power sequences, as outside of the DT we can always work the old way and use callbacks. If we were to remove DT support, I am not sure this work would still be worth being merged. Ah, I guess you meant hooks in the driver, not hooks to board files? Yes, that would work, but if all the hooks do essentially the same things with just minor modifications like sleep-time, it makes more sense to have just one piece of code which gets the sequence as data. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v6 0/4] Runtime Interpreted Power Sequences
On Thu, Sep 13, 2012 at 03:42:11PM +0900, Alex Courbot wrote: On Thursday 13 September 2012 14:25:53 Mark Brown wrote: It would be sensible to make sure that the framework is done in such a way that drivers can use it - there will be drivers (perhaps not display ones) that have a known power sequence and which could benefit from the ability to use library code to implement it based on the user simply supplying named resources. Not sure I understand what you mean, but things should be working this way already - regulators and PWMs are acquired by name using the standard regulator_get() and pwm_get() functions. GPIOs do not, AFAIK, have a way to be referenced by name so their number is used instead. Right, but the sequencing for enabling them is currently open coded in each driver. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On Thursday 13 September 2012 15:19:30 Mark Brown wrote: On Thu, Sep 13, 2012 at 03:42:11PM +0900, Alex Courbot wrote: On Thursday 13 September 2012 14:25:53 Mark Brown wrote: It would be sensible to make sure that the framework is done in such a way that drivers can use it - there will be drivers (perhaps not display ones) that have a known power sequence and which could benefit from the ability to use library code to implement it based on the user simply supplying named resources. Not sure I understand what you mean, but things should be working this way already - regulators and PWMs are acquired by name using the standard regulator_get() and pwm_get() functions. GPIOs do not, AFAIK, have a way to be referenced by name so their number is used instead. Right, but the sequencing for enabling them is currently open coded in each driver. Mmm then I'm afraid I don't see what you wanted to say initially - could you elaborate? Alex. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On Thu, Sep 13, 2012 at 04:26:34PM +0900, Alex Courbot wrote: On Thursday 13 September 2012 15:19:30 Mark Brown wrote: On Thursday 13 September 2012 14:25:53 Mark Brown wrote: It would be sensible to make sure that the framework is done in such a way that drivers can use it - there will be drivers (perhaps not display ones) that have a known power sequence and which could benefit from the ability to use library code to implement it based on the user simply supplying named resources. Not sure I understand what you mean, but things should be working this way already - regulators and PWMs are acquired by name using the standard regulator_get() and pwm_get() functions. GPIOs do not, AFAIK, have a way to be referenced by name so their number is used instead. Right, but the sequencing for enabling them is currently open coded in each driver. Mmm then I'm afraid I don't see what you wanted to say initially - could you elaborate? The driver knows the power sequence. Having to type the same sequence into the DT or platform data for each board using the device wouuld be retarded so we need the drivers to be able to give the sequence to the library if they're going to be able to reuse it (which is a lot of what Tomi is talking about). -- 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 v6 0/4] Runtime Interpreted Power Sequences
On 09/13/2012 01:29 AM, Mark Brown wrote: On Thu, Sep 13, 2012 at 04:26:34PM +0900, Alex Courbot wrote: On Thursday 13 September 2012 15:19:30 Mark Brown wrote: On Thursday 13 September 2012 14:25:53 Mark Brown wrote: It would be sensible to make sure that the framework is done in such a way that drivers can use it - there will be drivers (perhaps not display ones) that have a known power sequence and which could benefit from the ability to use library code to implement it based on the user simply supplying named resources. Not sure I understand what you mean, but things should be working this way already - regulators and PWMs are acquired by name using the standard regulator_get() and pwm_get() functions. GPIOs do not, AFAIK, have a way to be referenced by name so their number is used instead. Right, but the sequencing for enabling them is currently open coded in each driver. Mmm then I'm afraid I don't see what you wanted to say initially - could you elaborate? The driver knows the power sequence. Having to type the same sequence into the DT or platform data for each board using the device wouuld be retarded so we need the drivers to be able to give the sequence to the library if they're going to be able to reuse it (which is a lot of what Tomi is talking about). I believe that's trivial to implement. The relevant function is: struct power_seq_set *devm_power_seq_set_build(struct device *dev, struct platform_power_seq_set *pseq); It's up to the driver whether pseq comes from platform data or is hard-coded into the driver (or not provided at all, for the DT case). So, the only change needed to convert a hard-coded driver to this API is to convert the current custom data structure (or code) that describes the sequence into a struct platform_power_seq_set. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On Thursday 13 September 2012 05:33:56 Anton Vorontsov wrote: > On Wed, Sep 12, 2012 at 03:27:04PM -0600, Stephen Warren wrote: > > > On 09/12/2012 03:57 AM, Alexandre Courbot wrote: > > > > > New revision of the power sequences, taking as usual the feedback that > > > was > > > kindly provided about the last version. > > > > > > I think now is a good time to discuss integrating this and to start > > > looking for a maintainer who would be willing to merge this into > > > his/her tree (I am especially thinking about the power framework > > > maintainers, since this is where the code is right now. > > > > > > The other alternative is for you to maintain this going forward; I > > believe that would be as simple as: > > > > * Create a patch to add yourself to MAINTAINERS for the > > drivers/power/power_seq/ directory. > > > > * Get a kernel.org account, push this patch to a branch there, and add > > the branch into linux-next. > > > > * Send a pull request to Linus at the appropriate time. > > > > * Ongoing: Accept any patches, perform any maintenance required, etc. > > > > Does anyone see any issue with Alexandre doing this? Nobody else has > > volunteered yet:-) > > > Yup, looks like the best way. I am fine this way too - it will just take some time for me to get ready as I will need to get my GPG key signed by some kernel developers first (that's what I forgot to do during the last LinuxCon!). I know a few here so it should not be too hard to get them drunk and sign my key, but I don't expect to be ready for the 3.7 merge window. Would anybody be concerned by this delay? By the meantime I can also make a branch available somewhere. Alex. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On Wed, 2012-09-12 at 18:57 +0900, Alexandre Courbot wrote: > New revision of the power sequences, taking as usual the feedback that was > kindly provided about the last version. > > I think now is a good time to discuss integrating this and to start looking > for > a maintainer who would be willing to merge this into his/her tree (I am > especially thinking about the power framework maintainers, since this is where > the code is right now. The second patch in this series enables the > pwm_backlight > driver to be used with the device tree, without relying on board-dependent > callbacks to support complex power sequences. We also plan to use power > sequences in other Tegra drivers, and other people have expressed interest in > this work during earlier reviews. See for instance > > https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-August/018532.html > > and > > https://lkml.org/lkml/2012/9/6/270 > > There is probably some more details to fix and improve, but the current shape > should be enough to know if we want this and where - therefore any sign from > a maintainer would be greatly appreciated! I want to reiterate my opinion that I think power sequences in DT data is the wrong way to go. Powering sequences are device specific issues and should be handled in the device driver. But I also think that power sequences inside the drivers would probably be useful. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v6 0/4] Runtime Interpreted Power Sequences
On Wed, Sep 12, 2012 at 03:27:04PM -0600, Stephen Warren wrote: > On 09/12/2012 03:57 AM, Alexandre Courbot wrote: > > New revision of the power sequences, taking as usual the feedback that was > > kindly provided about the last version. > > > > I think now is a good time to discuss integrating this and to start looking > > for > > a maintainer who would be willing to merge this into his/her tree (I am > > especially thinking about the power framework maintainers, since this is > > where > > the code is right now. > > The other alternative is for you to maintain this going forward; I > believe that would be as simple as: > > * Create a patch to add yourself to MAINTAINERS for the > drivers/power/power_seq/ directory. > > * Get a kernel.org account, push this patch to a branch there, and add > the branch into linux-next. > > * Send a pull request to Linus at the appropriate time. > > * Ongoing: Accept any patches, perform any maintenance required, etc. > > Does anyone see any issue with Alexandre doing this? Nobody else has > volunteered yet:-) Yup, looks like the best way. Anton. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On 09/12/2012 03:57 AM, Alexandre Courbot wrote: > New revision of the power sequences, taking as usual the feedback that was > kindly provided about the last version. > > I think now is a good time to discuss integrating this and to start looking > for > a maintainer who would be willing to merge this into his/her tree (I am > especially thinking about the power framework maintainers, since this is where > the code is right now. The other alternative is for you to maintain this going forward; I believe that would be as simple as: * Create a patch to add yourself to MAINTAINERS for the drivers/power/power_seq/ directory. * Get a kernel.org account, push this patch to a branch there, and add the branch into linux-next. * Send a pull request to Linus at the appropriate time. * Ongoing: Accept any patches, perform any maintenance required, etc. Does anyone see any issue with Alexandre doing this? Nobody else has volunteered yet:-) -- 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 v6 0/4] Runtime Interpreted Power Sequences
On 09/12/2012 03:57 AM, Alexandre Courbot wrote: New revision of the power sequences, taking as usual the feedback that was kindly provided about the last version. I think now is a good time to discuss integrating this and to start looking for a maintainer who would be willing to merge this into his/her tree (I am especially thinking about the power framework maintainers, since this is where the code is right now. The other alternative is for you to maintain this going forward; I believe that would be as simple as: * Create a patch to add yourself to MAINTAINERS for the drivers/power/power_seq/ directory. * Get a kernel.org account, push this patch to a branch there, and add the branch into linux-next. * Send a pull request to Linus at the appropriate time. * Ongoing: Accept any patches, perform any maintenance required, etc. Does anyone see any issue with Alexandre doing this? Nobody else has volunteered yet:-) -- 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 v6 0/4] Runtime Interpreted Power Sequences
On Wed, Sep 12, 2012 at 03:27:04PM -0600, Stephen Warren wrote: On 09/12/2012 03:57 AM, Alexandre Courbot wrote: New revision of the power sequences, taking as usual the feedback that was kindly provided about the last version. I think now is a good time to discuss integrating this and to start looking for a maintainer who would be willing to merge this into his/her tree (I am especially thinking about the power framework maintainers, since this is where the code is right now. The other alternative is for you to maintain this going forward; I believe that would be as simple as: * Create a patch to add yourself to MAINTAINERS for the drivers/power/power_seq/ directory. * Get a kernel.org account, push this patch to a branch there, and add the branch into linux-next. * Send a pull request to Linus at the appropriate time. * Ongoing: Accept any patches, perform any maintenance required, etc. Does anyone see any issue with Alexandre doing this? Nobody else has volunteered yet:-) Yup, looks like the best way. Anton. -- 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 v6 0/4] Runtime Interpreted Power Sequences
On Wed, 2012-09-12 at 18:57 +0900, Alexandre Courbot wrote: New revision of the power sequences, taking as usual the feedback that was kindly provided about the last version. I think now is a good time to discuss integrating this and to start looking for a maintainer who would be willing to merge this into his/her tree (I am especially thinking about the power framework maintainers, since this is where the code is right now. The second patch in this series enables the pwm_backlight driver to be used with the device tree, without relying on board-dependent callbacks to support complex power sequences. We also plan to use power sequences in other Tegra drivers, and other people have expressed interest in this work during earlier reviews. See for instance https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-August/018532.html and https://lkml.org/lkml/2012/9/6/270 There is probably some more details to fix and improve, but the current shape should be enough to know if we want this and where - therefore any sign from a maintainer would be greatly appreciated! I want to reiterate my opinion that I think power sequences in DT data is the wrong way to go. Powering sequences are device specific issues and should be handled in the device driver. But I also think that power sequences inside the drivers would probably be useful. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v6 0/4] Runtime Interpreted Power Sequences
On Thursday 13 September 2012 05:33:56 Anton Vorontsov wrote: On Wed, Sep 12, 2012 at 03:27:04PM -0600, Stephen Warren wrote: On 09/12/2012 03:57 AM, Alexandre Courbot wrote: New revision of the power sequences, taking as usual the feedback that was kindly provided about the last version. I think now is a good time to discuss integrating this and to start looking for a maintainer who would be willing to merge this into his/her tree (I am especially thinking about the power framework maintainers, since this is where the code is right now. The other alternative is for you to maintain this going forward; I believe that would be as simple as: * Create a patch to add yourself to MAINTAINERS for the drivers/power/power_seq/ directory. * Get a kernel.org account, push this patch to a branch there, and add the branch into linux-next. * Send a pull request to Linus at the appropriate time. * Ongoing: Accept any patches, perform any maintenance required, etc. Does anyone see any issue with Alexandre doing this? Nobody else has volunteered yet:-) Yup, looks like the best way. I am fine this way too - it will just take some time for me to get ready as I will need to get my GPG key signed by some kernel developers first (that's what I forgot to do during the last LinuxCon!). I know a few here so it should not be too hard to get them drunk and sign my key, but I don't expect to be ready for the 3.7 merge window. Would anybody be concerned by this delay? By the meantime I can also make a branch available somewhere. Alex. -- 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/
