Hi David,
On 27/11/2022 11:35, David Hildenbrand wrote:
> On 16.11.22 11:26, David Hildenbrand wrote:
>> FOLL_FORCE is really only for ptrace access. According to commit
>> 707947247e95 ("media: videobuf2-vmalloc: get_userptr: buffers are always
>> writable"), get_vaddr_frames() currently pins all
On 28.11.22 09:17, Hans Verkuil wrote:
Hi David,
On 27/11/2022 11:35, David Hildenbrand wrote:
On 16.11.22 11:26, David Hildenbrand wrote:
FOLL_FORCE is really only for ptrace access. According to commit
707947247e95 ("media: videobuf2-vmalloc: get_userptr: buffers are always
writable"), get_v
The underline length for the new Analog TV properties section doesn't
match the title length, resulting in a warning.
Fixes: 7d63cd8526f1 ("drm/connector: Add TV standard property")
Reported-by: kernel test robot
Signed-off-by: Maxime Ripard
---
Documentation/gpu/drm-kms.rst | 2 +-
1 file chan
The mode name in struct drm_cmdline_mode can hold 32 characters at most,
which can easily get overrun. Switch to strscpy() to prevent such a
thing.
Reported-by: coverity-bot
Addresses-Coverity-ID: 1527354 ("Security best practices violations")
Fixes: a7ab155397dd ("drm/modes: Switch to named mode
drm_kunit_device_init() is a public function meant to be used by other
tests, but isn't exported. This leads to modpost errors when the other
tests are compiled as module.
Reported-by: kernel test robot
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_kunit_helpers.c | 1 +
1 file cha
Hi,
On Fri, Nov 25, 2022 at 09:31:09PM +0100, Geert Uytterhoeven wrote:
> From: Thomas Zimmermann
>
> The mode fix-up function for simple display helpers is equivalent to the
> regular pipeline's CRTC mode fix-up function. It's called to adjust the
> CRTC's display mode for the encoder. Add this
On 28/11/2022 09:18, David Hildenbrand wrote:
> On 28.11.22 09:17, Hans Verkuil wrote:
>> Hi David,
>>
>> On 27/11/2022 11:35, David Hildenbrand wrote:
>>> On 16.11.22 11:26, David Hildenbrand wrote:
FOLL_FORCE is really only for ptrace access. According to commit
707947247e95 ("media: vi
Hi,
On Fri, Nov 25, 2022 at 09:31:10PM +0100, Geert Uytterhoeven wrote:
> +// FIXME create dynamically from atari_drm_modes[]?
Not necessarily, but they should have proper descriptors at the very least.
> +static const struct drm_named_mode atari_drm_named_modes[] =
> +{
> + { .name = "st-lo
On 21/11/2022 10:42, Carlo Caione wrote:
This patchset is trying to fix problems seen on S905X boards when interfacing
with an ILI9486 equipped SPI panel.
Gentle ping on this 2-patch set.
Cheers,
--
Carlo Caione
https://bugzilla.kernel.org/show_bug.cgi?id=216745
--- Comment #6 from Eric Zou (e...@outlook.com) ---
Hi Thorsten
Thanks for your attention. I will give you an update here:
I tried rc7 asap it was out as tarball. rc7 contains code changes that I
mentioned in https://gitlab.freedesktop.org/drm/am
On Mon, Nov 28, 2022 at 5:19 PM David Hildenbrand wrote:
>
> On 28.11.22 09:17, Hans Verkuil wrote:
> > Hi David,
> >
> > On 27/11/2022 11:35, David Hildenbrand wrote:
> >> On 16.11.22 11:26, David Hildenbrand wrote:
> >>> FOLL_FORCE is really only for ptrace access. According to commit
> >>> 7079
Hello,
On 17.11.22 08:11, ye.xingc...@zte.com.cn wrote:
> From: ye xingchen
>
> Replace the open-code with device_match_of_node().
device_match_of_node() exists so a pointer to the function can be passed
to class/driver_find_device. I see no reason to call it directly.
I don't think you should
On 11/25/2022 5:54 AM, Ville Syrjälä wrote:
On Thu, Nov 10, 2022 at 04:56:51PM -0800, Daniele Ceraolo Spurio wrote:
The fence is always initialized in huc_init_early, but the cleanup in
huc_fini is only being run if HuC is enabled. This causes a leaking of
the debug object when HuC is disable
On Fri, 25 Nov 2022 14:52:01 -0300
André Almeida wrote:
> This patchset adds a udev event for DRM device's resets.
Hi,
this seems a good idea to me.
> Userspace apps can trigger GPU resets by misuse of graphical APIs or driver
> bugs. Either way, the GPU reset might lead the system to a broken
On Fri, 25 Nov 2022 14:52:02 -0300
André Almeida wrote:
> From: Shashank Sharma
>
> Add a sysfs event to notify userspace about GPU resets providing:
> - PID that triggered the GPU reset, if any. Resets can happen from
> kernel threads as well, in that case no PID is provided
> - Information
The PID is racy, the user-space daemon could end up killing an
unrelated process… Is there any way we could use a pidfd instead?
On 25/11/2022 22:30, Andi Shyti wrote:
From: Chris Wilson
Introduce the concept of padding the i915_vma with guard pages before
and after. The major consequence is that all ordinary uses of i915_vma
must use i915_vma_offset/i915_vma_size and not i915_vma.node.start/size
directly, as the drm_m
On 25/11/2022 22:30, Andi Shyti wrote:
Chris commit "drm/i915: Introduce guard pages to i915_vma" was
"cunningly" changing display_alignment to u32 from u64. The
reason is that the display GGTT is and will be limited o 4GB.
Put it in a separate patch and use "max(...)" instead of
"max_t(64, ..
On 11/28/22 05:19, Maxime Ripard wrote:
> drm_kunit_device_init() is a public function meant to be used by other
> tests, but isn't exported. This leads to modpost errors when the other
> tests are compiled as module.
>
> Reported-by: kernel test robot
> Signed-off-by: Maxime Ripard
Reviewed-by
On Wed, 23 Nov 2022 16:25:52 +0100, Maxime Ripard wrote:
> On the vc4 devices (and later), the blending is done by a single device
> called the HVS. The HVS has three FIFO that can operate in parallel, and
> route their output to 6 CRTCs and 7 encoders on the BCM2711.
>
> Each of these CRTCs and e
On Wed, 23 Nov 2022 16:25:51 +0100, Maxime Ripard wrote:
> The drm_atomic_get_(old|new)_*_state don't modify the passed
> drm_atomic_state, so we can make it const.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Thu, 24 Nov 2022 09:51:13 +0800, Shang XiaoJing wrote:
> Commit f0601ef8631c ("drm/vc4: vec: Protect device resources after
> removal") add fail path for vc4_vec_encoder_enable(), and will put
> usage_counter only when pm_runtime_get_sync() succeeds. However,
> pm_runtime_get_sync() will increme
On Wed, 23 Nov 2022 16:25:56 +0100, Maxime Ripard wrote:
> The current order of variable assignments is unneccessarily complex,
> let's make it simpler.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Wed, 23 Nov 2022 16:25:53 +0100, Maxime Ripard wrote:
> None of our wrappers around container_of to access our objects from the
> DRM object pointer actually modify the latter.
>
> Let's make them const.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Wed, 23 Nov 2022 16:25:58 +0100, Maxime Ripard wrote:
> It makes more sense to register the CRTC before the encoder and
> connectors, so let's move our call around.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Wed, 23 Nov 2022 16:25:55 +0100, Maxime Ripard wrote:
> The vc4_hvs_get_(old|new)_global_state functions don't modify the
> drm_atomic_state passed as an argument, so let's make it const.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Wed, 23 Nov 2022 16:25:57 +0100, Maxime Ripard wrote:
> The TXP is integrated as a separate CRTC/Encoder/Connector combo, but
> for some reason doesn't rely on the vc4_encoder type and it's associated
> type.
>
> Let's create a type to make it consistent with the other encoders.
>
>
> [...]
On Wed, 23 Nov 2022 16:26:02 +0100, Maxime Ripard wrote:
> It's fairly hard to figure out the instance of the CRTC affected by an
> atomic change using the default name.
>
> Since we can provide our own to the CRTC initialization functions, let's
> do so to make the debugging sessions easier.
>
>
On Wed, 23 Nov 2022 16:25:59 +0100, Maxime Ripard wrote:
> Both users of vc4_crtc_init need the same extra initialization to set
> the pointer to the platform_device and the CRTC data. Since it's
> mandatory, let's make them both arguments of vc4_crtc_init().
>
>
Applied to drm/drm-misc (drm-mis
On 23/11/2022 22:03, Dmitry Baryshkov wrote:
> Add DPU and MDSS schemas to describe MDSS and DPU blocks on the Qualcomm
> SM8450 platform.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> .../bindings/display/msm/qcom,sm8450-dpu.yaml | 139 +++
> .../display/msm/qcom,sm8450-mdss.yaml | 34
Hi,
This series adds support for the Verisilicon VIPNano-QI NPU in the A311D
as in the VIM3 board.
The IP is very closeley based on previous Vivante GPUs, so the etnaviv
kernel driver works basically unchanged.
The userspace part of the driver is being reviewed at:
https://gitlab.freedesktop.or
This is a compute-only module marketed towards AI and vision
acceleration. This particular version can be found on the Amlogic A311D
SoC.
The feature bits are taken from the Khadas downstream kernel driver
6.4.4.3.310723AAA.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
Hi
Am 25.11.22 um 18:48 schrieb Noralf Trønnes:
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
Introduce struct drm_mipi_dbi_plane_state that contains state related to
MIPI DBI. It currently only inherits from struct drm_shadow_plane_state,
so that MIPI DBI drivers can use the vmap'ed GEM-buf
Den 28.11.2022 13.10, skrev Thomas Zimmermann:
> Hi
>
> Am 25.11.22 um 18:48 schrieb Noralf Trønnes:
>>
>>
>> Den 21.11.2022 11.45, skrev Thomas Zimmermann:
>>> Introduce struct drm_mipi_dbi_plane_state that contains state related to
>>> MIPI DBI. It currently only inherits from struct drm_shad
Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> Use the buffer mappings provided by shadow-plane helpers. As the
> mappings are established while the commit can still fail, errors
> are now reported correctly to callers.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Noralf Trønnes
Hi Thomas,
On Sat, Nov 26, 2022 at 3:51 PM Thomas Zimmermann wrote:
> that's an interesting driver. I left a few comments below.
Thanks for your comments!
> Am 25.11.22 um 21:31 schrieb Geert Uytterhoeven:
> > Supported formats:
> >- C[1248],
> >- RG16 (both standard DRM (little-endian)
On Mon, Nov 28, 2022 at 01:10:58AM -0800, Ceraolo Spurio, Daniele wrote:
>
>
> On 11/25/2022 5:54 AM, Ville Syrjälä wrote:
> > On Thu, Nov 10, 2022 at 04:56:51PM -0800, Daniele Ceraolo Spurio wrote:
> >> The fence is always initialized in huc_init_early, but the cleanup in
> >> huc_fini is only b
Il 25/11/22 17:34, Nícolas F. R. A. Prado ha scritto:
On Wed, Nov 23, 2022 at 10:15:25AM +0100, AngeloGioacchino Del Regno wrote:
Il 22/11/22 15:39, Nícolas F. R. A. Prado ha scritto:
mtk_drm_bind() can fail, in which case drm_dev_put() is called,
destroying the drm_device object. However a poi
The code 'b' is used for dma-buf IOCTLs.
Signed-off-by: Simon Ser
Cc: Linus Torvalds
Cc: Daniel Vetter
Cc: Christian König
Cc: Sumit Semwal
---
Documentation/userspace-api/ioctl/ioctl-number.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/userspace-api/ioctl/ioctl-numbe
,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut wrote:
>
> On 11/23/22 21:09, Jagan Teki wrote:
> > On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut wrote:
> >>
> >> On 11/17/22 14:04, Marek Szyprowski wrote:
> >>> On 17.11.2022 05:58, Marek Vasut wrote:
> On 11/10/22 19:38, Jagan Teki wrote:
>
On Mon, Nov 28, 2022 at 9:31 AM Mikhail Krylov wrote:
>
> On Mon, Apr 25, 2022 at 01:22:04PM -0400, Alex Deucher wrote:
> > + dri-devel
> >
> > On Mon, Apr 25, 2022 at 3:33 AM Krylov Michael wrote:
> > >
> > > Hello!
> > >
> > > After updating my Linux kernel from version 4.19 (Debian 10 version)
On Wed, Nov 09, 2022 at 11:37:34PM +0800, Dawei Li wrote:
> pin_user_pages() is unsafe without protection of mmap_lock,
> fix it by calling pin_user_pages_fast().
>
> Fixes: 7a7a933edd6c ("drm/vmwgfx: Introduce VMware mks-guest-stats")
> Signed-off-by: Dawei Li
> ---
> v1:
> https://lore.kernel.o
Hi,
This series introduce Kunit tests to the vc4 KMS driver, but unlike what we
have been doing so far in KMS, it actually tests the atomic modesetting code.
In order to do so, I've had to improve a fair bit on the Kunit helpers already
found in the tree in order to register a full blown and some
Commit 44a3928324e9 ("drm/tests: Add Kunit Helpers") introduced the
drm_kunit_device_init() function but didn't document it properly. Add
that documentation.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_kunit_helpers.c | 17 +
1 file changed, 17 insertions(+)
diff
We'll need to use those helpers from drivers too, so let's move it to a
more visible location.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_client_modeset_test.c| 3 +--
drivers/gpu/drm/tests/drm_kunit_helpers.c | 3 +--
drivers/gpu/drm/tests/drm_modes_
The name doesn't really fit the conventions for the other helpers in
DRM/KMS, so let's rename it to make it obvious that we allocate a new
DRM device.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_client_modeset_test.c | 3 ++-
drivers/gpu/drm/tests/drm_kunit_helpers.c | 8 +++
The device name isn't really useful, we can just define it instead of
exposing it in the API.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_client_modeset_test.c | 3 +--
drivers/gpu/drm/tests/drm_kunit_helpers.c | 7 ---
drivers/gpu/drm/tests/drm_modes_test.c | 3
The device managed resources are ran if the device has bus, which is not
the case of a root_device.
Let's use a platform_device instead.
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_kunit_helpers.c | 16 ++--
1 file changed, 14 in
We'll need in some tests to control when the device needs to be added
and removed, so let's split the device creation from the DRM device
creation function.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_client_modeset_test.c | 14 ++-
drivers/gpu/drm/tests/drm_kunit_helpers.c
The current helper to allocate a DRM device doesn't allow for any
subclassing by drivers, which is going to be troublesome as we work on
getting some kunit testing on atomic modesetting code.
Let's use a similar pattern to the other allocation helpers by providing
the structure size and offset as
We'll need a function that looks up an encoder by its vc4_encoder_type.
Such a function is already present in the CRTC code, so let's make it
public so that we can reuse it in the unit tests.
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c |
The device managed resources are freed when the device is detached, so
it has to be bound in the first place.
Let's create a fake driver that we will bind to our fake device to
benefit from the device managed cleanups in our tests.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_kuni
Accessing a register when running under kunit is a bad idea since our
device is completely mocked.
Fail the current test if we ever access any of our hardware registers.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 13 +++--
drivers/gpu/drm/vc4/vc4_dpi.c
We'll need to initialize the HVS structure without a backing device to
create a mock we'll use for testing.
Split the structure initialization part into a separate function.
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.h | 1 +
drivers/gpu
In order to test the current atomic_check hooks we need to have a DRM
device that has roughly the same capabilities and layout that the actual
hardware. We'll also need a bunch of functions to create arbitrary
atomic states.
Let's create some helpers to create a device that behaves like the real
o
Some tests will need to provide their own drm_driver instead of relying
on the dumb one in the helpers, so let's create a helper that allows to
do so.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_kunit_helpers.c | 15 +++--
include/drm/drm_kunit_helpers.h | 51 +++
The current vc4_crtc_init() helper assumes that we will be using
hardware planes and calls vc4_plane_init().
While it's a reasonable assumption, we'll want to mock the plane and
thus provide our own. Let's create a helper that will take the plane as
an argument.
Reviewed-by: Javier Martinez Canil
In order to introduce unit tests for the HVS state computation, we'll
need access to the vc4_hvs_state struct definition and its associated
helpers.
Let's move them in our driver header.
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.h | 23 +
The HVS to PixelValve muxing code is fairly error prone and has a bunch
of arbitrary constraints due to the hardware setup.
Let's create a test suite that makes sure that the possible combinations
work and the invalid ones don't.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/Makefile
DRM-managed actions are supposed to be ran whenever the device is
released. Let's introduce a basic unit test to make sure it happens.
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/Makefile | 1 +
drivers/gpu/drm/tests/drm_managed_test.c
Tegra20 and other Tegra SoCs have a video input (VI) peripheral that can
receive from either MIPI CSI-2 or parallel video (called respectively "CSI"
and "VIP" in the documentation). The kernel currently has a staging driver
for Tegra210 CSI capture. This patch set adds support for Tegra20 VIP
captu
The Tegra20 VI peripheral can receive parallel input from the VIP parallel
input module. Add it to the allowed properties and augment the existing
nvidia,tegra20-vi example to show a 'vip' property.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Luca Ceresoli
---
Changed in v2 (suggested by K
VIP is the parallel video capture component within the video input
subsystem of Tegra20 (and other Tegra chips, apparently).
Signed-off-by: Luca Ceresoli
---
Changed in v2 (suggested by Krzysztof Kozlowski):
- remove redundant "bindings" from subject line
- remove $nodename
- add channel@0 desc
Add "skip" in "so we can *skip* the current channel" or it doesn't make
sense.
Also add articles where appropriate to fix English grammar.
Signed-off-by: Luca Ceresoli
---
No changes in v2
---
drivers/staging/media/tegra-video/vi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Some fields are irrelevant for Tegra20/VIP. Add a note to clarify that.
Signed-off-by: Luca Ceresoli
---
No changes in v2
---
drivers/staging/media/tegra-video/vi.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/tegra-video/vi.h
b/drivers/stagi
Clarify what this function does.
Signed-off-by: Luca Ceresoli
---
No changes in v2
---
drivers/staging/media/tegra-video/vi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/media/tegra-video/vi.c
b/drivers/staging/media/tegra-video/vi.c
index 0fe3c7f6d234..8a7512ce2273
tegra_channel_fmt_align() takes care of the size constraints, alignment and
rounding requirements of the Tegra210 VI peripheral. Tegra20 has different
constraints.
In preparation for adding Tegra20 support, move this function to a new op
in the soc-specific `struct tegra_vi_ops` .
Also move to te
The .vidioc_enum_fmt_vid_cap (called tegra_channel_enum_format() here)
should return all the supported formats. Instead the current implementation
computes the intersection between the formats it supports and those
supported by the first subdev in the stream (typically the image sensor).
Remove al
of_node_put(node) does nothing if node == NULL, so it can be moved to the
cleanup section at the bottom.
Signed-off-by: Luca Ceresoli
---
No changes in v2
---
drivers/staging/media/tegra-video/vi.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/medi
struct tegra_vi_graph_entity is an internal implementation detail of the VI
module. Move its declaration from vi.h to vi.c.
Signed-off-by: Luca Ceresoli
---
No changes in v2
---
drivers/staging/media/tegra-video/vi.c | 13 +
drivers/staging/media/tegra-video/vi.h | 13 -
Tegra20 supports planar YUV422 capture, which can be implemented by writing
U and V base address registers in addition to the "main" base buffer
address register.
It also supports H and V flip, which among others requires to write the
start address (i.e. the 1st offset to write, at the end of the
The Tegra20 VI needs an additional operation to enable the VI, add an
operation for that.
Signed-off-by: Luca Ceresoli
---
No changes in v2
---
drivers/staging/media/tegra-video/vi.c | 7 +++
drivers/staging/media/tegra-video/vi.h | 4
2 files changed, 11 insertions(+)
diff --git a/d
The VI peripheral of Tegra supports capturing from MIPI CSI-2 or parallel
video (called VIP in the docs). MIPI CSI-2 is already implemented. Add a
VIP implementation.
Signed-off-by: Luca Ceresoli
---
No changes in v2
---
MAINTAINERS| 1 +
drivers/staging/media
tegra_channel_host1x_syncpt_init() gets the host1x syncpts needed for the
Tegra210 implementation, and tegra_channel_host1x_syncpts_free() puts
them.
Tegra20 needs to get and put a different syncpt. In preparation for adding
Tegra20 support, move these functions to new ops in the soc-specific
`str
We are about to add support for the Tegra20 parallel video capture, which
has no TPG. In preparation for that, limit the VIDEO_TEGRA_TPG option to
Tegra210 which is the only implementation currently provided by this
driver.
Signed-off-by: Luca Ceresoli
---
No changes in v2
---
drivers/staging/
Tegra20 can do horizontal and vertical image flip, but Tegra210 cannot
(either the hardware, or this driver).
In preparation to adding Tegra20 support, add a flag in struct tegra_vi_soc
so the generic vi.c code knows whether the flip controls should be added or
not.
Also provide a generic impleme
The tegra_default_format in vi.c is specific to Tegra210 CSI.
In preparation for adding Tegra20 VIP support, move the default format to a
new field in the soc-specific `struct tegra_vi_soc`. Instead of an entire
format struct, only store a pointer to an item in the existing format
array.
No funct
The CSI module does not handle all the MIPI lane calibration procedure,
leaving a small part of it to the VI module. In doing this,
tegra_channel_enable_stream() (vi.c) manipulates the private data of the
upstream subdev casting it to struct 'tegra_csi_channel', which will be
wrong after introducin
The staging tegra-video driver currently implements MIPI CSI-2 video
capture for Tegra210. Add support for parallel video capture (VIP) on
Tegra20. With the generalizations added to the VI driver in previous
commits, this is only a matter of adding the tegra20.c implementation and
registering it.
There is only a pointer reference to struct tegra_vi in video.h, thus vi.h
is not needed.
Signed-off-by: Luca Ceresoli
---
No changes in v2
---
drivers/staging/media/tegra-video/video.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/media/tegra-video/video.h
b/drivers/stag
In preparation to implement Tegra20 parallel video capture, add variables
to hold the required syncpt.
Signed-off-by: Luca Ceresoli
---
No changes in v2
---
drivers/staging/media/tegra-video/vi.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/
tegra_vi_channels_alloc() can primarily fail for two reasons:
1. "ports" node not found
2. port_num > vi->soc->vi_max_channels
Case 1 prints nothing, case 2 has a dev_err(). The caller [tegra_vi_init()]
has a generic dev_err() on any failure. This mean that in case 2 we print
two messages, and
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: 0ae41323a83233610e64e926eefb4d132ecb9028
commit: 1e4a91db109f623d0e3ef7d8bfae3c88b4d2fa87 [12/19] drm/probe-helper:
Provide a TV get_modes helper
config: hexagon-randconfig-r041-20221128
compiler: clang version 16.0.0 (https
On Mon, Nov 28, 2022 at 2:18 AM Demi Marie Obenour
wrote:
>
> Dear Christian:
>
> What is the status of the AMDGPU work for Xen dom0? That was mentioned in
> https://lore.kernel.org/dri-devel/b2dec9b3-03a7-e7ac-306e-1da024af8...@amd.com/
> and there have been bug reports to Qubes OS about problem
The Google Pixel C has a JDI LPM102A188A display panel. Add a
DT node for it. Tested on Pixel C.
Signed-off-by: Diogo Ivo
---
Changes in v2:
- renamed backlight node to a generic name
- removed underscores
arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 70 +++
1 file changed,
In cases where the DSI module is left on by the bootloader
some panels may fail to initialize if the enable register is not cleared
before the panel's initialization sequence is sent, so clear it if that
is the case.
Signed-off-by: Diogo Ivo
---
Changes in v2:
- detect if the DSI module is on b
Hello,
These patches add support for the JDI LPM102A188A display panel,
found in the Google Pixel C.
Patch 1 adds the DT bindings for the panel (omitted in RESEND).
Patch 2 adds a register clear to the Tegra DSI driver, needed for the
panel initialization commands to be properly sent.
Patch 3 a
The JDI LPM102A188A is a 2560x1800 IPS panel found in the Google Pixel C.
This driver is based on the downstream GPLv2 driver released by Google
written by Sean Paul [1], which was then adapted to the newer kernel APIs.
[1]:
https://android.googlesource.com/kernel/tegra/+/refs/heads/android-tegra
On 11/28/2022 5:08 AM, Ville Syrjälä wrote:
On Mon, Nov 28, 2022 at 01:10:58AM -0800, Ceraolo Spurio, Daniele wrote:
On 11/25/2022 5:54 AM, Ville Syrjälä wrote:
On Thu, Nov 10, 2022 at 04:56:51PM -0800, Daniele Ceraolo Spurio wrote:
The fence is always initialized in huc_init_early, but th
Hi Dave & Daniel,
Here are the gpu/gem bits for v6.2. Dmitry already sent a separate
pull request[1] for the display bits. Summary below and in tag.
[1]
https://patchwork.kernel.org/project/dri-devel/patch/20221126102141.721353-1-dmitry.barysh...@linaro.org/
The following changes since commit
On Mon, Sep 12, 2022 at 11:15:05AM +0200, Uwe Kleine-König wrote:
> While working on a drm driver that doesn't need the i2c algobit stuff I
> noticed that DRM selects this code even tough only 8 drivers actually use
> it. While also only some drivers use i2c, keep the select for I2C for the
> next
Hello Uwe,
Thanks for your patch.
On 9/12/22 11:15, Uwe Kleine-König wrote:
> While working on a drm driver that doesn't need the i2c algobit stuff I
> noticed that DRM selects this code even tough only 8 drivers actually use
> it. While also only some drivers use i2c, keep the select for I2C for
Hi Xinhui,
On 11/28/2022 12:04 PM, xinhui pan wrote:
Currently drm-buddy does not have full knowledge of continuous memory.
Lets consider scenario below.
order 1:L R
order 0: LL LR RL RR
for order 1 allocation, it can offer L or R or LR+RL.
For now, we only impl
Hello,
On Wed, Nov 16, 2022 at 11:21:31AM -0600, Rob Herring wrote:
> On Thu, Nov 10, 2022 at 10:49:45AM +0100, Uwe Kleine-König wrote:
> > This is a straight forward conversion. Note that fsl,imx-lcdc was picked
> > as the new name as this is the compatible that should supersede the
> > legacy fb
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 15f2f20ccbf2d04cb14e3e7635aa0447208c71e7 Add linux-next specific
files for 20221128
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202211041320.coq8eelj-...@intel.com
https
From: Tetsuo Handa
[ Upstream commit a6a00d7e8ffd78d1cdb7a43f1278f081038c638f ]
A kernel built with syzbot's config file reported that
scr_memcpyw(q, save, array3_size(logo_lines, new_cols, 2))
causes uninitialized "save" to be copied.
--
[drm] Initialized vgem 1.0.0 20120112 fo
From: Dillon Varone
[ Upstream commit dd2c028c1395d622df7ddd6837f8ab2dc94008ee ]
[WHY?]
MALL allocation size depends on the viewport height, not the addressable
vertical lines, which will not match when scaling.
[HOW?]
Base MALL allocation size calculations off viewport height.
Reviewed-by: Al
From: Taimur Hassan
[ Upstream commit 2a5dd86a69ea5435f1a837bdb7fafcda609a7c91 ]
[Why]
Pixel rate divider values should never be set to N/A (0xF) as the K1/K2
field is only 1/2 bits wide.
[How]
Set valid divider values for virtual and FRL/DP2 cases.
Reviewed-by: Nicholas Kazlauskas
Acked-by:
From: "Stanley.Yang"
[ Upstream commit 3cb93f390453cde4d6afda1587aaa00e75e09617 ]
[Why]
[ 754.862560] refcount_t: underflow; use-after-free.
[ 754.862898] Call Trace:
[ 754.862903]
[ 754.862913] amdgpu_job_free_cb+0xc2/0xe1 [amdgpu]
[ 754.863543] drm_sched_main.cold+
1 - 100 of 169 matches
Mail list logo
