05.06.2019 11:28, Thierry Reding пишет:
> On Tue, Jun 04, 2019 at 07:07:42PM +0300, Dmitry Osipenko wrote:
>> 04.06.2019 18:31, Thierry Reding пишет:
>>> From: Thierry Reding
>>>
>>> When deferring probe, avoid logging a confusing error message. While at
>>> it, make the error message more informa
From: Yongqiang Niu
Update device tree binding documention for the display subsystem for
Mediatek MT8183 SOCs
Signed-off-by: Yongqiang Niu
---
Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bind
From: Yongqiang Niu
Here is two modifition in this patch:
1.bls->dpi0 and rdma1->dsi are differen usecase,
Split DISP_REG_CONFIG_DSI_SEL setting into anther usecase
2.remove DISP_REG_CONFIG_DPI_SEL setting, DPI_SEL_IN_BLS is 0 and
this is same with hardware defautl setting,
Signed-off-by: Yongqi
05.06.2019 15:32, Thierry Reding пишет:
> On Wed, Jun 05, 2019 at 02:25:43PM +0300, Dmitry Osipenko wrote:
>> 05.06.2019 11:28, Thierry Reding пишет:
>>> On Tue, Jun 04, 2019 at 07:07:42PM +0300, Dmitry Osipenko wrote:
04.06.2019 18:31, Thierry Reding пишет:
> From: Thierry Reding
>
>
From: Yongqiang Niu
This patch add layer_nr for ovl private data
ovl_2l almost same with with ovl hardware, except the
layer number for ovl_2l is 2 and ovl is 4.
this patch is a preparation for ovl-2l and
ovl share the same driver.
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_
From: Yongqiang Niu
Update device tree binding documention for the display subsystem for
Mediatek MT8183 SOCs
Signed-off-by: Yongqiang Niu
---
.../bindings/display/mediatek/mediatek,disp.txt| 34 +-
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git
a/Docume
From: Yongqiang Niu
Update device tree binding documention for the display subsystem for
Mediatek MT8183 SOCs
Signed-off-by: Yongqiang Niu
---
Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bind
From: Yongqiang Niu
except mutex mod, mutex mod reg,mutex sof reg,
and mutex sof id will be ddp private data
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 53 +++---
1 file changed, 36 insertions(+), 17 deletions(-)
diff --git a/drivers/
We have device iterators to find a particular device matching a criteria
for a given bus/class/driver. i.e, {bus,class,driver}_find_device() APIs.
The matching criteria is a function pointer for the APIs. Often the lookup
is based on a generic property of a device (e.g, name, fwnode, of node pointe
From: Yongqiang Niu
This patch add mmsys private data for ddp path config
all these register offset and value will be different in future SOC
add these define into mmsys private data
u32 ovl0_mout_en;
u32 rdma0_sout_sel_in;
u32 rdma0_sout_color0;
u32 rdma1_sout_sel
05.06.2019 16:04, Thierry Reding пишет:
> On Wed, Jun 05, 2019 at 03:40:28PM +0300, Dmitry Osipenko wrote:
>> 05.06.2019 15:32, Thierry Reding пишет:
>>> On Wed, Jun 05, 2019 at 02:25:43PM +0300, Dmitry Osipenko wrote:
05.06.2019 11:28, Thierry Reding пишет:
> On Tue, Jun 04, 2019 at 07:07
From: Yongqiang Niu
This patch add clock property check before get it
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_dr
From: Yongqiang Niu
This patch add connection from RDMA1 to DSI0
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index adafa41..9986c6
From: Yongqiang Niu
Update device tree binding documention for the display subsystem for
Mediatek MT8183 SOCs
Signed-off-by: Yongqiang Niu
---
Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bind
From: Yongqiang Niu
This series are based on 5.2-rc1 and provid 27 patch
to support mediatek SOC MT8183
Change since v2
- fix reviewed issue in v2
- add mutex node into dts file
Yongqiang Niu (27):
dt-bindings: mediatek: add binding for mt8183 display
dt-bindings: mediatek: add ovl_2l descr
https://bugs.freedesktop.org/show_bug.cgi?id=107877
John M. Haynes changed:
What|Removed |Added
Version|unspecified |DRI git
Assignee|portland-bu
Hi Bart,
On Tue, May 28, 2019 at 11:02:31AM +0200, Daniel Vetter wrote:
> Hi all,
>
> I think we're slowly getting there. Previous cover letters with more
> context:
>
> https://lists.freedesktop.org/archives/dri-devel/2019-May/218362.html
>
> tldr; I have a multi-year plan to improve fbcon lockin
On Wed, Jun 05, 2019 at 04:44:23PM -0700, davidri...@chromium.org wrote:
> From: David Riley
>
> After data is copied to the cache entry, atomic_set is used indicate
> that the data is the entry is valid without appropriate memory barriers.
> Similarly the read side was missing the same memory ba
On Thu, Jun 06, 2019 at 08:39:12AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 05.06.19 um 17:58 schrieb Gerd Hoffmann:
> > On Wed, Jun 05, 2019 at 11:59:04AM +0200, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 05.06.19 um 11:03 schrieb Gerd Hoffmann:
> >>> On Tue, Jun 04, 2019 at 01:13:30PM +020
On Wed, Jun 05, 2019 at 07:19:37PM +0800, Liviu Dudau wrote:
> Hi Lowry,
>
> On Tue, Apr 30, 2019 at 07:19:29AM +0100, Lowry Li (Arm Technology China)
> wrote:
> > Adds iommu_connect and disconnect for SMMU support, and configures
> > TBU translation once SMMU has been attached to the display dev
On Thu, Jun 6, 2019 at 9:45 AM Gerd Hoffmann wrote:
>
> On Thu, Jun 06, 2019 at 08:39:12AM +0200, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 05.06.19 um 17:58 schrieb Gerd Hoffmann:
> > > On Wed, Jun 05, 2019 at 11:59:04AM +0200, Thomas Zimmermann wrote:
> > >> Hi
> > >>
> > >> Am 05.06.19 um 11:0
Hi Sam,
On Tue, May 28, 2019 at 06:59:00PM +0200, Sam Ravnborg wrote:
> Hi Laurent.
>
> > > >
> > > > +Optional properties:
> > > > +
> > > > +- renesas,companion : phandle to the companion LVDS encoder. This
> > > > property is
> > > > + mandatory for the first LVDS encoder on D3 and E3 SoCs
Hi Sam,
On Tue, May 28, 2019 at 07:02:42PM +0200, Sam Ravnborg wrote:
> On Tue, May 28, 2019 at 07:50:52PM +0300, Laurent Pinchart wrote:
> > On Tue, May 28, 2019 at 06:42:13PM +0200, Sam Ravnborg wrote:
> >> On Tue, May 28, 2019 at 05:12:31PM +0300, Laurent Pinchart wrote:
> >>> In dual-link LVDS
Hi Simon,
On Mon, Jun 03, 2019 at 01:40:45PM +0200, Simon Horman wrote:
> On Tue, May 28, 2019 at 05:12:32PM +0300, Laurent Pinchart wrote:
> > Add the new renesas,companion property to the LVDS0 node to point to the
> > companion LVDS encoder LVDS1.
> >
> > Signed-off-by: Laurent Pinchart
> > R
On 05.06.2019 09:04, Andrey Smirnov wrote:
> Replace explicit polling loop with equivalent call to
> tc_poll_timeout() for brevity. No functional change intended.
>
> Signed-off-by: Andrey Smirnov
> Cc: Archit Taneja
> Cc: Andrzej Hajda
> Cc: Laurent Pinchart
> Cc: Tomi Valkeinen
> Cc: Andrey
Hi
Am 06.06.19 um 09:49 schrieb Daniel Vetter:
> On Thu, Jun 6, 2019 at 9:45 AM Gerd Hoffmann wrote:
>>
>> On Thu, Jun 06, 2019 at 08:39:12AM +0200, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 05.06.19 um 17:58 schrieb Gerd Hoffmann:
On Wed, Jun 05, 2019 at 11:59:04AM +0200, Thomas Zimmermann
Hi,
at 11:30, Kai-Heng Feng wrote:
Another panel that needs 6BPC quirk.
Please include this patch if possible.
Kai-Heng
BugLink: https://bugs.launchpad.net/bugs/1819968
Cc: # v4.8+
Signed-off-by: Kai-Heng Feng
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
di
On Thu, Jun 06, 2019 at 12:11:14PM +1000, Dave Airlie wrote:
> Hi Liviu,
Hi Dave,
>
> dim: c43de636a469 ("drm/komeda: Potential error pointer dereference"):
> committer Signed-off-by missing.
> dim: c43de636a469 ("drm/komeda: Potential error pointer dereference"):
> SHA1 in fixes line not found:
On 05.06.2019 09:04, Andrey Smirnov wrote:
> Replace explicit polling in tc_link_training() with equivalent call to
> tc_poll_timeout() for simplicity. No functional change intended (not
> including slightly altered debug output).
>
> Signed-off-by: Andrey Smirnov
> Cc: Archit Taneja
> Cc: Andrze
On Wed, Jun 05, 2019 at 09:45:56PM +0200, Daniel Vetter wrote:
> We can be called from any context, we need to be prepared.
>
> Noticed this while hacking on vkms, which calls this function from a
> normal worker. Which really upsets lockdep.
>
> Cc: Rodrigo Siqueira
> Cc: Tomeu Vizoso
> Cc: Em
Hi Liviu,
Please ignore last email and please find the latest feedback inline as
below.
On Wed, Jun 05, 2019 at 07:19:37PM +0800, Liviu Dudau wrote:
> Hi Lowry,
>
> On Tue, Apr 30, 2019 at 07:19:29AM +0100, Lowry Li (Arm Technology China)
> wrote:
> > Adds iommu_connect and disconnect for SMMU
On 05.06.2019 09:04, Andrey Smirnov wrote:
> Simplify tc_set_video_mode() by replacing explicit shifting using
> macros from . No functional change intended.
>
> Signed-off-by: Andrey Smirnov
> Cc: Archit Taneja
> Cc: Andrzej Hajda
> Cc: Laurent Pinchart
> Cc: Tomi Valkeinen
> Cc: Andrey Gusak
On Thu, Jun 06, 2019 at 12:22:46AM +0200, Paul Cercueil wrote:
> This patch adds MEDIA_BUS_FMT_RGB888_3X8, used for the GiantPlus
> GPM940B0 24-bit TFT panel, where the RGB components are transferred
> sequentially on a 8-bit bus.
>
> Signed-off-by: Paul Cercueil
Acked-by: Sakari Ailus
--
Sak
https://bugs.freedesktop.org/show_bug.cgi?id=110751
Michel Dänzer changed:
What|Removed |Added
QA Contact|xorg-t...@lists.x.org |
Component|Driver/Radeon
Le jeu. 6 juin 2019 à 10:12, Ville Syrjälä
a écrit :
>
> On Wed, Jun 05, 2019 at 09:45:56PM +0200, Daniel Vetter wrote:
> > We can be called from any context, we need to be prepared.
> >
> > Noticed this while hacking on vkms, which calls this function from a
> > normal worker. Which really upsets
In
commit def35e7c592616bc09be328de8795e5e624a3cf8
Author: Shayenne Moura
Date: Wed Jan 30 14:06:36 2019 -0200
drm/vkms: Bugfix extra vblank frame
we fixed the vblank counter to give accurate results outside of
drm_crtc_handle_vblank, which fixed bugs around vblank timestamps
being off-by
On Thu, Jun 06, 2019 at 10:59:57AM +0300, Laurent Pinchart wrote:
> Hi Simon,
>
> On Mon, Jun 03, 2019 at 01:40:45PM +0200, Simon Horman wrote:
> > On Tue, May 28, 2019 at 05:12:32PM +0300, Laurent Pinchart wrote:
> > > Add the new renesas,companion property to the LVDS0 node to point to the
> > >
On Wed, Jun 05, 2019 at 12:19:29PM +0100, Liviu Dudau wrote:
> dp_wait_cond() currently returns the number of retries left over which
> is hardly an useful information. Convert to returning -ETIMEDOUT when
> the wait times out, or 0 (zero) when condition is met before deadline.
>
> Also convert th
On Tue, 2019-06-04 at 17:15 +0200, Christian König wrote:
> Am 04.06.19 um 17:05 schrieb Ser, Simon:
> > Hi,
> >
> > I'm trying to link ALSA playback devices and DRM connectors. In other
> > words, I'd like to be able to know which ALSA device I should open to
> > play audio on a given connector.
On Fri, May 24, 2019 at 02:57:59PM +0200, Hans de Goede wrote:
> GPD has done it again, make a nice device (good), use way too generic
> DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).
>
> Because of the too generic DMI strings this entry is also doing bios-date
> matching, s
On Tue, 2019-06-04 at 17:24 +0200, Daniel Vetter wrote:
> On Tue, Jun 4, 2019 at 5:15 PM Christian König
> wrote:
> > Am 04.06.19 um 17:05 schrieb Ser, Simon:
> > > Hi,
> > >
> > > I'm trying to link ALSA playback devices and DRM connectors. In other
> > > words, I'd like to be able to know which
Am 06.06.19 um 11:13 schrieb Ser, Simon:
> On Tue, 2019-06-04 at 17:15 +0200, Christian König wrote:
>> Am 04.06.19 um 17:05 schrieb Ser, Simon:
>>> Hi,
>>>
>>> I'm trying to link ALSA playback devices and DRM connectors. In other
>>> words, I'd like to be able to know which ALSA device I should op
Hi Laurent.
> >
> > The main difference is "when dual-link mode is supported".
> > As per my understanding this property is only relevant when the actual
> > HW supports / uses dual-link mode.
> > So for a board that do not even wire up dual-link, then setting the
> > property would be confusing.
Hi Laurent.
> > > Gen3 is the newest generation :-) We thus use >= through the DU and LVDS
> > > drivers to prepare for support of Gen4, just in case.
> >
> > OK, but I guess we agree that the comment needs a small update them.
> >
> > Actually I implicitly reads that it is only from Gen3 onwards
On Thu, Jun 06, 2019 at 10:27:23AM +0200, Benjamin Gaignard wrote:
> Le jeu. 6 juin 2019 à 10:12, Ville Syrjälä
> a écrit :
> >
> > On Wed, Jun 05, 2019 at 09:45:56PM +0200, Daniel Vetter wrote:
> > > We can be called from any context, we need to be prepared.
> > >
> > > Noticed this while hacking
Hi,
This patch set addresses warnings that module names are named the
same, this may lead to a problem that wrong module gets loaded or if one
of the two same-name modules exports a symbol, this can confuse the
dependency resolution. and the build may fail.
Patch "drivers: net: dsa: realtek: fix
When building with CONFIG_ASIX_PHY and CONFIG_USB_NET_AX8817X enabled as
loadable modules, we see the following warning:
warning: same module names found:
drivers/net/phy/asix.ko
drivers/net/usb/asix.ko
Rework so media coda matches the config fragment. Leaving
CONFIG_USB_NET_AX8817X as is sin
When building with CONFIG_MFD_88PM800 and CONFIG_REGULATOR_88PM800
enabled as loadable modules, we see the following warning:
warning: same module names found:
drivers/regulator/88pm800.ko
drivers/mfd/88pm800.ko
Rework so the names matches the config fragment.
Signed-off-by: Anders Roxell
-
When building with CONFIG_MFD_88PM800 and CONFIG_REGULATOR_88PM800
enabled as loadable modules, we see the following warning:
warning: same module names found:
drivers/regulator/88pm800.ko
drivers/mfd/88pm800.ko
Rework to rename the name.
Signed-off-by: Anders Roxell
---
drivers/regulator/
When building with CONFIG_VIDEO_CODA and CONFIG_CODA_FS enabled as
loadable modules, we see the following warning:
warning: same module names found:
fs/coda/coda.ko
drivers/media/platform/coda/coda.ko
Rework so media coda matches the config fragment. Leaving CODA_FS as is
since thats a well k
When building with CONFIG_DRM_MXSFB and CONFIG_FB_MXS enabled as
loadable modules, we see the following warning:
warning: same module names found:
drivers/video/fbdev/mxsfb.ko
drivers/gpu/drm/mxsfb/mxsfb.ko
Rework so the names matches the config fragment.
Signed-off-by: Anders Roxell
---
d
When building with CONFIG_NET_DSA_REALTEK_SMI and CONFIG_REALTEK_PHY
enabled as loadable modules, we see the following warning:
warning: same module names found:
drivers/net/phy/realtek.ko
drivers/net/dsa/realtek.ko
Rework so the names matches the config fragment.
Signed-off-by: Anders Roxel
When building with CONFIG_VIDEO_ADV7511 and CONFIG_DRM_I2C_ADV7511
enabled as loadable modules, we see the following warning:
warning: same module names found:
drivers/gpu/drm/bridge/adv7511/adv7511.ko
drivers/media/i2c/adv7511.ko
Rework so the names matches the config fragment.
Signed-off-b
Hi,
This serie aims at adding the support for SMMU on Komeda driver.
Also updates the device-tree doc about how to enable SMMU by devicetree.
This patch series depends on:
- https://patchwork.freedesktop.org/series/58710/
- https://patchwork.freedesktop.org/series/59000/
- https://patchwork.freed
Updates the device-tree doc about how to enable SMMU by devicetree.
Signed-off-by: Lowry Li (Arm Technology China)
Reviewed-by: Liviu Dudau
Reviewed-by: James Qian Wang (Arm Technology China)
---
Documentation/devicetree/bindings/display/arm,komeda.txt | 7 +++
1 file changed, 7 insertion
From: "Lowry Li (Arm Technology China)"
Adds iommu_connect and disconnect for SMMU support, and configures
TBU translation once SMMU has been attached to the display device.
Signed-off-by: Lowry Li (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/d71/d71_component.c | 5 +++
drivers/
On 6/6/19 11:47 AM, Anders Roxell wrote:
> When building with CONFIG_VIDEO_ADV7511 and CONFIG_DRM_I2C_ADV7511
> enabled as loadable modules, we see the following warning:
>
> warning: same module names found:
> drivers/gpu/drm/bridge/adv7511/adv7511.ko
> drivers/media/i2c/adv7511.ko
>
> Rewor
Em Thu, 6 Jun 2019 11:46:57 +0200
Anders Roxell escreveu:
> Hi,
>
> This patch set addresses warnings that module names are named the
> same, this may lead to a problem that wrong module gets loaded or if one
> of the two same-name modules exports a symbol, this can confuse the
> dependency res
On 6/6/19 11:47 AM, Anders Roxell wrote:
> When building with CONFIG_VIDEO_CODA and CONFIG_CODA_FS enabled as
> loadable modules, we see the following warning:
>
> warning: same module names found:
> fs/coda/coda.ko
> drivers/media/platform/coda/coda.ko
>
> Rework so media coda matches the co
On 2019-05-24 7:15 a.m., zhoucm1 wrote:
> anyone can pick up to gitlab for libdrm?
Can you create a merge request?
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
https://gitlab.freedesktop.org/mesa/drm, Where the merge request button?
-David
On 2019年06月06日 18:20, Michel Dänzer wrote:
On 2019-05-24 7:15 a.m., zhoucm1 wrote:
anyone can pick up to gitlab for libdrm?
Can you create a merge request?
___
dri-
Seconded, I'm always totally confused about the web interface as well.
Christian.
Am 06.06.19 um 12:26 schrieb zhoucm1:
> https://gitlab.freedesktop.org/mesa/drm, Where the merge request button?
>
> -David
>
>
> On 2019年06月06日 18:20, Michel Dänzer wrote:
>> On 2019-05-24 7:15 a.m., zhoucm1 wrote:
On Fri, May 31, 2019 at 08:19:03PM +, Harry Wentland wrote:
> On 2019-05-30 12:12 p.m., Colin King wrote:
> > From: Colin Ian King
> >
> > The variable status is initialized with a value that is never read
> > and status is reassigned several statements later. This initialization
> > is redun
On 2019-06-06 12:26 p.m., zhoucm1 wrote:
> https://gitlab.freedesktop.org/mesa/drm, Where the merge request button?
If you push to a branch in your personal repository, the output of git
push contains an URL for creating a merge request.
--
Earthling Michel Dänzer | h
On 05.06.2019 09:04, Andrey Smirnov wrote:
> A very unfortunate aspect of tc_write()/tc_read() macro helpers is
> that they capture quite a bit of context around them and thus require
> the caller to have magic variables 'ret' and 'tc' as well as label
> 'err'. That makes a number of code paths rat
https://bugs.freedesktop.org/show_bug.cgi?id=110751
vaidas.bo...@gmail.com changed:
What|Removed |Added
Attachment #144341|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=110751
vaidas.bo...@gmail.com changed:
What|Removed |Added
Attachment #144340|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=110751
Michel Dänzer changed:
What|Removed |Added
Attachment #144466|text/x-log |text/plain
mime type|
On 05.06.2019 09:04, Andrey Smirnov wrote:
> Simplify AUX data read by removing index arithmetic and shifting with
> a helper functions that does three things:
>
> 1. Fetch data from up to 4 32-bit registers from the chip
> 2. Optionally fix data endianness (not needed on LE hosts)
> 3.
On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
>
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
> From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
>
> Cc: Lucas Stach
> Cc: Ch
On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
>
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
> From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
>
> Note: the outstanding DRM
On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
>
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
> From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
>
> Cc: Rob Clark
> Cc: Sean
On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
>
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
> From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
>
> Note: the outstanding DRM
On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
>
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
> From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
>
> Cc: Qiang Yu
> Cc: l...@
On Thu, Jun 06, 2019 at 11:47:36AM +0200, Anders Roxell wrote:
> obj-$(CONFIG_REGULATOR_88PG86X) += 88pg86x.o
> -obj-$(CONFIG_REGULATOR_88PM800) += 88pm800.o
> +obj-$(CONFIG_REGULATOR_88PM800) += 88pm800-regulator.o
> +88pm800-regulator-objs := 88pm800.o
Don't do this, no need for
On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
>
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
> From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
>
> Cc: Gerd Hoffmann
> Cc:
On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
>
> From: Emil Velikov
>
> The authentication can be circumvented, by design, by using the render
> node.
>
> From the driver POV there is no distinction between primary and render
> nodes, thus we can drop the token.
>
> Cc: David Airlie
> Cc: D
On 05.06.2019 09:04, Andrey Smirnov wrote:
> Simplify AUX data write by dropping index arithmetic and shifting and
> replacing it with a call to a helper function that does three things:
>
> 1. Copies user-provided data into a write buffer
> 2. Optionally fixes the endianness of the write b
On 05.06.2019 09:05, Andrey Smirnov wrote:
> According to the datasheet tc358767 can transfer up to 16 bytes via
> its AUX channel, so the artificial limit of 8 apperas to be too
> low. However only up to 15-bytes seem to be actually supported and
> trying to use 16-byte transfers results in transf
Hi,
On 06-06-19 11:14, Maxime Ripard wrote:
On Fri, May 24, 2019 at 02:57:59PM +0200, Hans de Goede wrote:
GPD has done it again, make a nice device (good), use way too generic
DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).
Because of the too generic DMI strings this en
Am Do., 6. Juni 2019 um 12:59 Uhr schrieb Emil Velikov
:
>
> On Mon, 27 May 2019 at 09:19, Emil Velikov wrote:
> >
> > From: Emil Velikov
> >
> > The authentication can be circumvented, by design, by using the render
> > node.
> >
> > From the driver POV there is no distinction between primary an
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #14 from Steffen Klee (steffen.k...@gmail.com) ---
Reproducible on an R9 390 with kernel 5.1.6-arch1-1-ARCH using amdgpu driver.
Setting amdgpu.dpm=1 or changing amdgpu.dc does not have any effect.
Also, sensors does not report the cu
On Wed, Jun 5, 2019 at 1:54 PM Sam Ravnborg wrote:
>
> Hi Vivek,
>
> On Mon, May 27, 2019 at 03:56:16PM +0530, Vivek Gautam wrote:
> > MTP SDM845 panel seems to need additional delay to bring panel
> > to a workable state. Running modetest without this change displays
> > blurry artifacts.
> >
> >
On Thu, 06 Jun 2019, Harish Chegondi wrote:
> This would allow the EDID override to be handled correctly in
> drm_do_get_edid() for cases where EDID data is missing or corrupt.
>
> All drm_probe_ddc() does is call drm_do_probe_ddc_edid( , , , 1)
> which probes the display by reading 1 byte of EDID
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #15 from danglingpointerexcept...@gmail.com
(danglingpointerexcept...@gmail.com) ---
@Rudolf - Have you tried my solution in the link I provided above? I'm on
5.1.6 mainline and have no issues whatsoever with R9-290X
@Alex Smith - I
Hi Dave & Daniel,
No i915 fixes this week, but forwarding the GVT pull request still.
One GVT regression fix for debug build of i915 guest, guest ring
state fix after execution for hang check and a couple of static
checker fixes.
CI is being clogged curently, but we really don't have that much G
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #16 from Steffen Klee (steffen.k...@gmail.com) ---
(In reply to danglingpointerexcept...@gmail.com from comment #15)
> @Steffen - Try my steps in the link mate, it may solve your problem. Alex
> Ducher himself gave me the tip on fixin
On Wed, May 29, 2019 at 06:50:40PM +0200, Mario Kleiner wrote:
> On Wed, May 29, 2019 at 7:02 AM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > From VESA EDID implementation guide v1.0:
> > "For EDID version 1 revision 2 or earlier data structures when offset 14h
> > bit 7 is set to
On Thu, Jun 06, 2019 at 01:13:40PM +0200, Hans de Goede wrote:
> On 06-06-19 11:14, Maxime Ripard wrote:
> > On Fri, May 24, 2019 at 02:57:59PM +0200, Hans de Goede wrote:
> > > GPD has done it again, make a nice device (good), use way too generic
> > > DMI strings (bad) and use a portrait screen r
Hi,
On 06-06-19 15:38, Maxime Ripard wrote:
On Thu, Jun 06, 2019 at 01:13:40PM +0200, Hans de Goede wrote:
On 06-06-19 11:14, Maxime Ripard wrote:
On Fri, May 24, 2019 at 02:57:59PM +0200, Hans de Goede wrote:
GPD has done it again, make a nice device (good), use way too generic
DMI strings (
Guys, this discussion is getting heated for no reason. Let's put
personal frustrations aside and discuss the issue on its merits:
Maxime Ripard writes:
> On Wed, Jun 05, 2019 at 12:13:17PM +0200, Torsten Duwe wrote:
> > On Tue, Jun 04, 2019 at 08:08:40AM -0700, Vasily Khoruzhick wrote:
> > > On Tu
On 2019-06-06 12:31 p.m., Michel Dänzer wrote:
> On 2019-06-06 12:26 p.m., zhoucm1 wrote:
>> https://gitlab.freedesktop.org/mesa/drm, Where the merge request button?
>
> If you push to a branch in your personal repository, the output of git
> push contains an URL for creating a merge request.
Dan
> -Original Message-
> From: Michel Dänzer
> Sent: Thursday, June 06, 2019 10:09 PM
> To: Zhou, David(ChunMing) ; Koenig, Christian
> ; Zhou, David(ChunMing)
>
> Cc: dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH 1/2] update drm.h
>
> On 2019-06-06 12:31 p.m., Michel Dänzer wrot
Add device tree bindings documentation for the Renesas R-Car Display
Unit Color Management Module.
CMM is the image enhancement module available on each R-Car DU video
channel on Gen2 and Gen3 SoCs (V3H and V3M excluded).
Signed-off-by: Jacopo Mondi
---
.../bindings/display/renesas,cmm.txt
Hello,
this series add support for the Color Management Module (CMM) found on
the R-Car Display Unit output channels. CMM is present in most of the Gen3
SoCs (V3-H and V3-M excluded) and in Gen2 (which is not supported by the
series).
The CMM allows setting 1-D and 3-D gamma tables and generate
Update the 'vsps' property structure in the documentation example to
reflect what's actually implemented in the device tree sources.
Signed-off-by: Jacopo Mondi
---
Documentation/devicetree/bindings/display/renesas,du.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Docume
Add clock definitions for CMM units on Renesas R-Car Gen3 M3-N.
Signed-off-by: Jacopo Mondi
---
drivers/clk/renesas/r8a77965-cpg-mssr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/clk/renesas/r8a77965-cpg-mssr.c
b/drivers/clk/renesas/r8a77965-cpg-mssr.c
index eb1cca58a1e1..58
Add clock definitions for CMM units on Renesas R-Car Gen3 H3.
Signed-off-by: Jacopo Mondi
---
drivers/clk/renesas/r8a7795-cpg-mssr.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c
b/drivers/clk/renesas/r8a7795-cpg-mssr.c
index 86842c9fd314..e8f1d5
Add clock definitions for CMM units on Renesas R-Car Gen3 M3-W.
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
drivers/clk/renesas/r8a7796-cpg-mssr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/clk/renesas/r8a7796-cpg-mssr.c
b/
Add CMM units to Renesas R-Car M3-W device tree and reference them from
the Display Unit they are connected to.
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 25
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77
1 - 100 of 225 matches
Mail list logo
