Hey Laurent,
I merged drm-misc-next and noticed this, I'm not sure if it's
collateral damage from something else changing or I've just missed it
previously. 32-bit arm build.
/home/airlied/devel/kernel/dim/src/drivers/gpu/drm/omapdrm/omap_connector.c:
In function ‘omap_connector_mode_valid’:
/ho
Hi Sebastian.
On Tue, Jun 30, 2020 at 12:33:11AM +0200, Sebastian Reichel wrote:
> Subject: panel-dsi-cm: update bindings
>
> The cleanup series for omapdrm's DSI code got too big. Reviewing
> this is not fun and the same goes for keeping track of the change
> requests. Let's do the cleanup in sm
Hi Sebastian.
On Tue, Jun 30, 2020 at 12:33:12AM +0200, Sebastian Reichel wrote:
> Convert panel-dsi-cm bindings to YAML and add
> missing properties while at it.
>
> Signed-off-by: Sebastian Reichel
Thanks, one of the few panel bindings still pending.
And you added some nice explanations too,
On Mon, Jun 29, 2020 at 4:49 PM Jonathan Marek wrote:
>
> Initialize hardware clock-gating registers on A640 and A650 GPUs.
>
> I put the hwcg tables in adreno_device.c, but maybe it makes more
> sense to keep them in a6xx_gpu.c? (this would allow switching a5xx
> to use the gpulist too.. it isn't
On Thu, Jun 25, 2020 at 6:00 AM Thomas Zimmermann wrote:
>
> A firmware framebuffer might also be specified via device-tree files. If
> no device platform data is given, try the DT device node.
You are missing a DT match table for driver matching and module
loading (if a module is supported).
>
On Mon, Jun 29, 2020 at 10:04 AM Greg KH wrote:
>
> On Mon, Jun 29, 2020 at 11:22:30AM +0200, Daniel Vetter wrote:
> > On Thu, Jun 25, 2020 at 02:00:11PM +0200, Thomas Zimmermann wrote:
> > > We register the simplekms device with the DRM platform helpers. A
> > > native driver for the graphics har
On Mon, 29 Jun 2020 18:55:00 -0300, Fabio Estevam wrote:
> Pass the sysreg unit name to fix the following warning seen with
> 'make dt_binding_check':
>
> Warning (unit_address_vs_reg): /example-0/sysreg: node has a reg or ranges
> property, but no unit name
>
> Signed-off-by: Fabio Estevam
> -
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/gvt/handlers.c
between commit:
fc1e3aa0337c ("drm/i915/gvt: Fix incorrect check of enabled bits in mask
registers")
from the drm-intel-fixes tree and commit:
5f4ae2704d59 ("drm/i915: Identify
Hi Sam,
On Mon, Jun 29, 2020 at 10:11:40AM +0200, Sam Ravnborg wrote:
> On Thu, May 14, 2020 at 08:44:19AM +0200, Geert Uytterhoeven wrote:
> > On Thu, May 14, 2020 at 1:39 AM Laurent Pinchart wrote:
> > > From: Fabrizio Castro
> > >
> > > Document RZ/G2E support for property renesas,companion.
>
Hi Sam,
On Mon, Jun 29, 2020 at 10:10:01AM +0200, Sam Ravnborg wrote:
> On Fri, May 15, 2020 at 12:42:11AM +0300, Laurent Pinchart wrote:
> > Convert the Renesas R-Car LVDS encoder text binding to YAML.
> >
> > Signed-off-by: Laurent Pinchart
> > Acked-by: Maxime Ripard
> > ---
> > Changes sinc
The Starry KR070PE2T panel is a DPI panel, not and LVDS panel. Fix its
connector type.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-
The Satoz SAT050AT40H12R2 panel is an LVDS panel, the
MEDIA_BUS_FMT_RGB888_1X24 bus format is thus incorrect. Set it to the
correct value MEDIA_BUS_FMT_RGB888_1X7X4_SPWG.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
The DRM bus flags reporting on which clock edge the pixel data and sync
signals are sampled or driven don't make sense for LVDS panels, as the
bus then uses sub-clock timings to send data. Drop those flags and add a
warning in the probe function to make sure the mistake won't be
repeated.
Signed-o
Only the MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
MEDIA_BUS_FMT_RGB888_1X7X4_SPWG and MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA bus
formats are valid for LVDS panels. Warn at probe time to catch the
common mistake of using an incorrect format, as well as discrepancies
between the bus format and the reported bpc.
S
Hello,
This small patch series is the second version of what has been
previously submitted as "[PATCH] drm: panel: simple: Drop drive/sample
bus flags for LVDS panels". It fixes incorrect bus format and connector
type in the description of two panels (patches 1/4 and 2/4), drop
invalid bus flags f
On Thu, Jun 18, 2020 at 01:26:57AM +0300, Dmitry Osipenko wrote:
> In some case, like a DRM display code for example, it's useful to silently
> check whether port node exists at all in a device-tree before proceeding
> with parsing of the graph.
>
> This patch adds of_graph_presents() that returns
While I had thought I'd tested this before, it looks like this one issue
slipped by my original CRC patches. Basically, there seem to be a few
rules we need to follow when sending CRC commands to the display
controller:
* CRCs cannot be both disabled and enabled for a single head in the same
flu
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #34 from mn...@protonmail.com ---
Has anyone tried 5.8-rc3? I've been testing it out for the past 3 hours and it
seems stable to me. Also, there were some amdgpu drm fixes pushed between rc2
and rc3 which could have fixed it.
Could so
On Fri, 26 Jun 2020 02:55:50 +0200, Ondrej Jirman wrote:
> Convert Rocktech MIPI DSI panel driver from txt to yaml bindings.
>
> Signed-off-by: Ondrej Jirman
> ---
> .../display/panel/rocktech,jh057n00900.txt| 23 ---
> .../display/panel/rocktech,jh057n00900.yaml | 66 +
Pass the sysreg unit name to fix the following warning seen with
'make dt_binding_check':
Warning (unit_address_vs_reg): /example-0/sysreg: node has a reg or ranges
property, but no unit name
Signed-off-by: Fabio Estevam
---
.../bindings/display/panel/arm,versatile-tft-panel.yaml | 2 +
On Mon, Jun 29, 2020 at 10:31:21PM +0200, Alexander A. Klimov wrote:
> Rationale:
> https://lore.kernel.org/linux-doc/20200626110706.7b5d4...@lwn.net/
>
> Signed-off-by: Alexander A. Klimov
> ---
> @Jon I thought about what I said and *no*, unfortunately I *can't* automate
> the detection of su
On Mon, Jun 29, 2020 at 11:19 AM Eric Anholt wrote:
>
> We don't expect to find vbif_nrt or regdma on cheza, but were clogging
> up dmesg with errors about it.
nit: s/cheza/sdm845/ (since this really applies to the SoC rather than
the board..
also, maybe msm_ioremap_optional() ?
BR,
-R
>
> Sig
On Fri, Jun 19, 2020 at 3:53 PM Sam Ravnborg wrote:
>
> Hi Rob.
>
> Good to have these converted. A few comments in the following. One
> comment is for the backlight people as you copied the original text.
>
> Sam
>
> On Thu, Jun 18, 2020 at 04:44:13PM -0600, Rob Herring wrote:
> > Convert
On Mon, Jun 29, 2020 at 11:57:37AM -0600, Rob Herring wrote:
> On Mon, Jun 22, 2020 at 10:57 AM Daniel Thompson
> wrote:
> >
> > On Fri, Jun 19, 2020 at 11:53:41PM +0200, Sam Ravnborg wrote:
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml
> > > >
We don't expect to find vbif_nrt or regdma on cheza, but were clogging
up dmesg with errors about it.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 ++--
drivers/gpu/drm/msm/msm_drv.c | 22 ++
drivers/gpu/drm/msm/msm_drv.h |
Nothing was using the lengths of these ioremaps.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 21 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 9 -
3 files changed, 31 deletions(-)
diff --
On Mon, Jun 22, 2020 at 10:57 AM Daniel Thompson
wrote:
>
> On Fri, Jun 19, 2020 at 11:53:41PM +0200, Sam Ravnborg wrote:
> > > diff --git
> > > a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml
> > > b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml
> > >
On Mon, Jun 29, 2020 at 10:32:41AM +0200, Daniel Vetter wrote:
> On Fri, Jun 26, 2020 at 05:48:00PM +0100, Brian Starkey wrote:
> > In cases such as DRM_FORMAT_MOD_SAMSUNG_16_16_TILE, the modifier
> > describes a generic pixel re-ordering which can be applicable to
> > multiple vendors.
> >
> > De
On Mon, Jun 29, 2020 at 05:23:16PM +0100, Mark Brown wrote:
> On Mon, Jun 29, 2020 at 06:04:21PM +0200, Greg KH wrote:
>
> > Yes, please do that. Or, use the "virtual bus/device" code that some
> > people at Intel are still trying to get into mergable shape. See the
> > posts on the netdev list
https://bugzilla.kernel.org/show_bug.cgi?id=208333
--- Comment #1 from Roberto Guerrini (robyguerr...@yahoo.it) ---
Tested with 5.8 rc3 also and the result is the same black screen ... but
the computer works so I think it is the Nouveau driver with the gtx 760 to
wrong the video output.
--
On Mon, Jun 8, 2020 at 5:05 PM Sean Paul wrote:
>
> From: Sean Paul
>
> This series is the latest in my journey to create a lightweight,
> always-on "flight recorder" (name credit Weston) of drm logs. This
> incarnation uses a trace_array to keep logs in memory exposed through
> tracefs. Users an
On Mon, Jun 29, 2020 at 2:22 PM Andrzej Hajda wrote:
>
> During probe every time driver gets resource it should usually check for
> error printk some message if it is not -EPROBE_DEFER and return the error.
> This pattern is simple but requires adding few lines after any resource
> acquisition cod
On Mon, Jun 29, 2020 at 2:22 PM Andrzej Hajda wrote:
>
> /sys/kernel/debug/devices_deferred property contains list of deferred devices.
> This list does not contain reason why the driver deferred probe, the patch
> improves it.
> The natural place to set the reason is dev_err_probe function introd
On Mon, Jun 29, 2020 at 06:04:21PM +0200, Greg KH wrote:
> Yes, please do that. Or, use the "virtual bus/device" code that some
> people at Intel are still trying to get into mergable shape. See the
> posts on the netdev list for those details.
Any pointers on that? There's also some ongoing d
On Mon, Jun 29, 2020 at 11:22:30AM +0200, Daniel Vetter wrote:
> On Thu, Jun 25, 2020 at 02:00:11PM +0200, Thomas Zimmermann wrote:
> > We register the simplekms device with the DRM platform helpers. A
> > native driver for the graphics hardware will kickout the simplekms
> > driver before taking o
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Monday, June 29, 2020 11:19 AM
>To: dri-devel@lists.freedesktop.org
>Subject: [PATCH 1/2] drm/ttm: cleanup
>ttm_mem_type_manager_func.get_node interface v3
>
>Instead of signaling failure by setting the node pointer
From: Adam Ford
commit efb94790852ae673b18efde1b171d284689ff333 upstream.
The LogicPD Type28 display used by several Logic PD products has not
worked since v5.6.
The connector type for the LogicPD Type 28 display is missing and
drm_panel_bridge_add() requires connector type to be set.
Signed-o
From: Daniel Vetter
commit dc5bdb68b5b369d5bc7d1de96fa64cc1737a6320 upstream.
In the past we had a pile of hacks to orchestrate access between fbdev
emulation and native kms clients. We've tried to streamline this, by
always preferring the kms side above fbdev calls when a drm master
exists, bec
We only need the page array when the BO is about to be accessed.
So not only populate, but also create it on demand.
v2: move NULL check into ttm_tt_create()
v3: fix the occurrence in ttm_bo_kmap_ttm as well
Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
---
drivers/gpu/drm/ttm/t
Instead of signaling failure by setting the node pointer to
NULL do so by returning -ENOSPC.
v2: add memset() to make sure that mem is always initialized.
v3: drop memset() only set mm_node = NULL, move mm_node init in amdgpu
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_
https://bugzilla.kernel.org/show_bug.cgi?id=208373
--- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) ---
If this is a regression between 5.7.2 and 5.7.0, can you bisect?
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
On Sat, Jun 27, 2020 at 01:11:14PM -0700, Rob Clark wrote:
> On Sat, Jun 27, 2020 at 12:56 PM Rob Clark wrote:
> >
> > On Fri, Jun 26, 2020 at 1:04 PM Jordan Crouse
> > wrote:
> > >
> > > Add support for using per-instance pagetables if all the dependencies are
> > > available.
> > >
> > > Signe
On Sat, Jun 27, 2020 at 10:10:14AM -0700, Rob Clark wrote:
> On Fri, Jun 26, 2020 at 1:01 PM Jordan Crouse wrote:
> >
> > Use the aperture settings from the IOMMU domain to set up the virtual
> > address range for the GPU. This allows us to transparently deal with
> > IOMMU side features (like spl
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Monday, June 29, 2020 8:22 AM
>To: dri-devel@lists.freedesktop.org
>Subject: [PATCH 2/2] drm/ttm: make TT creation purely optional v2
>
>We only need the page array when the BO is about to be accessed.
>
>So not only
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Monday, June 29, 2020 8:22 AM
>To: dri-devel@lists.freedesktop.org
>Subject: [PATCH 1/2] drm/ttm: cleanup
>ttm_mem_type_manager_func.get_node interface v2
>
>Instead of signaling failure by setting the node pointer t
We only need the page array when the BO is about to be accessed.
So not only populate, but also create it on demand.
v2: move NULL check into ttm_tt_create()
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 37 ---
drivers/gpu/drm/ttm/ttm_bo_ut
Instead of signaling failure by setting the node pointer to
NULL do so by returning -ENOSPC.
v2: add memset() to make sure that mem is always initialized.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 4 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c |
This is a note to let you know that I've just added the patch titled
drm/panel-simple: fix connector type for LogicPD Type28 Display
to the 5.7-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch
This is a note to let you know that I've just added the patch titled
drm/fb-helper: Fix vt restore
to the 5.7-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-fb-helper-fix-vt-resto
Hi Grygorii,
(...)
>> /*
>> * deferred_devs_show() - Show the devices in the deferred probe
>> pending list.
>> */
>> @@ -221,7 +241,8 @@ static int deferred_devs_show(struct seq_file *s,
>> void *data)
>> mutex_lock(&deferred_probe_mutex);
>> list_for_each_entry(curr, &de
/sys/kernel/debug/devices_deferred property contains list of deferred devices.
This list does not contain reason why the driver deferred probe, the patch
improves it.
The natural place to set the reason is dev_err_probe function introduced
recently,
ie. if dev_err_probe will be called with -EPROBE
During probe every time driver gets resource it should usually check for
error printk some message if it is not -EPROBE_DEFER and return the error.
This pattern is simple but requires adding few lines after any resource
acquisition code, as a result it is often omitted or implemented only
partially
In case of error during resource acquisition driver should print error
message only in case it is not deferred probe, using dev_err_probe helper
solves the issue. Moreover it records defer probe reason for debugging.
Signed-off-by: Andrzej Hajda
Reviewed-by: Neil Armstrong
---
drivers/gpu/drm/b
Hi All,
Thanks for comments.
Changes since v6:
- removed leftovers from old naming scheme in commit descritions,
- added R-Bs.
Changes since v5:
- removed patch adding macro, dev_err_probe(dev, PTR_ERR(ptr), ...) should be
used instead,
- added dev_dbg logging in case of -EPROBE_DEFER,
- rename
Using dev_err_probe code has following advantages:
- shorter code,
- recorded defer probe reason for debugging,
- uniform error code logging.
Signed-off-by: Andrzej Hajda
Reviewed-by: Neil Armstrong
---
drivers/gpu/drm/bridge/lvds-codec.c | 10 +++---
1 file changed, 3 insertions(+), 7 dele
On Fri, Jun 26, 2020 at 10:37:42PM +0200, Linus Walleij wrote:
> The only way the platform data for the SKY81452 ever gets populated
> is through the device tree.
>
> The MFD device is bothered with this for no reason at all. Just
> allocate the platform data in the driver and be happy.
>
> Cc: G
On Fri, Jun 26, 2020 at 10:37:41PM +0200, Linus Walleij wrote:
> The SKY81452 backlight driver just obtains a GPIO (named "gpios"
> in the device tree) drives it high and leaves it high until the
> driver is removed.
>
> Switch to use GPIO descriptors for this, simple and
> straight-forward.
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=208373
Bug ID: 208373
Summary: drm:drm_atomic_helper_wait_for_dependencies -
drm_kms_helper - flip_done timed out
Product: Drivers
Version: 2.5
Kernel Version: 5.7.2
Hardware:
On 6/29/20 5:36 AM, Dmitry Osipenko wrote:
28.06.2020 12:44, Mikko Perttunen пишет:
On 6/28/20 2:27 AM, Dmitry Osipenko wrote:
23.06.2020 15:09, Mikko Perttunen пишет:
### IOCTL HOST1X_ALLOCATE_SYNCPOINT (on /dev/host1x)
Allocates a free syncpoint, returning a file descriptor representing it
Hi,
On 6/25/20 2:00 PM, Thomas Zimmermann wrote:
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 simplekms, binds to a simple-frambuffer platform
device. The kernel's boot
On Thu, Jun 25, 2020 at 02:00:10PM +0200, Thomas Zimmermann wrote:
> 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
> fram
On Thu, Jun 25, 2020 at 02:00:11PM +0200, Thomas Zimmermann wrote:
> We register the simplekms device with the DRM platform helpers. A
> native driver for the graphics hardware will kickout the simplekms
> driver before taking over the device.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers
On Thu, Jun 25, 2020 at 02:00:06PM +0200, Thomas Zimmermann wrote:
> This displays a console on the simplefb framebuffer. The default
> framebuffer format is being used.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/tiny/simplekms.c | 3 +++
> 1 file changed, 3 insertions(+)
>
>
On Thu, Jun 25, 2020 at 03:34:05PM +0200, Geert Uytterhoeven wrote:
> Hi Thomas,
>
> On Thu, Jun 25, 2020 at 2:00 PM 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 dr
On Thu, Jun 25, 2020 at 02:00:05PM +0200, Thomas Zimmermann wrote:
> The simplekms 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
On Thu, Jun 25, 2020 at 02:00:04PM +0200, Thomas Zimmermann wrote:
> The blitter functions copy a framebuffer to I/O memory using one of
> the existing conversion functions.
>
> Signed-off-by: Thomas Zimmermann
Hm I guess reason for adding dst_pitch in the previous patch is so that
there wouldn'
Hi Adrian,
On 09/06/2020 19:49, Adrian Ratiu wrote:
> [Re-submitting to cc dri-devel, sorry about the noise]
>
> Hello all,
>
> v9 cleanly applies on top of latest next-20200609 tree.
>
> v9 does not depend on other patches as the last binding doc has been merged.
>
> All feedback up to this p
On 11/06/2020 16:34, Doug Anderson wrote:
> Hi,
>
> On Thu, Jun 11, 2020 at 2:58 AM Stephen Boyd wrote:
>>
>> Quoting Douglas Anderson (2020-06-08 10:48:35)
>>> The ti_sn_bridge_gpio_set() got the return value of
>>> regmap_update_bits() but didn't check it. The function can't return
>>> an erro
On Thu, Jun 25, 2020 at 02:00:03PM +0200, Thomas Zimmermann wrote:
> 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
But I do have questions ... why d
Hi,
On 21/06/2020 17:38, Vinay Simha BN wrote:
> Signed-off-by: Vinay Simha BN
>
> ---
> v1:
> Initial version
>
> v2:
> * Andrzej Hajda review comments incorporated
> SPDX identifier
> development debug removed
> alphabetic order headers
> u32 instead of unit32_t
> magic numbers to
On Fri, 26 Jun 2020, Dave Airlie wrote:
> Usual rc3 pickup, lots of little fixes all over, The core VT
> registration regression fix is probably the largest, otherwise ttm,
> amdgpu and tegra are the bulk, with some minor driver fixes. No i915
> pull this week which may or may not mean I get 2x of
On Fri, Jun 26, 2020 at 10:42:52PM +0200, Antonio Borneo wrote:
> Some of these comments are part of the Linux GPU Driver Developer's
> Guide.
> Fix some minor typo in the comments and remove a repeated 'the'.
>
> Signed-off-by: Antonio Borneo
Queued up for 5.9 in drm-misc-next, thanks for your
On 26/06/2020 12:01, Andrzej Hajda wrote:
> In case of error during resource acquisition driver should print error
> message only in case it is not deferred probe, using dev_err_probe helper
> solves the issue. Moreover it records defer probe reason for debugging.
>
> Signed-off-by: Andrzej Hajda
On 26/06/2020 12:01, Andrzej Hajda wrote:
> Using dev_err_probe code has following advantages:
> - shorter code,
> - recorded defer probe reason for debugging,
> - uniform error code logging.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/bridge/lvds-codec.c | 10 +++---
> 1 file c
On Fri, Jun 26, 2020 at 05:48:00PM +0100, Brian Starkey wrote:
> In cases such as DRM_FORMAT_MOD_SAMSUNG_16_16_TILE, the modifier
> describes a generic pixel re-ordering which can be applicable to
> multiple vendors.
>
> Define an alias: DRM_FORMAT_MOD_GENERIC_16_16_TILE, which can be
> used to de
On Thu, May 14, 2020 at 08:44:19AM +0200, Geert Uytterhoeven wrote:
> On Thu, May 14, 2020 at 1:39 AM Laurent Pinchart
> wrote:
> > From: Fabrizio Castro
> >
> > Document RZ/G2E support for property renesas,companion.
> >
> > Signed-off-by: Fabrizio Castro
> > Reviewed-by: Laurent Pinchart
> >
On Fri, May 15, 2020 at 12:42:11AM +0300, Laurent Pinchart wrote:
> Convert the Renesas R-Car LVDS encoder text binding to YAML.
>
> Signed-off-by: Laurent Pinchart
> Acked-by: Maxime Ripard
> ---
> Changes since v1:
>
> - Mention RZ/G1 and R2/G2 explicitly
> - Drop the part numbers in comments
On Mon, May 11, 2020 at 11:29:24PM +0300, Maksim Melnikov wrote:
> The NL10276BC13-01C is a 6.5" 1024x768 XGA TFT LCD panel with LVDS interface.
> It is used for industrial purposes in devices such as HMI.
>
> Signed-off-by: Maksim Melnikov
> ---
> drivers/gpu/drm/panel/panel-simple.c | 28
On Tue, May 05, 2020 at 05:03:27PM +0100, Emil Velikov wrote:
> Currently the function heap allocates when we have any payload. Where in
> many case the payload is 1 byte - ouch.
>
> >From casual observation, vast majority of the payloads are smaller than
> 8 bytes - so use a stack array tx[8] to
On Tue, May 05, 2020 at 05:03:29PM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> The helper uses the MIPI_DCS_SET_TEAR_SCANLINE, although it's currently
> using the generic write. This does not look right.
>
> Perhaps some platforms don't distinguish between the two writers?
>
> Cc: Rober
On Mon, May 11, 2020 at 12:28:40PM +0100, Emil Velikov wrote:
> On Tue, 5 May 2020 at 17:05, Emil Velikov wrote:
> >
> > From: Emil Velikov
> >
> > A few of the new panels create a local macro wrapping around
> > mipi_dsi_dcs_write. At the same time, they don't really care about the
> > command/p
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #33 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to rtmasura+kernel from comment #24)
> xfwm4 --replace --vblank=glx &
FWIW, I recommend
xfwm4 --vblank=xpresent
instead. --vblank=glx is less efficient and relies on rather
On Mon, May 04, 2020 at 07:32:30PM +0800, Jason Yan wrote:
> Fix the following coccicheck warning:
>
> drivers/gpu/drm/zte/zx_vga.c:158:2-3: Unneeded semicolon
> drivers/gpu/drm/zte/zx_vga.c:171:2-3: Unneeded semicolon
> drivers/gpu/drm/zte/zx_vga.c:179:2-3: Unneeded semicolon
>
> Signed-off-by:
83 matches
Mail list logo
