from:"Pavel Machek"

Re: [PATCH 000/190] Revertion of all of the umn.edu commits

2021-04-29 Thread Pavel Machek

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 inconsequental. Either error paths that are very unlikely, or
> drivers which are very dead (looking at the entire list, not just what
> you reverted here).
> 
> Acked-by: Daniel Vetter 

So you are knowingly acking patch re-introducing bugs into kernel, because 
the bugs are minor? I don't believe that's an okay thing to do.

Maybe something needs reverting, but lets not introduce bugs into kernel 
because they are
"minor".

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5] Add power/gpu_frequency tracepoint.

2021-03-12 Thread Pavel Machek

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 a debugfs node.  This patch
> > standardize it as a common trace event in upstream linux kernel to help
> > the ecosystem have a common implementation across hardware vendors.
> > Toolings in the Linux ecosystem will benefit from this especially in the
> > downstream Android, where this information is critical to graphics
> > developers.
...
> >  /* This part must be outside protection */
> > --
> > 2.29.2.684.gfbc64c5ab5-goog
> >
> 
> Hi there,
> 
> Could you please take a look at this patch?

Please trim email quotes when replying.

Also, you might want to state _name_ of person who should apply this,
so there's no ambiguity. You cc-ed many people...
Pavel
-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5.10 078/120] drm/dp/mst: Export drm_dp_get_vc_payload_bw()

2021-02-10 Thread Pavel Machek

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 instead of the encoding of the same rate.

> Cc: 

This adds exports, but there's no user of the export, neither in
5.10-stable nor in linux-next. What is the plan here?

Best regards,
Pavel

-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] kernel: Expose SYS_kcmp by default

2021-02-13 Thread Pavel Machek

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 functionality, lift SYS_kcmp out of the non-default
> CONFIG_CHECKPOINT_RESTORE into the selectable syscall category.

Is it good idea to enable everything because Mesa uses it for file
descriptors?

This is really interesting syscall...

Best regards,
Pavel

-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V1 0/2] Fix WLED FSC Sync and brightness Sync settings

2021-02-19 Thread Pavel Machek

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 hardware, it might make sense to cc:
phone-devel@vger...

Best regards,
Pavel

-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

udldrmfb: causes WARN in i915 on X60 (x86-32)

2021-02-24 Thread Pavel Machek

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 
185mm
   1024x768  50.00*+  60.0040.00  
   800x600   60.3256.25  
   640x480   59.94  
VGA1 disconnected (normal left inverted right x axis y axis)
DVI-1-0 connected 1024x768+0+0 304mm x 228mm
   1024x768  60.00*+  75.03  
   800x600   75.0060.32  
   640x480   75.0059.94  
   720x400   70.08  
  1024x768 (0x45) 65.000MHz -HSync -VSync
h: width  1024 start 1048 end 1184 total 1344 skew0 clock  48.36KHz
v: height  768 start  771 end  777 total  806   clock  60.00Hz
  800x600 (0x47) 40.000MHz +HSync +VSync
h: width   800 start  840 end  968 total 1056 skew0 clock  37.88KHz
v: height  600 start  601 end  605 total  628   clock  60.32Hz
  640x480 (0x49) 25.175MHz -HSync -VSync
h: width   640 start  656 end  752 total  800 skew0 clock  31.47KHz
v: height  480 start  490 end  492 total  525   clock  59.94Hz
pavel@amd:~/g/tui/crashled$ 


[13957.499755] wlan0: associated
[13962.906368] udl 1-5:1.0: [drm] fb1: udldrmfb frame buffer device
[13972.585101] [ cut here ]
[13972.585117] WARNING: CPU: 0 PID: 3159 at kernel/dma/mapping.c:192 
dma_map_sg_attrs+0x38/0x50
[13972.585137] Modules linked in:
[13972.585149] CPU: 0 PID: 3159 Comm: Xorg Not tainted 5.11.0-next-20210223+ 
#176
[13972.585158] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 ) 
03/31/2011
[13972.585166] EIP: dma_map_sg_attrs+0x38/0x50
[13972.585176] Code: f0 01 00 00 00 74 23 ff 75 0c 53 e8 72 1b 00 00 5a 59 85 
c0 78 1c 8b 5d fc c9 c3 8d b4 26 00 00 00 00 0f 0b 8d b6 00 00 00 00 <0f> 0b 31 
c0 eb e6 66 90 0f 0b 8d b4 26 00 00 00 00 8d b4 26 00 00
[13972.585186] EAX: c296c41c EBX:  ECX: 0055 EDX: dbbc4800
[13972.585194] ESI: c69f9ea0 EDI: d2c313c0 EBP: c5cbdda8 ESP: c5cbdda4
[13972.585202] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210246
[13972.585211] CR0: 80050033 CR2: b6b99000 CR3: 05d42000 CR4: 06b0
[13972.585219] Call Trace:
[13972.585227]  i915_gem_map_dma_buf+0xee/0x160
[13972.585240]  dma_buf_map_attachment+0xb8/0x140
[13972.585251]  drm_gem_prime_import_dev.part.0+0x33/0xc0
[13972.585262]  ? drm_gem_shmem_create+0x10/0x10
[13972.585271]  drm_gem_prime_import_dev+0x22/0x70
[13972.585280]  drm_gem_prime_fd_to_handle+0x186/0x1c0
[13972.585289]  ? drm_gem_prime_import_dev+0x70/0x70
[13972.585298]  ? drm_prime_destroy_file_private+0x20/0x20
[13972.585307]  drm_prime_fd_to_handle_ioctl+0x1c/0x30
[13972.585315]  drm_ioctl_kernel+0x8e/0xe0
[13972.585325]  ? drm_prime_destroy_file_private+0x20/0x20
[13972.585334]  drm_ioctl+0x1fd/0x380
[13972.585343]  ? drm_prime_destroy_file_private+0x20/0x20
[13972.585352]  ? ksys_write+0x5c/0xd0
[13972.585363]  ? vfs_write+0xeb/0x3f0
[13972.585371]  ? drm_ioctl_kernel+0xe0/0xe0
[13972.585380]  __ia32_sys_ioctl+0x369/0x7d0
[13972.585389]  ? exit_to_user_mode_prepare+0x4e/0x170
[13972.585398]  do_int80_syscall_32+0x2c/0x40
[13972.585409]  entry_INT80_32+0x111/0x111
[13972.585419] EIP: 0xb7f68092
[13972.585427] Code: 00 00 00 e9 90 ff ff ff ff a3 24 00 00 00 68 30 00 00 00 
e9 80 ff ff ff ff a3 e8 ff ff ff 66 90 00 00 00 00 00 00 00 00 cd 80  8d b4 
26 00 00 00 00 8d b6 00 00 00 00 8b 1c 24 c3 8d b4 26 00
[13972.585436] EAX: ffda EBX: 0030 ECX: c00c642e EDX: bfaeda30
[13972.585444] ESI: 00915790 EDI: c00c642e EBP: 0030 ESP: bfaed9e4
[13972.585452] DS: 007b ES: 007b FS:  GS: 0033 SS: 007b EFLAGS: 00200296
[13972.585461]  ? asm_exc_nmi+0xcc/0x2bc
[13972.585470] ---[ end trace 46a21fad0595bc89 ]---
pavel@amd:~/g/tui/crashled$ 

Any ideas?

Best regards,

Pavel
-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm: Use USB controller's DMA mask when importing dmabufs

2021-02-25 Thread Pavel Machek

Hi!

> USB devices cannot perform DMA and hence have no dma_mask set in their
> device structure. Therefore importing dmabuf into a USB-based driver
> fails, which breaks joining and mirroring of display in X11.
> 
> For USB devices, pick the associated USB controller as attachment device.
> This allows the DRM import helpers to perform the DMA setup. If the DMA
> controller does not support DMA transfers, we're out of luck and cannot
> import. Our current USB-based DRM drivers don't use DMA, so the actual
> DMA device is not important.
> 
> Drivers should 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,
Pavel
-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

udldrm does not recover from powersave? Re: udldrmfb: causes WARN in i915 on X60 (x86-32)

2021-02-25 Thread Pavel Machek

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, 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.

Any ideas?

Best regards,
Pavel
-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: udldrm does not recover from powersave? Re: udldrmfb: causes WARN in i915 on X60 (x86-32)

2021-02-25 Thread Pavel Machek

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.
> > 
> > Any ideas?
> 
> Did it work before the regression?

I don't know. I'm trying to get it to work, I basically did not use it before.

> For testing, could you please remove the fix and then do
> 
>   git revert 6eb0233ec2d0
> 
> This would restore the old version. Please report back on the results.

I doubt this is related, but I can try.

Best regards,
Pavel
-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: udldrm does not recover from powersave? Re: udldrmfb: causes WARN in i915 on X60 (x86-32)

2021-02-25 Thread Pavel Machek

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, 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.
> > 
> > Any ideas?
> 
> Did it work before the regression?
> 
> For testing, could you please remove the fix and then do
> 
>   git revert 6eb0233ec2d0
> 
> This would restore the old version. Please report back on the
> results.

Ok, I went to 7f206cf3ec2b with 6eb0233ec2d0 reverted. That fails to
build:

drivers/usb/core/message.c: In function ‘usb_set_configuration’:
drivers/usb/core/message.c:2100:12: error: ‘struct device’ has no member named 
‘dma_pfn_offset’
 2100 |   intf->dev.dma_pfn_offset = dev->dev.dma_pfn_offset;
  |^
drivers/usb/core/message.c:2100:38: error: ‘struct device’ has no member named 
‘dma_pfn_offset’
 2100 |   intf->dev.dma_pfn_offset = dev->dev.dma_pfn_offset;
  |  ^
  CC  drivers/net/ethernet/intel/e1000e/param.o
make[3]: *** [scripts/Makefile.build:271: drivers/usb/core/message.o]
Error 1

So I tried to go to bad commit's parent:

git checkout 6eb0233ec2d0^
git log
commit cf141ae989e2ff119cd320326da5923b480d1641
ARM/keystone: move the DMA offset handling under ifdef CONFIG_ARM_LPAE

But that resulted in lockup soon after "--setprovidersource" command
was isued.

Best regards,
Pavel

-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5] drm: Use USB controller's DMA mask when importing dmabufs

2021-02-26 Thread Pavel Machek

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 supported"))
> > +   return ERR_PTR(-ENODEV);
> > +
> > +   obj = drm_gem_prime_import_dev(dev, dma_buf, dmadev);
> > +
> > +   put_device(dmadev);
> 
> Just realized there's another can of worms here because dma_buf_attach
> does not refcount the struct device. But the dma_buf can easily outlive
> the underlying device, at least right now.
> 
> We should probably require that devices get rid of all their mappings in
> their hotunplug code.
> 
> Ofc now that we pick some random other device struct this gets kinda
> worse.
> 
> Anyway, also just another pre-existing condition that we should worry
> about here. It's all still a very bad hack.

This is actually regression fix if I understand this correctly. Bug
means udl is unusable, so that's kind of bad.

Should we revert the original commit causing this while this get
sorted out?

Best regards,
Pavel
-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH AUTOSEL 4.4 08/31] drm/virtio: Fixes a potential NULL pointer dereference on probe failure

2021-07-12 Thread Pavel Machek

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 least in 4.4:

> +++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
> @@ -257,6 +257,9 @@ int virtio_gpu_driver_unload(struct drm_device *dev)
>   flush_work(&vgdev->config_changed_work);
>   vgdev->vdev->config->del_vqs(vgdev->vdev);
>  
> + if (!vgdev)
> + return;
> +

Pointer is dereferenced before being tested.

Best regards,
Pavel
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany



signature.asc
Description: Digital signature

Re: [PATCH 5/5] spi: make remove callback a void function

2022-03-02 Thread Pavel Machek

Hi!

> The value returned by an spi driver's remove function is mostly ignored.
> (Only an error message is printed if the value is non-zero that the
> error is ignored.)
> 
> So change the prototype of the remove function to return no value. This
> 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.

Acked-by: Pavel Machek 
Pavel
-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

AUTOSEL series truncated was -- Re: [PATCH AUTOSEL 5.15 001/146] dma-buf: WARN on dmabuf release with pending attachments

2021-11-09 Thread 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 confirming they are seeing the same
problem...

Best regards,
Pavel

-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

[PATCH 0/7] de-stage SW_SYNC validation frawework

2016-08-07 Thread Pavel Machek

On Sun 2016-07-24 15:21:11, Greg Kroah-Hartman wrote:
> On Mon, Jul 18, 2016 at 04:12:45PM -0300, Gustavo Padovan wrote:
> > Hi,
> > 
> > Do you think there is time to get this in for 4.8?
> 
> No, it was too late on my end, due to travel and vacation, sorry.  I'll
> queue it up for 4.9-rc1.

Could we get some documentation what this does? Is it visilble to
userspace?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH 0/7] de-stage SW_SYNC validation frawework

2016-08-08 Thread Pavel Machek

On Mon 2016-08-08 16:08:12, Gustavo Padovan wrote:
> 2016-08-07 Pavel Machek :
> 
> > On Sun 2016-07-24 15:21:11, Greg Kroah-Hartman wrote:
> > > On Mon, Jul 18, 2016 at 04:12:45PM -0300, Gustavo Padovan wrote:
> > > > Hi,
> > > > 
> > > > Do you think there is time to get this in for 4.8?
> > > 
> > > No, it was too late on my end, due to travel and vacation, sorry.  I'll
> > > queue it up for 4.9-rc1.
> > 
> > Could we get some documentation what this does? Is it visilble to
> > userspace?
> 
> This interface is only intended for testing and validation, there are
> ioctls on the debugfs file that can be accessed by userspace but there
> isn't any exported kernel header with this info. The tester should know
> and add a internal header to be able to access it. We want to prevent
> people from misusing this feature by not advertising it nor providing
> documentation.

You are playing dangerous game here. debugfs is not normally considered stable,
but otoh... ioctls on debugfs?

Anyway, please provide some documentation. Kernel hackers need to know what 
this does.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH v2 1/6] staging/android: remove doc from sw_sync

2016-08-09 Thread Pavel Machek

On Mon 2016-08-08 18:24:17, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> SW_SYNC should never be used by other pieces of the kernel apart from
> sync_debug as it is only a Sync File Validation Framework, so hide any
> info to avoid confuse this with a standard kernel internal API.

> Signed-off-by: Gustavo Padovan 

NAK.

It is unclear for what the code does, removing the docs is not going to help.

If it should not be used, document that it should not be used.. but not remove
the docs.

> -/**
> - * sync_timeline_signal() - signal a status change on a sync_timeline
> - * @obj: sync_timeline to signal
> - * @inc: num to increment on timeline->value
> - *
> - * A sync implementation should call this any time one of it's fences
> - * has signaled or has an error condition.
> - */
>  static void sync_timeline_signal(struct sync_timeline *obj, unsigned int inc)
>  {

And as the functions are static... there's little danger that someone will 
misuse them.


Pavel

[PATCH 0/7] de-stage SW_SYNC validation frawework

2016-08-10 Thread Pavel Machek

On Tue 2016-08-09 08:04:54, Daniel Vetter wrote:
> On Sun, Jul 24, 2016 at 05:00:31PM +0200, Pavel Machek wrote:
> > On Mon 2016-08-08 16:08:12, Gustavo Padovan wrote:
> > > 2016-08-07 Pavel Machek :
> > > 
> > > > On Sun 2016-07-24 15:21:11, Greg Kroah-Hartman wrote:
> > > > > On Mon, Jul 18, 2016 at 04:12:45PM -0300, Gustavo Padovan wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Do you think there is time to get this in for 4.8?
> > > > > 
> > > > > No, it was too late on my end, due to travel and vacation, sorry.  
> > > > > I'll
> > > > > queue it up for 4.9-rc1.
> > > > 
> > > > Could we get some documentation what this does? Is it visilble to
> > > > userspace?
> > > 
> > > This interface is only intended for testing and validation, there are
> > > ioctls on the debugfs file that can be accessed by userspace but there
> > > isn't any exported kernel header with this info. The tester should know
> > > and add a internal header to be able to access it. We want to prevent
> > > people from misusing this feature by not advertising it nor providing
> > > documentation.
> > 
> > You are playing dangerous game here. debugfs is not normally considered 
> > stable,
> > but otoh... ioctls on debugfs?
> 
> It's not considered stable. The idea is that we also add the existing
> testcases to kselftest. It's purely a bit of interface to be able to drive
> run the test logic for real fences. What it really tests is the fence
> interface (which is public in the uapi headers and all that), but to be
> able to do that we need some (hw-independent way) to expose fences, which
> this provides.
> 
> Long term we might even do this as a proper interface (with some
> restrictions to make it safe and avoid userspace pulling the kernel over
> the table). And then rip out sw_sync entirely.
> 
> Imo there's no need at all for docs for this.

There's full directory of files, with absolutely zero comments/documentation. 
They
are quite hard to understand. Plus it has userland interface.

IMO comment should be added, explaining what it is testing, that interface is 
not considered
stable, and where the test lives.

I know what "fence" is in the cpu sense (mfence and friends), but I'm not sure 
what "real fence" is in this context.

Best regards,

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH] staging/android: add Doc for SW_SYNC ioctl interface

2016-08-18 Thread Pavel Machek

On Thu 2016-08-11 13:45:53, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> This interface is hidden from kernel headers and it is intended for use
> only for testing. So testers would have to add the ioctl information
> internally. This is to prevent misuse of this feature.
> 
> v2: take in Eric suggestions for the Documentation
> 
> v3: really take in Eric suggestions
> 
> Signed-off-by: Gustavo Padovan 
> Reviewed-by: Eric Engestrom 

Acked-by: Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCHv6 4/4] drm/omap: add support for manually updated displays

2019-05-22 Thread Pavel Machek

On Wed 2019-04-03 17:11:09, Tony Lindgren wrote:
> * Sebastian Reichel  [190403 20:14]:
> > This adds the required infrastructure for manually updated displays,
> > such as DSI command mode panels. While those panels often support
> > partial updates we currently always do a full refresh.
> > 
> > The display will be refreshed when something calls the dirty callback,
> > such as libdrm's drmModeDirtyFB(). This is currently being done at least
> > by the kernel console and Xorg (with modesetting driver) in their
> > default configuration. Weston does not implement this and the fbdev
> > backend does not work (display will not update). Weston's DRM backend
> > uses double buffering and the page flip will also trigger a display
> > refresh.
> 
> I've tested this with Linux next and the latest lm3532
> patches and it works fine as long as we leave out the
> backlight = <&lcd_backlight> entry from dts like I
> replied in the lm3532 tread. So as far as I'm concerned,
> we're good to go:
> 
> Tested-by: Tony Lindgren 

I've tested this on 5.2-rc1, and it is still neccessary, still needed,
and still not merged.

How can I help? Can the patches simply be picked up for drm tree?

Tested-by: Pavel Machek 
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v6 2/3] dt-bindings: backlight: add lm3630a bindings

2019-04-24 Thread Pavel Machek

Hi!

> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
> @@ -0,0 +1,129 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/backlight/lm3630a-backlight.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#

I'm not a great fan on links to external websites. But this is comment
for Rob.

> +title: TI LM3630A High-Efficiency Dual-String White LED
> +
> +maintainers:
> +  - Lee Jones 
> +  - Daniel Thompson 
> +  - Jingoo Han 

Not a great fan of duplicating MAINTAINERS information here. But this
is a comment for Rob, again.

Acked-by: Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 3/3] backlight: lm3630a: add firmware node support

2019-04-24 Thread Pavel Machek

On Wed 2019-04-24 05:25:05, Brian Masney wrote:
> Add fwnode support to the lm3630a driver and optionally allow
> configuring the label, default brightness level, and maximum brightness
> level. The two outputs can be controlled by bank A and B independently
> or bank A can control both outputs.
> 
> If the platform data was not configured, then the driver defaults to
> enabling both banks. This patch changes the default value to disable
> both banks before parsing the firmware node so that just a single bank
> can be enabled if desired. There are no in-tree users of this driver.
> 
> Driver was tested on a LG Nexus 5 (hammerhead) phone.
> 
> Signed-off-by: Brian Masney 
> Reviewed-by: Dan Murphy 

Acked-by: Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 2/3] dt-bindings: backlight: add lm3630a bindings

2019-04-24 Thread Pavel Machek

On Wed 2019-04-24 10:57:50, Rob Herring wrote:
> On Wed, Apr 24, 2019 at 9:20 AM Pavel Machek  wrote:
> >
> > Hi!
> >
> > > --- /dev/null
> > > +++ 
> > > b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
> > > @@ -0,0 +1,129 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/leds/backlight/lm3630a-backlight.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >
> > I'm not a great fan on links to external websites. But this is comment
> > for Rob.
> 
> This is simply how json-schema works. $schema says what meta-schema
> this file should validate against so it's versioned if we change the
> schema format. $id is just a unique identifier and is used to resolve
> $ref values. Note that these aren't live urls either (but could be at
> some point in the future).

Umm. Interesting design :-).

> > > +title: TI LM3630A High-Efficiency Dual-String White LED
> > > +
> > > +maintainers:
> > > +  - Lee Jones 
> > > +  - Daniel Thompson 
> > > +  - Jingoo Han 
> >
> > Not a great fan of duplicating MAINTAINERS information here. But this
> > is a comment for Rob, again.
> 
> Hopefully this is temporary until we move to per directory MAINTAINERS
> files. Not sure what happened with that.

Aha, ok.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/3] backlight: lm3630a: add firmware node support

2019-05-01 Thread Pavel Machek

Hi!

> > @@ -396,13 +506,20 @@ static int lm3630a_probe(struct i2c_client *client,
> >  GFP_KERNEL);
> > if (pdata == NULL)
> > return -ENOMEM;
> > +
> > /* default values */
> > -   pdata->leda_ctrl = LM3630A_LEDA_ENABLE;
> > -   pdata->ledb_ctrl = LM3630A_LEDB_ENABLE;
> > +   pdata->leda_ctrl = LM3630A_LEDA_DISABLE;
> > +   pdata->ledb_ctrl = LM3630A_LEDB_DISABLE;
> 
> This is not needed since default is disabled and kzalloc will set these to 0

Let compiler do this kind of optimalizations. Code makes sense as-is.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support

2019-06-03 Thread Pavel Machek

Hi!

> > > Here is another round of the DSI command mode panel patchset
> > > integrating the feedback from PATCHv5. The patches are based
> > > on v5.2-rc1 tag. It does not contain the patches required for
> > > OMAP3 support (it needs a workaround for a hardware bug) and
> > > for automatic display rotation. They should get their own series,
> > > once after everything has been moved to DRM panel API. I think
> > > DRM panel conversion should happen _after_ this series, since
> > > otherwise there is a high risk of bricking DSI support completely.
> > > I already started a WIP branch for converting DSI to the DRM panel
> > > API on top of this patchset.
> > 
> > Looks good to me. For some reason I can't boot 5.2-rc2 (on x15) so I haven't
> > been able to test yet. I'll pick the series up in any case, and I'll test it
> > when I get the kernel booting.
> 
> Great good to have these merged finally :)
> 
> Hmm I wonder if some x15 models are affected by the SoC variant
> changes queued in my fixes branch?

I still don't see the patches in next-20190603 . Are they expected to
be there, or should I use different tree?

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 1/2] dt-bindings: pwm-backlight: Add 'max-brightness' property

2019-06-11 Thread Pavel Machek

On Mon 2019-06-10 16:37:38, Matthias Kaehlcke wrote:
> Add an optional 'max-brightness' property, which is used to specify
> the number of brightness levels (max-brightness + 1) when the node
> has no 'brightness-levels' table.
> 
> Signed-off-by: Matthias Kaehlcke 

Acked-by: Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] backlight: pwm_bl: Get number of brightness levels for CIE 1931 from the device tree

2019-06-11 Thread Pavel Machek

On Mon 2019-06-10 16:37:39, Matthias Kaehlcke wrote:
> Commit 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED
> linearly to human eye") uses pwm_period / hweight32(pwm_period) as
> as heuristic to determine the number of brightness levels when the DT
> doesn't provide a brightness level table. This heuristic is broken
> and can result in excessively large brightness tables.
> 
> Instead of using the heuristic try to retrieve the number of
> brightness levels from the device tree (property 'max-brightness'
> + 1). If the value is not specified use a default of 256 levels.
> 
> Fixes: 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED linearly 
> to human eye")

I don't think this one is suitable for stable. I'm pretty sure the
heuristics works well for many boards, and you just replaced it with
another heuristics ("256").

> Signed-off-by: Matthias Kaehlcke 

Acked-by: Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix

2019-06-21 Thread Pavel Machek

Hi!

> [Sorry to those receiving this twice... had to dig this out from the
> archives and sent it to the lists from the wrong mailer]
> 
> On 27/11/2018 00:44, Brian Dodge wrote:
> >Thank you Pavel, that is a good point.
> >
> >The chip vendor has indicated that there is no reason to maintain the
> >old/improper prefix and wishes to go forward (only) with the "arctic"
> >prefix and any existing dts files are or will be updated.
> 
> Looks like this patch series has fallen into the cracks a little.
> 
> I think I assumed this info would end in the description of patch v2 1/3 (in
> order to answer Rob's feedback) and I sat and waited for a respin. On the
> other hand... I didn't actually say that explicitly anywhere! So... I'd
> recommend a respin perhaps with a small bit of text explaining how the
> vendor can state that any existing dts files will be updated. This is a
> peripheral device so these strings are probably embedded into OEM
> devicetrees rather than exclusively under the control of the vendor.

So in next email you give good reason not to apply this :-).

Anyway, this is Doc*/devicetree/, so not my area.
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/4] backlight: Expose brightness curve type through sysfs

2019-06-26 Thread Pavel Machek

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 separated by commas, starting with the
> most-detailed description and ending with the least-detailed one. An
> example for a composite string is "cie-1931,perceptual,non-linear"
> This brightness curve was generated with the CIE 1931 algorithm, it
> is perceptually linear, but not actually linear in terms of the
> emitted light. If userspace doesn't know about 'cie-1931' or
> 'perceptual' it should at least be able to interpret the 'non-linear'
> part.

I'm not sure the comma-separated thing is a good idea. If it is, it should 
go to the Documentation, not to changelog.

> +What:/sys/class/backlight//scale
> +Date:June 2019
> +KernelVersion:   5.4
> +Contact: Daniel Thompson 
> +Description:
> + Description of the scale of the brightness curve. The
> + description consists of one or more elements separated by
> + commas, from the most detailed to the least detailed
> + description.
> +
> + Possible values are:
> +
> + unknown
> +   The scale of the brightness curve is unknown.
> +
> + linear
> +   The brightness changes linearly in terms of the emitted
> +   light, changes are perceived as non-linear by the human eye.
> +
> + non-linear
> +   The brightness changes non-linearly in terms of the emitted
> +   light, changes might be perceived as linear by the human eye.

non-linear is not too useful as described.

> + perceptual,non-linear
> +   The brightness changes non-linearly in terms of the emitted
> +   light, changes should be perceived as linear by the human eye.
> +
> + cie-1931,perceptual,non-linear
> +   The brightness curve was calculated with the CIE 1931
> +   algorithm. Brightness changes non-linearly in terms of the
> +   emitted light, changes should be perceived as linear by the
> +   human eye.

Is it useful to know difference between perceptual, and cie-1931?

Would it be useful to export absolute values in some well-known units?

If I'm in dark room, I may want 100mW/m^2 of backlight... And it would
be nice if I could set same backlight intensity on all my devices easily.

Pavel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/4] backlight: pwm_bl: Set scale type for brightness curves specified in the DT

2019-06-26 Thread Pavel Machek

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 linear it is compared to a interpolated linear
> curve between min and max brightness. The curve is considered linear if
> no value deviates more than +/-5% of ${brightness_range} from their
> interpolated value.

I don't think this works. Some hardware does takes brightness in perceptual 
units,
converting it in the LED controller.

Pavel

Re: [PATCH 1/2] dt-bindings: backlight: fix vendor prefix for ArcticSand arcxcnn driver bindings

2019-06-26 Thread Pavel Machek

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.
> 
> Deprecation is fine (by me at least) it's just that I'm not sure that
> removing the documentation for the deprecated bindings is the right way
> to do it. What is the prior art here?

I believe we should keep the docs.

Pavel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/4] backlight: pwm_bl: Set scale type for brightness curves specified in the DT

2019-06-28 Thread Pavel Machek

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 the corresponding property accordingly. This makes the
> > > scale type available to userspace via the 'scale' sysfs attribute.
> > > 
> > > To determine if a curve is linear it is compared to a interpolated linear
> > > curve between min and max brightness. The curve is considered linear if
> > > no value deviates more than +/-5% of ${brightness_range} from their
> > > interpolated value.
> > 
> > I don't think this works. Some hardware does takes brightness in perceptual 
> > units,
> > converting it in the LED controller.
> 
> This check is exclusive to PWM backlights so I'd like to double check
> that you are thinking specifically of hardware that takes it's signal
> from the PWM and works in perceptual units?

I missed that details. Taking PWM input then converting it to
perceptual units would indeed be strange.

Sorry,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] backlight: arcxcnn: add "arctic" vendor prefix

2019-07-05 Thread Pavel Machek

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 least one
> (Samsung Chromebook Plus)
> 
> Signed-off-by: Brian Dodge 
> Acked-by: Daniel Thompson 

ack.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/4] backlight: add led-backlight driver

2019-07-05 Thread Pavel Machek

Hi!

> > > > Also still relevant is whether the LED device is being correctly
> > > > modelled if the act of turning on the LED doesn't, in fact, turn the LED
> > > > on. Is it *really* a correct implementation of an LED device that
> > > > setting it to LED_FULL using sysfs doesn't cause it to light up?
> > > What I understood from the discussion between Rob and Tomi is that the
> > > child-node of the LED controller should be considered a backlight device,
> > > not a simple LED. I'm not sure if the sysfs interface is still relevant in
> > > that case. Maybe it should just be disabled by the backlight driver
> > > (possible with led_sysfs_disable())
> > led_sysfs_disable() sounds like a sensible change but that's not quite
> > what I mean.
> > 
> > It is more a thought experiment to see if the power control *should* be
> > implemented by the backlight. Consider what happens if we *don't*
> > enable CONFIG_BACKLIGHT_LED in the kernel: we would still have an LED
> > device and it would not work correctly.
> > 
> > In other words I naively expect turning on an LED using the LED API
> > (any of them, sysfs or kernel) to result in the LED turning on.
> > Implementing a workaround in the client for what appears to be
> > something missing in the LED driver strikes me as odd. Why shouldn't
> > the regulator be managed in the LED driver?
> 
> I see your point. Indeed having the regulator handled in the LED-core makes
> sense in a lot of situations
> 
> I'll think about it.

For the record, I also believe regulator and enable gpio should be
handled in the core.

Pavel
PS please trim down the quoted text.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/4] devicetree: Add led-backlight binding

2019-07-05 Thread Pavel Machek

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
> +  are in the range from 0 to 255, passed to the LED class driver.

These days, we support more (or less) than 256 brightness levels for LED.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/4] Add a generic driver for LED-based backlight

2019-07-05 Thread Pavel Machek

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:
> https://patchwork.kernel.org/patch/7293991/
> https://patchwork.kernel.org/patch/7294001/
> https://patchwork.kernel.org/patch/7293981/
> 
> The discussion stopped because Tomi lacked the time to work on it.
> 
> This series takes it from there and implements the binding that was
> discussed in https://patchwork.kernel.org/patch/7293991/. In this new
> binding the backlight device is a child of the LED controller instead of
> being another platform device that uses a phandle to reference a LED.

Other option would be to have backlight trigger. What are
advantages/disadvantages relative to that?
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH AUTOSEL 5.0 070/262] drm/amd/display: Pass app_tf by value rather than by reference

2019-03-28 Thread Pavel Machek

> From: Nathan Chancellor 
> 
> [ Upstream commit 672e78cab819ebe31e3b9b8abac367be8a110472 ]
> 
> Clang warns when an expression that equals zero is used as a null
> pointer constant (in lieu of NULL):

Fixes warning, with unsupported compiler; not a serious bug. Plus, not
a minimal fix.
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/3] dt-bindings: backlight: add lm3630a bindings

2019-04-01 Thread Pavel Machek

On Mon 2019-04-01 06:30:33, Brian Masney wrote:
> Add new backlight bindings for the TI LM3630A dual-string white LED.
> 
> Signed-off-by: Brian Masney 
> ---
>  .../leds/backlight/lm3630a-backlight.yaml | 112
++

What is that? Is it future of all the bindings?

Up to device tree people, I guess, but...

Pavel


>  1 file changed, 112 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml 
> b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
> new file mode 100644
> index ..42a8c59d237a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
> @@ -0,0 +1,112 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/backlight/lm3630a-backlight.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI LM3630A High-Efficiency Dual-String White LED
> +
> +maintainers:
> +  - Lee Jones 
> +  - Daniel Thompson 
> +  - Jingoo Han 
> +
> +description: |
> +  The LM3630A is a current-mode boost converter which supplies the power and
> +  controls the current in up to two strings of 10 LEDs per string.
> +  https://www.ti.com/product/LM3630A
> +
> +properties:
> +  compatible:
> +const: ti,lm3630a
> +
> +  reg:
> +maxItems: 1
> +
> +  ti,linear-mapping-mode:
> +description: |
> +  Enable linear mapping mode. If disabled, then it will use exponential
> +  mapping mode in which the ramp up/down appears to have a more uniform
> +  tranisiton to the human eye.
> +type: boolean
> +
> +required:
> +  - compatible
> +  - reg
> +
> +patternProperties:
> +  "^led*$":
> +type: object
> +description: |
> +  Properties for a string of connected LEDs.
> +
> +properties:
> +  label:
> +description: |
> +  The label for this LED. If omitted, the label is taken from the 
> node
> +  name (excluding the unit address). It has to uniquely identify a
> +  device, i.e. no other LED class device can be assigned the same 
> label.
> +
> +  led-sources:
> +description: |
> +  List of device current outputs the LED is connected to.
> +allOf:
> +  - $ref: /schemas/types.yaml#/definitions/uint32-array
> +  - minItems: 1
> +maxItems: 2
> +items:
> +  minimum: 0
> +  maximum: 1
> +
> +  default-brightness:
> +description: Default brightness level on boot.
> +minimum: 0
> +maximum: 255
> +
> +  max-brightness:
> +description: Maximum brightness level on boot.
> +minimum: 0
> +maximum: 255
> +
> +examples:
> +  - |
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +lm3630a_bl@38 {
> +compatible = "ti,lm3630a";
> +status = "ok";
> +reg = <0x38>;
> +
> +led {
> +label = "main-lcd";
> +led-sources = <0 1>;
> +default-brightness = <200>;
> +max-brightness = <255>;
> +};
> +};
> +};
> +  - |
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +lm3630a_bl@38 {
> +compatible = "ti,lm3630a";
> +status = "ok";
> +reg = <0x38>;
> +
> +led-bank-a {
> +led-sources = <0>;
> +default-brightness = <150>;
> +ti,linear-mapping-mode;
> +};
> +
> +led-bank-b {
> +led-sources = <1>;
> +default-brightness = <225>;
> +ti,linear-mapping-mode;
> +};
> +};
> +};

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/3] backlight: lm3630a: return 0 on success in update_status functions

2019-04-01 Thread Pavel Machek

On Mon 2019-04-01 06:30:32, Brian Masney wrote:
> lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status()
> both return the brightness value if the brightness was successfully
> updated. Writing to these attributes via sysfs would cause a 'Bad
> address' error to be returned. These functions should return 0 on
> success, so let's change it to correct that error.
> 
> Signed-off-by: Brian Masney 
> Fixes: 28e64a68a2ef ("backlight: lm3630: apply chip revision")

Acked-by: Pavel Machek 

> ---
>  drivers/video/backlight/lm3630a_bl.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/backlight/lm3630a_bl.c 
> b/drivers/video/backlight/lm3630a_bl.c
> index 2030a6b77a09..ef2553f452ca 100644
> --- a/drivers/video/backlight/lm3630a_bl.c
> +++ b/drivers/video/backlight/lm3630a_bl.c
> @@ -201,7 +201,7 @@ static int lm3630a_bank_a_update_status(struct 
> backlight_device *bl)
> LM3630A_LEDA_ENABLE, LM3630A_LEDA_ENABLE);
>   if (ret < 0)
>   goto out_i2c_err;
> - return bl->props.brightness;
> + return 0;
>  
>  out_i2c_err:
>   dev_err(pchip->dev, "i2c failed to access\n");
> @@ -278,7 +278,7 @@ static int lm3630a_bank_b_update_status(struct 
> backlight_device *bl)
> LM3630A_LEDB_ENABLE, LM3630A_LEDB_ENABLE);
>   if (ret < 0)
>   goto out_i2c_err;
> - return bl->props.brightness;
> + return 0;
>  
>  out_i2c_err:
>   dev_err(pchip->dev, "i2c failed to access REG_CTRL\n");

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/3] backlight: lm3630a: add device tree supprt

2019-04-01 Thread Pavel Machek

On Mon 2019-04-01 06:30:34, Brian Masney wrote:
> Add device tree support to the lm3630a driver and allow configuring
> independently on both banks the mapping mode (linear or exponential),
> initial and maximum LED brightness.
> 
> Driver was tested on a LG Nexus 5 (hammerhead) phone.
> 
> Signed-off-by: Brian Masney 
> ---
>  drivers/video/backlight/lm3630a_bl.c | 69 
>  1 file changed, 69 insertions(+)
> 
> diff --git a/drivers/video/backlight/lm3630a_bl.c 
> b/drivers/video/backlight/lm3630a_bl.c
> index ef2553f452ca..96fbc1273dda 100644
> --- a/drivers/video/backlight/lm3630a_bl.c
> +++ b/drivers/video/backlight/lm3630a_bl.c
> @@ -35,6 +35,9 @@
>  #define REG_MAX  0x50
>  
>  #define INT_DEBOUNCE_MSEC10
> +
> +#define LM3630A_MAX_SOURCES  2
> +
>  struct lm3630a_chip {
>   struct device *dev;
>   struct delayed_work work;
> @@ -364,6 +367,64 @@ static const struct regmap_config lm3630a_regmap = {
>   .max_register = REG_MAX,
>  };
>  
> +static void lm3630a_parse_dt(struct lm3630a_chip *pchip)
> +{
> + u32 sources[LM3630A_MAX_SOURCES], val;
> + struct device_node *child_node;
> + int num_sources, ret, i;
> + bool linear;
> +
> + for_each_available_child_of_node(pchip->dev->of_node, child_node) {
> + num_sources = of_property_count_u32_elems(child_node,
> +   "led-sources");
> + if (num_sources < 0)
> + continue;
> +
> + if (num_sources > LM3630A_MAX_SOURCES)
> + num_sources = LM3630A_MAX_SOURCES;
> +
> + ret = of_property_read_u32_array(child_node, "led-sources",
> +  sources, num_sources);
> + if (ret) {
> + dev_err(pchip->dev,
> + "Error parsing led-sources node: %d\n", ret);
> + return;
> + }
> +
> + linear = of_property_read_bool(child_node,
> +"ti,linear-mapping-mode");
> +
> + for (i = 0; i < num_sources; i++) {
> + if (sources[i] == 0)
> + pchip->pdata->leda_ctrl = linear ?
> + LM3630A_LEDA_ENABLE_LINEAR :
> + LM3630A_LEDA_ENABLE;
> + else if (sources[i] == 1)
> + pchip->pdata->ledb_ctrl = linear ?
> + LM3630A_LEDB_ENABLE_LINEAR :
> + LM3630A_LEDB_ENABLE;

This makes my head spin.

So ... we can have multiple LEDs, each can have up to two
sources.. and the settings are really per source, not per LED.

But you do not test for overlaps. What prevents me from having

   foo {
   led_sources = <0>;
   ti,linear-mapping-mode;
   }
   bar {
   led_sources = <0>;
   }

(I.e. conflicting settings for a source?)

Plus I do not see parsing of led labels etc...

> + ret = of_property_read_u32(child_node,
> +"default-brightness", &val);
> + if (!ret) {
> + if (sources[i] == 0)
> + pchip->pdata->leda_init_brt = val;
> + else if (sources[i] == 1)
> + pchip->pdata->ledb_init_brt = val;
> + }
> +
> + ret = of_property_read_u32(child_node, "max-brightness",
> +&val);
> + if (!ret) {
> + if (sources[i] == 0)
> + pchip->pdata->leda_max_brt = val;
> + else if (sources[i] == 1)
> + pchip->pdata->ledb_max_brt = val;
> + }
> + }
> + };

Extra ";"

> +}
> +
>  static int lm3630a_probe(struct i2c_client *client,
>const struct i2c_device_id *id)
>  {
> @@ -405,6 +466,7 @@ static int lm3630a_probe(struct i2c_client *client,
>   pdata->ledb_init_brt = LM3630A_MAX_BRIGHTNESS;
>   }
>   pchip->pdata = pdata;
> + lm3630a_parse_dt(pchip);

I'd expect abort if we are using dt and dt parsing fails.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/3] backlight: lm3630a: add device tree supprt

2019-04-02 Thread Pavel Machek

On Tue 2019-04-02 08:45:40, Dan Murphy wrote:
> Hello
> 
> On 4/1/19 5:30 AM, Brian Masney wrote:
> > Add device tree support to the lm3630a driver and allow configuring
> > independently on both banks the mapping mode (linear or exponential),
> > initial and maximum LED brightness.
> > 
> > Driver was tested on a LG Nexus 5 (hammerhead) phone.
> > 
> 
> Don't need this in the commit message.

Actually yes, we want that in commit message.

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/4] leds: Add of_led_get() and led_put()

2019-07-10 Thread Pavel Machek

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 of_pwm_get() and pwm_put().
> 
> Signed-off-by: Tomi Valkeinen 
> Signed-off-by: Jean-Jacques Hiblot 


> @@ -214,6 +215,55 @@ static int led_resume(struct device *dev)
>  
>  static SIMPLE_DEV_PM_OPS(leds_class_dev_pm_ops, led_suspend, led_resume);
>  
> +static int led_match_led_node(struct device *led_dev, const void *data)
> +{
> + return led_dev->of_node == data ? 1 : 0;
> +}

Get rid of the "? 1 : 0"?


> + led_node = of_parse_phandle(np, "leds", index);
> + if (!led_node)
> + return ERR_PTR(-ENOENT);
> + led_dev = class_find_device(leds_class, NULL, led_node,
> + led_match_led_node);
> + of_node_put(led_node);
> +
> + if (!led_dev)
> + return ERR_PTR(-EPROBE_DEFER);

Won't this defer probe "forever" when the driver is not available?

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/4] leds: Add managed API to get a LED from a device driver

2019-07-10 Thread Pavel Machek

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 Machek 
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/4] dt-bindings: backlight: Add led-backlight binding

2019-07-10 Thread Pavel Machek

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 
> Documentation/devicetree/bindings/leds/backlight/led-backlight.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt 
> b/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt
> new file mode 100644
> index ..0444eec8efe1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt
> @@ -0,0 +1,28 @@
> +led-backlight bindings
> +
> +This binding is used to describe a basic backlight device made of
> LEDs.

Ok.

> +It can also be used to describe a backlight device controlled by the output 
> of
> +a LED driver.

? The LED driver should better be driving some LEDs...

> +Required properties:
> +  - compatible: "led-backlight"
> +  - leds: a list of LEDs
> +
> +Optional properties:
> +  - brightness-levels: Array of distinct brightness levels. The levels must 
> be
> +   in the range accepted by the underlying LED devices.
> +   This is used to translate a backlight brightness level
> +   into a LED brightness level. if not provided, the
> +   identity mapping is used.

"If it is not"
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v3 4/4] backlight: add led-backlight driver

2019-07-10 Thread Pavel Machek

On Wed 2019-07-10 14:39:32, Jean-Jacques Hiblot wrote:
> 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 backlight.
> 
> Signed-off-by: Tomi Valkeinen 
> Signed-off-by: Jean-Jacques Hiblot 

> +
> + /*
> +  *try to map actual LED brightness to backlight brightness
> +  * level
> +  */

"* Try"

> + db = priv->default_brightness;
> + for (i = 0 ; i < num_levels; i++) {
> + if ((i && db > levels[i-1]) && db <= levels[i])
> + break;
> + }
> + priv->default_brightness = i;
> + priv->max_brightness = num_levels - 1;
> + priv->levels = levels;
> + } else if (num_levels >= 0)
> + dev_warn(dev, "not enought levels defined\n");

"Not enough"

> + ret = of_property_read_u32(node, "default-brightness-level", &value);
> + if (!ret && value <= priv->max_brightness)
> + priv->default_brightness = value;
> + else if (!ret  && value > priv->max_brightness)
> + dev_warn(dev, "invalid default brightness. ignoring it\n");

"Invalid... Ignoring it."

Acked-by: Pavel Machek 
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] Enable backlight when trigger is activated

2019-07-18 Thread Pavel Machek

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-backlight.c
index 487577d..6e6bc78 100644
--- a/drivers/leds/trigger/ledtrig-backlight.c
+++ 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);
+
ret = fb_register_client(&n->notifier);
if (ret)
dev_err(led->dev, "unable to register backlight trigger\n");
@@ -126,6 +128,7 @@ static void bl_trig_deactivate(struct led_classdev *led)
struct bl_trig_notifier *n = led_get_trigger_data(led);
 
fb_unregister_client(&n->notifier);
+   led_set_brightness(led, LED_OFF);
kfree(n);
 }
 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] Enable backlight when trigger is activated

2019-07-22 Thread Pavel Machek

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 bl_trig_activate(struct led_classdev *led)
> > n->old_status = UNBLANK;
> > n->notifier.notifier_call = fb_notifier_callback;
> >  
> > +   led_set_brightness(led, LED_ON);
> > +
> 
> 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, that's not what I want. LED should go on if the display
is active, as soon as trigger is activated.

Unfortunately, I have see no good way to tell if the display is
active (and display is usually active when trigger is activated).

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] Enable backlight when trigger is activated

2019-07-22 Thread Pavel Machek

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, that's not what I want. LED should go on if the display
> > is active, as soon as trigger is activated.
> > 
> > Unfortunately, I have see no good way to tell if the display is
> > active (and display is usually active when trigger is activated).
> 
> default-state DT property can be also set to "on"
> (see Documentation/devicetree/bindings/leds/common.txt).

Ok, thanks for the hint, that could work. (I thought we were using
default trigger to set the LED "on").

Now...this gives me option of 0% or 100% brightness, while best would
be 10% brightness but I guess we can live with that ;-).

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] Enable backlight when trigger is activated

2019-07-24 Thread Pavel Machek

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);
> >>> +
> >>
> >> 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, that's not what I want. LED should go on if the display
> > is active, as soon as trigger is activated.
> > 
> > Unfortunately, I have see no good way to tell if the display is
> > active (and display is usually active when trigger is activated).
> 
> default-state DT property can be also set to "on"
> (see Documentation/devicetree/bindings/leds/common.txt).

Yes, except that it does not work with all drivers :-(. In particular,
it does not work with lm3532.

We should really move more of the device tree parsing into core, so
that there's one place to fix...
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v4 1/4] leds: Add of_led_get() and led_put()

2019-07-30 Thread Pavel Machek

On Wed 2019-07-17 16:15:11, 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 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


signature.asc
Description: Digital signature

Re: [PATCH 0/4] Remove support for Hyper-V 2008 and 2008R2/Win7

2022-05-04 Thread Pavel Machek

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 for extended security updates). As initial versions, they
> lack the performance features needed for effective production usage
> of Linux guests. In total, there's no need to continue to support
> the latest Linux kernels on these versions of Hyper-V.
> 
> Simplify the code for running on Hyper-V by removing the special
> cases. This includes removing the negotiation of the VMbus protocol
> versions for 2008 and 2008R2, and the special case code based on
> those VMbus protocol versions. Changes are in the core VMbus code and
> several drivers for synthetic VMbus devices.

> 2008 and 2008R2, so if the broader Linux kernel community surfaces
> a reason why this clean-up should not be done now, we can wait.
> But I think we want to eventually stop carrying around this extra
> baggage, and based on discussions with the Hyper-V team within
> Microsoft, we're already past the point that it has any value.

Normal way to do such deprecations is to put printks in first, then hide it
under config option noone sets, and wait for year or so if anyone complains.

We can't really remove code that is in use.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v6 04/13] dt-bindings: leds: Add MediaTek MT6370 flashlight

2022-07-30 Thread Pavel Machek

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 regards,
Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.


signature.asc
Description: PGP signature

Re: [PATCH v6 11/13] leds: rgb: mt6370: Add MediaTek MT6370 current sink type LED Indicator support

2022-07-30 Thread Pavel Machek

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 driver,
> a display bias driver and a general LDO for portable devices.
> 
> In MediaTek MT6370, there are four channel current-sink RGB LEDs that
> support hardware pattern for constant current, PWM, and breath mode.
> Isink4 channel can also be used as a CHG_VIN power good indicator.
>

> +config LEDS_MT6370_RGB
> + tristate "LED Support for MediaTek MT6370 PMIC"
> + depends on MFD_MT6370
> + select LINEAR_RANGE
> + help
> +   Say Y here to enable support for MT6370_RGB LED device.
> +   In MT6370, there are four channel current-sink LED drivers that
> +   support hardware pattern for constant current, PWM, and breath mode.


> +   Isink4 channel can also be used as a CHG_VIN power good  indicator.

That does not really belong here.

> +struct mt6370_priv {
> + /* Per LED access lock */
> + struct mutex lock;

Do we really need per-led locking?

> +static int mt6370_gen_breath_pattern(struct mt6370_priv *priv,
> +  struct led_pattern *pattern, u32 len,
> +  u8 *pattern_val, u32 val_len)
> +{
> + enum mt6370_led_ranges sel_range;
> + struct led_pattern *curr;
> + unsigned int sel;
> + u8 val[P_MAX_PATTERNS / 2] = {};
> + int i;
> +
> + if (len < P_MAX_PATTERNS && val_len < P_MAX_PATTERNS / 2)
> + return -EINVAL;
> +
> + /*
> +  * Pattern list
> +  * tr1: byte 0, b'[7: 4]
> +  * tr2: byte 0, b'[3: 0]
> +  * tf1: byte 1, b'[7: 4]
> +  * tf2: byte 1, b'[3: 0]
> +  * ton: byte 2, b'[7: 4]
> +  * toff: byte 2, b'[3: 0]
> +  */
> + for (i = 0; i < P_MAX_PATTERNS; i++) {
> + curr = pattern + i;
> +
> + sel_range = i == P_LED_TOFF ? R_LED_TOFF : R_LED_TRFON;
> +
> + linear_range_get_selector_within(priv->ranges + sel_range,
> +  curr->delta_t, &sel);
> +
> + val[i / 2] |= sel << (4 * ((i + 1) % 2));
> + }
> +
> + memcpy(pattern_val, val, 3);
> +
> + return 0;
> +}

I wonder how this works... you are not creating private sysfs
interface, are you?

> +static int mt6370_init_led_properties(struct mt6370_led *led,
> +   struct led_init_data *init_data)
> +{
> + struct mt6370_priv *priv = led->priv;
> + struct device *dev = priv->dev;
> + struct led_classdev *lcdev;
> + struct fwnode_handle *child;
> + enum mt6370_led_ranges sel_range;
> + u32 max_uA, max_level;
> + const char * const states[] = { "off", "keep", "on" };

We'd really preffer not to add "keep" / "on" support unless you need
it.

> + if (ret)
> + return dev_err_probe(dev, ret,
> +  "led %d, no color 
> specified\n",
> +  led->index);

led->LED.

> + if (num_color < 2)
> + return dev_err_probe(dev, -EINVAL,
> +  "Multicolor must include
> 2 or more led channel\n");

"LED channels".

> +static int mt6370_isnk_init_default_state(struct mt6370_led *led)
> +{
> + struct mt6370_priv *priv = led->priv;
> + unsigned int enable, level;
> + int ret;
> +
> + ret = mt6370_get_led_brightness(priv, led->index, &level);
> + if (ret)
> + return ret;
> +
> + ret = regmap_field_read(priv->fields[F_RGB_EN], &enable);
> + if (ret)
> + return ret;
> +
> + if (!(enable & MT6370_CHEN_BIT(led->index)))
> + level = LED_OFF;

Just use 0 instead of LED_OFF.

Best regards,
Pavel

-- 
People of Russia, stop Putin before his war on Ukraine escalates.


signature.asc
Description: PGP signature

Re: [PATCH v6 12/13] leds: flash: mt6370: Add MediaTek MT6370 flashlight support

2022-07-30 Thread Pavel Machek

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 driver,
> a display bias driver and a general LDO for portable devices.
> 
> The Flash LED in MT6370 has 2 channels and support torch/strobe mode.
> Add the support of MT6370 FLASH LED.
> 
> Signed-off-by: Alice Chen 

> +config LEDS_MT6370_FLASHLIGHT
> + tristate "Flash LED Support for MediaTek MT6370 PMIC"
> + depends on LEDS_CLASS

I'd name it just LEDS_MT6370_FLASH.

> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2022 Richtek Technology Corp.
> + *
> + * Author: Alice Chen " at end of line.

The series is quite big, would it be possible to submit LED changes
in separate series?

Thanks,
Pavel

-- 
People of Russia, stop Putin before his war on Ukraine escalates.


signature.asc
Description: PGP signature

Re: [PATCH AUTOSEL 5.10 01/46] drm/r128: Fix undefined behavior due to shift overflowing the constant

2022-08-12 Thread Pavel Machek

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) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH AUTOSEL 5.10 05/46] drm/panfrost: Handle HW_ISSUE_TTRX_2968_TTRX_3162

2022-08-13 Thread Pavel Machek

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 are not
queued. We don't need this in 5.10.

Best regards,
Pavel
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


signature.asc
Description: PGP signature

Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195

2022-05-30 Thread Pavel Machek

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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH AUTOSEL 4.19 04/22] drm/vc4: crtc: Use an union to store the page flip callback

2022-06-29 Thread Pavel Machek

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 store the page flip
callback is queued for 4.9 / 4.19, preparing for change that is not
queued into 4.19.

Please drop at least from 4.9 and 4.19.

Best regards,
Pavel
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


signature.asc
Description: PGP signature

Re: [PATCH AUTOSEL 4.9 05/13] video: fbdev: skeletonfb: Fix syntax errors in comments

2022-06-29 Thread Pavel Machek

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,
Pavel

> +++ b/drivers/video/fbdev/skeletonfb.c
> @@ -96,7 +96,7 @@ static struct fb_fix_screeninfo xxxfb_fix = {
>  
>  /*
>   *   Modern graphical hardware not only supports pipelines but some 
> - *  also support multiple monitors where each display can have its  
> + *  also support multiple monitors where each display can have
>   *  its own unique data. In this case each display could be  
>   *  represented by a separate framebuffer device thus a separate 
>   *  struct fb_info. Now the struct xxx_par represents the graphics
> -- 
> 2.35.1

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


signature.asc
Description: PGP signature

Re: [PATCH AUTOSEL 4.9 08/13] video: fbdev: simplefb: Check before clk_put() not needed

2022-06-29 Thread Pavel Machek

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,
Pavel
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


signature.asc
Description: PGP signature

Re: [PATCH v5 11/13] leds: mt6370: Add MediaTek MT6370 current sink type LED Indicator support

2022-07-17 Thread Pavel Machek

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 driver and a general LDO for portable devices.
> 
> In MediaTek MT6370, there are four channel current-sink RGB LEDs that
> support hardware pattern for constant current, PWM, and breath mode.
> Isink4 channel can also be used as a CHG_VIN power good indicator.
> 
> Signed-off-by: ChiYuan Huang 

> index a49979f..71bacb5 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -244,6 +244,20 @@ config LEDS_MT6323
> This option enables support for on-chip LED drivers found on
> Mediatek MT6323 PMIC.
>  
> +config LEDS_MT6370_RGB
> + tristate "LED Support for MediaTek MT6370 PMIC"
> + depends on LEDS_CLASS
> + depends on MFD_MT6370
> + select LINEAR_RANGE
> + help
> +   Say Y here to enable support for MT6370_RGB LED device.
> +   In MT6370, there are four channel current-sink LED drivers that
> +   support hardware pattern for constant current, PWM, and breath mode.
> +   Isink4 channel can also be used as a CHG_VIN power good

Should this go to leds/rgb directory, and should it depend on
multicolor framework?

Best regards,
Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.


signature.asc
Description: PGP signature

Re: [PATCH 6/8] dt-bindings: backlight: Update Lee Jones' email address

2022-07-17 Thread Pavel Machek

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 Ukraine escalates.


signature.asc
Description: PGP signature

Re: [PATCH 6/6] i2c: Make remove callback return void

2022-07-18 Thread Pavel Machek

Hi!

> From: Uwe Kleine-König 
> 
> The value returned by an i2c driver's remove function is mostly ignored.
> (Only an error message is printed if the value is non-zero that the
> error is ignored.)
> 
> So change the prototype of the remove function to return no value. This
> 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: Acked-by: Pavel Machek 

Best regards,
Pavel

-- 
People of Russia, stop Putin before his war on Ukraine escalates.


signature.asc
Description: PGP signature

Re: [PATCH V6 2/8] backlight: qcom-wled: restructure the qcom-wled bindings

2019-11-04 Thread Pavel Machek

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,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

LED backlight on Droid 4 and others

2020-01-05 Thread Pavel Machek

Hi!

It would be good to get LED backlight to work in clean way for 5.6
kernel.

As far as I can see, these are neccessary (but not enough; it does not
work for me): lm3532 changes to register LED with of node, plus device
tree changes for droid 4, and these generic changes:

commit d457d0c97d6d55fe3e62633791ac05d289a37d2e
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 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 Hiblot 
Acked-by: Pavel Machek 
Reviewed-by: Daniel Thompson 

commit 44b7adbf0b07904e4198ae1d0a763917d1c68a23
Author: Jean-Jacques Hiblot 
Date:   Thu Oct 3 10:28:10 2019 +0200

leds: Add managed API to get a LED from a device driver

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 
Signed-off-by: Pavel 

commit 93b98c570d7f898063ab6204e1b3950a3335dd12
Author: Tomi Valkeinen 
Date:   Thu Oct 3 10:28:09 2019 +0200

leds: Add of_led_get() and led_put()

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 of_pwm_get() and pwm_put().

Signed-off-by: Tomi Valkeinen 
Signed-off-by: Jean-Jacques Hiblot 
Acked-by: Pavel Machek 
Signed-off-by: Pavel 

[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 take "backlight: add led-backlight
driver"? Would it help if I got "leds: Add managed API to get a LED
from a device driver" and "leds: Add of_led_get() and led_put()" into
for_next tree of the LED subsystem?

It is kind of important as, well, phone without screen looks pretty
much dead, and same issue hits Droid 4 and Librem 5 phones at least...

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: LED backlight on Droid 4 and others

2020-01-05 Thread Pavel Machek

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.]
> 
> I have some version of these patches working with modified dts in my
> droid4-pending-v5.4 branch git branch, maybe try to diff against that.

Thanks a lot. I was missing 7dc08cb9ac7baff1601f65f66c4c611f841abc64.

Best regards,
Pavel
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: LED backlight on Droid 4 and others

2020-01-05 Thread Pavel Machek

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.]
> 
> I have some version of these patches working with modified dts in my
> droid4-pending-v5.4 branch git branch, maybe try to diff against that.

So.. backlight now works for me, and I put the LED parts of the
patches to

gitolite.kernel.org:pub/scm/linux/kernel/git/pavel/linux-leds.git for-next

tree. [I guess I could try to sneak them into 5.5 if that helps.]

Could we somehow get this to the backlight tree?

commit d457d0c97d6d55fe3e62633791ac05d289a37d2e
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 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 Hiblot 
 Acked-by: Pavel Machek 
 Reviewed-by: Daniel Thompson 

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v10 6/6] backlight: add led-backlight driver

2020-01-07 Thread Pavel Machek

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 backlight.
> > ...
> > 
> > > + ret = of_property_read_u32(node, "default-brightness", &value);
> > > + if (!ret && value <= priv->max_brightness)
> > > + priv->default_brightness = value;
> > > + else if (!ret  && value > priv->max_brightness)
> > > + dev_warn(dev, "Invalid default brightness. Ignoring it\n");
> > 
> > Hmm so just wondering.. Are we using "default-brightness" instead of the
> > usual "default-brightness-level" here?
> 
> Did this get answered?
> 
> > Please Cc me on the next patchset too :)
> 
> I've been waiting for v11.

I guess I could just remove it from a merge for now if there's no other
fix.

Best regards,
Pavel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: New sysfs interface for privacy screens

2019-10-06 Thread Pavel Machek

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
> physical privacy filter. In discussions with my colleagues the idea of
> using either /sys/class/backlight or /sys/class/leds but this new
> feature does not seem to quite fit into either of those classes.

Thank you for not trying to push it as a LED ;-).

> I am proposing adding a class called "privacy_screen" to interface
> with these devices. The initial API would be simple just a single
> property called "privacy_state" which when set to 1 would mean that
> privacy is enabled and 0 when privacy is disabled.
> 
> Current known use cases will use ACPI _DSM in order to interface with
> the privacy screens, but this class would allow device driver authors
> to use other interfaces as well.
> 
> Example:
> 
> # get privacy screen state
> cat /sys/class/privacy_screen/cros_privacy/privacy_state # 1: privacy
> enabled 0: privacy disabled
> 
> # set privacy enabled
> echo 1 > /sys/class/privacy_screen/cros_privacy/privacy_state
> 
>  Does this approach seem to be reasonable?

Not really. How does the userland know which displays this will
affect?

This sounds like something that should go through drm drivers,
probably to be selected by xrandr, rather than separate file somewhere
in sysfs.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: New sysfs interface for privacy screens

2019-10-06 Thread Pavel Machek

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 instead of needing to use a
> > physical privacy filter. In discussions with my colleagues the idea of
> > using either /sys/class/backlight or /sys/class/leds but this new
> > feature does not seem to quite fit into either of those classes.
> 
> FWIW, it seems that you're not alone in this; 5.4 got some support for
> such screens if I understand things correctly:
> 
>   
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=110ea1d833ad

Hmm. We may want to revert that one because it does more damage :-(.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: New sysfs interface for privacy screens

2019-10-06 Thread Pavel Machek

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 the idea of
> > >> using either /sys/class/backlight or /sys/class/leds but this new
> > >> feature does not seem to quite fit into either of those classes.
> > >
> > > FWIW, it seems that you're not alone in this; 5.4 got some support for
> > > such screens if I understand things correctly:
> > >
> > >   
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=110ea1d833ad
> > 
> > Oh, I didn't realize it got merged already, I thought this was
> > related...
> > 
> > So we've already replicated the backlight sysfs interface problem for
> > privacy screens. :(
> 
> I guess... although the Thinkpad code hasn't added any standard
> interfaces (no other laptop should be placing controls for a privacy
> screen in /proc/acpi/ibm/... ). Maybe its not too late.

There's new interface for controlling privacyguard... but perhaps we
need better solution than what went in 5.4. Perhaps it should be
reconsidered?

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v8 0/5] Add a generic driver for LED-based backlight

2019-10-08 Thread Pavel Machek

On Thu 2019-10-03 12:40:28, Lee Jones wrote:
> On Thu, 03 Oct 2019, 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:
> > https://patchwork.kernel.org/patch/7293991/
> > https://patchwork.kernel.org/patch/7294001/
> > https://patchwork.kernel.org/patch/7293981/
> > 
> > The discussion stopped because Tomi lacked the time to work on it.
> 
> [...]
> 
> >  .../bindings/leds/backlight/led-backlight.txt |  28 ++
> >  drivers/leds/led-class.c  |  98 ++-
> >  drivers/video/backlight/Kconfig   |   7 +
> >  drivers/video/backlight/Makefile  |   1 +
> >  drivers/video/backlight/led_bl.c  | 260 ++
> >  include/linux/leds.h  |   6 +
> >  6 files changed, 399 insertions(+), 1 deletion(-)
> >  create mode 100644 
> > Documentation/devicetree/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, series is Tested-by: Pavel Machek  .

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v9 3/5] leds: Add managed API to get a LED from a device driver

2019-10-13 Thread Pavel Machek

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 
>  include/linux/leds.h |  2 ++
>  2 files changed, 51 insertions(+)
> 
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index 1d1f1d546dc7..639224392ffa 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -264,6 +264,55 @@ void led_put(struct led_classdev *led_cdev)
>  }
>  EXPORT_SYMBOL_GPL(led_put);
>  
> +static void devm_led_release(struct device *dev, void *res)
> +{
> + struct led_classdev **p = res;
> +
> + led_put(*p);
> +}
> +
> +/**
> + * devm_of_led_get - Resource-managed request of a LED device
> + * @dev: LED consumer
> + * @index:   index of the LED to obtain in the consumer
> + *
> + * The device node of the device is parse to find the request LED device.
> + * The LED device returned from this function is automatically released
> + * on driver detach.
> + *
> + * @return a pointer to a LED device or ERR_PTR(errno) on failure.
> + */
> +struct led_classdev *__must_check devm_of_led_get(struct device *dev,
> +   int index)
> +{
> + struct led_classdev *led;
> + struct led_classdev **dr;
> +
> + if (!dev)
> + return ERR_PTR(-EINVAL);
> +
> + /* Consummer not using device tree? */

Typo "consumer". I may fix it before applying the patch.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V6 2/8] backlight: qcom-wled: restructure the qcom-wled bindings

2019-10-13 Thread Pavel Machek

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 my branch, it should appear in -next shortly.

yaml conversion can be done in a followup...

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Add support for integrated privacy screens

2019-10-25 Thread Pavel Machek

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 check the status. The idea
> was discussed here:

Much better than separate /sys interface, thanks!
Pavel

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: LED backlight on Droid 4 and others

2020-02-12 Thread Pavel Machek

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 take "backlight: add led-backlight
> > > driver"? Would it help if I got "leds: Add managed API to get a LED
> > > from a device driver" and "leds: Add of_led_get() and led_put()" into
> > > for_next tree of the LED subsystem?
> > 
> > It looks like you have an open question from Tony on v10.
> > 
> > Is that patch orthogonal, or are there depend{ants,encies}?
> 
> Uhh looks like we messed up a bit with integration. Now droid4
> LCD backlight can no longer be enabled at all manually in v5.6-rc1
> without the "add led-backlight driver" patch.. Should we just
> merge it to fix it rather than start scrambling with other
> temporary hacks?

We should just merge the "add led-backlight driver". Everything should
be ready for it. I'm sorry if I broke something working, I was not
aware it worked at all.

Unfortunately, this is backlight code, not LED, so I can't just merge it.

> I don't care if we use "default-brightness", or if we use
> "default-brightness-level". The binding merged says now
> "default-brightness", so let's go with that one. That's what
> other LED drivers are using too.

No opinion on that.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: LED backlight on Droid 4 and others

2020-02-18 Thread Pavel Machek

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 take "backlight: add led-backlight
> > > > > > driver"? Would it help if I got "leds: Add managed API to get a LED
> > > > > > from a device driver" and "leds: Add of_led_get() and led_put()" 
> > > > > > into
> > > > > > for_next tree of the LED subsystem?
> > > > > 
> > > > > It looks like you have an open question from Tony on v10.
> > > > > 
> > > > > Is that patch orthogonal, or are there depend{ants,encies}?
> > > > 
> > > > Uhh looks like we messed up a bit with integration. Now droid4
> > > > LCD backlight can no longer be enabled at all manually in v5.6-rc1
> > > > without the "add led-backlight driver" patch.. Should we just
> > > > merge it to fix it rather than start scrambling with other
> > > > temporary hacks?
> > > 
> > > We should just merge the "add led-backlight driver". Everything should
> > > be ready for it. I'm sorry if I broke something working, I was not
> > > aware it worked at all.
> > > 
> > > Unfortunately, this is backlight code, not LED, so I can't just merge it.
> > 
> > Please go ahead.  Apply my Acked-by and merge away ASAP.
> > 
> > Acked-by: Lee Jones 
> 
> OK best to merge the driver via the LED tree:
> 
> Acked-by: Tony Lindgren 
> Tested-by: Tony Lindgren 

Is the patch below the one both of you are talking about?

Hmm. I should s/default-brightness-level/default-brightness/
below.

Lee, I can of course take it (thanks), but won't Kconfig/Makefile
pieces cause rejects? It might be still better if you took it. I can
hand-edit it and submit it in form for easy application... tommorow.

Best regards,

    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 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 Hiblot 
Acked-by: Pavel Machek 
Reviewed-by: Daniel Thompson 

diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 4c8f73394aac..93836ef872f5 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -463,6 +463,13 @@ config BACKLIGHT_RAVE_SP
help
  Support for backlight control on RAVE SP device.
 
+config BACKLIGHT_LED
+   tristate "Generic LED based Backlight Driver"
+   depends on LEDS_CLASS && OF
+   help
+ If you have a LCD backlight adjustable by LED class driver, say Y
+ to enable this driver.
+
 endif # BACKLIGHT_CLASS_DEVICE
 
 endmenu
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 961fb553b9c0..5e13242f31d6 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -60,3 +60,4 @@ obj-$(CONFIG_BACKLIGHT_TPS65217)  += tps65217_bl.o
 obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
 obj-$(CONFIG_BACKLIGHT_ARCXCNN)+= arcxcnn_bl.o
 obj-$(CONFIG_BACKLIGHT_RAVE_SP)+= rave-sp-backlight.o
+obj-$(CONFIG_BACKLIGHT_LED)+= led_bl.o
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
new file mode 100644
index ..3f66549997c8
--- /dev/null
+++ b/drivers/video/backlight/led_bl.c
@@ -0,0 +1,260 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2015-2019 Texas Instruments Incorporated -  http://www.ti.com/
+ * Author: Tomi Valkeinen 
+ *
+ * Based on pwm_bl.c
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+struct led_bl_data {
+   struct device   *dev;
+   struct backlight_device *bl_dev;
+   struct led_classdev **leds;
+   boolenabled;
+   int nb_leds;
+   unsigned int*levels;
+   unsigned intdefault_brightness;
+   unsigned intmax_brightness;
+};
+
+static void led_bl_set_brightness(struct led_bl_d

[PATCH] backlight: add led-backlight driver

2020-02-19 Thread Pavel Machek

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 backlight.

Signed-off-by: Tomi Valkeinen 
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/backlight/Kconfig  |   7 ++
 drivers/video/backlight/Makefile |   1 +
 drivers/video/backlight/led_bl.c | 260 +++
 3 files changed, 268 insertions(+)
 create mode 100644 drivers/video/backlight/led_bl.c

Hi!

Here's the version of the driver I have. AFAICT
default-brightness-level handling is ok, so does not need to be
changed.

Lee, it would be easiest for me if you could apply it to your tree and
push, but given enough time I can push it to Linus, too.

Thanks,
Pavel

diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 403707a3e503..0093bbd0d326 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -456,6 +456,13 @@ config BACKLIGHT_RAVE_SP
help
  Support for backlight control on RAVE SP device.
 
+config BACKLIGHT_LED
+   tristate "Generic LED based Backlight Driver"
+   depends on LEDS_CLASS && OF
+   help
+ If you have a LCD backlight adjustable by LED class driver, say Y
+ to enable this driver.
+
 endif # BACKLIGHT_CLASS_DEVICE
 
 endmenu
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 6f8777037c37..0c1a1524627a 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_BACKLIGHT_TPS65217)  += tps65217_bl.o
 obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
 obj-$(CONFIG_BACKLIGHT_ARCXCNN)+= arcxcnn_bl.o
 obj-$(CONFIG_BACKLIGHT_RAVE_SP)+= rave-sp-backlight.o
+obj-$(CONFIG_BACKLIGHT_LED)+= led_bl.o
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
new file mode 100644
index ..3f66549997c8
--- /dev/null
+++ b/drivers/video/backlight/led_bl.c
@@ -0,0 +1,260 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2015-2019 Texas Instruments Incorporated -  http://www.ti.com/
+ * Author: Tomi Valkeinen 
+ *
+ * Based on pwm_bl.c
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+struct led_bl_data {
+   struct device   *dev;
+   struct backlight_device *bl_dev;
+   struct led_classdev **leds;
+   boolenabled;
+   int nb_leds;
+   unsigned int*levels;
+   unsigned intdefault_brightness;
+   unsigned intmax_brightness;
+};
+
+static void led_bl_set_brightness(struct led_bl_data *priv, int level)
+{
+   int i;
+   int bkl_brightness;
+
+   if (priv->levels)
+   bkl_brightness = priv->levels[level];
+   else
+   bkl_brightness = level;
+
+   for (i = 0; i < priv->nb_leds; i++)
+   led_set_brightness(priv->leds[i], bkl_brightness);
+
+   priv->enabled = true;
+}
+
+static void led_bl_power_off(struct led_bl_data *priv)
+{
+   int i;
+
+   if (!priv->enabled)
+   return;
+
+   for (i = 0; i < priv->nb_leds; i++)
+   led_set_brightness(priv->leds[i], LED_OFF);
+
+   priv->enabled = false;
+}
+
+static int led_bl_update_status(struct backlight_device *bl)
+{
+   struct led_bl_data *priv = bl_get_data(bl);
+   int brightness = bl->props.brightness;
+
+   if (bl->props.power != FB_BLANK_UNBLANK ||
+   bl->props.fb_blank != FB_BLANK_UNBLANK ||
+   bl->props.state & BL_CORE_FBBLANK)
+   brightness = 0;
+
+   if (brightness > 0)
+   led_bl_set_brightness(priv, brightness);
+   else
+   led_bl_power_off(priv);
+
+   return 0;
+}
+
+static const struct backlight_ops led_bl_ops = {
+   .update_status  = led_bl_update_status,
+};
+
+static int led_bl_get_leds(struct device *dev,
+  struct led_bl_data *priv)
+{
+   int i, nb_leds, ret;
+   struct device_node *node = dev->of_node;
+   struct led_classdev **leds;
+   unsigned int max_brightness;
+   unsigned int default_brightness;
+
+   ret = of_count_phandle_with_args(node, "leds", NULL);
+   if (ret < 0) {
+   dev_err(dev, "Unable to get led count\n");
+   return -EINVAL;
+   }
+
+   nb_leds = ret;
+   if (nb_leds < 1) {
+   dev_err(dev, "At least one LED must be specified!\n");
+

Re: [PATCH] backlight: add led-backlight driver

2020-02-19 Thread Pavel Machek

Hi!

> > 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 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/backlight/Kconfig  |   7 ++
> >  drivers/video/backlight/Makefile |   1 +
> >  drivers/video/backlight/led_bl.c | 260 
> > +++
> >  3 files changed, 268 insertions(+)
> >  create mode 100644 drivers/video/backlight/led_bl.c

> > Here's the version of the driver I have. AFAICT
> > default-brightness-level handling is ok, so does not need to be
> > changed.
> > 
> > Lee, it would be easiest for me if you could apply it to your tree and
> > push, but given enough time I can push it to Linus, too.
> 
> Oh you're using quoted-printable for patches.. Got it applied now,
> and it still works. Below is also the related dts change that
> I tested with.
> 
> Feel free to pick the dts change too, naturally that should
> not be applied before the driver.
> 
> If you guys instead want me to pick these both into my fixes
> branch, just let me know and I'll do the explaining why these
> are needed as fixes. Basically we no longer have a way to enable
> the LCD backlight for droid4 manually starting with v5.6-rc1
> unlike earlier.

If you are willing to do that, it looks like good solution from my
point of view.

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] backlight: add led-backlight driver

2020-02-19 Thread Pavel Machek

Hi!

> > > If you guys instead want me to pick these both into my fixes
> > > branch, just let me know and I'll do the explaining why these
> > > are needed as fixes. Basically we no longer have a way to enable
> > > the LCD backlight for droid4 manually starting with v5.6-rc1
> > > unlike earlier.
> > 
> > If you are willing to do that, it looks like good solution from my
> > point of view.
> 
> OK. I'll apply them but won't push out yet in case Lee is already
> applying the driver change..
> 
> Pavel, care 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/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] backlight: lm3630a: add an enable gpio for the HWEN pin

2019-09-15 Thread Pavel Machek

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 needed. We would need to call chip_init() everytime
> > > we enable the gpio or live with default values.
> > > Therefore I did decide to not put it into any power management path.
> > > But switching it on and not switching it off feels so unbalanced.   
> > 
> > Either the power consumed by the controller when strings aren't lit up
> > matters, in which case the driver should implement proper power
> > management or it doesn't matter and changing the pin state isn't needed.
> > 
> > I'm happy with either of the above but this looks like a third way,
> > where eager users could hack in a bit of extra power management by
> > forcing drivers to unbind. 
> > 
> I think I will take the simple way. I am quite sure that the power
> consumption with HWEN on and leds off does not matter. If someone
> later comes up and finds out that I misread the datasheet, things
> are prepared to be improved.

Dunno.. if the power consumption does not matter, why does the chip have the 
enable
pin in the first place, and why do we bother supporting it? We could hardcode 
the
pin to enabled as well..
Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

AUXdisplay for LED arrays, keyboards with per-key LEDs -- was Re: [PATCH v2 2/2] leds: add aw20xx driver

2023-02-28 Thread Pavel Machek

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 programmed via
> > + an I2C interface, up to 36/54/72 LEDs or 12/18/24 RGBs,
> > + 3 pattern controllers for auto breathing or group dimming control.
> 
> I'm afraid this should be handled as a display, not as an array of
> individual LEDs.

You probably want to see

AUXILIARY DISPLAY DRIVERS
M:  Miguel Ojeda 
S:  Maintained
F:  Documentation/devicetree/bindings/auxdisplay/
F:  drivers/auxdisplay/
F:  include/linux/cfag12864b.h

And this brings another question...

...sooner or later we'll see LED displays with around 100 pixels in
almost rectangular grid. Minority of the pixels will have funny
shapes. How will we handle those? Pretend it is regular display with
some pixels missing? How do we handle cellphone displays with rounded
corners and holes for front camera?

And yes, such crazy displays are being manufactured -- it is called
keyboard with per-key backlight... 

https://www.reddit.com/r/MechanicalKeyboards/comments/8dtvgo/keyboard_with_individually_programmable_leds/

Best regards,
Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.


signature.asc
Description: PGP signature

6.1-rc: names of video outputs changed?

2022-10-31 Thread Pavel Machek

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:~$ xrandr --output VGA-1 --mode 1280x1024 --below HDMI-1
xrandr: cannot find crtc for output VGA-1
pavel@duo:~$ xrandr --output LVDS-1 --off
pavel@duo:~$ xrandr --output VGA-1 --mode 1280x1024 --below HDMI-1

Notice the change from HDMI1 to HDMI-1. I believe that's new in 6.1 or
so. Who did it and why? Hardware is thinkpad x220, and this breaks my
scripts :-(.

Best regards,
Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.


signature.asc
Description: PGP signature

Re: 6.1-rc: names of video outputs changed?

2022-10-31 Thread Pavel Machek

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:~$ xrandr --output VGA-1 --mode 1280x1024 --below HDMI-1
> > xrandr: cannot find crtc for output VGA-1
> > pavel@duo:~$ xrandr --output LVDS-1 --off
> > pavel@duo:~$ xrandr --output VGA-1 --mode 1280x1024 --below HDMI-1
> > 
> > Notice the change from HDMI1 to HDMI-1. I believe that's new in 6.1 or
> > so. Who did it and why? Hardware is thinkpad x220, and this breaks my
> > scripts :-(.
> 
> Are you sure you didn't just switch from intel ddx to modesetting ddx?

How do I tell?

I don't think I did such changes recently. It is Debian 10.13 system
(rather old) so I don't think it did update for me.

Thanks and best regards,
Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.


signature.asc
Description: PGP signature

Re: [PATCH v2 01/11] pwm: Make .get_state() callback return an error code

2022-12-05 Thread Pavel Machek

Hi!

> .get_state() might fail in some cases. To make it possible that a driver
> signals such a failure change the prototype of .get_state() to return an
> error code.
> 
> This patch was created using coccinelle and the following semantic patch:
> 
> @p1@
> identifier getstatefunc;
> identifier driver;
> @@
>  struct pwm_ops driver = {
> ...,
> .get_state = getstatefunc
> ,...
>  };
> 
> @p2@
> identifier p1.getstatefunc;
> identifier chip, pwm, state;
> @@
> -void
> +int
>  getstatefunc(struct pwm_chip *chip, struct pwm_device *pwm, struct pwm_state 
> *state)
>  {
>...
> -  return;
> +  return 0;
>...
>  }
> 
> plus the actual change of the prototype in include/linux/pwm.h (plus some
> manual fixing of indentions and empty lines).
> 
> So 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

>  static const struct pwm_ops ti_sn_pwm_ops = {
> diff --git a/drivers/leds/rgb/leds-qcom-lpg.c 
> b/drivers/leds/rgb/leds-qcom-lpg.c
> index 02f51cc61837..741cc2fd817d 100644
> --- a/drivers/leds/rgb/leds-qcom-lpg.c
> +++ b/drivers/leds/rgb/leds-qcom-lpg.c
> @@ -968,8 +968,8 @@ static int lpg_pwm_apply(struct pwm_chip *chip, struct 
> pwm_device *pwm,
>   return ret;
>  }
>  
> -static void lpg_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> -   struct pwm_state *state)
> +static int lpg_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> +  struct pwm_state *state)
>  {
>   struct lpg *lpg = container_of(chip, struct lpg, pwm);
>   struct lpg_channel *chan = &lpg->channels[pwm->hwpwm];
> @@ -982,20 +982,20 @@ static void lpg_pwm_get_state(struct pwm_chip *chip, 
> struct pwm_device *pwm,
>  
>   ret = regmap_read(lpg->map, chan->base + LPG_SIZE_CLK_REG, &val);
>   if (ret)
> - return;
> + return 0;
>  
>   refclk = lpg_clk_rates[val & PWM_CLK_SELECT_MASK];
>   if (refclk) {
>   ret = regmap_read(lpg->map, chan->base + LPG_PREDIV_CLK_REG, 
> &val);
>   if (ret)
> - return;
> + return 0;
>  
>   pre_div = lpg_pre_divs[FIELD_GET(PWM_FREQ_PRE_DIV_MASK, val)];
>   m = FIELD_GET(PWM_FREQ_EXP_MASK, val);
>  
>   ret = regmap_bulk_read(lpg->map, chan->base + PWM_VALUE_REG, 
> &pwm_value, sizeof(pwm_value));
>   if (ret)
> - return;
> + return 0;
>  
>   state->period = DIV_ROUND_UP_ULL((u64)NSEC_PER_SEC * 
> LPG_RESOLUTION * pre_div * (1 << m), refclk);
>   state->duty_cycle = DIV_ROUND_UP_ULL((u64)NSEC_PER_SEC * 
> pwm_value * pre_div * (1 << m), refclk);
> @@ -1006,13 +1006,15 @@ static void lpg_pwm_get_state(struct pwm_chip *chip, 
> struct pwm_device *pwm,
>  
>   ret = regmap_read(lpg->map, chan->base + PWM_ENABLE_CONTROL_REG, &val);
>   if (ret)
> - return;
> + return 0;
>  
>   state->enabled = FIELD_GET(LPG_ENABLE_CONTROL_OUTPUT, val);
>   state->polarity = PWM_POLARITY_NORMAL;
>  
>   if (state->duty_cycle > state->period)
>   state->duty_cycle = state->period;
> +
> + return 0;
>  }

-- 
People of Russia, stop Putin before his war on Ukraine escalates.


signature.asc
Description: PGP signature

Re: [PATCH] treewide: Convert del_timer() to timer_shutdown()

2022-12-20 Thread Pavel Machek

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 least add the trivial ones
> now as Thomas suggested that this gets applied at the end of the
> merge window, to avoid conflicts with linux-next during the
> development cycle. I can wait to Friday to run it again, and
> resubmit.
> 
> What is the best way to handle this?
> ]
> 
> From: "Steven Rostedt (Google)" 
> 
> Due to several bugs caused by timers being re-armed after they are
> shutdown and just before they are freed, a new state of timers was added
> called "shutdown". After a timer is set to this state, then it can no
> longer be re-armed.
> 
> The following script was run to find all the trivial locations where
> del_timer() or del_timer_sync() is called in the same function that the
> object holding the timer is freed. It also ignores any locations where the
> timer->function is modified between the del_timer*() and the free(), as
> that is not considered a "trivial" case.
> 
> This was created by using a coccinelle script and the following
commands:

LED parts looks good to me.

Getting it in just before -rc1 would be best solution for me.

Best regards,
Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.


signature.asc
Description: PGP signature

Re: [PATCH v4 0/4] Add PinePhone Pro display support

2023-01-01 Thread Pavel Machek

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 and patch #3 adds
> an entry for the driver in the MAINTAINERS file.
> 
> Finally patch #4 adds the needed devicetree nodes in the PinePhone Pro DTS,
> to enable both the display and the touchscreen. This makes the upstream DTS
> much more usable and will allow for example to enable support for the phone
> in the Fedora distribution.

Thanks for the series. Please cc: phone-de...@vger.kernel.org with
future patches.

Best regards,
Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.


signature.asc
Description: PGP signature

Re: [PATCH] drm/display: Add missing OLED Vesa brightnesses definitions

2023-03-25 Thread Pavel Machek

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 DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP   (1 << 5)
>  # define DP_EDP_DYNAMIC_BACKLIGHT_CAP(1 << 6)
>  # define DP_EDP_VBLANK_BACKLIGHT_UPDATE_CAP  (1 << 7)
> +#define DP_EDP_OLED_VESA_BRIGHTNESS_ON  0x80
> +# define DP_EDP_OLED_VESA_CAP(1 << 4)
>  

Are you fixing a compile problem? Otherwise this should go in with the
user...

BR,
Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.


signature.asc
Description: PGP signature

Re: [PATCH AUTOSEL 4.14 5/6] fbdev: imsttfb: Release framebuffer and dealloc cmap on error path

2023-06-16 Thread Pavel Machek

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,
Pavel

> +++ b/drivers/video/fbdev/imsttfb.c
> @@ -1452,9 +1452,13 @@ static void init_imstt(struct fb_info *info)
> FBINFO_HWACCEL_FILLRECT |
> FBINFO_HWACCEL_YPAN;
>  
> - fb_alloc_cmap(&info->cmap, 0, 0);
> + if (fb_alloc_cmap(&info->cmap, 0, 0)) {
> + framebuffer_release(info);
> + return -ENODEV;
> + }
>  
>   if (register_framebuffer(info) < 0) {
> + fb_dealloc_cmap(&info->cmap);
>   framebuffer_release(info);
>   return;
>   }

-- 
DENX Software Engineering GmbH,Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


signature.asc
Description: PGP signature

Re: [PATCH] video/aperture: fix typos

2023-05-12 Thread Pavel Machek

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
> in comments".

I seem to remember that 'all your bases are belong to us' is an old
meme, but that was probably not intentional here.

Best regards,
Pavel

--

Re: [PATCH AUTOSEL 4.14 1/9] drm/radeon: Fix integer overflow in radeon_cs_parser_init

2023-07-24 Thread Pavel Machek

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 only got the first patch of the series via lkml, rest seems to have
been lost somewhere :-(.

Best regards,
Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.


signature.asc
Description: PGP signature

4.8-rc1: it is now common that machine needs re-run of xrandr after resume

2016-10-18 Thread Pavel Machek

Hi!

On Wed 2016-09-14 14:14:35, Jani Nikula wrote:
> On Wed, 14 Sep 2016, Jani Nikula  wrote:
> > On Wed, 14 Sep 2016, Pavel Machek  wrote:
> >> For the "sometimes need xrandr after resume": I don't think I can
> >> bisect that. It only happens sometimes :-(. But there's something
> >> helpful in the logs:
> >
> >> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> >> invalid, remainder is 130
> >> [ 1856.218863] Raw EDID:
> >> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> >> invalid, remainder is 130
> >> [ 1856.218863] Raw EDID:
> >> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> >> invalid, remainder is 130
> >> [ 1856.218863] Raw EDID:
> >> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> >> invalid, remainder is 130
> >> [ 1856.218863] Raw EDID:
> >> [ 1856.218863] 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >> [ 1856.218863] i915 :00:02.0: HDMI-A-1: EDID block 0 invalid.
> >
> > Pavel, Martin, do you always see this when the display fails to resume?
> > Is it HDMI/DVI for both of you?
> 
> Please try this patch, backported from our next.

Sorry, spam filter hidden your emails.

I believe I still see the issue on v4.9-rc1. ... does it still make
sense to retry the patch?

What I also is re-aranged windows. So I get resume, I get both
monitors, but I also see that X windows lost connection with the big
monitor (and re-arranged my windows for me).

Oh and I guess I should mention:

1) Yes, I only see the issue on the DVI output. VGA seems to work.

2) I do have power switch on the monitors, so it is possible that
during resume, monitors have no AC power. (Not merely turned off by
the soft switch. No AC power.)

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161018/b5f0bbda/attachment.sig>

Re: [regression] Re: 4.11-rc0, thinkpad x220: GPU hang

2017-04-09 Thread Pavel Machek

On Mon 2017-03-06 12:23:41, Chris Wilson wrote:
> On Mon, Mar 06, 2017 at 01:10:48PM +0100, Pavel Machek wrote:
> > On Mon 2017-03-06 11:15:28, Chris Wilson wrote:
> > > On Mon, Mar 06, 2017 at 12:01:51AM +0100, Pavel Machek wrote:
> > > > Hi!
> > > > 
> > > > > > mplayer stopped working after a while. Dmesg says:
> > > > > > 
> > > > > > [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at
> > > > 
> > > > Now I'm pretty sure it is a regression in v4.11-rc0. Any ideas what to
> > > > try? Bisect will be slow and nasty :-(.
> > > 
> > > I came the conclusion that #99671 is the ring HEAD overtaking the TAIL,
> > > and under the presumption that your bug matches (as the symptoms do):
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> > > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > index 4ffa35faff49..62e31a7438ac 100644
> > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > @@ -782,10 +782,10 @@ static void i9xx_submit_request(struct 
> > > drm_i915_gem_request *request)
> > >  {
> > > struct drm_i915_private *dev_priv = request->i915;
> > >  
> > > -   i915_gem_request_submit(request);
> > > -
> > > GEM_BUG_ON(!IS_ALIGNED(request->tail, 8));
> > > I915_WRITE_TAIL(request->engine, request->tail);
> > > +
> > > +   i915_gem_request_submit(request);
> > >  }
> > >  
> > >  static void i9xx_emit_breadcrumb(struct drm_i915_gem_request *req, u32 
> > > *cs)
> > 
> > I applied it as:
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index 91bc4ab..9c49c7a 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -1338,9 +1338,9 @@ static void i9xx_submit_request(struct 
> > drm_i915_gem_request *request)
> >  {
> > struct drm_i915_private *dev_priv = request->i915;
> >  
> > -   i915_gem_request_submit(request);
> > -
> > I915_WRITE_TAIL(request->engine, request->tail);
> > +
> > +   i915_gem_request_submit(request);
> >  }
> >  
> >  static void i9xx_emit_breadcrumb(struct drm_i915_gem_request *req,
> > 
> > Hmm. But your next mail suggest that it may not be smart to try to
> > boot it? :-).
> 
> Don't bother, it'll promptly hang.

Any news here? 4.11-rc5 is actually usable on the hardware (unlike
-rc1), not sure what changed.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

v4.9-rc3: radeon oops on shutdown

2016-11-07 Thread Pavel Machek

Hi!

On old thinkpad T40p... with v4.9-rc3+ I'm getting radeon oops on
shutdown. Seems repeatable.

Unable to handle kernel NULL pointer dereference at 78c.
IP: .. radeon_connector_unregister
...
trace:
? drm_connector_unregister.part.5
drm_connector_unregister_all

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL:

v4.9-rc3: graphical artefacts in X

2016-11-18 Thread Pavel Machek

Hi!

With v4.9, if I maximize "nowcast -x" application, I get broken
display (as if someone split the window into rectangles and shuffled
them a bit). Switching virtual desktops either fixes it or breaks it,
depending in how fast I switch. (Yes, strange).

pavel at amd:~$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
Integrated Graphics Controller (rev 03)
pavel at amd:~$

Recompile, reboot, and graphics is okay.

(On thinkpad x60, I have seen other strange problems, mostly when I maximize
video, but not as easily reproducible).

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL:

[Intel-gfx] v4.9-rc3: graphical artefacts in X

2016-11-25 Thread Pavel Machek

On Fri 2016-11-18 11:14:16, Chris Wilson wrote:
> On Fri, Nov 18, 2016 at 12:02:56PM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > With v4.9, if I maximize "nowcast -x" application, I get broken
> > display (as if someone split the window into rectangles and shuffled
> > them a bit). Switching virtual desktops either fixes it or breaks it,
> > depending in how fast I switch. (Yes, strange).
> 
> The fix should have landed in v4.9-rc5

Yep, I just tested -rc5, and problem seems gone. Thanks!
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161125/6b145771/attachment.sig>

Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900

2017-07-04 Thread Pavel Machek

Hi!

>  Are you sure it doesn't probe? It fails the omapdss_stack_is_ready()
>  check?
> >>>
> >>> It appears the reason was that I didn't have
> >>> CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV enabled.
> >>>
> >>> I think that's wrong. I don't own an analog TV, so why should I enable
> >>> such option to get device's built-in display working?
> >>
> >> Indeed. Unfortunately I don't have a solution for that.
> >>
> >> DRM doesn't support adding devices after probe. So at omapdrm probe time
> >> we have to decide which displays to use. In the dts file, n900 defines
> >> the lcd and analog tv. omapdrm sees those, and, of course, must wait
> >> until their respective drivers have probed. If you don't have the
> >> display driver enabled, it's never loaded and omapdrm never probes as it
> >> keeps waiting for those.
> > 
> > Could you at least print some kind of message early in the boot ("omapdrm
> > is waiting for drivers for display x and y")?
> 
> That could be quite spammy. omapdrm will defer probe if the displays are
> not present, and the deferred probing machinery will then cause a new
> omapdrm probe later. That can happen a lot of times before the drivers
> are there.

Well doing printk just once should not be a problem...?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

4.11-rc0, thinkpad x220: GPU hang

2017-02-28 Thread Pavel Machek

Hi!

mplayer stopped working after a while. Dmesg says:

[ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at
usb-:00:1d.0-1.2, CDC Ethernet Device, 22:1b:e4:4e:56:f5
[ 3190.767227] [drm] GPU HANG: ecode 6:0:0xbb409fff, in chromium
[4597], reason: Hang on render ring, action: reset
[ 3190.767311] [drm] GPU hangs can indicate a bug anywhere in the
entire gfx stack, including userspace.
[ 3190.767313] [drm] Please file a _new_ bug report on
bugs.freedesktop.org against DRI -> DRM/Intel
[ 3190.767315] [drm] drm/i915 developers can then reassign to the
right component if it's not a kernel issue.
[ 3190.767317] [drm] The gpu crash dump is required to analyze gpu
hangs, so please always attach it.
[ 3190.767320] [drm] GPU crash dump saved to
/sys/class/drm/card0/error
[ 3190.767427] drm/i915: Resetting chip after gpu hang
[ 3228.329384] cdc_ether 2-1.2:1.0 usb0: kevent 12 may have been
dropped
[ 3228.329604] cdc_ether 2-1.2:1.0 usb0: kevent 12 may have been
dropped
[ 3877.246261] perf: interrupt took too long (3142 > 3133), lowering
kernel.perf_event_max_sample_rate to 63500
[ 4802.784478] drm/i915: Resetting chip after gpu hang
[ 4810.784851] drm/i915: Resetting chip after gpu hang
[ 4829.829795] drm/i915: Resetting chip after gpu hang
[ 4837.826154] drm/i915: Resetting chip after gpu hang
[ 5125.026814] [drm:intel_pipe_update_end] *ERROR* Atomic update
failure on pipe A (start=308257 end=308258) time 203 us, min 763, max
767, scanline start 761, end 771
[ 5125.192602] [drm:intel_pipe_update_end] *ERROR* Atomic update
failure on pipe B (start=307385 end=307386) time 204 us, min 1073, max
1079, scanline start 1071, end 1086
[ 5125.309992] [drm:intel_pipe_update_end] *ERROR* Atomic update
failure on pipe A (start=308274 end=308275) time 203 us, min 763, max
767, scanline start 758, end 768
[ 5125.460013] [drm:intel_pipe_update_end] *ERROR* Atomic update
failure on pipe A (start=308283 end=308284) time 204 us, min 763, max
767, scanline start 761, end 771
[ 5125.493340] [drm:intel_pipe_update_end] *ERROR* Atomic update
failure on pipe A (start=308285 end=308286) time 202 us, min 763, max
767, scanline start 761, end 771
[ 5125.526684] [drm:intel_pipe_update_end] *ERROR* Atomic update
failure on pipe A (start=308287 end=308288) time 204 us, min 763, max
767, scanline start 762, end 772
[ 5125.593245] [drm:intel_pipe_update_end] *ERROR* Atomic update
failure on pipe A (start=308291 end=308292) time 203 us, min 763, max
767, scanline start 758, end 768
[ 5125.676636] [drm:intel_pipe_update_end] *ERROR* Atomic update
failure on pipe A (start=308296 end=308297) time 202 us, min 763, max
767, scanline start 762, end 772
[ 5125.709960] [drm:intel_pipe_update_end] *ERROR* Atomic update
failure on pipe A (start=308298 end=308299) time 203 us, min 763, max
767, scanline start 762, end 772
[ 5126.093109] [drm:intel_pipe_update_end] *ERROR* Atomic update
failure on pipe A (start=308321 end=308322) time 204 us, min 763, max
767, scanline start 759, end 770
[ 5647.879171] drm/i915: Resetting chip after gpu hang
[ 5655.879507] drm/i915: Resetting chip after gpu hang
[ 5850.864464] drm/i915: Resetting chip after gpu hang
[ 5858.864853] drm/i915: Resetting chip after gpu hang
[ 5904.850879] drm/i915: Resetting chip after gpu hang
[ 5912.851252] drm/i915: Resetting chip after gpu hang
[ 5949.876973] drm/i915: Resetting chip after gpu hang
[ 5957.877460] drm/i915: Resetting chip after gpu hang
[ 6018.872153] drm/i915: Resetting chip after gpu hang
[ 6030.872646] drm/i915: Resetting chip after gpu hang
[ 7108.362610] perf: interrupt took too long (3935 > 3927), lowering
kernel.perf_event_max_sample_rate to 50750
[ 9670.047072] drm/i915: Resetting chip after gpu hang
[ 9678.047415] drm/i915: Resetting chip after gpu hang
[10408.064806] drm/i915: Resetting chip after gpu hang
[10416.097168] drm/i915: Resetting chip after gpu hang
[10416.097181] [drm:i915_reset] *ERROR* GPU recovery failed
pavel@duo:/data/film$

Umm. Dmesg wants me to attach card0/error, but it looks like it
contains quite a lot of data. If it contains actual framebuffer
content, it may not be wise to post to mailing list

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[regression] Re: 4.11-rc0, thinkpad x220: GPU hang

2017-03-05 Thread Pavel Machek

Hi!

> > mplayer stopped working after a while. Dmesg says:
> > 
> > [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at

Now I'm pretty sure it is a regression in v4.11-rc0. Any ideas what to
try? Bisect will be slow and nasty :-(.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [regression] Re: 4.11-rc0, thinkpad x220: GPU hang

2017-03-06 Thread Pavel Machek

On Mon 2017-03-06 11:15:28, Chris Wilson wrote:
> On Mon, Mar 06, 2017 at 12:01:51AM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > > mplayer stopped working after a while. Dmesg says:
> > > > 
> > > > [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at
> > 
> > Now I'm pretty sure it is a regression in v4.11-rc0. Any ideas what to
> > try? Bisect will be slow and nasty :-(.
> 
> I came the conclusion that #99671 is the ring HEAD overtaking the TAIL,
> and under the presumption that your bug matches (as the symptoms do):
> 
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 4ffa35faff49..62e31a7438ac 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -782,10 +782,10 @@ static void i9xx_submit_request(struct 
> drm_i915_gem_request *request)
>  {
> struct drm_i915_private *dev_priv = request->i915;
>  
> -   i915_gem_request_submit(request);
> -
> GEM_BUG_ON(!IS_ALIGNED(request->tail, 8));
> I915_WRITE_TAIL(request->engine, request->tail);
> +
> +   i915_gem_request_submit(request);
>  }
>  
>  static void i9xx_emit_breadcrumb(struct drm_i915_gem_request *req, u32 *cs)

I applied it as:

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 91bc4ab..9c49c7a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1338,9 +1338,9 @@ static void i9xx_submit_request(struct 
drm_i915_gem_request *request)
 {
struct drm_i915_private *dev_priv = request->i915;
 
-   i915_gem_request_submit(request);
-
I915_WRITE_TAIL(request->engine, request->tail);
+
+   i915_gem_request_submit(request);
 }
 
 static void i9xx_emit_breadcrumb(struct drm_i915_gem_request *req,

Hmm. But your next mail suggest that it may not be smart to try to
boot it? :-).


Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

1 2 3 4 >

1 - 100 of 304 matches

Mail list logo