Hi, Thomas:
On Thu, 2020-03-05 at 16:59 +0100, Thomas Zimmermann wrote:
> The mediatak driver uses empty implementations for its encoders. Replace
> the code with the generic simple encoder.
>
Acked-by: CK Hu
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 14
On Mon, Mar 09, 2020 at 07:49:15PM +0800, Christian König wrote:
> Pierre-eric, just a gentle ping on this? Could I get a tested-by?
>
> Ray can you ack or even review this?
>
> Thanks,
> Christian.
>
> Am 06.03.20 um 13:41 schrieb Christian König:
> > The assert sometimes incorrectly triggers w
If there's a 3D context available, initialize the fence using
the 3D context's fence context.
We can't process just the largest fence id anymore, since it's
not the same as the sequence number now.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 15 ---
d
We don't want fences from different 3D contexts/processes (GL, VK) to
be on the same timeline. Sending this out as a RFC to solicit feedback
on the general approach.
Gurchetan Singh (8):
drm/virtio: use fence_id when processing fences
drm/virtio: allocate a fence context for every 3D context
We don't want fences from different 3D contexts (GL, VK) to
be on the same timeline.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm/virtio/virtgpu_kms.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/d
We signal the fences ourselves in virtio_gpu_fence_event_process,
shortly after we set last_fence_id. The window of time is small
enough such that it may be possible to return false in this optional
callback and rely on DMA_FENCE_FLAG_SIGNALED_BIT.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/
Each fence should be associated with a [fence ID, context ID,
seqno].
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm/virtio/virtgpu_fence.c | 5 +++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_d
Currently, the fence ID, which can be used to identify a
virtgpu fence, is the same as the fence sequence number.
They could be the same, but not necessarily so. Let's differentiate
them.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +-
drivers/gpu/drm/virtio/vi
To be clearer about our intentions to differentiate per-context
sequence numbers and fence IDs, let's rename these variables.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 4 ++--
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
drivers/gpu/drm/virtio/virtgpu_fe
We'll need it when initiating a dma-fence.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
drivers/gpu/drm/virtio/virtgpu_fence.c | 3 ++-
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 9 +
drivers/gpu/drm/virtio/virtgpu_plane.c | 2 +-
4 files changed, 10
This change:
- Lookups virtgpu_fence given a fence_id
- Signals all prior fences in a given context
- Signals current fence
No functional changes yet, since all fences are initialized from
context 0.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_fence
In Pete Goodliffe words, "You can improve a system by adding new code. You
can also improve a system by removing code" - In this case, commit
"202b52b7fbf70" added new code to initialize end of the node. So, there
is no need for duplicated initialization, and this patch simply removes it.
Signed-o
Quoting Enric Balletbo Serra (2020-03-06 14:09:50)
> Missatge de Stephen Boyd del dia dv., 6 de mar
> 2020 a les 22:37:
> >
> > Quoting Enric Balletbo i Serra (2020-03-06 08:30:16)
> > > On 5/3/20 22:01, Stephen Boyd wrote:
> > > > Quoting Enric Balletbo i Serra (2020-03-02 03:01:26)
> > > >> diff
Hi Prabhakar
On Mon, Mar 09, 2020 at 09:23:24PM +, Lad, Prabhakar wrote:
> Hi Rob,
>
> On Mon, Mar 9, 2020 at 8:32 PM Rob Herring wrote:
> >
> > On Fri, 6 Mar 2020 15:20:31 +, Lad Prabhakar wrote:
> > > From: Fabrizio Castro
> > >
> > > Add binding for the idk-2121wr LVDS panel from Ad
Hi Ville,
On Mon, Mar 09, 2020 at 11:22:51PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 09, 2020 at 10:29:42PM +0200, Laurent Pinchart wrote:
> > On Mon, Mar 09, 2020 at 08:45:41PM +0100, Sam Ravnborg wrote:
> > > On Mon, Mar 09, 2020 at 09:01:27PM +0200, Laurent Pinchart wrote:
> > > > On Mon, Mar
This patch adds defines for the detailed monitor
range flags as per the EDID specification.
v2:
* Rename the flags with DRM_EDID_ (Jani N)
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Clinton A Taylor
Cc: Kazlauskas Nicholas
Cc: Jani Nikula
Signed-off-by: Manasi Nava
Adaptive Sync is a VESA feature so add a DRM core helper to parse
the EDID's detailed descritors to obtain the adaptive sync monitor range.
Store this info as part fo drm_display_info so it can be used
across all drivers.
This part of the code is stripped out of amdgpu's function
amdgpu_dm_update_f
On Mon, Mar 09, 2020 at 10:29:42PM +0200, Laurent Pinchart wrote:
> Hi Sam,
>
> On Mon, Mar 09, 2020 at 08:45:41PM +0100, Sam Ravnborg wrote:
> > On Mon, Mar 09, 2020 at 09:01:27PM +0200, Laurent Pinchart wrote:
> > > On Mon, Mar 09, 2020 at 08:00:47PM +0100, Sam Ravnborg wrote:
> > > > On Mon, Ma
On Mon, Mar 9, 2020 at 5:01 PM Lyude Paul wrote:
>
> Sigh, this is mostly my fault for not giving commit cd82d82cbc04
> ("drm/dp_mst: Add branch bandwidth validation to MST atomic check")
> enough scrutiny during review. The way we're checking bandwidth
> limitations here is mostly wrong:
>
> For
On Fri, Mar 6, 2020 at 6:46 PM Lyude Paul wrote:
>
> It's already prefixed by dp_mst, so we don't really need to repeat
> ourselves here. One of the changes I should have picked up originally
> when reviewing MST DSC support.
>
> There should be no functional changes here
>
> Cc: Mikita Lipski
>
On Fri, Mar 6, 2020 at 6:49 PM Lyude Paul wrote:
>
> While fixing some regressions caused by introducing bandwidth checking
> into the DP MST atomic helpers, I realized there was another much more
> subtle regression that got introduced by a seemingly harmless patch to
> fix unused variable errors
Sigh, this is mostly my fault for not giving commit cd82d82cbc04
("drm/dp_mst: Add branch bandwidth validation to MST atomic check")
enough scrutiny during review. The way we're checking bandwidth
limitations here is mostly wrong:
For starters, drm_dp_mst_atomic_check_bw_limit() determines the
pbn
Hi Boris,
On Mon, Mar 09, 2020 at 09:42:44PM +0100, Boris Brezillon wrote:
> On Mon, 9 Mar 2020 22:32:11 +0200 Laurent Pinchart wrote:
> > On Mon, Mar 09, 2020 at 09:22:18PM +0100, Boris Brezillon wrote:
> >> On Mon, 9 Mar 2020 21:59:26 +0200 Laurent Pinchart wrote:
> >>> On Mon, Mar 09, 2020 at
On Mon, 9 Mar 2020 22:32:11 +0200
Laurent Pinchart wrote:
> Hi Boris,
>
> On Mon, Mar 09, 2020 at 09:22:18PM +0100, Boris Brezillon wrote:
> > On Mon, 9 Mar 2020 21:59:26 +0200 Laurent Pinchart wrote:
> > > On Mon, Mar 09, 2020 at 08:55:59PM +0100, Boris Brezillon wrote:
> > > > On Mon, 9 Ma
On Mon, Mar 9, 2020 at 4:27 PM Lyude Paul wrote:
>
> On Sat, 2020-03-07 at 14:00 +0530, Pankaj Bharadiya wrote:
> > drm_dp_mst_topology_mgr_cbs.register_connector callbacks are identical
> > amongst every driver and don't do anything other than calling
> > drm_connector_register().
> > drm_dp_mst_
The TFP410 supports configuration through I2C (in which case the
corresponding DT node is a child of an I2C controller) or through pins
(in which case the DT node creates a platform device). When I2C access
to the device is available, read and validate the device ID at probe
time to ensure that the
On Mon, Mar 09, 2020 at 10:35:52AM +0200, Jani Nikula wrote:
> On Fri, 06 Mar 2020, Manasi Navare wrote:
> > On Fri, Mar 06, 2020 at 12:30:46PM +0200, Jani Nikula wrote:
> >> On Thu, 05 Mar 2020, Manasi Navare wrote:
> >> > This patch adds defines for the detailed monitor
> >> > range flags as pe
On Fri, 6 Mar 2020 15:20:31 +, Lad Prabhakar wrote:
> From: Fabrizio Castro
>
> Add binding for the idk-2121wr LVDS panel from Advantech.
>
> Some panel-specific documentation can be found here:
> https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.h
Hi Boris,
On Mon, Mar 09, 2020 at 09:22:18PM +0100, Boris Brezillon wrote:
> On Mon, 9 Mar 2020 21:59:26 +0200 Laurent Pinchart wrote:
> > On Mon, Mar 09, 2020 at 08:55:59PM +0100, Boris Brezillon wrote:
> > > On Mon, 9 Mar 2020 21:23:06 +0200 Laurent Pinchart wrote:
> > > > On Mon, Mar 09, 2020
Hi Sam,
On Mon, Mar 09, 2020 at 08:45:41PM +0100, Sam Ravnborg wrote:
> On Mon, Mar 09, 2020 at 09:01:27PM +0200, Laurent Pinchart wrote:
> > On Mon, Mar 09, 2020 at 08:00:47PM +0100, Sam Ravnborg wrote:
> > > On Mon, Mar 09, 2020 at 08:42:10PM +0200, Laurent Pinchart wrote:
> > > > The OrtusTech
On Sat, 2020-03-07 at 14:00 +0530, Pankaj Bharadiya wrote:
> drm_dp_mst_topology_mgr_cbs.register_connector callbacks are identical
> amongst every driver and don't do anything other than calling
> drm_connector_register().
> drm_dp_mst_topology_mgr_cbs.destroy_connector callbacks are identical
> a
On Mon, 9 Mar 2020 21:59:26 +0200
Laurent Pinchart wrote:
> Hi Boris,
>
> On Mon, Mar 09, 2020 at 08:55:59PM +0100, Boris Brezillon wrote:
> > On Mon, 9 Mar 2020 21:23:06 +0200 Laurent Pinchart wrote:
> > > On Mon, Mar 09, 2020 at 11:50:59AM +0100, Philipp Zabel wrote:
> > > > On Thu, 2019-1
Hi Boris,
On Mon, Mar 09, 2020 at 08:55:59PM +0100, Boris Brezillon wrote:
> On Mon, 9 Mar 2020 21:23:06 +0200 Laurent Pinchart wrote:
> > On Mon, Mar 09, 2020 at 11:50:59AM +0100, Philipp Zabel wrote:
> > > On Thu, 2019-11-14 at 14:17 +0100, Marek Vasut wrote:
> > > > The bus_flags and bus_form
On Mon, 9 Mar 2020 21:23:06 +0200
Laurent Pinchart wrote:
> On Mon, Mar 09, 2020 at 11:50:59AM +0100, Philipp Zabel wrote:
> > On Thu, 2019-11-14 at 14:17 +0100, Marek Vasut wrote:
> > > The bus_flags and bus_format handling logic does not seem to cover
> > > all potential usecases. Specificall
A fair number of includes are not needed. Drop them, and add a couple of
required includes that were included indirectly.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 12 +++-
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 5 -
2 files changed, 3 insertions(+), 14
mxsfb_regs.h defines macros related to register bits. Some of them are
not used and don't clearly map to any particular register, so their
purpose isn't known. Remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/mxsfb_regs.h | 8
1 file changed, 8 deletions(-)
diff -
Enable vblank handling when the CRTC is turned on and disable it when it
is turned off. This requires moving vblank init after the KMS pipeline
initialisation, otherwise drm_vblank_init() gets called with 0 CRTCs.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 15 +++
The mxsfb_set_pixel_fmt() function returns an error when the selected
pixel format is unsupported. This can never happen, as such errors are
caught by the DRM core. Remove the error check.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 11 ++-
1 file changed, 2 i
Extend the Kconfig option description by listing the i.MX7 SoCs, as they
are supported by the same driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxs
Hello,
This patch series adds i.MX7 support to the mxsfb driver. The eLCDIF
instance found in the i.MX7 is backward-compatible with the already
supported LCDC v4, but has extended features amongst which the most
notable one is a second plane.
The first 9 patches (01/21 to 09/21) contain miscellan
The debug0 and ipversion fields of the mxsfb_devdata structure are
unused. Remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 2 --
2 files changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/dri
Replace the convoluted way to set the format and bus width through
difficult to read macros with more explicit ones. Also remove the
outdated comment related to the limitations on bus width setting as it
doesn't apply anymore (the bus width can be specified through the
display_info bus format).
Si
The DRM simple display pipeline helper only supports a single plane. In
order to prepare for support of the alpha plane on i.MX6SX and i.MX7,
move away from the helper. No new feature is added.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 184 +
The mxsfb_crtc.c file doesn't handle just the CRTC, but also the other
KMS objects. Rename it accordingly.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/Makefile | 2 +-
drivers/gpu/drm/mxsfb/{mxsfb_crtc.c => mxsfb_kms.c} | 0
2 files changed, 1 insertion(+), 1 d
The LCDC_CTRL register is located at address 0x. Some of the
accesses to the register simply use the mxsfb->base address. Reference
the LCDC_CTRL register explicitly instead to clarify the code.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 8
1 file chang
The mxsfb driver is only used by OF platforms. Drop non-OF support.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 25 +++--
1 file changed, 7 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsf
The vblank event is armed in the plane .atomic_update(). This works fine
as we have a single plane, but will break as soon as multiple planes are
supported (not to mention it's logically the wrong place to perform the
operation). Move it to CRTC .atomic_flush().
Signed-off-by: Laurent Pinchart
--
Replace the manual connector implementation based on drm_panel with the
drm_panel_bridge helper. This simplifies the mxsfb driver by removing
connector-related code, and standardizing all pipeline control
operations on bridges.
A hack is needed to get hold of the connector, as that's our only sour
The driver attempts agressive power management by enabling and disabling
the AXI clock around register accesses. This results in attempts to
enable and disable the clock in the IRQ handler, which is a no-go as
preparing or unpreparing the clock may sleep.
On the other hand, the driver enables the
The mxsfb_set_pixel_fmt() and mxsfb_set_bus_fmt() functions both deal
with format configuration, are always called in a row from
mxsfb_crtc_mode_set_nofb(), and set fields from the LCDC_CTRL register.
This requires a read-modify-update cycle in mxsfb_set_bus_fmt(). Make
this more efficient by mergi
The mxsfb_reset_block() function isn't special, pass it the
mxsfb_drm_private pointer instead of a pointer to the base address.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/
Using BIT() is preferred over manual shifts as it's more readable,
handles the 1 << 31 case properly, and avoids other mistakes as shown by
the DEBUG0_HSYNC and DEBUG0_VSYNC bits (that are currently unused). Use
it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/mxsfb_regs.h | 56
The LCDIF in the i.MX6SX and i.MX7 have a second plane called the alpha
plane. Support it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 3 +
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 16 ++--
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 129 +
driver
mxsfb_crtc.c defines several macros related to register addresses and
bit, which duplicates macros from mxsfb_regs.h. Use the macros from
mxsfb_regs.h instead and remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 14 +-
1 file changed, 5 insertions
Commit 8e93f1028d74 ("drm/mxsfb: Use drm_fbdev_generic_setup()")
replaced fbdev handling with drm_fbdev_generic_setup() but left
inclusion of the drm/drm_fb_cma_helper.h header. Remove it.
Fixes: 8e93f1028d74 ("drm/mxsfb: Use drm_fbdev_generic_setup()")
Signed-off-by: Laurent Pinchart
---
driver
The LCDIF present in the i.MX6SX has extra features compared to
the i.MX28. It has however lost its IP version register, so no official
version number is known. Bump the version to MXSFB_V6 following the i.MX
version, in preparation for support for the additional features.
Signed-off-by: Laurent P
On Mon, Mar 9, 2020 at 4:18 AM Brian Masney wrote:
>
> The sram property was incorrectly added to the GMU binding when it
> really belongs with the GPU binding instead. Let's go ahead and
> move it.
>
> While changes are being made here, let's update the sram property
> description to mention that
On Mon, Mar 09, 2020 at 09:01:27PM +0200, Laurent Pinchart wrote:
> Hi Sam,
>
> On Mon, Mar 09, 2020 at 08:00:47PM +0100, Sam Ravnborg wrote:
> > On Mon, Mar 09, 2020 at 08:42:10PM +0200, Laurent Pinchart wrote:
> > > The OrtusTech COM43H4M85ULC is a DPI panel, set the connector type
> > > accordi
Hi Philipp,
(CC'ing Boris)
On Mon, Mar 09, 2020 at 11:50:59AM +0100, Philipp Zabel wrote:
> On Thu, 2019-11-14 at 14:17 +0100, Marek Vasut wrote:
> > The bus_flags and bus_format handling logic does not seem to cover
> > all potential usecases. Specifically, this seems to fail with an
> > "edt,et
Hi Sam,
On Mon, Mar 09, 2020 at 08:00:47PM +0100, Sam Ravnborg wrote:
> On Mon, Mar 09, 2020 at 08:42:10PM +0200, Laurent Pinchart wrote:
> > The OrtusTech COM43H4M85ULC is a DPI panel, set the connector type
> > accordingly.
> >
> > Signed-off-by: Laurent Pinchart
>
> Reviewed-by: Sam Ravnborg
Hi Laurent.
On Mon, Mar 09, 2020 at 08:42:10PM +0200, Laurent Pinchart wrote:
> The OrtusTech COM43H4M85ULC is a DPI panel, set the connector type
> accordingly.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Sam Ravnborg
I assume you will apply to drm-misc-next - OK?
Sam
> ---
>
Hi Phong.
On Mon, Mar 09, 2020 at 04:36:54PM +0100, Phong LE wrote:
> This commit is a simple driver for bridge HMDI it66121.
> The input format is RBG and there is no color conversion.
> Audio, HDCP and CEC are not supported yet.
Nice driver. Some few comments below.
Patch fails to apply/build
The TFP410 supports configuration through I2C (in which case the
corresponding DT node is a child of an I2C controller) or through pins
(in which case the DT node creates a platform device). When I2C access
to the device is available, read and validate the device ID at probe
time to ensure that the
The OrtusTech COM43H4M85ULC is a DPI panel, set the connector type
accordingly.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index e14c14ac
On Mon, 9 Mar 2020 at 13:13, Emil Velikov wrote:
> > OTOH, if applications exist that rely on drop-master failing in this
> > specific case, making drop-master succeed would break them. That might
> > include a buggy set-master path that was written, but does not actually
> > work because it was
On Fri, 6 Mar 2020 17:06:00 +0530, Krishna Manikandan wrote:
> MSM Mobile Display Subsytem(MDSS) encapsulates sub-blocks
> like DPU display controller, DSI etc. Add YAML schema
> for the device tree bindings for the same.
>
> Signed-off-by: Krishna Manikandan
> ---
> .../bindings/display/msm/dp
Hi Phong.
On Mon, Mar 09, 2020 at 04:36:53PM +0100, Phong LE wrote:
> Add the ITE bridge HDMI it66121 bindings.
Good to see that you used DT Schema.
>
> Signed-off-by: Phong LE
> ---
> .../bindings/display/bridge/ite,it66121.yaml | 95 +++
> 1 file changed, 95 insertions(+)
>
Hi Phong.
On Mon, Mar 09, 2020 at 04:36:52PM +0100, Phong LE wrote:
> Add ITE Tech Inc. prefix "ite" in vendor-prefixes
Maybe add to the changelog that their domain is http://www.ite.com.tw/?
>
> Signed-off-by: Phong LE
Acked-by: Sam Ravnborg
> ---
> Documentation/devicetree/bindings/vendor-
Hi,
On Mon, Mar 09, 2020 at 10:53:04AM +0530, Harigovindan P wrote:
> Add support for Visionox panel driver.
>
> Signed-off-by: Harigovindan P
> ---
>
> Changes in v2:
> - Dropping redundant space in Kconfig(Sam Ravnborg).
> - Changing structure for include files(Sam Ravnborg).
>
Am 05.03.20 um 16:54 schrieb Jason Ekstrand:
On Thu, Mar 5, 2020 at 7:06 AM Christian König wrote:
[SNIP]
Well as far as I can see this won't work because it would break the
semantics of the timeline sync.
I'm not 100% convinced it has to. We already have support for the
seqno regressing and
On Mon, Mar 9, 2020 at 2:38 PM Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> The listed dotclocks are two orders of mangnitude out.
> Fix them.
>
> v2: Just divide everything by 100 (Linus)
>
> Cc: Linus Walleij
> Cc: Thierry Reding
> Signed-off-by: Ville Syrjälä
Reviewed-by: Linus Walleij
On Mon, Mar 9, 2020 at 2:36 PM Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> The dotclock is three orders of magnitude out. Fix it.
>
> v2: Just set it to 20MHz (Linus)
>
> Cc: Linus Walleij
> Cc: Sam Ravnborg
> Signed-off-by: Ville Syrjälä
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
The GMU has very few memory allocations and uses a flat memory space so
there is no good reason to go out of our way to bypass the DMA APIs which
were basically designed for this exact scenario.
v4: Use dma_alloc_wc()
v3: Set the dma mask correctly and use dma_addr_t for the iova type
v2: Pass for
Convert display/msm/gmu.txt to display/msm/gmu.yaml and remove the old
text bindings.
Acked-by: Sam Ravnborg
Reviewed-by: Rob Herring
Signed-off-by: Jordan Crouse
---
.../devicetree/bindings/display/msm/gmu.txt| 65 ---
.../devicetree/bindings/display/msm/gmu.yaml | 12
When CONFIG_INIT_ON_ALLOC_DEFAULT_ON the GMU memory allocator runs afoul of
cache coherency issues because it is mapped as write-combine without clearing
the cache after it was zeroed.
Rather than duplicate the hacky workaround we use in the GEM allocator for the
same reason it turns out that we d
On Mon, Mar 09, 2020 at 07:18:04AM -0400, Brian Masney wrote:
> The sram property was incorrectly added to the GMU binding when it
> really belongs with the GPU binding instead. Let's go ahead and
> move it.
>
> While changes are being made here, let's update the sram property
> description to men
On 09/03/2020 13:41, Lukasz Luba wrote:
> Register devfreq cooling device and attempt to register Energy Model. This
> will add the devfreq device to the Energy Model framework. It will create
> a dedicated and unified data structures used i.e. in thermal framework.
> The last NULL parameter indica
From: Ville Syrjälä
The listed dotclocks are two orders of mangnitude out.
Fix them.
v2: Just divide everything by 100 (Linus)
Cc: Linus Walleij
Cc: Thierry Reding
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 14 +++---
1 file changed, 7 insertions
From: Ville Syrjälä
The dotclock is three orders of magnitude out. Fix it.
v2: Just set it to 20MHz (Linus)
Cc: Linus Walleij
Cc: Sam Ravnborg
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/panel/panel-novatek-nt35510.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/d
On Fri, Mar 06, 2020 at 09:02:57AM +0100, Marco Felsch wrote:
> On 20-03-03 16:52, Ville Syrjälä wrote:
> > On Tue, Mar 03, 2020 at 08:33:20AM +0100, Marco Felsch wrote:
> > > Hi Ville,
> > >
> > > On 20-03-02 22:34, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > The currently
On Mon, 9 Mar 2020 at 08:38, Pekka Paalanen wrote:
>
> On Fri, 6 Mar 2020 18:51:22 +
> Emil Velikov wrote:
>
> > On Fri, 6 Mar 2020 at 14:00, Pekka Paalanen wrote:
> > >
> > > On Wed, 19 Feb 2020 13:27:28 +
> > > Emil Velikov wrote:
> > >
> > > > From: Emil Velikov
> > > >
> > >
> > >
On Thu, Mar 05, 2020 at 08:41:43PM +0100, H. Nikolaus Schaller wrote:
>
> > Am 03.03.2020 um 16:49 schrieb H. Nikolaus Schaller :
> >
> > Hi,
> >
> >> Am 03.03.2020 um 16:03 schrieb Ville Syrjälä
> >> :
> >>
> >>> I haven't looked into the driver code, but would it be
> >>> possible to specify
Mark up the potential racy read in drm_mm_initialized(), as we want a
cheap and cheerful check:
[ 121.098731] BUG: KCSAN: data-race in _i915_gem_object_create_stolen [i915] /
rm_hole
[ 121.098766]
[ 121.098789] write (marked) to 0x8881f01ed330 of 8 bytes by task 3568 on
cpu 3:
[ 121.0988
[ 1715.899800] BUG: KCSAN: data-race in drm_gem_handle_create_tail /
drm_gem_object_handle_put_unlocked
[ 1715.899838]
[ 1715.899861] write to 0x8881830f3604 of 4 bytes by task 7834 on cpu 1:
[ 1715.899896] drm_gem_handle_create_tail+0x62/0x250
[ 1715.899927] drm_gem_open_ioctl+0xc1/0x160
[
Pierre-eric, just a gentle ping on this? Could I get a tested-by?
Ray can you ack or even review this?
Thanks,
Christian.
Am 06.03.20 um 13:41 schrieb Christian König:
The assert sometimes incorrectly triggers when pinned BOs are destroyed.
Signed-off-by: Christian König
---
drivers/gpu/dr
Store the IOMMU mapping created by the device core of each Exynos DRM
sub-device and restore it when the Exynos DRM driver is unbound. This
fixes IOMMU initialization failure for the second time when a deferred
probe is triggered from the bind() callback of master's compound DRM
driver. This also f
Hi Marek,
On Thu, 2019-11-14 at 14:17 +0100, Marek Vasut wrote:
> The bus_flags and bus_format handling logic does not seem to cover
> all potential usecases. Specifically, this seems to fail with an
> "edt,etm0700g0edh6" display attached to an 24bit display interface,
> with interface-pix-fmt = "
Hi Laurent,
On Tue, 25 Feb 2020 10:13:54 +0100
Boris Brezillon wrote:
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > > b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> > > index 8f373029f5d2..7c4e42f4de61 100644
> > > --- a/Doc
Hello Marek,
Thank for your patch. Pm_runtime_put_sync is also done into function
ltdc_crtc_mode_fixup.
To avoid several call of Pm_runtime_put_sync, it could be better to check
pm_runtime activity:
+ int ret;
DRM_DEBUG_DRIVER("\n");
+ if (!pm_runtime_active(ddev->dev)) {
On Wed, Mar 04, 2020 at 05:32:11PM -0800, Gurchetan Singh wrote:
> A resource will be a shmem based resource or a (planned)
> vram based resource, so it makes sense to factor out common fields
> (resource handle, dumb).
>
> v2: move mapped field to shmem object
Pushed to drm-misc-next.
thanks,
On Fri, 6 Mar 2020 18:51:22 +
Emil Velikov wrote:
> On Fri, 6 Mar 2020 at 14:00, Pekka Paalanen wrote:
> >
> > On Wed, 19 Feb 2020 13:27:28 +
> > Emil Velikov wrote:
> >
> > > From: Emil Velikov
> > >
> >
> > ...
> >
> > > +/*
> > > + * In the olden days the SET/DROP_MASTER ioctl
On Fri, 06 Mar 2020, Manasi Navare wrote:
> On Fri, Mar 06, 2020 at 12:30:46PM +0200, Jani Nikula wrote:
>> On Thu, 05 Mar 2020, Manasi Navare wrote:
>> > This patch adds defines for the detailed monitor
>> > range flags as per the EDID specification.
>> >
>> > Suggested-by: Ville Syrjälä
>> > C
Von: kernel-janitors-ow...@vger.kernel.org
im Auftrag von Christophe JAILLET
Gesendet: Sonntag, 8. März 2020 10:26
An: harry.wentl...@amd.com; sunpeng...@amd.com; alexander.deuc...@amd.com;
christian.koe...@amd.com; david1.z...@amd.com; airl...@linux.
Hello,
syzbot found the following crash on:
HEAD commit:63623fd4 Merge tag 'for-linus' of git://git.kernel.org/pub..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=177bf331e0
kernel config: https://syzkaller.appspot.com/x/.config?x=9833e26bab355358
das
Adding support for visionox rm69299 panel driver and adding bindings for the
same panel.
Harigovindan P (2):
dt-bindings: display: add visionox rm69299 panel variant
drm/panel: add support for rm69299 visionox panel driver
.../display/panel/visionox,rm69299.yaml | 85 +
drivers/g
Add jump function so that client can jump to any address which
contains instruction.
Signed-off-by: Dennis YC Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 13 +
include/linux/soc/mediatek/mtk-cmdq.h | 11 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/soc/
Add bindings for visionox rm69299 panel.
Signed-off-by: Harigovindan P
---
Changes in v2:
- Removed unwanted properties from description.
- Creating source files without execute permissions(Rob Herring).
Changes in v3:
- Changing txt file into yaml
Changes in v4:
Hi,
chained to this message is a driver for CH7033 along with device tree
binding docs. I'm hoping that it could perhaps make it into 5.7. Please
take a look.
Previous submission [1] contained the exact same patches as this one,
but at that time they relied on Laurent's omapdrm/bridge/devel branc
The IT6505 is a high-performance DisplayPort 1.1a transmitter, fully compliant
with DisplayPort 1.1a, HDCP 1.3 specifications. The IT6505 supports color depth
of up to 36 bits (12 bits/color) and ensures robust transmission of
high-quality uncompressed video content, along with uncompressed and
Do success callback in channel when shutdown. For those task not finish,
callback with error code thus client has chance to cleanup or reset.
Signed-off-by: Dennis YC Hsieh
Reviewed-by: CK Hu
---
drivers/mailbox/mtk-cmdq-mailbox.c | 38 ++
1 file changed, 38 insertio
1 - 100 of 134 matches
Mail list logo
