Hi
Am 08.11.19 um 13:06 schrieb Böszörményi Zoltán:
> Hi!
>
> 2019. 11. 08. 8:36 keltezéssel, Thomas Zimmermann írta:
>> Hi Böszörményi
>
> FYI, it's Zoltan, as it's my first name. :-)
Sorry.
>
>> Am 07.11.19 um 16:10 schrieb Böszörményi Zoltán:
>> Have you tried to increase the buffer size?
Hi!
2019. 11. 08. 8:36 keltezéssel, Thomas Zimmermann írta:
Hi Böszörményi
FYI, it's Zoltan, as it's my first name. :-)
Am 07.11.19 um 16:10 schrieb Böszörményi Zoltán:
Have you tried to increase the buffer size? There's a command-line
option to control this setting. [1]
Yes, I did, it did
Hi Böszörményi
Am 07.11.19 um 16:10 schrieb Böszörményi Zoltán:
> Hi,
>
> 2019. 11. 07. 10:43 keltezéssel, Thomas Zimmermann írta:
>> Udl's GEM implementation is mostly SHMEM and we should attempt to
>> replace it with the latter.
>>
>> Patches #1 and #2 update udl to simplify the conversion. In
2019. 11. 07. 16:10 keltezéssel, Böszörményi Zoltán írta:
what's the trick to actually enable the UDL device?
With 5.3.8, 5.3.9 or 5.4-rc6 + drm-next and this patchset, I get this:
[long messages]
I didn't mention that the system is 32-bit, using a PAE kernel.
Is it a problem for swiotlb?
The
Hi,
2019. 11. 07. 10:43 keltezéssel, Thomas Zimmermann írta:
Udl's GEM implementation is mostly SHMEM and we should attempt to
replace it with the latter.
Patches #1 and #2 update udl to simplify the conversion. In patch #3
the udl code is being replaced by SHMEM. The GEM object's mmap() and
fr
Udl's GEM implementation is mostly SHMEM and we should attempt to
replace it with the latter.
Patches #1 and #2 update udl to simplify the conversion. In patch #3
the udl code is being replaced by SHMEM. The GEM object's mmap() and
free_object() functions are wrappers around their SHMEM counterpar
