diff for duplicates of <20160617141719.GH21702@dell> diff --git a/a/1.txt b/N1/1.txt index 9e2826d..2cbea95 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -13,9 +13,9 @@ On Sat, 11 Jun 2016, Lothar Waßmann wrote: > > > > > > > where the value at index 0 may well be non-zero > > > > > > > (tegra30-apalis-eval.dts and tegra30-colibri-eval-v3.dts are real-life > > > > > > > examples). -> > > > > > > Thus brightness = 0 does not necessarily mean that the PWM output +> > > > > > > Thus brightness == 0 does not necessarily mean that the PWM output > > > > > > > will be inactive. -> > > > > > > Check for 'duty_cycle = 0' rather than 'brightness = 0' to decide +> > > > > > > Check for 'duty_cycle == 0' rather than 'brightness == 0' to decide > > > > > > > whether to disable the PWM. > > > > > > > > > > > > > > Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de> @@ -81,8 +81,8 @@ On Sat, 11 Jun 2016, Lothar Waßmann wrote: > > > > someone is going to get screwed by this logic. > > > > > > > The backlight framework does not (and does not need to) know anything -> > > about PWM duty cycles. Its 'brightness' values are consistently 0 = -> > > dark, max = brightest in either case. +> > > about PWM duty cycles. Its 'brightness' values are consistently 0 == +> > > dark, max == brightest in either case. > > > > What I'm getting at is; by the look of the documentation, the > > brightest setting can either be a duty cycle of 0 or 255. So what @@ -96,7 +96,7 @@ On Sat, 11 Jun 2016, Lothar Waßmann wrote: > first element of brightness-levels, the PWM will be disabled rather than > switched to the given duty cycle. > Disabling the PWM should have the same effect as setting the duty cycle -> to 0, so it is safe to check for duty_cycle = 0 to decide whether to +> to 0, so it is safe to check for duty_cycle == 0 to decide whether to > disable the PWM. I agree with this. BUT, that's not what you're doing is it? @@ -110,11 +110,11 @@ if (duty_cycle > 0) { } else pwm_backlight_power_off(pb); -Let's say duty_cycle = 0. In some cases this can mean "turn +Let's say duty_cycle == 0. In some cases this can mean "turn brightness up to the *maximum*", but with your new logic you just turned the backlight *off*. -Conversely, let's say duty_cycle = 255. In some cases this can mean +Conversely, let's say duty_cycle == 255. In some cases this can mean "turn the brightness to the *lowest* setting" i.e. *off*. Well your logic just turned the backlight *on*. diff --git a/a/content_digest b/N1/content_digest index 094ff6d..2023401 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -7,7 +7,7 @@ "ref\020160611090803.42aeaf5f@ipc1.ka-ro\0" "From\0Lee Jones <lee.jones@linaro.org>\0" "Subject\0Re: [PATCHv2] backlight: pwm_bl: disable PWM when 'duty_cycle' is zero\0" - "Date\0Fri, 17 Jun 2016 14:17:19 +0000\0" + "Date\0Fri, 17 Jun 2016 15:17:19 +0100\0" "To\0Lothar Wa\303\237mann <LW@karo-electronics.de>\0" "Cc\0Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>" Jingoo Han <jingoohan1@gmail.com> @@ -40,9 +40,9 @@ "> > > > > > > where the value at index 0 may well be non-zero\n" "> > > > > > > (tegra30-apalis-eval.dts and tegra30-colibri-eval-v3.dts are real-life\n" "> > > > > > > examples).\n" - "> > > > > > > Thus brightness = 0 does not necessarily mean that the PWM output\n" + "> > > > > > > Thus brightness == 0 does not necessarily mean that the PWM output\n" "> > > > > > > will be inactive.\n" - "> > > > > > > Check for 'duty_cycle = 0' rather than 'brightness = 0' to decide\n" + "> > > > > > > Check for 'duty_cycle == 0' rather than 'brightness == 0' to decide\n" "> > > > > > > whether to disable the PWM.\n" "> > > > > > > \n" "> > > > > > > Signed-off-by: Lothar Wa\303\237mann <LW@KARO-electronics.de>\n" @@ -108,8 +108,8 @@ "> > > > someone is going to get screwed by this logic.\n" "> > > > \n" "> > > The backlight framework does not (and does not need to) know anything\n" - "> > > about PWM duty cycles. Its 'brightness' values are consistently 0 =\n" - "> > > dark, max = brightest in either case.\n" + "> > > about PWM duty cycles. Its 'brightness' values are consistently 0 ==\n" + "> > > dark, max == brightest in either case.\n" "> > \n" "> > What I'm getting at is; by the look of the documentation, the\n" "> > brightest setting can either be a duty cycle of 0 or 255. So what\n" @@ -123,7 +123,7 @@ "> first element of brightness-levels, the PWM will be disabled rather than\n" "> switched to the given duty cycle.\n" "> Disabling the PWM should have the same effect as setting the duty cycle\n" - "> to 0, so it is safe to check for duty_cycle = 0 to decide whether to\n" + "> to 0, so it is safe to check for duty_cycle == 0 to decide whether to\n" "> disable the PWM.\n" "\n" "I agree with this. BUT, that's not what you're doing is it?\n" @@ -137,11 +137,11 @@ "} else\n" " pwm_backlight_power_off(pb);\n" "\n" - "Let's say duty_cycle = 0. In some cases this can mean \"turn\n" + "Let's say duty_cycle == 0. In some cases this can mean \"turn\n" "brightness up to the *maximum*\", but with your new logic you just\n" "turned the backlight *off*.\n" "\n" - "Conversely, let's say duty_cycle = 255. In some cases this can mean\n" + "Conversely, let's say duty_cycle == 255. In some cases this can mean\n" "\"turn the brightness to the *lowest* setting\" i.e. *off*. Well your\n" "logic just turned the backlight *on*.\n" "\n" @@ -154,4 +154,4 @@ "Linaro.org \342\224\202 Open source software for ARM SoCs\n" Follow Linaro: Facebook | Twitter | Blog -12ba95965e199c8e2f97865aaff6cdabe7d4fb54a82e5726544aa46abdd28ed8 +a1d0630dad75b46a2db9bd1e4ade981dfca29b3665f3b3763c3b8b1da36de92c
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.