On 2021/3/19 11:54, Viresh Kumar wrote:
On 18-03-21, 15:52, Arnd Bergmann wrote:
Allowing multiple virtio-i2c controllers in one system, and multiple i2c
devices attached to each controller is clearly something that has to work.
Good.
I don't actually see a limitation though. Viresh, what
On 2021-03-16 19:16, Jean-Philippe Brucker wrote:
The ACPI Virtual I/O Translation Table describes topology of
para-virtual platforms. For now it describes the relation between
virtio-iommu and the endpoints it manages. Supporting that requires
three steps:
(1) acpi_viot_init(): parse the VIOT
On Tue, Mar 16, 2021 at 08:16:54PM +0100, Jean-Philippe Brucker wrote:
> With the VIOT support in place, x86 platforms can now use the
> virtio-iommu.
>
> The arm64 Kconfig selects IOMMU_DMA, while x86 IOMMU drivers select it
> themselves.
>
> Signed-off-by: Jean-Philippe Brucker
Acked-by:
The pull request you sent on Thu, 18 Mar 2021 14:11:35 -0400:
> https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/bf152b0b41dc141c8d32eb6e974408f5804f4d00
Thank you!
--
Deet-doot-dot, I am a
The following changes since commit 16c10bede8b3d8594279752bf53153491f3f944f:
virtio-input: add multi-touch support (2021-02-23 07:52:59 -0500)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
for you to fetch changes up to
On Wed, Mar 17, 2021 at 8:45 AM Stefan Hajnoczi wrote:
>
> On Tue, Mar 16, 2021 at 09:56:44PM +, jiang.wang wrote:
> > Add supports for datagram type for virtio-vsock. Datagram
> > sockets are connectionless and unreliable. To avoid contention
> > with stream and other sockets, add two more
Hi Jean,
On 3/16/21 8:16 PM, Jean-Philippe Brucker wrote:
> Just here for reference, don't merge!
>
> The actual commits will be pulled from the next ACPICA release.
> I squashed the three relevant commits:
>
> ACPICA commit fc4e33319c1ee08f20f5c44853dd8426643f6dfd
> ACPICA commit
On Thu, Mar 18, 2021 at 3:42 PM Enrico Weigelt, metux IT consult
wrote:
>
> On 16.03.21 08:44, Viresh Kumar wrote:
>
> > FWIW, this limits this driver to support a single device ever. We
> > can't bind multiple devices to this driver now. Yeah, perhaps we will
> > never be required to do so, but
On Wed, Mar 17, 2021 at 01:12:01PM -0500, Connor Kuehl wrote:
> Hi,
>
> I've been familiarizing myself with the virtiofs guest kernel module and I'm
> trying to better understand how virtiofs maps a FUSE request into
> scattergather lists.
>
> sg_count_fuse_req() starts knowing that there will
On 2021-03-16 19:16, Jean-Philippe Brucker wrote:
With the VIOT support in place, x86 platforms can now use the
virtio-iommu.
The arm64 Kconfig selects IOMMU_DMA, while x86 IOMMU drivers select it
themselves.
Actually, now that both AMD and Intel are converted over, maybe it's
finally time
Hi
Am 18.03.21 um 11:39 schrieb Geert Uytterhoeven:
Hi Thomas,
On Thu, Mar 18, 2021 at 11:29 AM Thomas Zimmermann wrote:
Make sure required hardware clocks are enabled while the firmware
framebuffer is in use.
The basic code has been taken from the simplefb driver and adapted
to DRM. Clocks
On Tue, Mar 16, 2021 at 08:16:54PM +0100, Jean-Philippe Brucker wrote:
> With the VIOT support in place, x86 platforms can now use the
> virtio-iommu.
>
> The arm64 Kconfig selects IOMMU_DMA, while x86 IOMMU drivers select it
> themselves.
>
> Signed-off-by: Jean-Philippe Brucker
> ---
>
Hi Thomas,
On Thu, Mar 18, 2021 at 11:29 AM Thomas Zimmermann wrote:
> Make sure required hardware clocks are enabled while the firmware
> framebuffer is in use.
>
> The basic code has been taken from the simplefb driver and adapted
> to DRM. Clocks are released automatically via devres helpers.
Make sure required hardware clocks are enabled while the firmware
framebuffer is in use.
The basic code has been taken from the simplefb driver and adapted
to DRM. Clocks are released automatically via devres helpers.
Signed-off-by: Thomas Zimmermann
Tested-by: nerdopolis
---
The simpledrm driver is a DRM driver for simplefb framebuffers as
provided by the kernel's boot code. This driver enables basic
graphical output on many different graphics devices that are provided
by the platform (e.g., EFI, VESA, embedded framebuffers).
With the kernel's simplefb
We register the simplekms device with the DRM platform helpers. A
native driver for the graphics hardware will kick-out the simpledrm
driver before taking over the device.
v2:
* adapt to aperture changes
* use drm_dev_unplug() and drm_dev_enter/exit()
* don't split error
A firmware framebuffer might also be specified via device-tree files. If
no device platform data is given, try the DT device node.
v2:
* add Device Tree match table
* clean-up parser wrappers
Signed-off-by: Thomas Zimmermann
Tested-by: nerdopolis
---
Make sure required hardware regulators are enabled while the firmware
framebuffer is in use.
The basic code has been taken from the simplefb driver and adapted
to DRM. Regulators are released automatically via devres helpers.
v2:
* use strscpy()
Signed-off-by: Thomas Zimmermann
Platform devices might operate on firmware framebuffers, such as VESA or
EFI. Before a native driver for the graphics hardware can take over the
device, it has to remove any platform driver that operates on the firmware
framebuffer. Aperture helpers provide the infrastructure for platform
drivers
This displays a console on simpledrm's framebuffer. The default
framebuffer format is being used.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Tested-by: nerdopolis
---
drivers/gpu/drm/tiny/simpledrm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
Fbdev's helpers for handling conflicting framebuffers are related to
framebuffer apertures, not console emulation. Therefore move them into a
drm_aperture.h, which will contain the interfaces for the new aperture
helpers.
Signed-off-by: Thomas Zimmermann
Tested-by: nerdopolis
---
The blitter functions copy a framebuffer to I/O memory using one of
the existing conversion functions.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Tested-by: nerdopolis
---
drivers/gpu/drm/drm_format_helper.c | 87 +
include/drm/drm_format_helper.h
The memcpy's destination buffer might have a different pitch than the
source. Support different pitches as function argument.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Tested-by: nerdopolis
---
drivers/gpu/drm/drm_format_helper.c| 9 +
This patchset adds support for simple-framebuffer platform devices and
a handover mechanism for native drivers to take-over control of the
hardware.
The new driver, called simpledrm, binds to a simple-frambuffer platform
device. The kernel's boot code creates such devices for firmware-provided
在 2021/3/18 下午5:18, Eugenio Perez Martin 写道:
On Thu, Mar 18, 2021 at 4:11 AM Jason Wang wrote:
在 2021/3/18 上午12:47, Eugenio Perez Martin 写道:
On Wed, Mar 17, 2021 at 3:05 AM Jason Wang wrote:
在 2021/3/16 下午6:31, Eugenio Perez Martin 写道:
On Tue, Mar 16, 2021 at 8:18 AM Jason Wang wrote:
On Wed, Mar 17, 2021 at 01:57:15PM +0800, Jiapeng Chong wrote:
> Fix the following coccicheck warnings:
>
> ./drivers/net/virtio_net.c:1551:2-5: WARNING: Use BUG_ON instead of if
> condition followed by BUG.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
> ---
>
26 matches
Mail list logo
