Add a VCC regulator which needs to be enabled before the EN pin is
released.
Reviewed-by: Sam Ravnborg
Signed-off-by: Alexander Stein
---
.../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/displ
From: Laurent Pinchart
The SN65DSI8x EN signal may be tied to VCC, or otherwise controlled by
means not available to the kernel. Make the GPIO optional.
Signed-off-by: Laurent Pinchart
Signed-off-by: Alexander Stein
---
.../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 1 -
1
The enable signal may not be controllable by the kernel. Make it
optional.
This is a similar to commit bbda1704fc15 ("drm/bridge: ti-sn65dsi86: Make
enable GPIO optional")
Reviewed-by: Laurent Pinchart
Reviewed-by: Sam Ravnborg
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/ti-sn65d
VCC needs to be enabled before releasing the enable GPIO.
Reviewed-by: Sam Ravnborg
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
b/drivers/gpu/drm/bridge/ti
Changes in V3 of this set:
* Do not require vcc-supply in bindings, making it purely optional
* Move regulator enable/disable to sn65dsi83_atomic_pre_enable and
sn65dsi83_atomic_disable
Changes in V2 of this set:
* Add patch from Laurent for fixing the binding regarding optional GPIO
* Reorder p
Hi Marek,
On Tue, Oct 19, 2021 at 12:18:11AM +0200, Marek Vasut wrote:
> On 10/18/21 9:57 PM, Laurent Pinchart wrote:
>
> Hi,
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
https://bugzilla.kernel.org/show_bug.cgi?id=214197
Pablo Cholaky (walterc...@slash.cl) changed:
What|Removed |Added
CC||walterc...@slash.cl
On 18.10.2021 23:13, Andrzej Hajda wrote:
> Beside updating email, the patch updates maintainers
> of Samsung drivers.
>
> Signed-off-by: Andrzej Hajda
> ---
> .mailmap| 1 +
> MAINTAINERS | 13 -
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/.mailmap b/.
In the current implementation, substring comparison
using device node name is used to find mdp node
during driver probe. Use compatible string list instead
of node name to get mdp node from the parent mdss node.
Signed-off-by: Krishna Manikandan
Changes in v2:
- Use compatible lists instead o
On 2021-10-16 07:21, Dmitry Baryshkov wrote:
On Sat, 16 Oct 2021 at 01:25, wrote:
Hi Dmitry
On 2021-10-14 17:11, Dmitry Baryshkov wrote:
> Merge old hdmi_bridge and hdmi_connector implementations. Use
> drm_bridge_connector instead.
>
Can you please comment on the validation done on this chan
First off, sidenote: I wonder if we even need total_avail_slots and
could just use start_slot. Anyway, more productive comments below:
On Mon, 2021-10-18 at 15:47 -0400, Bhawanpreet Lakha wrote:
> I understand the mst_state argument its just that most of the mst
> functions are using mst_mgr/port
On 2021-10-16 15:18, Bjorn Andersson wrote:
The sc8180x has 2 DP and 1 eDP controllers, add support for these to
the
DP driver.
Link:
https://lore.kernel.org/linux-arm-msm/20210725042436.3967173-7-bjorn.anders...@linaro.org/
Signed-off-by: Bjorn Andersson
Reviewed-by: Abhinav Kumar
---
Cha
On 2021-10-16 15:18, Bjorn Andersson wrote:
Based on the removal of the g_dp_display and the movement of the
priv->dp lookup into the DP code it's now possible to have multiple
DP instances.
In line with the other controllers in the MSM driver, introduce a
per-compatible list of base addresses w
On 2021-10-16 15:18, Bjorn Andersson wrote:
eDP panels might need some power sequencing and backlight management,
so make it possible to associate a drm_panel with an eDP instance and
prepare and enable the panel accordingly.
Now that we know which hardware instance is DP and which is eDP,
parse
On 2021-10-16 15:18, Bjorn Andersson wrote:
As the following patches introduced support for multiple DP blocks in a
platform and some of those block might be eDP it becomes useful to be
able to specify the connector type per block.
Although there's only a single block at this point, the array of
On Mon, Oct 18, 2021 at 12:37:30PM -0700, Dan Williams wrote:
> > device-dax uses PUD, along with TTM, they are the only places. I'm not
> > sure TTM is a real place though.
>
> I was setting device-dax aside because it can use Joao's changes to
> get compound-page support.
Ideally, but that ide
Adds the bindings for the Tianma TL057FVXP01 DSI panel,
found on the Motorola Moto G6.
v2:
Fixed accidental whitespace deletion.
Signed-off-by: Julian Braha
---
.../devicetree/bindings/display/panel/panel-simple-dsi.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git
a/Documentation/d
On Sunday, October 17, 2021 1:33:05 PM EDT Sam Ravnborg wrote:
> Hi Julian,
>
> On Sun, Aug 08, 2021 at 04:08:54PM -0400, Julian Braha wrote:
> > This is a 5.7" 2160x1080 panel found on the Motorola Moto G6.
> > There may be other smartphones using it, as well.
> >
> > Signed-off-by: Julian Braha
Adds the bindings for the Tianma TL057FVXP01 DSI panel,
found on the Motorola Moto G6.
Signed-off-by: Julian Braha
---
.../devicetree/bindings/display/panel/panel-simple-dsi.yaml| 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/p
On 10/18/21 9:57 PM, Laurent Pinchart wrote:
Hi,
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
index 1faae3e323a4..708de84ac138 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-
On Mon, Oct 18, 2021 at 10:33 AM Caleb Connolly
wrote:
>
> Hi all,
>
> On 18/10/2021 17:42, John Stultz wrote:
> > On Mon, Oct 18, 2021 at 8:31 AM Rob Clark wrote:
> >>
> >> From: Rob Clark
> >>
> >> Until we better understand the stability issues caused by frequent
> >> frequency changes, lets
Hi Dave & Daniel,
One more fix for v5.15, to work around a power stability issue on a630
(and possibly others)
The following changes since commit c8f01ffc83923a91e8087aaa077de13354a7aa59:
drm/msm/dsi: fix off by one in dsi_bus_clk_enable error handling
(2021-10-11 17:30:54 -0700)
are availabl
Beside updating email, the patch updates maintainers
of Samsung drivers.
Signed-off-by: Andrzej Hajda
---
.mailmap| 1 +
MAINTAINERS | 13 -
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/.mailmap b/.mailmap
index 4f6e37da60589..4283a86f70d26 100644
--- a/.mailma
Hi,
On Sat, Oct 16, 2021 at 9:57 AM Philip Chen wrote:
>
> Conventionally, panel is listed under the root in the device tree.
> When userland asks for display mode, ps8640 bridge is responsible
> for returning EDID when ps8640_bridge_get_edid() is called.
>
> Now enable a new option of listing th
Hi,
On Sat, Oct 16, 2021 at 9:57 AM Philip Chen wrote:
>
> @@ -319,81 +345,70 @@ static void ps8640_bridge_poweron(struct ps8640
> *ps_bridge)
> */
> msleep(200);
>
> - ret = regmap_read_poll_timeout(map, PAGE2_GPIO_H, status,
> - statu
On Mon, Oct 18, 2021 at 11:35:44AM -0700, Umesh Nerlige Ramappa wrote:
On Mon, Oct 18, 2021 at 08:58:01AM +0100, Tvrtko Ursulin wrote:
On 16/10/2021 00:47, Umesh Nerlige Ramappa wrote:
With GuC handling scheduling, i915 is not aware of the time that a
context is scheduled in and out of the en
Hi Marek,
On Mon, Oct 18, 2021 at 09:47:13PM +0200, Marek Vasut wrote:
> On 10/18/21 8:08 PM, Laurent Pinchart wrote:
>
> [...]
>
> >> diff --git
> >> a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> >> b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> >>
On 10/18/21 8:08 PM, Laurent Pinchart wrote:
[...]
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
index 1faae3e323a4..708de84ac138 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvd
I understand the mst_state argument its just that most of the mst
functions are using mst_mgr/port structs and there is no easy way to
extract the mst_state using mgr/port in these places
(drm_dp_update_payload_part1, drm_dp_mst_allocate_vcpi, drm_dp_init_vcpi
etc) where we need the slot info.
On Mon, Oct 18, 2021 at 9:19 AM Markus Schneider-Pargmann
wrote:
>
> Hi Rob,
>
> On Mon, Oct 11, 2021 at 07:43:16PM -0500, Rob Herring wrote:
> > On Mon, Oct 11, 2021 at 11:46:19AM +0200, Markus Schneider-Pargmann wrote:
> > > This controller is present on several mediatek hardware. Currently
> >
On Mon, Oct 18, 2021 at 11:26 AM Jason Gunthorpe wrote:
>
> On Sun, Oct 17, 2021 at 11:35:35AM -0700, Dan Williams wrote:
>
> > > DAX is stuffing arrays of 4k pages into the PUD/PMDs. Aligning with
> > > THP would make using normal refconting much simpler. I looked at
> > > teaching the mm core to
Hi Thomas,
On 10/18/21 3:06 PM, Thomas Zimmermann wrote:
Hi
Am 18.10.21 um 19:41 schrieb Igor Matheus Andrade Torrente:
Hello,
On 10/18/21 7:14 AM, Thomas Zimmermann wrote:
Hi
Am 05.10.21 um 22:16 schrieb Igor Matheus Andrade Torrente:
Currently, the vkms atomic check only goes through the
Hi Pekka,
On 10/18/21 5:30 AM, Pekka Paalanen wrote:
On Tue, 5 Oct 2021 17:16:37 -0300
Igor Matheus Andrade Torrente wrote:
Currently the blend function only accepts XRGB_ and ARGB_
as a color input.
This patch refactors all the functions related to the plane composition
to overcome
On Mon, Oct 18, 2021 at 08:58:01AM +0100, Tvrtko Ursulin wrote:
On 16/10/2021 00:47, Umesh Nerlige Ramappa wrote:
With GuC handling scheduling, i915 is not aware of the time that a
context is scheduled in and out of the engine. Since i915 pmu relies on
this info to provide engine busyness to t
On Mon 18 Oct 11:07 PDT 2021, abhin...@codeaurora.org wrote:
> Hi Bjorn
>
> On 2021-10-17 09:42, Bjorn Andersson wrote:
> > On Fri 15 Oct 16:53 PDT 2021, abhin...@codeaurora.org wrote:
> >
> > > On 2021-10-15 16:17, Bjorn Andersson wrote:
> > > > In the cleanup path of the MSM DP driver the DP d
On Sun, Oct 17, 2021 at 11:35:35AM -0700, Dan Williams wrote:
> > DAX is stuffing arrays of 4k pages into the PUD/PMDs. Aligning with
> > THP would make using normal refconting much simpler. I looked at
> > teaching the mm core to deal with page arrays - it is certainly
> > doable, but it is quite
Hi Thomas,
On 10/18/21 7:02 AM, Thomas Zimmermann wrote:
Hi
Am 05.10.21 um 22:16 schrieb Igor Matheus Andrade Torrente:
The `drm_mode_config_init` was deprecated since c3b790e commit, and it's
being replaced by the `drmm_mode_config_init`.
Signed-off-by: Igor Matheus Andrade Torrente
---
d
Hi Marek,
Thank you for the patch.
On Sun, Oct 17, 2021 at 02:12:03AM +0200, Marek Vasut wrote:
> The OnSemi FIN3385 Parallel-to-LVDS encoder has a dedicated input line to
> select input pixel data sampling edge. Add DT property "pclk-sample", not
> the same as the one used by display timings but
Hi Bjorn
On 2021-10-17 09:42, Bjorn Andersson wrote:
On Fri 15 Oct 16:53 PDT 2021, abhin...@codeaurora.org wrote:
On 2021-10-15 16:17, Bjorn Andersson wrote:
> In the cleanup path of the MSM DP driver the DP driver's debugfs files
> are destroyed by invoking debugfs_remove_recursive() on debug
Hi
Am 18.10.21 um 19:41 schrieb Igor Matheus Andrade Torrente:
Hello,
On 10/18/21 7:14 AM, Thomas Zimmermann wrote:
Hi
Am 05.10.21 um 22:16 schrieb Igor Matheus Andrade Torrente:
Currently, the vkms atomic check only goes through the first position of
the `vkms_wb_formats` vector.
This chan
Add some details around non-LLC platforms and cflushing, when dealing
with the flush-on-acquire, which is potentially security sensitive.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 11
.../gpu/drm/i915/gem/i91
Just like we do for internal objects. Also just use
i915_gem_object_set_cache_coherency() here. No need for over-flushing on
LLC platforms.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 7 ++-
1 file changed, 6 insertions(+), 1 deleti
While the pages can't be swapped out, they can be discarded by the shrinker.
Normally such objects are marked with __I915_MADV_PURGED, which can't be
unset, and therefore requires a new object. For kernel internal objects
this is not true, since the madv hint is reset for our special volatile
objec
Hi pq,
On 10/18/21 4:53 AM, Pekka Paalanen wrote:
On Tue, 5 Oct 2021 17:16:31 -0300
Igor Matheus Andrade Torrente wrote:
XRGB to ARGB behavior
=
During the development, I decided to always fill the alpha channel of
the output pixel whenever the conversion from a format withou
On 10/16/2021 12:35 PM, Dan Carpenter wrote:
On Fri, Oct 15, 2021 at 12:34:20PM -0700, Jessica Zhang wrote:
Hey Dmitry,
On 10/15/2021 11:24 AM, Dmitry Baryshkov wrote:
On Fri, 15 Oct 2021 at 04:43, Jessica Zhang wrote:
Hey Dan,
On 10/1/2021 5:31 AM, Dan Carpenter wrote:
Hello Sean Paul,
On Sun, 17 Oct 2021 02:12:03 +0200, Marek Vasut wrote:
> The OnSemi FIN3385 Parallel-to-LVDS encoder has a dedicated input line to
> select input pixel data sampling edge. Add DT property "pclk-sample", not
> the same as the one used by display timings but rather the same as used by
> media, to def
As pointed out by Thomas, we likely need to flush the pages here if the
GPU can read the page contents directly from main memory. Underneath we
don't know what the sg_table is pointing to, so just add a
wbinvd_on_all_cpus() here, for now.
Reported-by: Thomas Hellström
Signed-off-by: Matthew Auld
Even though userptr objects are always coherent with the GPU, with no
way for userspace to change this with the set_caching ioctl, even on
non-LLC platforms, there is still the 'Bypass LCC' mocs setting, which
might permit reading the contents of main memory directly.
Signed-off-by: Matthew Auld
It looks like we will need this in some more places, so extract as a
helper.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 26 ++
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_shmem.c
On non-LLC platforms, force the flush-on-acquire if this is ever
swapped-in. Our async flush path is not trust worthy enough yet(and
happens in the wrong order), and with some tricks it's conceivable for
userspace to change the cache-level to I915_CACHE_NONE after the pages
are swapped-in, and sinc
These are userspace objects, so mark them as such. In a later patch it's
useful to determine how paranoid we need to be when managing cache
flushes. In theory no functional changes.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 3 ++-
1 file
These are userspace objects, so mark them as such. In a later patch it's
useful to determine how paranoid we need to be when managing cache
flushes. In theory no functional changes.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 3 ++-
1 file c
Hi Maxime,
On Mon, Oct 18, 2021 at 05:20:13PM +0200, Maxime Ripard wrote:
> On Sat, Oct 16, 2021 at 05:34:59AM +0300, Laurent Pinchart wrote:
> > On Thu, Oct 14, 2021 at 09:41:10AM +0200, Maxime Ripard wrote:
> > > On Wed, Oct 13, 2021 at 12:37:47PM +0300, Laurent Pinchart wrote:
> > > > On Wed, O
Hello,
On 10/18/21 7:14 AM, Thomas Zimmermann wrote:
Hi
Am 05.10.21 um 22:16 schrieb Igor Matheus Andrade Torrente:
Currently, the vkms atomic check only goes through the first position of
the `vkms_wb_formats` vector.
This change prepares the atomic_check to check the entire vector.
Signed-
Hi all,
On 18/10/2021 17:42, John Stultz wrote:
On Mon, Oct 18, 2021 at 8:31 AM Rob Clark wrote:
From: Rob Clark
Until we better understand the stability issues caused by frequent
frequency changes, lets limit them to a618.
Signed-off-by: Rob Clark
---
Caleb/John, I think this should help
Am 13.10.21 um 15:38 schrieb Arunpravin:
Move vram related defines and inline functions into
a separate header file
Signed-off-by: Arunpravin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h | 72
1 file changed, 72 insertions(+)
create mode 100644 drivers/gpu/drm/amd/
On Mon, Oct 18, 2021 at 8:31 AM Rob Clark wrote:
>
> From: Rob Clark
>
> Until we better understand the stability issues caused by frequent
> frequency changes, lets limit them to a618.
>
> Signed-off-by: Rob Clark
> ---
> Caleb/John, I think this should help as a workaround for the power
> inst
On Mon, Oct 18, 2021 at 5:34 AM Maxime Ripard wrote:
>
> Hi Rob,
>
> On Wed, Oct 13, 2021 at 05:16:58PM -0700, Rob Clark wrote:
> > On Wed, Oct 13, 2021 at 7:16 AM Maxime Ripard wrote:
> > >
> > > Hi Caleb,
> > >
> > > On Thu, Sep 30, 2021 at 09:20:52PM +0100, Caleb Connolly wrote:
> > > > Hi,
>
From: Rob Clark
Until we better understand the stability issues caused by frequent
frequency changes, lets limit them to a618.
Signed-off-by: Rob Clark
---
Caleb/John, I think this should help as a workaround for the power
instability issues on a630.. could you give it a try?
drivers/gpu/drm/
On Sat, Oct 16, 2021 at 05:34:59AM +0300, Laurent Pinchart wrote:
> On Thu, Oct 14, 2021 at 09:41:10AM +0200, Maxime Ripard wrote:
> > On Wed, Oct 13, 2021 at 12:37:47PM +0300, Laurent Pinchart wrote:
> > > On Wed, Oct 13, 2021 at 09:47:22AM +0200, Maxime Ripard wrote:
> > > > On Tue, Oct 12, 2021
Convert the Toshiba TC358764 txt documentation to YAML.
Signed-off-by: AngeloGioacchino Del Regno
---
Note: dtbs_check on exynos5250-arndale.dts will give some warnings after
applying this patch: since the preferred way is to have 'ports',
this warning was ignored.
I have no Ex
Convert the Toshiba TC358767 txt documentation to YAML.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Rob Herring
---
.../display/bridge/toshiba,tc358767.txt | 54
.../display/bridge/toshiba,tc358767.yaml | 118 ++
2 files changed, 118 insertions(+
From: Benoit Parrot
In preparation to add omap plane state specific extensions we need to
subclass drm_plane_state and add the relevant helpers.
The addition of specific extension will be done separately.
Signed-off-by: Benoit Parrot
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/omapdrm/
From: Benoit Parrot
If the drm_plane has a source width that's greater than the max width
supported by a single hw overlay, then we assign a 'r_overlay' to it in
omap_plane_atomic_check().
Both overlays should have the capabilities required to handle the source
framebuffer. The only parameters t
From: Benoit Parrot
We currently assume that an overlay has the same maximum width and
maximum height as the overlay manager. This assumption is incorrect. On
some variants the overlay manager maximum width is twice the maximum
width that the overlay can handle. We need to add the appropriate dat
From: Benoit Parrot
Global shared resources (like hw overlays) for omapdrm are implemented
as a part of atomic state using the drm_private_obj infrastructure
available in the atomic core.
omap_global_state is introduced as a drm atomic private object. The two
funcs omap_get_global_state() and om
Call drm_atomic_helper_check_plane_state() from the plane
atomic_check() callback in order to add plane state sanity
checking.
It will permit filtering out totally bad scaling factors, even
if the real check are done later in the atomic commit.
Signed-off-by: Benoit Parrot
Signed-off-by: Neil Ar
From: Benoit Parrot
(re)assign the hw overlays to planes based on required caps, and to
handle situations where we could not modify an in-use plane.
This means all planes advertise the superset of formats and properties.
Userspace must (as always) use atomic TEST_ONLY step for atomic updates,
as
From: Benoit Parrot
Now that we added specific item to our subclassed drm_plane_state
we can add omap_plane_atomic_print_state() helper to dump out our own
driver specific plane state.
Signed-off-by: Benoit Parrot
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/omapdrm/omap_plane.c | 16 +++
From: Benoit Parrot
Split out the hardware overlay specifics from omap_plane.
To start, the hw overlays are statically assigned to planes.
The goal is to eventually assign hw overlays dynamically to planes
during plane->atomic_check() based on requested caps (scaling, YUV,
etc). And then perform
From: Benoit Parrot
In order to be able to dynamically assign overlays to planes we need to
be able to asses the overlay capabilities.
Add a helper function to be able to retrieve the supported capabilities
of an overlay.
And export the function to check if a fourcc is supported on a given
over
This patchset is the follow-up the v4 patchset from Benoit Parrot at [1].
This patch series adds virtual-plane support to omapdrm driver to allow the use
of display wider than 2048 pixels.
In order to do so we introduce the concept of hw_overlay which can then be
dynamically allocated to a plane.
https://bugzilla.kernel.org/show_bug.cgi?id=205649
Michael Rauch (mich...@rauch.be) changed:
What|Removed |Added
Summary|Daisy Chain (MST) Session |Daisy Chain (MST) Sessi
https://bugzilla.kernel.org/show_bug.cgi?id=205649
Michael Rauch (mich...@rauch.be) changed:
What|Removed |Added
Kernel Version|5.3, 5.4, 5.5-rc3, 5.9-rc7 |5.3, 5.4, 5.5-rc3, 5.9-
https://bugzilla.kernel.org/show_bug.cgi?id=205649
--- Comment #5 from Michael Rauch (mich...@rauch.be) ---
Created attachment 299241
--> https://bugzilla.kernel.org/attachment.cgi?id=299241&action=edit
error messages with kernel 5.13
I still get errors and kernel freeze.
--
You may reply to
Hi Rob,
On Mon, Oct 11, 2021 at 07:43:16PM -0500, Rob Herring wrote:
> On Mon, Oct 11, 2021 at 11:46:19AM +0200, Markus Schneider-Pargmann wrote:
> > This controller is present on several mediatek hardware. Currently
> > mt8195 and mt8395 have this controller without a functional difference,
> > s
Hi Neil,
Thank you for the patch.
On Fri, Oct 15, 2021 at 04:11:04PM +0200, Neil Armstrong wrote:
> This moves all the non-DW-HDMI code where it should be:
> an encoder in the drm/meson core driver.
>
> The bridge functions are copied as-is, except:
> - the encoder init uses the simple kms helpe
On Wed, Oct 13, 2021 at 04:41:36PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The resume helper is called conditionally and causes a harmless
> warning when stubbed out:
>
> drivers/gpu/drm/tegra/nvdec.c:240:12: error: 'nvdec_runtime_resume' defined
> but not used [-Werror=unused-fun
On Wed, Oct 13, 2021 at 04:40:58PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Without CONFIG_IOMMU_API, the nvdec_writel() function is
> unused, causing a warning:
>
> drivers/gpu/drm/tegra/nvdec.c:48:13: error: 'nvdec_writel' defined but not
> used [-Werror=unused-function]
>48
I got a null-ptr-deref report:
BUG: kernel NULL pointer dereference, address: 0030
...
RIP: 0010:kobject_put+0x2a/0x180
...
Call Trace:
put_device+0x25/0x30
drm_minor_alloc_release.cold+0x45/0x7f [drm]
drm_managed_release+0x158/0x2d0 [drm]
drm_dev_init+0x3a7/0x4a0 [drm]
__devm_drm
On Sun, 17 Oct 2021 16:43:50 +0200, David Heidelberg wrote:
> Conversion of text binding for Adreno GPU to the YAML format.
>
> Signed-off-by: David Heidelberg
> ---
> v2:
> - added compatbile description from Rob Clark
> - dropped reg description
> - reg numbers increased to 3 (since we al
From: Thomas Zimmermann
commit b693e42921e0220c0d564c55c6cdc680b0f85390 upstream.
Clamp the fbdev surface size of the available maximumi height to avoid
failing to init console emulation. An example error is shown below.
bad framebuffer height 2304, should be >= 768 && <= 768
[drm] Initiali
Am 12.10.21 um 14:09 schrieb Gal Pressman:
The pin callback does not necessarily have to move the memory to system
memory, remove the sentence from the comment.
Signed-off-by: Gal Pressman
Reviewed-by: Christian König
---
include/linux/dma-buf.h | 4 ++--
1 file changed, 2 insertions(+)
Am So., 10. Okt. 2021 um 16:08 Uhr schrieb Christophe JAILLET
:
>
> 'destroy_workqueue()' already drains the queue before destroying it, so
> there is no need to flush it explicitly.
>
> Remove the redundant 'flush_workqueue()' calls.
>
> This was generated with coccinelle:
>
> @@
> expression E;
>
Hi Rob,
On Wed, Oct 13, 2021 at 05:16:58PM -0700, Rob Clark wrote:
> On Wed, Oct 13, 2021 at 7:16 AM Maxime Ripard wrote:
> >
> > Hi Caleb,
> >
> > On Thu, Sep 30, 2021 at 09:20:52PM +0100, Caleb Connolly wrote:
> > > Hi,
> > >
> > > On 30/09/2021 20:49, Amit Pundir wrote:
> > > > On Thu, 30 Sept
On Fri, Oct 15, 2021 at 10:40 AM Thomas Zimmermann wrote:
>
> struct gtt_range represents a GEM object and should not be used for GTT
> setup. Change psb_gtt_insert() and psb_gtt_remove() to receive all
> necessary parameters from their caller. This also eliminates possible
> failure from psb_gtt_
On Fri, Oct 15, 2021 at 10:40 AM Thomas Zimmermann wrote:
>
> psb_gtt_alloc_range() allocates struct gtt_range, create the GTT resource
> and performs some half-baked initialization. Inline the function into its
> only caller psb_gem_create(). For creating the GTT resource, introduce a
> new helpe
Hi luo,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20211015]
url:
https://github.com/0day-ci/linux/commits/luo-penghao/drm-i915-display-Remove-unused-variable-in-the-for-loop/20211018-164557
base:7c832d2f9b959e3181370c8b0dacaf9efe13fc05
config
Hello Joerg,
On Mon, 18 Oct 2021 12:25:38 +0200
Joerg Roedel wrote:
> On Fri, Oct 01, 2021 at 04:34:23PM +0200, Boris Brezillon wrote:
> > +/*
> > + * Mapping is only accessed by the device behind the iommu. That means
> > other
> > + * devices or CPUs are not expected to access this physical m
Hi Christian,
On Mon, Oct 18, 2021 at 1:41 PM Christian König
wrote:
> Am 18.10.21 um 13:38 schrieb Geert Uytterhoeven:
> > On Mon, Oct 18, 2021 at 1:37 PM Christian König
> > wrote:
> >> Am 13.10.21 um 16:42 schrieb Arnd Bergmann:
> >>> From: Arnd Bergmann
> >>>
> >>> When CONFIG_COMMON_CLOCK
Am 18.10.21 um 13:46 schrieb Arnd Bergmann:
On Mon, Oct 18, 2021 at 1:40 PM Christian König
wrote:
I have absolutely no idea how a platform can have IOMMU but no MMU
support but it indeed seems to be the case here.
Huh?
Parisc has config MMU def_bool y?
Then why vmap isn't available?
See th
On Mon, Oct 18, 2021 at 1:40 PM Christian König
wrote:
> >> I have absolutely no idea how a platform can have IOMMU but no MMU
> >> support but it indeed seems to be the case here.
> > Huh?
> >
> > Parisc has config MMU def_bool y?
>
> Then why vmap isn't available?
>
> See the mail thread: [linux
Hi Christian,
On Mon, Oct 18, 2021 at 1:37 PM Christian König
wrote:
> Am 13.10.21 um 16:42 schrieb Arnd Bergmann:
> > From: Arnd Bergmann
> >
> > When CONFIG_COMMON_CLOCK is disabled, the 8996 specific
> > phy code is left out, which results in a link failure:
> >
> > ld: drivers/gpu/drm/msm/hd
Am 18.10.21 um 13:38 schrieb Geert Uytterhoeven:
Hi Christian,
On Mon, Oct 18, 2021 at 1:37 PM Christian König
wrote:
Am 13.10.21 um 16:42 schrieb Arnd Bergmann:
From: Arnd Bergmann
When CONFIG_COMMON_CLOCK is disabled, the 8996 specific
phy code is left out, which results in a link failure
Am 13.10.21 um 16:42 schrieb Arnd Bergmann:
From: Arnd Bergmann
When CONFIG_COMMON_CLOCK is disabled, the 8996 specific
phy code is left out, which results in a link failure:
ld: drivers/gpu/drm/msm/hdmi/hdmi_phy.o:(.rodata+0x3f0): undefined reference to
`msm_hdmi_phy_8996_cfg'
This was only
This patch fixes the following Coccinelle warning:
drivers/gpu/drm/nouveau/nouveau_gem.c:630: WARNING opportunity for vmemdup_user
Use vmemdup_user rather than duplicating its implementation
This is a little bit restricted to reduce false positives
Signed-off-by: Qing Wang
---
drivers/gpu/drm/
This patch fixes the following Coccinelle warning:
drivers/gpu/drm/tegra/submit.c:173: WARNING opportunity for vmemdup_user
Use vmemdup_user rather than duplicating its implementation
This is a little bit restricted to reduce false positives
Signed-off-by: Qing Wang
---
drivers/gpu/drm
Am 15.10.21 um 13:57 schrieb Maarten Lankhorst:
Commit ada5c48b11a3 ("dma-buf: use new iterator in dma_resv_wait_timeout")
accidentally started mishandling timeout = 0, by forcing a blocking wait
with timeout = 1 passed to fences. This is not intended, as timeout = 0
may be used for peeking, simi
Op 14-10-2021 om 15:56 schreef Tvrtko Ursulin:
>
> On 14/10/2021 14:45, Maarten Lankhorst wrote:
>> Op 14-10-2021 om 15:25 schreef Tvrtko Ursulin:
>>>
>>> On 14/10/2021 13:05, Maarten Lankhorst wrote:
Op 14-10-2021 om 10:37 schreef Tvrtko Ursulin:
>
> On 13/10/2021 11:41, Maarten Lankh
On Fri, Oct 01, 2021 at 04:34:23PM +0200, Boris Brezillon wrote:
> +/*
> + * Mapping is only accessed by the device behind the iommu. That means other
> + * devices or CPUs are not expected to access this physical memory region,
> + * and the MMU driver can safely restrict the shareability domain t
1 - 100 of 149 matches
Mail list logo
