Re: [PATCH 0/3] Use acpi_video_unregister_backlight instead of acpi_video_unregister in platfrom backlight drivers
On Mon, Jun 01, 2015 at 11:25:05AM +0200, Hans de Goede wrote: > Hi All, > > I'm working on cleaning up the currently somewhat convoluted logic to > select which backlight interfaces to register on x86 systems, see: > http://lists.freedesktop.org/archives/dri-devel/2014-December/074687.html > > For a rought outline (details will change in the actual patch-set). > > These 3 patches are a preparation for that work, as the behavior of the > current code is not always consistent (it changes depending on module > loading order in some cases). These 3 patches remove this inconsistency > which in some cases may result in a behavior change. > > This way the cleanup can have a consistent base to build upon, and I can > ensure that the cleanup itself does not cause any functional changes. These are now available in for-next. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Use acpi_video_unregister_backlight instead of acpi_video_unregister in platfrom backlight drivers
On Mon, Jun 01, 2015 at 11:25:05AM +0200, Hans de Goede wrote: > Hi All, > > I'm working on cleaning up the currently somewhat convoluted logic to > select which backlight interfaces to register on x86 systems, see: > http://lists.freedesktop.org/archives/dri-devel/2014-December/074687.html > > For a rought outline (details will change in the actual patch-set). > > These 3 patches are a preparation for that work, as the behavior of the > current code is not always consistent (it changes depending on module > loading order in some cases). These 3 patches remove this inconsistency > which in some cases may result in a behavior change. > > This way the cleanup can have a consistent base to build upon, and I can > ensure that the cleanup itself does not cause any functional changes. > > I hope to post a v1 of the actual cleanup patch-set in 1-2 weeks. Letting these sit in my testing branch while awaiting at ack from Corentin on 2 of the 3. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Use acpi_video_unregister_backlight instead of acpi_video_unregister in platfrom backlight drivers
On Tue, Jun 02, 2015 at 10:33:50PM +0800, Aaron Lu wrote: > On Tue, Jun 02, 2015 at 12:14:28PM +0200, Hans de Goede wrote: > > > > If this makes sense (*) then the cooling device stuff should maybe moved > > from the acpi/video.c code to the backlight core code. > > It's just a specific driver that provides thermal capability, no need to > move to the core code. I didn't get this when replying and now I think it's doable. Regards, Aaron -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Use acpi_video_unregister_backlight instead of acpi_video_unregister in platfrom backlight drivers
On Tue, Jun 02, 2015 at 12:14:28PM +0200, Hans de Goede wrote: > Hi, > > On 02-06-15 11:59, Jani Nikula wrote: > >On Mon, 01 Jun 2015, Hans de Goede wrote: > >>Hi All, > >> > >>I'm working on cleaning up the currently somewhat convoluted logic to > >>select which backlight interfaces to register on x86 systems, see: > >>http://lists.freedesktop.org/archives/dri-devel/2014-December/074687.html > >> > >>For a rought outline (details will change in the actual patch-set). > >> > >>These 3 patches are a preparation for that work, as the behavior of the > >>current code is not always consistent (it changes depending on module > >>loading order in some cases). These 3 patches remove this inconsistency > >>which in some cases may result in a behavior change. > >> > >>This way the cleanup can have a consistent base to build upon, and I can > >>ensure that the cleanup itself does not cause any functional changes. > > > >Thanks for doing this. > > > >Slightly unrelated, but you'll end up calling: > > > >acpi_video_unregister_backlight > > acpi_video_bus_unregister_backlight > > acpi_video_dev_unregister_backlight > > thermal_cooling_device_unregister > > > >Uhm, err, what? What business does *that* have in the backlight > >unregister call chain?! > > I think the idea is that having the backlight on can cause the main board > to heat up as there is often a regulator / pwm for the backlight on the > main board. If that is turned off it may help to cool down the main board, > so the backlight is a cooling device in the sense that when it is turned > off it stops generating heat. I think so. > > If this makes sense (*) then the cooling device stuff should maybe moved > from the acpi/video.c code to the backlight core code. It's just a specific driver that provides thermal capability, no need to move to the core code. > > Or does the acpi-video code use some info from the BIOS to determine > whether or not to register a cooling device ? As long as we create the ACPI video backlight interface, we will create the thermal cooling device. If we somehow knows that the ACPI methods to adjust the backlight level doesn't work(a good hint is that the acpi_video_unregister_backlight is called), we should make that cooling device disappear. Regards, Aaron > > Regards, > > Hans > > > > > *) This is tricky, e.g. going low brightness may cause the main board > to heat up more then full brightness depending on how things are hooked > up. > > > > Should that be untangled from the mess too? > > > >BR, > >Jani. > > > > > >> > >>I hope to post a v1 of the actual cleanup patch-set in 1-2 weeks. > >> > >>Regards, > >> > >>Hans > >>___ > >>dri-devel mailing list > >>[email protected] > >>http://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Use acpi_video_unregister_backlight instead of acpi_video_unregister in platfrom backlight drivers
On Tue, Jun 02, 2015 at 12:59:10PM +0300, Jani Nikula wrote: > On Mon, 01 Jun 2015, Hans de Goede wrote: > > Hi All, > > > > I'm working on cleaning up the currently somewhat convoluted logic to > > select which backlight interfaces to register on x86 systems, see: > > http://lists.freedesktop.org/archives/dri-devel/2014-December/074687.html > > > > For a rought outline (details will change in the actual patch-set). > > > > These 3 patches are a preparation for that work, as the behavior of the > > current code is not always consistent (it changes depending on module > > loading order in some cases). These 3 patches remove this inconsistency > > which in some cases may result in a behavior change. > > > > This way the cleanup can have a consistent base to build upon, and I can > > ensure that the cleanup itself does not cause any functional changes. > > Thanks for doing this. > > Slightly unrelated, but you'll end up calling: > > acpi_video_unregister_backlight > acpi_video_bus_unregister_backlight > acpi_video_dev_unregister_backlight > thermal_cooling_device_unregister > > Uhm, err, what? What business does *that* have in the backlight > unregister call chain?! Should that be untangled from the mess too? I think it should be OK. We currently will create a thermal cooling device for the ACPI backlight device, its intention is that we can achieve some thermal purpose by increasing or decreasing the backlight level(using the same set of methods as the ACPI backlight one, though I'm not sure if it is being used by anyone). When we are going to unregister the ACPI video backlight interface, it most likely means that the interface doesn't work so it doesn't make much sense to keep that thermal interface and hence the thermal_cooling_device_unregister ends up being called here. Regards, Aaron > > BR, > Jani. > > > > > > I hope to post a v1 of the actual cleanup patch-set in 1-2 weeks. > > > > Regards, > > > > Hans > > ___ > > dri-devel mailing list > > [email protected] > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Use acpi_video_unregister_backlight instead of acpi_video_unregister in platfrom backlight drivers
Hi, On 02-06-15 11:59, Jani Nikula wrote: On Mon, 01 Jun 2015, Hans de Goede wrote: Hi All, I'm working on cleaning up the currently somewhat convoluted logic to select which backlight interfaces to register on x86 systems, see: http://lists.freedesktop.org/archives/dri-devel/2014-December/074687.html For a rought outline (details will change in the actual patch-set). These 3 patches are a preparation for that work, as the behavior of the current code is not always consistent (it changes depending on module loading order in some cases). These 3 patches remove this inconsistency which in some cases may result in a behavior change. This way the cleanup can have a consistent base to build upon, and I can ensure that the cleanup itself does not cause any functional changes. Thanks for doing this. Slightly unrelated, but you'll end up calling: acpi_video_unregister_backlight acpi_video_bus_unregister_backlight acpi_video_dev_unregister_backlight thermal_cooling_device_unregister Uhm, err, what? What business does *that* have in the backlight unregister call chain?! I think the idea is that having the backlight on can cause the main board to heat up as there is often a regulator / pwm for the backlight on the main board. If that is turned off it may help to cool down the main board, so the backlight is a cooling device in the sense that when it is turned off it stops generating heat. If this makes sense (*) then the cooling device stuff should maybe moved from the acpi/video.c code to the backlight core code. Or does the acpi-video code use some info from the BIOS to determine whether or not to register a cooling device ? Regards, Hans *) This is tricky, e.g. going low brightness may cause the main board to heat up more then full brightness depending on how things are hooked up. Should that be untangled from the mess too? BR, Jani. I hope to post a v1 of the actual cleanup patch-set in 1-2 weeks. Regards, Hans ___ dri-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Use acpi_video_unregister_backlight instead of acpi_video_unregister in platfrom backlight drivers
On Mon, 01 Jun 2015, Hans de Goede wrote: > Hi All, > > I'm working on cleaning up the currently somewhat convoluted logic to > select which backlight interfaces to register on x86 systems, see: > http://lists.freedesktop.org/archives/dri-devel/2014-December/074687.html > > For a rought outline (details will change in the actual patch-set). > > These 3 patches are a preparation for that work, as the behavior of the > current code is not always consistent (it changes depending on module > loading order in some cases). These 3 patches remove this inconsistency > which in some cases may result in a behavior change. > > This way the cleanup can have a consistent base to build upon, and I can > ensure that the cleanup itself does not cause any functional changes. Thanks for doing this. Slightly unrelated, but you'll end up calling: acpi_video_unregister_backlight acpi_video_bus_unregister_backlight acpi_video_dev_unregister_backlight thermal_cooling_device_unregister Uhm, err, what? What business does *that* have in the backlight unregister call chain?! Should that be untangled from the mess too? BR, Jani. > > I hope to post a v1 of the actual cleanup patch-set in 1-2 weeks. > > Regards, > > Hans > ___ > dri-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Use acpi_video_unregister_backlight instead of acpi_video_unregister in platfrom backlight drivers
Hi Darren, On 01-06-15 19:41, Darren Hart wrote: On Mon, Jun 01, 2015 at 11:25:05AM +0200, Hans de Goede wrote: Hi All, I'm working on cleaning up the currently somewhat convoluted logic to select which backlight interfaces to register on x86 systems, see: http://lists.freedesktop.org/archives/dri-devel/2014-December/074687.html For a rought outline (details will change in the actual patch-set). These 3 patches are a preparation for that work, as the behavior of the current code is not always consistent (it changes depending on module loading order in some cases). These 3 patches remove this inconsistency which in some cases may result in a behavior change. This way the cleanup can have a consistent base to build upon, and I can ensure that the cleanup itself does not cause any functional changes. I hope to post a v1 of the actual cleanup patch-set in 1-2 weeks. That will likely mean we miss the 4.2 merge window and will target this for 4.3 (which is fine by me, but just so you know). IMHO this patches are worthwhile to have by themselves, as said they fix various inconsistencies, which is a good thing to fix regardless. I think that these going into 4.2, and the cleanup which depends on them (but is other then that pretty much an orthogonal patch set) going into 4.3 is actually a good thing, because if people then experience any problems due to my work on this, we can easily see if it is due to the behavior change these 3 patches may introduce in some cases, or if it is due to the actual cleanup causing a behavior change (which it should not). Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Use acpi_video_unregister_backlight instead of acpi_video_unregister in platfrom backlight drivers
On Mon, Jun 01, 2015 at 11:25:05AM +0200, Hans de Goede wrote: > Hi All, > > I'm working on cleaning up the currently somewhat convoluted logic to > select which backlight interfaces to register on x86 systems, see: > http://lists.freedesktop.org/archives/dri-devel/2014-December/074687.html > > For a rought outline (details will change in the actual patch-set). > > These 3 patches are a preparation for that work, as the behavior of the > current code is not always consistent (it changes depending on module > loading order in some cases). These 3 patches remove this inconsistency > which in some cases may result in a behavior change. > > This way the cleanup can have a consistent base to build upon, and I can > ensure that the cleanup itself does not cause any functional changes. > > I hope to post a v1 of the actual cleanup patch-set in 1-2 weeks. That will likely mean we miss the 4.2 merge window and will target this for 4.3 (which is fine by me, but just so you know). -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Use acpi_video_unregister_backlight instead of acpi_video_unregister in platfrom backlight drivers
Hi All, I'm working on cleaning up the currently somewhat convoluted logic to select which backlight interfaces to register on x86 systems, see: http://lists.freedesktop.org/archives/dri-devel/2014-December/074687.html For a rought outline (details will change in the actual patch-set). These 3 patches are a preparation for that work, as the behavior of the current code is not always consistent (it changes depending on module loading order in some cases). These 3 patches remove this inconsistency which in some cases may result in a behavior change. This way the cleanup can have a consistent base to build upon, and I can ensure that the cleanup itself does not cause any functional changes. I hope to post a v1 of the actual cleanup patch-set in 1-2 weeks. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
