The commit: a55944ca82d287ca099ca90413af857af9086773 has posed some extra
restrictions on blanking and unblanking frame buffer device.
Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank operation.
This code in case of initial unblank of backlight device (default behaviour)
sets use_count to 1 and marks this particular backlight device as used
by all available fb devices (since it is not known during probe how much
and which fb devices will be assigned).
Without this code, the backlight works properly until one tries to blank it
manually from sysfs with "echo 1 > /sys/class/graphics/fb0/blank".
Since fb_bl_on[0] and use_count were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank) it.
As a result we see garbage from fb displayed.
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with vanilla 4.7 and 4.8 kernels.
It applies on 4.9-rcX SHA1: dcd4693cf47801b7d988ea897519de90dfd25d17.
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
On Saturday, October 22, 2016, Lukasz Majewski wrote:
The commit: a55944ca82d287ca099ca90413af857af9086773 has posed some extra
Please add the subject of the patch, in order to let people know which patch
you mention exactly. Please loot at other commits that fixed bugs or
behavior
of other patches.
quoted hunk
restrictions on blanking and unblanking frame buffer device.
Unfortunately, pwm_bl driver's probe did not initialize members of struct
backlight_device necessary for further blank/unblank operation.
This code in case of initial unblank of backlight device (default
behaviour) sets use_count to 1 and marks this particular backlight device
as used by all available fb devices (since it is not known during probe
how much and which fb devices will be assigned).
Without this code, the backlight works properly until one tries to blank
it manually from sysfs with "echo 1 > /sys/class/graphics/fb0/blank".
Since fb_bl_on[0] and use_count were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank) it.
As a result we see garbage from fb displayed.
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with vanilla 4.7 and 4.8 kernels.
It applies on 4.9-rcX SHA1: dcd4693cf47801b7d988ea897519de90dfd25d17.
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c
index 8040fd6..def39e8 100644
On Saturday, October 22, 2016, Lukasz Majewski wrote:
quoted
The commit: a55944ca82d287ca099ca90413af857af9086773 has posed some
extra
Please add the subject of the patch, in order to let people know
which patch you mention exactly. Please loot at other commits that
fixed bugs or behavior
of other patches.
Thanks for the tip.
The mentioned patch:
commit a55944ca82d287ca099ca90413af857af9086773
Author: Liu Ying [off-list ref]
Date: Thu Apr 3 14:48:54 2014 -0700
backlight: update bd state & fb_blank properties when necessary
We don't have to update the state and fb_blank properties of a backlight
device every time a blanking or unblanking event comes because they may
have already been what we want. Another thought is that one backlight
device may be shared by multiple framebuffers. The backlight driver
should take the backlight device as a resource shared by all the
associated framebuffers.
This patch adds some logic to record each framebuffer's backlight usage
to determine the backlight device use count and whether the two
properties should be updated or not. To be more specific, only one
unblank operation on a certain blanked framebuffer may increase the
backlight device's use count by one, while one blank operation on a
certain unblanked framebuffer may decrease the use count by one, because
the userspace is likely to unblank an unblanked framebuffer or blank a
blanked framebuffer.
Could you provide more feedback regarding provided fix?
Thanks in advance,
Łukasz Majewski
quoted
restrictions on blanking and unblanking frame buffer device.
Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank
operation.
This code in case of initial unblank of backlight device (default
behaviour) sets use_count to 1 and marks this particular backlight
device as used by all available fb devices (since it is not known
during probe how much and which fb devices will be assigned).
Without this code, the backlight works properly until one tries to
blank it manually from sysfs with "echo 1
quoted
/sys/class/graphics/fb0/blank". Since fb_bl_on[0] and use_count
were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank) it.
As a result we see garbage from fb displayed.
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with vanilla 4.7 and 4.8
kernels. It applies on 4.9-rcX SHA1:
dcd4693cf47801b7d988ea897519de90dfd25d17.
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c
index 8040fd6..def39e8 100644
On Monday, October 24, 2016, Lukasz Majewski wrote:
Hi Jingoo,
quoted
On Saturday, October 22, 2016, Lukasz Majewski wrote:
quoted
The commit: a55944ca82d287ca099ca90413af857af9086773 has posed some
extra
Please add the 'subject' of patch as below.
The commit a55944ca82d2 ("backlight: update bd state & fb_blank properties when necessary ")
has posted some extra.
Best regards,
Jingoo Han
quoted
Please add the subject of the patch, in order to let people know
which patch you mention exactly. Please loot at other commits that
fixed bugs or behavior
of other patches.
Thanks for the tip.
The mentioned patch:
commit a55944ca82d287ca099ca90413af857af9086773
Author: Liu Ying [off-list ref]
Date: Thu Apr 3 14:48:54 2014 -0700
backlight: update bd state & fb_blank properties when necessary
We don't have to update the state and fb_blank properties of a
backlight
device every time a blanking or unblanking event comes because they
may
have already been what we want. Another thought is that one backlight
device may be shared by multiple framebuffers. The backlight driver
should take the backlight device as a resource shared by all the
associated framebuffers.
This patch adds some logic to record each framebuffer's backlight
usage
to determine the backlight device use count and whether the two
properties should be updated or not. To be more specific, only one
unblank operation on a certain blanked framebuffer may increase the
backlight device's use count by one, while one blank operation on a
certain unblanked framebuffer may decrease the use count by one,
because
the userspace is likely to unblank an unblanked framebuffer or blank a
blanked framebuffer.
Could you provide more feedback regarding provided fix?
Thanks in advance,
�ukasz Majewski
quoted
quoted
restrictions on blanking and unblanking frame buffer device.
Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank
operation.
This code in case of initial unblank of backlight device (default
behaviour) sets use_count to 1 and marks this particular backlight
device as used by all available fb devices (since it is not known
during probe how much and which fb devices will be assigned).
Without this code, the backlight works properly until one tries to
blank it manually from sysfs with "echo 1
quoted
/sys/class/graphics/fb0/blank". Since fb_bl_on[0] and use_count
were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank) it.
As a result we see garbage from fb displayed.
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with vanilla 4.7 and 4.8
kernels. It applies on 4.9-rcX SHA1:
dcd4693cf47801b7d988ea897519de90dfd25d17.
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c
index 8040fd6..def39e8 100644
@@ -203,7 +203,7 @@ static int pwm_backlight_probe(struct
platform_device *pdev)
struct pwm_bl_data *pb;
int initial_blank = FB_BLANK_UNBLANK;
struct pwm_args pargs;
- int ret;
+ int ret, i;
if (!data) {
ret = pwm_backlight_parse_dt(&pdev->dev,
&defdata); @@ - 349,6 +349,14 @@ static int
pwm_backlight_probe(struct platform_device *pdev)
bl->props.brightness = data->dft_brightness;
bl->props.power = initial_blank;
+
+ if (initial_blank == FB_BLANK_UNBLANK) {
+ for (i = 0; i < FB_MAX; i++)
+ bl->fb_bl_on[i] = true;
+
+ bl->use_count = 1;
+ }
+
backlight_update_status(bl);
platform_set_drvdata(pdev, bl);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday, October 24, 2016, Lukasz Majewski wrote:
quoted
Hi Jingoo,
quoted
On Saturday, October 22, 2016, Lukasz Majewski wrote:
quoted
The commit: a55944ca82d287ca099ca90413af857af9086773 has posed
some extra
Please add the 'subject' of patch as below.
The commit a55944ca82d2 ("backlight: update bd state & fb_blank
properties when necessary ") has posted some extra.
Ok, I will add such information.
However, I'm more interested in some technical comments regarding
proposed fix.
Could you provide some feedback on the technical side of the patch?
Best regards,
Łukasz Majewski
Best regards,
Jingoo Han
quoted
quoted
Please add the subject of the patch, in order to let people know
which patch you mention exactly. Please loot at other commits that
fixed bugs or behavior
of other patches.
Thanks for the tip.
The mentioned patch:
commit a55944ca82d287ca099ca90413af857af9086773
Author: Liu Ying [off-list ref]
Date: Thu Apr 3 14:48:54 2014 -0700
backlight: update bd state & fb_blank properties when necessary
We don't have to update the state and fb_blank properties of a
backlight
device every time a blanking or unblanking event comes because
they may
have already been what we want. Another thought is that one
backlight device may be shared by multiple framebuffers. The
backlight driver should take the backlight device as a resource
shared by all the associated framebuffers.
This patch adds some logic to record each framebuffer's
backlight usage
to determine the backlight device use count and whether the two
properties should be updated or not. To be more specific, only
one unblank operation on a certain blanked framebuffer may increase
the backlight device's use count by one, while one blank operation
on a certain unblanked framebuffer may decrease the use count by
one, because
the userspace is likely to unblank an unblanked framebuffer or
blank a blanked framebuffer.
Could you provide more feedback regarding provided fix?
Thanks in advance,
Łukasz Majewski
quoted
quoted
restrictions on blanking and unblanking frame buffer device.
Unfortunately, pwm_bl driver's probe did not initialize members
of struct backlight_device necessary for further blank/unblank
operation.
This code in case of initial unblank of backlight device
(default behaviour) sets use_count to 1 and marks this
particular backlight device as used by all available fb devices
(since it is not known during probe how much and which fb
devices will be assigned).
Without this code, the backlight works properly until one tries
to blank it manually from sysfs with "echo 1
quoted
/sys/class/graphics/fb0/blank". Since fb_bl_on[0] and
use_count were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn
on (unblanked) the backlight device and refuses to disable
(blank) it. As a result we see garbage from fb displayed.
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with vanilla 4.7 and 4.8
kernels. It applies on 4.9-rcX SHA1:
dcd4693cf47801b7d988ea897519de90dfd25d17.
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c
index 8040fd6..def39e8 100644
The commit a55944ca82d2 ("backlight: update bd state & fb_blank properties
when necessary") has posed some extra restrictions on blanking and
unblanking frame buffer device.
Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank operation.
This code in case of initial unblank of backlight device (default
behaviour) sets use_count to 1 and marks this particular backlight device
as used by all available fb devices (since it is not known during probe
how much and which fb devices will be assigned).
Without this code, the backlight works properly until one tries to blank
it manually from sysfs with "echo 1 > /sys/class/graphics/fb0/blank".
Since fb_bl_on[0] and use_count were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank) it.
As a result we see garbage from fb displayed.
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with 4.9-rc3
SHA1: a909d3e636995ba7c349e2ca5dbb528154d4ac30
---
Changes for v2:
- Update commit message with proper other commit reference
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
The commit a55944ca82d2 ("backlight: update bd state & fb_blank
properties when necessary") has posed some extra restrictions on
blanking and unblanking frame buffer device.
Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank operation.
This code in case of initial unblank of backlight device (default
behaviour) sets use_count to 1 and marks this particular backlight
device as used by all available fb devices (since it is not known
during probe how much and which fb devices will be assigned).
Without this code, the backlight works properly until one tries to
blank it manually from sysfs with "echo 1
quoted
/sys/class/graphics/fb0/blank". Since fb_bl_on[0] and use_count
were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank) it.
As a result we see garbage from fb displayed.
COmments/acks are more than welcome :-)
Best regards,
Łukasz Majewski
quoted hunk
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with 4.9-rc3
SHA1: a909d3e636995ba7c349e2ca5dbb528154d4ac30
---
Changes for v2:
- Update commit message with proper other commit reference
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c index 1261400..6859ba0 100644
From: Lee Jones <hidden> Date: 2016-11-09 14:49:56
On Tue, 08 Nov 2016, Lukasz Majewski wrote:
Dear All,
quoted
The commit a55944ca82d2 ("backlight: update bd state & fb_blank
properties when necessary") has posed some extra restrictions on
blanking and unblanking frame buffer device.
Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank operation.
This code in case of initial unblank of backlight device (default
behaviour) sets use_count to 1 and marks this particular backlight
device as used by all available fb devices (since it is not known
during probe how much and which fb devices will be assigned).
Without this code, the backlight works properly until one tries to
blank it manually from sysfs with "echo 1
quoted
/sys/class/graphics/fb0/blank". Since fb_bl_on[0] and use_count
were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank) it.
As a result we see garbage from fb displayed.
COmments/acks are more than welcome :-)
I thought Jingoo already replied to you?
quoted
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with 4.9-rc3
SHA1: a909d3e636995ba7c349e2ca5dbb528154d4ac30
---
Changes for v2:
- Update commit message with proper other commit reference
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c index 1261400..6859ba0 100644
The commit a55944ca82d2 ("backlight: update bd state & fb_blank
properties when necessary") has posed some extra restrictions on
blanking and unblanking frame buffer device.
Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank
operation.
This code in case of initial unblank of backlight device (default
behaviour) sets use_count to 1 and marks this particular backlight
device as used by all available fb devices (since it is not known
during probe how much and which fb devices will be assigned).
Without this code, the backlight works properly until one tries to
blank it manually from sysfs with "echo 1
quoted
/sys/class/graphics/fb0/blank". Since fb_bl_on[0] and use_count
were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank)
it. As a result we see garbage from fb displayed.
COmments/acks are more than welcome :-)
I thought Jingoo already replied to you?
Yes, Jingoo replied to me and asked for correcting the patch
description. The corrected patch is the v2.
Best regards,
Łukasz Majewski
quoted
quoted
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with 4.9-rc3
SHA1: a909d3e636995ba7c349e2ca5dbb528154d4ac30
---
Changes for v2:
- Update commit message with proper other commit reference
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c index 1261400..6859ba0 100644
From: Lee Jones <hidden> Date: 2016-11-10 07:44:24
On Wed, 09 Nov 2016, Lukasz Majewski wrote:
Hi Lee,
quoted
On Tue, 08 Nov 2016, Lukasz Majewski wrote:
quoted
Dear All,
quoted
The commit a55944ca82d2 ("backlight: update bd state & fb_blank
properties when necessary") has posed some extra restrictions on
blanking and unblanking frame buffer device.
Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank
operation.
This code in case of initial unblank of backlight device (default
behaviour) sets use_count to 1 and marks this particular backlight
device as used by all available fb devices (since it is not known
during probe how much and which fb devices will be assigned).
Without this code, the backlight works properly until one tries to
blank it manually from sysfs with "echo 1
quoted
/sys/class/graphics/fb0/blank". Since fb_bl_on[0] and use_count
were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank)
it. As a result we see garbage from fb displayed.
COmments/acks are more than welcome :-)
I thought Jingoo already replied to you?
Yes, Jingoo replied to me and asked for correcting the patch
description. The corrected patch is the v2.
Ah, I see. You've attached the v4 to the original set.
Ball is in Jingoo's court.
quoted
quoted
quoted
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with 4.9-rc3
SHA1: a909d3e636995ba7c349e2ca5dbb528154d4ac30
---
Changes for v2:
- Update commit message with proper other commit reference
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c index 1261400..6859ba0 100644
From: Lee Jones <hidden> Date: 2016-11-10 08:13:31
On Tue, 08 Nov 2016, Lukasz Majewski wrote:
Dear All,
quoted
The commit a55944ca82d2 ("backlight: update bd state & fb_blank
properties when necessary") has posed some extra restrictions on
blanking and unblanking frame buffer device.
Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank operation.
This code in case of initial unblank of backlight device (default
behaviour) sets use_count to 1 and marks this particular backlight
device as used by all available fb devices (since it is not known
during probe how much and which fb devices will be assigned).
Without this code, the backlight works properly until one tries to
blank it manually from sysfs with "echo 1
quoted
/sys/class/graphics/fb0/blank". Since fb_bl_on[0] and use_count
were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank) it.
As a result we see garbage from fb displayed.
COmments/acks are more than welcome :-)
Ah, it looks like you dropped Jingoo from the list!
I'll reply to the original mail with him in CC.
quoted
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with 4.9-rc3
SHA1: a909d3e636995ba7c349e2ca5dbb528154d4ac30
---
Changes for v2:
- Update commit message with proper other commit reference
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c index 1261400..6859ba0 100644
The commit a55944ca82d2 ("backlight: update bd state & fb_blank
properties when necessary") has posed some extra restrictions on
blanking and unblanking frame buffer device.
Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank
operation.
This code in case of initial unblank of backlight device (default
behaviour) sets use_count to 1 and marks this particular backlight
device as used by all available fb devices (since it is not known
during probe how much and which fb devices will be assigned).
Without this code, the backlight works properly until one tries to
blank it manually from sysfs with "echo 1
quoted
/sys/class/graphics/fb0/blank". Since fb_bl_on[0] and use_count
were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank)
it. As a result we see garbage from fb displayed.
COmments/acks are more than welcome :-)
Ah, it looks like you dropped Jingoo from the list!
I can only apologize for such situation.... strange mistake.
I'll reply to the original mail with him in CC.
Thank you for your help.
Best regards,
Lukasz Majewski
quoted
quoted
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with 4.9-rc3
SHA1: a909d3e636995ba7c349e2ca5dbb528154d4ac30
---
Changes for v2:
- Update commit message with proper other commit reference
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c index 1261400..6859ba0 100644
From: Lee Jones <hidden> Date: 2016-11-10 08:13:57
Adding Jingoo.
On Tue, 01 Nov 2016, Lukasz Majewski wrote:
quoted hunk
The commit a55944ca82d2 ("backlight: update bd state & fb_blank properties
when necessary") has posed some extra restrictions on blanking and
unblanking frame buffer device.
Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank operation.
This code in case of initial unblank of backlight device (default
behaviour) sets use_count to 1 and marks this particular backlight device
as used by all available fb devices (since it is not known during probe
how much and which fb devices will be assigned).
Without this code, the backlight works properly until one tries to blank
it manually from sysfs with "echo 1 > /sys/class/graphics/fb0/blank".
Since fb_bl_on[0] and use_count were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank) it.
As a result we see garbage from fb displayed.
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with 4.9-rc3
SHA1: a909d3e636995ba7c349e2ca5dbb528154d4ac30
---
Changes for v2:
- Update commit message with proper other commit reference
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
The commit a55944ca82d2
("backlight: update bd state & fb_blank properties when necessary")
has posed some extra restrictions on blanking and unblanking frame buffer
device.
Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank operation.
This code in case of initial unblank of backlight device (default
behaviour) sets use_count to 1 and marks this particular backlight device
as used by all available fb devices (since it is not known during probe
how much and which fb devices will be assigned).
Without this code, the backlight works properly until one tries to blank it
manually from sysfs with "echo 1 > /sys/class/graphics/fb0/blank".
Since fb_bl_on[0] and use_count were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank) it.
As a result we see garbage from fb displayed.
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with vanilla 4.9 kernel.
It applies on 4.10-rc1.
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
The commit a55944ca82d2
("backlight: update bd state & fb_blank properties when necessary")
has posed some extra restrictions on blanking and unblanking frame
buffer device.
Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank operation.
This code in case of initial unblank of backlight device (default
behaviour) sets use_count to 1 and marks this particular backlight
device as used by all available fb devices (since it is not known
during probe how much and which fb devices will be assigned).
Without this code, the backlight works properly until one tries to
blank it manually from sysfs with "echo 1
quoted
/sys/class/graphics/fb0/blank". Since fb_bl_on[0] and use_count
were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank) it.
As a result we see garbage from fb displayed.
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with vanilla 4.9 kernel.
It applies on 4.10-rc1.
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c index 1261400..6859ba0 100644
From: Lee Jones <hidden> Date: 2017-01-03 08:26:58
Thierry, Jingoo,
Please respond to Lukasz.
On Mon, 26 Dec 2016, Lukasz Majewski wrote:
quoted hunk
The commit a55944ca82d2
("backlight: update bd state & fb_blank properties when necessary")
has posed some extra restrictions on blanking and unblanking frame buffer
device.
Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank operation.
This code in case of initial unblank of backlight device (default
behaviour) sets use_count to 1 and marks this particular backlight device
as used by all available fb devices (since it is not known during probe
how much and which fb devices will be assigned).
Without this code, the backlight works properly until one tries to blank it
manually from sysfs with "echo 1 > /sys/class/graphics/fb0/blank".
Since fb_bl_on[0] and use_count were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank) it.
As a result we see garbage from fb displayed.
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with vanilla 4.9 kernel.
It applies on 4.10-rc1.
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
The commit a55944ca82d2
("backlight: update bd state & fb_blank properties when necessary")
has posed some extra restrictions on blanking and unblanking frame
buffer device.
Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank
operation.
This code in case of initial unblank of backlight device (default
behaviour) sets use_count to 1 and marks this particular backlight
device as used by all available fb devices (since it is not known
during probe how much and which fb devices will be assigned).
Without this code, the backlight works properly until one tries to
blank it manually from sysfs with "echo 1
quoted
/sys/class/graphics/fb0/blank". Since fb_bl_on[0] and use_count
were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank) it.
As a result we see garbage from fb displayed.
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with vanilla 4.9 kernel.
It applies on 4.10-rc1.
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c index 1261400..6859ba0 100644
Yes, your response is more than welcome....... :-)
Thanks in advance,
�ukasz Majewski
On Mon, 26 Dec 2016, Lukasz Majewski wrote:
quoted
The commit a55944ca82d2
("backlight: update bd state & fb_blank properties when necessary")
has posed some extra restrictions on blanking and unblanking frame
buffer device.
Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank
operation.
This code in case of initial unblank of backlight device (default
behaviour) sets use_count to 1 and marks this particular backlight
device as used by all available fb devices (since it is not known
during probe how much and which fb devices will be assigned).
Without this code, the backlight works properly until one tries to
blank it manually from sysfs with "echo 1
quoted
/sys/class/graphics/fb0/blank". Since fb_bl_on[0] and use_count
were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank) it.
As a result we see garbage from fb displayed.
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with vanilla 4.9 kernel.
It applies on 4.10-rc1.
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c index 1261400..6859ba0 100644
@@ -202,7 +202,7 @@ static int pwm_backlight_probe(struct
platform_device *pdev) struct pwm_bl_data *pb;
int initial_blank = FB_BLANK_UNBLANK;
struct pwm_args pargs;
- int ret;
+ int ret, i;
if (!data) {
ret = pwm_backlight_parse_dt(&pdev->dev, &defdata);
@@ -348,6 +348,14 @@ static int pwm_backlight_probe(struct
platform_device *pdev)
bl->props.brightness = data->dft_brightness;
bl->props.power = initial_blank;
+
+ if (initial_blank = FB_BLANK_UNBLANK) {
+ for (i = 0; i < FB_MAX; i++)
+ bl->fb_bl_on[i] = true;
+
+ bl->use_count = 1;
+ }
+
backlight_update_status(bl);
platform_set_drvdata(pdev, bl);
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Yes, your response is more than welcome....... :-)
More, more than welcome.
Ping for this patch. I do understand that kernel developers are busy
people, but this patch is not reviewed since Nov last year :-)
Thanks in advance,
�ukasz Majewski
quoted
On Mon, 26 Dec 2016, Lukasz Majewski wrote:
quoted
The commit a55944ca82d2
("backlight: update bd state & fb_blank properties when
necessary") has posed some extra restrictions on blanking and
unblanking frame buffer device.
Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank
operation.
This code in case of initial unblank of backlight device (default
behaviour) sets use_count to 1 and marks this particular backlight
device as used by all available fb devices (since it is not known
during probe how much and which fb devices will be assigned).
Without this code, the backlight works properly until one tries to
blank it manually from sysfs with "echo 1
quoted
/sys/class/graphics/fb0/blank". Since fb_bl_on[0] and use_count
were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank)
it. As a result we see garbage from fb displayed.
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with vanilla 4.9 kernel.
It applies on 4.10-rc1.
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c
b/drivers/video/backlight/pwm_bl.c index 1261400..6859ba0 100644
@@ -202,7 +202,7 @@ static int pwm_backlight_probe(struct
platform_device *pdev) struct pwm_bl_data *pb;
int initial_blank = FB_BLANK_UNBLANK;
struct pwm_args pargs;
- int ret;
+ int ret, i;
if (!data) {
ret = pwm_backlight_parse_dt(&pdev->dev,
&defdata); @@ -348,6 +348,14 @@ static int
pwm_backlight_probe(struct platform_device *pdev)
bl->props.brightness = data->dft_brightness;
bl->props.power = initial_blank;
+
+ if (initial_blank = FB_BLANK_UNBLANK) {
+ for (i = 0; i < FB_MAX; i++)
+ bl->fb_bl_on[i] = true;
+
+ bl->use_count = 1;
+ }
+
backlight_update_status(bl);
platform_set_drvdata(pdev, bl);
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Dec 26, 2016 at 11:21:36PM +0100, Lukasz Majewski wrote:
The commit a55944ca82d2
("backlight: update bd state & fb_blank properties when necessary")
has posed some extra restrictions on blanking and unblanking frame buffer
device.
Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank operation.
This code in case of initial unblank of backlight device (default
behaviour) sets use_count to 1 and marks this particular backlight device
as used by all available fb devices (since it is not known during probe
how much and which fb devices will be assigned).
Without this code, the backlight works properly until one tries to blank it
manually from sysfs with "echo 1 > /sys/class/graphics/fb0/blank".
Since fb_bl_on[0] and use_count were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank) it.
As a result we see garbage from fb displayed.
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with vanilla 4.9 kernel.
It applies on 4.10-rc1.
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
It's difficult to wrap one's head around the above-mentioned commit
a55944ca82d2 ("backlight: update bd state & fb_blank properties when
necessary"). The solution borders on crazy. That said, this patch
builds on top of crazy, and given that it looks okay to me.
Acked-by: Thierry Reding <redacted>
From: Lee Jones <hidden> Date: 2017-01-24 09:33:13
On Mon, 26 Dec 2016, Lukasz Majewski wrote:
The commit a55944ca82d2
("backlight: update bd state & fb_blank properties when necessary")
has posed some extra restrictions on blanking and unblanking frame buffer
device.
Unfortunately, pwm_bl driver's probe did not initialize members of
struct backlight_device necessary for further blank/unblank operation.
This code in case of initial unblank of backlight device (default
behaviour) sets use_count to 1 and marks this particular backlight device
as used by all available fb devices (since it is not known during probe
how much and which fb devices will be assigned).
Without this code, the backlight works properly until one tries to blank it
manually from sysfs with "echo 1 > /sys/class/graphics/fb0/blank".
Since fb_bl_on[0] and use_count were both set to 0, the logic at
fb_notifier_callback (@backlight.c) thought that we didn't turn on
(unblanked) the backlight device and refuses to disable (blank) it.
As a result we see garbage from fb displayed.
Signed-off-by: Lukasz Majewski <redacted>
---
The patch has been tested on i.MX6q with vanilla 4.9 kernel.
It applies on 4.10-rc1.
---
drivers/video/backlight/pwm_bl.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)