Hi!
> For all these reasons the display analogy really is a bit fit for these
> keyboards
> we tried to come up with a universal coordinate system for these at the
> beginning
> of the thread and we failed ...
I quite liked the coordinate system proposal. I can propose this:
Vendor maps the
Hi!
> > To be honest, I think the kernel shouldn't include too much high-level
> > complexity. If there is a desire to implement a generic display device on
> > top of the RGB device, this should be a configurable service running in
> > user space. The kernel should provide an interface to
Hi!
> > > so after more feedback from the OpenRGB maintainers I came up with an even
> > > more generic proposal:
> > > https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916#note_1753072869
> >
> > > >evaluate-set-command ioctl taking:
> > > >{
> > > > enum command /* one
Hi!
> > Yeah, so ... this is not a interface. This is a backdoor to pass
> > arbitrary data. That's not going to fly.
>
> Pavel, Note the data will be interpreted by a kernel driver and
> not passed directly to the hw.
Yes, still not flying :-).
> With that said I tend to agree that this seems
Hi!
> so after more feedback from the OpenRGB maintainers I came up with an even
> more generic proposal:
> https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916#note_1753072869
> >evaluate-set-command ioctl taking:
> >{
> > enum command /* one of supported_commands */
> >
Hi!
> > And while I would personally hate it, you can imagine a use case where
> > you'd like a keypress to have a visual effect around the key you
> > pressed. A kind of force feedback, if you will. I don't actually know,
> > and correct me if I'm wrong, but feels like implementing that outside
Hi!
> > > And then storing RGB in separate bytes, so userspace will then
> > > always send a buffer of 192 bytes per line (64x3) x 14 rows
> > > = 3072 bytes. With the kernel driver ignoring parts of
> > > the buffer where there are no actual keys.
> > That's really really weird interface. If you
Hi!
> >> 2. Implement per-key keyboards as auxdisplay
> >>
> >> - Pro:
> >>
> >> - Already has a concept for led positions
> >>
> >> - Is conceptually closer to "multiple leds forming a singular
> >> entity"
> >>
> >> - Con:
> >>
> >> - No preexisting UPower
Hi!
> We have an upcoming device that has a per-key keyboard backlight, but does
> the control completely via a wmi/acpi interface. So no usable hidraw here
> for a potential userspace driver implementation ...
>
> So a quick summary for the ideas floating in this thread so far:
>
> 1. Expand
Hi!
> > > From: Ziqi Zhao
> > >
> > > [ Upstream commit 3823119b9c2b5f9e9b760336f75bc989b805cde6 ]
> > >
> > > The connector_set contains uninitialized values when allocated with
> > > kmalloc_array. However, in the "out" branch, the logic assumes that any
> > > element in connector_set would
On Mon 2023-10-23 13:44:46, Miguel Ojeda wrote:
> On Mon, Oct 23, 2023 at 1:40 PM Jani Nikula
> wrote:
> >
> > One could also reasonably make the argument that controlling the
> > individual keyboard key backlights should be part of the input
> > subsystem. It's not a display per se. (Unless you
Hi!
> >> So... a bit of rationale. The keyboard does not really fit into the
> >> LED subsystem; LEDs are expected to be independent ("hdd led") and not
> >> a matrix of them.
> >
> > Makes sense.
> >
> >> We do see various strange displays these days -- they commonly have
> >> rounded corners
Hi!
> > > From: Alex Deucher
> > >
> > > [ Upstream commit 49afe91370b86566857a3c2c39612cf098110885 ]
> > >
> > > For pptable structs that use flexible array sizes, use flexible arrays.
> > >
> > > Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039926
> > > Reviewed-by: Mario
Hi!
> This patchset adds three secure heaps:
> 1) secure_mtk_cm: secure chunk memory for MediaTek SVP (Secure Video Path).
>The buffer is reserved for the secure world after bootup and it is used
>for vcodec's ES/working buffer;
> 2) secure_mtk_cma: secure CMA memory for MediaTek SVP.
Hi!
> > An orthogonal issue is labeling all of those regions. I think we should
> > start with fully obscured areas and maybe less readable ones like the
> > waterfall edges. Still, different features should live on different
> > masks – even if we don't attach meaningfull labels (like 'notch' or
Hi!
> coming from the leds mailing list I'm writing with Pavel how to best handle
> per-key RGB keyboards.
>
> His suggestion was that it could be implemented as an aux display, but he
> also suggested that I ask first if this fits.
Thanks for doing this.
> The specific keyboard RGB controller
Hi!
> > The specific keyboard RGB controller I want to implement takes 6*21 rgb
> > values. However not every one is actually mapped to a physical key. e.g. the
> > bottom row needs less entries because of the space bar. Additionally the
> > keys are ofc not in a straight line from top to bottom.
Hi!
> From: AngeloGioacchino Del Regno
>
> [ Upstream commit fd70e2019bfbcb0ed90c5e23839bf510ce6acf8f ]
>
> Change logging from drm_{err,info}() to dev_{err,info}() in functions
> mtk_dp_aux_transfer() and mtk_dp_aux_do_transfer(): this will be
> essential to avoid getting NULL pointer kernel
Hi!
> From: hackyzh002
>
> [ Upstream commit f828b681d0cd566f86351c0b913e6cb6ed8c7b9c ]
>
> The type of size is unsigned, if size is 0x4000, there will be an
> integer overflow, size will be zero after size *= sizeof(uint32_t),
> will cause uninitialized memory to be referenced later
I
Hi!
> From: Helge Deller
>
> [ Upstream commit 5cf9a090a39c97f4506b7b53739d469b1c05a7e9 ]
>
> Add missing cleanups in error path.
If we insist this is important enough for -stable, it will need
tweaking. The function returns void, so we can't return a value.
Best regards,
Hi!
> > Am 04.04.23 um 06:01 schrieb Sui Jingfeng:
> >> EFI FB, VESA FB or VGA FB etc are belong to firmware based framebuffer
> >> driver.
> >
>
...
> I fixed that before applying, also removed the "are" in the sentence
> above, since it sounded off and repharsed subject line as "Fix typos
On Wed 2023-03-22 10:05:13, Rodrigo Siqueira wrote:
> Cc: Anthony Koo
> Cc: Iswara Negulendran
> Cc: Felipe Clark
> Cc: Harry Wentland
> Signed-off-by: Rodrigo Siqueira
Some changelog would be useful.
> +++ b/include/drm/display/drm_dp.h
> @@ -977,6 +977,8 @@
> # define
Hi!
> > +config LEDS_AW200XX
> > + tristate "LED support for Awinic AW20036/AW20054/AW20072"
> > + depends on LEDS_CLASS
> > + depends on I2C
> > + help
> > + This option enables support for the AW20036/AW20054/AW20072 LED
> > driver.
> > + It is a 3x12/6x9/6x12 matrix LED driver
Hi!
> This series add support for the display present in the PinePhone Pro.
>
> Patch #1 adds a driver for panels using the Himax HX8394 panel controller,
> such as the HSD060BHW4 720x1440 TFT LCD panel present in the PinePhone Pro.
>
> Patch #2 adds a devicetree binding schema for this driver
On Tue 2022-12-20 13:45:19, Steven Rostedt wrote:
> [
> Linus,
>
> I ran the script against your latest master branch:
> commit b6bb9676f2165d518b35ba3bea5f1fcfc0d969bf
>
> As the timer_shutdown*() code is now in your tree, I figured
> we can start doing the conversions. At
o for now all drivers return success unconditionally. They are adapted
> in the following patches to make the changes easier reviewable.
>
> Signed-off-by: Uwe Kleine-König
LED part:
Acked-by: Pavel Machek
Best regards,
Pavel
> sta
Hi!
> > I used to be able to do:
> >
> > pavel@duo:~$ xrandr --output HDMI1 --mode 1920x1080 --primary
> > warning: output HDMI1 not found; ignoring
> > pavel@duo:~$ xrandr --output VGA1 --mode 1280x1024 --below HDMI1
> > warning: output VGA1 not found; ignoring
> >
> > ...but now I
Hi!
I used to be able to do:
pavel@duo:~$ xrandr --output HDMI1 --mode 1920x1080 --primary
warning: output HDMI1 not found; ignoring
pavel@duo:~$ xrandr --output VGA1 --mode 1280x1024 --below HDMI1
warning: output VGA1 not found; ignoring
...but now I have to do:
pavel@duo:~$
Hi!
> From: Alyssa Rosenzweig
>
> [ Upstream commit 382435709516c1a7dc3843872792abf95e786c83 ]
>
> Add handling for the HW_ISSUE_TTRX_2968_TTRX_3162 quirk. Logic ported
> from kbase. kbase lists this workaround as used on Mali-G57.
AFAICT this quirk is not used anywhere in 5.10, and its users
Hi!
In this series, I only received patches up-to 42/46. Is problem at sender or
receiver?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
Hi!
> From: Alice Chen
>
> The MediaTek MT6370 is a highly-integrated smart power management IC,
> which includes a single cell Li-Ion/Li-Polymer switching battery
> charger, a USB Type-C & Power Delivery (PD) controller, dual Flash
> LED current sources, a RGB LED driver, a backlight WLED
Hi!
> From: ChiYuan Huang
>
> The MediaTek MT6370 is a highly-integrated smart power management IC,
> which includes a single cell Li-Ion/Li-Polymer switching battery
> charger, a USB Type-C & Power Delivery (PD) controller, dual
> Flash LED current sources, a RGB LED driver, a backlight WLED
On Fri 2022-07-22 18:23:58, ChiaEn Wu wrote:
> From: Alice Chen
>
> Add MediaTek MT6370 flashlight binding documentation.
>
> Signed-off-by: Alice Chen
> Reviewed-by: Krzysztof Kozlowski
You'll need to get sign-offs right... And review from dt people before
this can be applied.
Best
> way driver authors are not tempted to assume that passing an error to
> the upper layer is a good idea. All drivers are adapted accordingly.
> There is no intended change of behaviour, all callbacks were prepared to
> return 0 before.
>
> Signed-off-by: Uwe Kleine-König
2-4
Hi!
> Going forward, I'll be using my kernel.org for upstream work.
>
Acked-by: Pavel Machek
Let me know if you want to take it through the LED tree.
Best regards,
Pavel
--
People of Russia, stop Putin before his war on U
Hi!
> The MediaTek MT6370 is a highly-integrated smart power management IC,
> which includes a single cell Li-Ion/Li-Polymer switching battery
> charger, a USB Type-C & Power Delivery (PD) controller, dual
> Flash LED current sources, a RGB LED driver, a backlight WLED driver,
> a display bias
Hi!
> [ Upstream commit 5491424d17bdeb7b7852a59367858251783f8398 ]
>
> clk_put() already checks the clk ptr using !clk and IS_ERR()
> so there is no need to check it again before calling it.
Nice cleanup, but not a bugfix; we don't need it in -stable.
Best regards,
Hi!
> From: Xiang wangx
>
> [ Upstream commit fc378794a2f7a19cf26010dc33b89ba608d4c70f ]
>
> Delete the redundant word 'its'.
Calling typo in comment "syntax error" is ... interesting. Anyway, we
don't need this in stable.
Best regards,
Hi!
> From: Maxime Ripard
>
> [ Upstream commit 2523e9dcc3be91bf9fdc0d1e542557ca00bbef42 ]
>
> We'll need to extend the vc4_async_flip_state structure to rely on
> another callback implementation, so let's move the current one into a
> union.
This and [04/22] drm/vc4: crtc: Use an union to
On Mon 2022-05-09 12:43:00, Rex-BC Chen wrote:
> From: "Nancy.Lin"
>
> Add vdosys1 RDMA definition.
>
> Signed-off-by: Nancy.Lin
> Reviewed-by: AngeloGioacchino Del Regno
>
Your signoff will be needed, too.
Best regards,
Pavel
Hi!
> Linux code for running as a Hyper-V guest includes special cases for the
> first released versions of Hyper-V: 2008 and 2008R2/Windows 7. These
> versions were very thinly used for running Linux guests when first
> released more than 12 years ago, and they are now out of support
> (except
tempted to assume that passing an error to
> the upper layer is a good idea. All drivers are adapted accordingly.
> There is no intended change of behaviour, all callbacks were prepared to
> return 0 before.
Acked-by: Pavel Machek
Hi!
This series is truncated .. I only got first patches. Similary, 5.10
series is truncated, [PATCH AUTOSEL 5.10 035/101] media: s5p-mfc: Add
checking to s5p_mfc_probe... is last one I got.
I got all the patches before that, so I believe it is not problem on
my side, but I'd not mind someone
Hi!
> From: Xie Yongji
>
> [ Upstream commit 17f46f488a5d82c5568e6e786cd760bba1c2ee09 ]
>
> The dev->dev_private might not be allocated if virtio_gpu_pci_quirk()
> or virtio_gpu_init() failed. In this case, we should avoid the cleanup
> in virtio_gpu_release().
The check is in wrong place at
Hi!
> > Revert "drm/radeon: Fix reference count leaks caused by
> > pm_runtime_get_sync"
> > Revert "drm/radeon: fix multiple reference count leak"
> > Revert "drm/amdkfd: Fix reference count leaks."
>
> I didn't review these carefully, but from a quick look they all seem
> rather
On Wed 2021-03-10 13:56:29, Peiyong Lin wrote:
> On Mon, Dec 21, 2020 at 12:10 PM Peiyong Lin wrote:
> >
> > Historically there is no common trace event for GPU frequency, in
> > downstream Android each different hardware vendor implements their own
> > way to expose GPU frequency, for example as
Hi!
> > + struct device *dmadev;
> > + struct drm_gem_object *obj;
> > +
> > + if (!dev_is_usb(dev->dev))
> > + return ERR_PTR(-ENODEV);
> > +
> > + dmadev = usb_intf_get_dma_device(to_usb_interface(dev->dev));
> > + if (drm_WARN_ONCE(dev, !dmadev, "buffer sharing not
Hi!
> > > > This is in -next, but I get same behaviour on 5.11; and no, udl does
> > >
> > > Thanks for reporting. We are in the process of fixing the issue. The
> > > latest
> > > patch is at [1].
> > >
> >
> > Thank you, that fixes the DMA issue, and I can use the udl.
> >
> > ...for a
Hi!
> > Thank you, that fixes the DMA issue, and I can use the udl.
> >
> > ...for a while. Then screensaver blanks laptop screen, udl screen
> > blanks too. Upon hitting a key, internal screen shows up, udl does
> > not.
> >
> > I try rerunning xrandr ... --auto, but could not recover it.
> >
Hi!
> >This is in -next, but I get same behaviour on 5.11; and no, udl does
>
> Thanks for reporting. We are in the process of fixing the issue. The latest
> patch is at [1].
>
Thank you, that fixes the DMA issue, and I can use the udl.
...for a while. Then screensaver blanks laptop screen,
use DRM_GEM_SHMEM_DROVER_OPS_USB to initialize their
> instance of struct drm_driver.
>
> Tested by joining/mirroring displays of udl and radeon un der
> Gnome/X11.
Thanks for doing this.
Tested-by: Pavel Machek
Best regards,
Hi!
This is in -next, but I get same behaviour on 5.11; and no, udl does
not work, but monitor is detected:
pavel@amd:~/g/tui/crashled$ xrandr
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 246mm x
Hi!
> The FSC (Full scale current) setting is not updated properly due to the
> wrong register toggling for WLED5. Also the ILED_SYNC toggle and MOD_SYNC
> toggle sequence is updated as per the hardware team recommendation to fix
> the FSC update and brightness update issue.
If this is phone
Hi!
> Userspace has discovered the functionality offered by SYS_kcmp and has
> started to depend upon it. In particular, Mesa uses SYS_kcmp for
> os_same_file_description() in order to identify when two fd (e.g. device
> or dmabuf) point to the same struct file. Since they depend on it for
> core
Hi!
> commit 83404d581471775f37f85e5261ec0d09407d8bed upstream.
>
> This function will be needed by the next patch where the driver
> calculates the BW based on driver specific parameters, so export it.
>
> At the same time sanitize the function params, passing the more natural
> link rate
Hi!
> Another round of wack-a-mole. The json-schema default is additional
> unknown properties are allowed, but for DT all properties should be
> defined.
for leds:
Acked-by: Pavel Machek
I assume you apply it..?
Hi!
> Milo Kim's email in TI bounces with permanent error (550: Invalid
> recipient). Last email from him on LKML was in 2017. Move Milo Kim to
> credits and remove the separate driver entries for:
>
> - TI LP855x backlight driver,
> - TI LP8727 charger driver,
> - TI LP8788 MFD (ADC, LEDs,
On Tue 2020-07-07 11:04:05, Randy Dunlap wrote:
> Drop the doubled word "for".
>
> Signed-off-by: Randy Dunlap
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> Cc: Jacek Anaszewski
Acked-by: Pavel Machek
(I expect documentation people take this,
Hi!
> > > > Would it not be better to have one st7703 driver that suipports both
> > > > panels?
> > > >
> > > > The driver would need dedicated init functions depending on the panel.
> > > > But a lot could also be shared.
> > >
> > > I guess I can move the code there.
> > In the same process
On Tue 2020-06-16 09:28:19, Sasha Levin wrote:
> On Tue, Jun 16, 2020 at 12:51:13PM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > > The driver creates the /dev/dxg device, which can be opened by user mode
> > > > application and handles their io
Hi!
> Thanks for the discussion. I may not be able to immediately answer all of
> your questions, but I'll do my best .
>
Could you do something with your email settings? Because this is not how you
should use
email on lkml. "[EXTERNAL]" in the subject, top-posting, unwrapped lines...
> > Having said that, I hit one stumbling block:
> > "Further, at this time there are no presentation integration. "
> >
> > If we upstream this driver as-is into some hyperv specific place, and
> > you decide to add presentation integration this is more than likely
> > going to mean you will want
Hi!
> > The driver creates the /dev/dxg device, which can be opened by user mode
> > application and handles their ioctls. The IOCTL interface to the driver
> > is defined in dxgkmthk.h (Dxgkrnl Graphics Port Driver ioctl
> > definitions). The interface matches the D3DKMT interface on Windows.
>
On Thu 2020-05-28 14:07:50, Michal Hocko wrote:
> On Thu 28-05-20 14:03:54, Pavel Machek wrote:
> > On Thu 2020-05-28 11:05:17, Michal Hocko wrote:
> > > On Tue 26-05-20 11:10:54, Pavel Machek wrote:
> > > [...]
> > > > [38617.276517] oom_reaper: reaped proc
Hi!
> PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
> display.
>
> Backlight levels curve was optimized by Martijn Braam using a
> lux meter.
If it was possible to preserve lux values for individual settings in
the comment somewhere... that would be nice :-).
One day, it
On Thu 2020-05-28 11:05:17, Michal Hocko wrote:
> On Tue 26-05-20 11:10:54, Pavel Machek wrote:
> [...]
> > [38617.276517] oom_reaper: reaped process 31769 (chromium), now
> > anon-rss:0kB, file-rss:0kB, shmem-rss:7968kB
> > [38617.277232] Xorg invoked oom-killer:
e to ack the dts patch?
It looks okay to me (but did not test it yet).
Acked-by: Pavel Machek
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/
gt; > Signed-off-by: Jean-Jacques Hiblot
> > Acked-by: Pavel Machek
> > Reviewed-by: Daniel Thompson
> > Acked-by: Lee Jones
> > Acked-by: Tony Lindgren
> > Tested-by: Tony Lindgren
> > Signed-off-by: Pavel Machek
> > ---
> > drivers/video/ba
Acked-by: Pavel Machek
Reviewed-by: Daniel Thompson
Acked-by: Lee Jones
Acked-by: Tony Lindgren
Tested-by: Tony Lindgren
Signed-off-by: Pavel Machek
---
drivers/video/backlight/Kconfig | 7 ++
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/led_bl.c | 260
Pavel
commit 81a2daadf8dd6c8e0cbc3b60246932436be3c714
Author: Tomi Valkeinen
Date: Thu Oct 3 10:28:12 2019 +0200
backlight: add led-backlight driver
This patch adds a led-backlight driver (led_bl), which is simila
Hi!
> > > It would be good to get LED backlight to work in clean way for 5.6
> > > kernel.
> ...
> > > [If you have an idea what else is needed, it would be welcome; it
> > > works for me in development tree but not in tree I'd like to
> > > upstream.]
> > >
> > > Lee, would you be willing to
Hi!
> > * Jean-Jacques Hiblot [700101 00:00]:
> > > From: Tomi Valkeinen
> > >
> > > This patch adds a led-backlight driver (led_bl), which is similar to
> > > pwm_bl except the driver uses a LED class driver to adjust the
> > > brightness in the HW. Multiple LEDs can be used for a single
ight driver
This patch adds a led-backlight driver (led_bl), which is similar
to pwm_bl except the driver uses a LED class driver to adjust the
brightness in the HW. Multiple LEDs can be used for a single
backlight.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jean-Jacques Hiblo
Hi!
> > It would be good to get LED backlight to work in clean way for 5.6
> > kernel.
>
> I agree, this is badly needed for many devices.
>
> > [If you have an idea what else is needed, it would be welcome; it
> > works for me in development tree but not in tree I'd like to
> > upstream.]
>
>
. Multiple LEDs can be used for a single backlight.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jean-Jacques Hiblot
Acked-by: Pavel Machek
Reviewed-by: Daniel Thompson
commit 44b7adbf0b07904e4198ae1d0a763917d1c68a23
Author: Jean-Jacques Hiblot
Date: Thu Oct 3 10:28:10
Hi!
> If you're going to apply them, you need to send out an immutable
> branch for me to pull from.
Aha, its backlight, not LED. I really should not be taking
those. Sorry for the noise, I dropped them from my tree.
Best regards,
On Tue 2019-10-22 17:12:06, Rajat Jain wrote:
> Certain laptops now come with panels that have integrated privacy
> screens on them. This patch adds support for such panels by adding
> a privacy-screen property to the drm_connector for the panel, that
> the userspace can then use to control and
Hi!
> If the LED is acquired by a consumer device with devm_led_get(), it is
> automatically released when the device is detached.
>
> Signed-off-by: Jean-Jacques Hiblot
> Acked-by: Pavel Machek
> ---
> drivers/leds/led-class.c | 49
On Mon 2019-09-30 12:09:07, Kiran Gunda wrote:
> Restructure the qcom-wled bindings for the better readability.
>
> Signed-off-by: Kiran Gunda
> Reviewed-by: Bjorn Andersson
> Reviewed-by: Rob Herring
> Acked-by: Daniel Thompson
> Acked-by: Pavel Machek
I applied 1,2 to
etree/bindings/leds/backlight/led-backlight.txt
> > create mode 100644 drivers/video/backlight/led_bl.c
>
> How should this set be processed? I'm happy to take it through
> Backlight via an immutable branch and PR to be consumed by LED.
That would make sense to me.
For the record, seri
Hi!
> > >> I have been looking into adding Linux support for electronic privacy
> > >> screens which is a feature on some new laptops which is built into the
> > >> display and allows users to turn it on instead of needing to use a
> > >> physical privacy filter. In discussions with my colleagues
On Wed 2019-10-02 09:46:50, Jonathan Corbet wrote:
> On Tue, 1 Oct 2019 10:09:46 -0600
> Mat King wrote:
>
> > I have been looking into adding Linux support for electronic privacy
> > screens which is a feature on some new laptops which is built into the
> > display and allows users to turn it
On Tue 2019-10-01 10:09:46, Mat King wrote:
> Resending in plain text mode
>
> I have been looking into adding Linux support for electronic privacy
> screens which is a feature on some new laptops which is built into the
> display and allows users to turn it on instead of needing to use a
>
Hi!
> > > > Is this needed?
> > > >
> > > > This is a remove path, not a power management path, and we have no idea
> > > > what the original status of the pin was anyway?
> > > >
> > >
> > > Looking at Ishdn on page 5 of the datasheet, switching it off everytime
> > > possible seems not
> PWM's of_pwm_get() and pwm_put().
>
> Signed-off-by: Tomi Valkeinen
> Signed-off-by: Jean-Jacques Hiblot
Acked-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
sign
Hi!
> >>> +++ b/drivers/leds/trigger/ledtrig-backlight.c
> >>> @@ -114,6 +114,8 @@ static int bl_trig_activate(struct led_classdev *led)
> >>> n->old_status = UNBLANK;
> >>> n->notifier.notifier_call = fb_notifier_callback;
> >>>
> >>> + led_set_brightness(led, LED_ON);
> >>> +
> >>
> >>
Hi!
> >> This looks fishy.
> >>
> >> Maybe you should use a default-state = "keep" instead? (and you'll have
> >> to support it in the LED driver).
> >>
> >> That'll give you proper "don't touch the LED if it was turned on" behavior,
> >> which is what you seem to want.
> >
> > Actually no,
Hi!
> > Configuring backlight trigger from dts results in backlight off during
> > boot. Machine looks dead upon boot, which is not good.
> >
> > Fix that by enabling LED on trigger activation.
> > +++ b/drivers/leds/trigger/ledtrig-backlight.c
> > @@ -114,6 +114,8 @@ static int
Configuring backlight trigger from dts results in backlight off during
boot. Machine looks dead upon boot, which is not good.
Fix that by enabling LED on trigger activation.
Signed-off-by: Pavel Machek
diff --git a/drivers/leds/trigger/ledtrig-backlight.c
b/drivers/leds/trigger/ledtrig
lt-brightness-level", );
> + if (!ret && value <= priv->max_brightness)
> + priv->default_brightness = value;
> + else if (!ret && value > priv->max_brightness)
> + dev_warn(dev, "invalid default brightness. ignoring
On Wed 2019-07-10 14:39:31, Jean-Jacques Hiblot wrote:
> Add DT binding for led-backlight.
>
> Signed-off-by: Jean-Jacques Hiblot
> ---
> .../bindings/leds/backlight/led-backlight.txt | 28 +++
> 1 file changed, 28 insertions(+)
> create mode 100644
>
On Wed 2019-07-10 14:39:30, Jean-Jacques Hiblot wrote:
> If the LED is acquired by a consumer device with devm_led_get(), it is
> automatically release when the device is detach.
released, detached.
Acked-by: Pavel
On Wed 2019-07-10 14:39:29, Jean-Jacques Hiblot wrote:
> From: Tomi Valkeinen
>
> This patch adds basic support for a kernel driver to get a LED device.
> This will be used by the led-backlight driver.
>
> Only OF version is implemented for now, and the behavior is similar to
> PWM's
On Mon 2019-07-01 17:14:19, Jean-Jacques Hiblot wrote:
> This series aims to add a led-backlight driver, similar to pwm-backlight,
> but using a LED class device underneath.
>
> A few years ago (2015), Tomi Valkeinen posted a series implementing a
> backlight driver on top of a LED device:
>
Hi!
> Add DT binding for led-backlight.
>
> Signed-off-by: Tomi Valkeinen
> Signed-off-by: Jean-Jacques Hiblot
> Cc: devicet...@vger.kernel.org
> ---
> +Required properties:
> + - compatible: "led-backlight"
> + - brightness-levels: Array of distinct LED brightness levels. These
> +
On Sun 2019-06-30 20:28:15, Brian Dodge wrote:
> The original patch adding this driver and DT bindings improperly
> used "arc" as the vendor-prefix. This adds "arctic" which is the
> proper prefix and retains "arc" to allow existing users of the
> "arc" prefix to update to new kernels. There is at
On Fri 2019-06-28 08:55:16, Daniel Thompson wrote:
> On Wed, Jun 26, 2019 at 04:56:18PM +0200, Pavel Machek wrote:
> > On Mon 2019-06-24 13:31:13, Matthias Kaehlcke wrote:
> > > Check if a brightness curve specified in the device tree is linear or
> > > not and set
On Wed 2019-06-26 11:56:14, Daniel Thompson wrote:
> On Tue, Jun 25, 2019 at 07:44:06AM -0400, Brian Dodge wrote:
> > I would like to deprecate the old prefix in the future after communicating
> > with all chip customers, which is why the old prefix is not documented in
> > the new bindings.
>
>
Hi!
> Export the type of the brightness curve via the new sysfs attribute
> 'scale'. The value of the attribute may be a simple string like
> 'linear' or 'non-linear', or a composite string similar to
> 'compatible' strings of the device tree. A composite string consists
> of different elements
On Mon 2019-06-24 13:31:13, Matthias Kaehlcke wrote:
> Check if a brightness curve specified in the device tree is linear or
> not and set the corresponding property accordingly. This makes the
> scale type available to userspace via the 'scale' sysfs attribute.
>
> To determine if a curve is
1 - 100 of 266 matches
Mail list logo
