From: YueHaibing
When building CONFIG_DEBUG_FS is not set
gcc warn this:
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c: In function a6xx_show:
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:1124:2: error: implicit declaration
of function adreno_show; did you mean adreno_dump?
[-Werror=implicit-func
On Mon, Mar 25, 2019 at 11:21 PM Kuehling, Felix wrote:
>
> On 2019-03-20 10:51 a.m., Andrey Konovalov wrote:
> > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > pass tagged user pointers (with the top byte set to something else other
> > than 0x00) as syscall argume
On Tue, Apr 02, 2019 at 01:55:03PM +0800, Qiang Yu wrote:
> Thanks, patch is:
> Reviewed-by: Qiang Yu
This looks like a fairly naive conversion from the old IDR API to the
XArray API. You should be able to remove mgr->lock entirely, relying on
the xa_lock for synchronising free and get. If you
The destroy function in drm_mode_config_cleanup will remove the objects
in ipu-drm-core by calling its destroy functions if the bind function
fails. The drm_encoder is also part of the devres allocated ipu_ldb
object. The ipu_ldb object will already be cleaned up if the bind for
the crtc fails. Thi
The list head is not initialised after imx_ldb_bind
allocates the imx_ldb object. Ensure it will be valid
before anyone uses it.
Signed-off-by: Michael Grzeschik
---
drivers/gpu/drm/imx/imx-ldb.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/imx/imx-ldb.c
From: Wangyan Wang
Recalculate the rate of this clock, by querying hardware to
make implementation of recalc_rate() to match the definition.
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 8 --
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 2 --
drive
Having DEFINE_SRCU() or DEFINE_STATIC_SRCU() in a loadable module
requires that the size of the reserved region be increased, which is not
something we really want to be doing. This commit therefore removes
the DEFINE_STATIC_SRCU() from drivers/gpu/drm/drm_drv.c in favor of
defining drm_unplug_src
- On Apr 2, 2019, at 10:28 AM, paulmck paul...@linux.ibm.com wrote:
> Hello!
>
> This series prohibits use of DEFINE_SRCU() and DEFINE_STATIC_SRCU()
> by loadable modules. The reason for this prohibition is the fact
> that using these two macros within modules requires that the size of
> the
From: Wangyan Wang
Due to a clerical error,there is one zero less for 1280.
Fix it for 12800
Fixes: 0fc721b2968e ("drm/mediatek: add hdmi driver for MT2701 and MT7623")
Reviewed-by: CK Hu
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 4 ++--
1 file c
On Fri, Mar 22, 2019 at 5:01 PM Catalin Marinas wrote:
>
> On Wed, Mar 20, 2019 at 03:51:29PM +0100, Andrey Konovalov wrote:
> > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > pass tagged user pointers (with the top byte set to something else other
> > than 0x00) as
From: Wangyan Wang
This is the second step to make MT2701 HDMI stable.
The factor depends on the divider of DPI in MT2701, therefore,
we should fix this factor to the right and new one.
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +++-
1 file changed, 3 insertion
From: Wangyan Wang
V8 adopt maintainer's suggestion.
Here is the change list between V7 & V8
1. Make title more clear in patch commit message.
2. To make MT2701 HDMI stable, TVDPLL should not be adjusted and
it's the parent clock of HDMI phy, so HDMI phy could not adjust parent
rate. there are
Having DEFINE_SRCU() or DEFINE_STATIC_SRCU() in a loadable module
requires that the size of the reserved region be increased, which is
not something we really want to be doing. This commit therefore removes
the DEFINE_STATIC_SRCU() from drivers/gpu/drm/amd/amdkfd/kfd_process.c in
favor of defining
On Tue, Apr 02, 2019 at 11:14:40AM -0400, Mathieu Desnoyers wrote:
> - On Apr 2, 2019, at 10:28 AM, paulmck paul...@linux.ibm.com wrote:
>
> > Hello!
> >
> > This series prohibits use of DEFINE_SRCU() and DEFINE_STATIC_SRCU()
> > by loadable modules. The reason for this prohibition is the fa
Hi Sam,
Le sam. 16 mars 2019 à 22:59, Sam Ravnborg a écrit
:
Hi Paul.
Thanks for the v2 submission.
Did you analyze the possibility to utilize
drm_simple_display_pipe_init()
and the related infrastructure?
If this fits it should simplify the driver.
If it does not fit please let us know wh
On Tue, Apr 02, 2019 at 08:23:34AM -0700, Paul E. McKenney wrote:
> On Tue, Apr 02, 2019 at 11:14:40AM -0400, Mathieu Desnoyers wrote:
> > - On Apr 2, 2019, at 10:28 AM, paulmck paul...@linux.ibm.com wrote:
> >
> > > Hello!
> > >
> > > This series prohibits use of DEFINE_SRCU() and DEFINE_STA
On Tue, Apr 02, 2019 at 10:50:06AM +1100, Stephen Rothwell wrote:
> +++ b/drivers/gpu/drm/lima/lima_ctx.c
> @@ -23,7 +23,7 @@ int lima_ctx_create(struct lima_device *dev, struct
> lima_ctx_mgr *mgr, u32 *id)
> goto err_out0;
> }
>
> - err = xa_alloc(&mgr->handles,
From: Wangyan Wang
This is the third step to make MT2701 HDMI stable.
We should not change the rate of parent for hdmi phy when
doing round_rate for this clock. The parent clock of hdmi
phy must be the same as it. We change it when doing set_rate
only.
Signed-off-by: Wangyan Wang
---
drivers/g
Hello
On 4/1/19 5:30 AM, Brian Masney wrote:
> Add device tree support to the lm3630a driver and allow configuring
> independently on both banks the mapping mode (linear or exponential),
> initial and maximum LED brightness.
>
> Driver was tested on a LG Nexus 5 (hammerhead) phone.
>
Don't need
Fix the issue: "drm/imx: Crash in drm_mode_config_cleanup".
Which was documented here:
https://www.spinics.net/lists/dri-devel/msg189388.html
And tried to address with this:
https://patchwork.kernel.org/patch/10633297/
https://patchwork.kernel.org/patch/10633299/
This series fixes the possible
Hello
On 4/1/19 5:30 AM, Brian Masney wrote:
> Add new backlight bindings for the TI LM3630A dual-string white LED.
>
> Signed-off-by: Brian Masney
> ---
> .../leds/backlight/lm3630a-backlight.yaml | 112 ++
> 1 file changed, 112 insertions(+)
> create mode 100644
> Docume
The destroy function in drm_mode_config_cleanup will remove the objects
in ipu-drm-core by calling its destroy functions if the bind function
fails. The drm_crtc is also part of the devres allocated ipu_crtc
object. The ipu_crtc object will already be cleaned up if the bind for
the crtc fails. This
From: Wangyan Wang
This is the first step to make MT2701 hdmi stable.
The parent rate of hdmi phy had set by DPI driver.
We should not set or change the parent rate of MT2701 hdmi phy,
as a result we should remove the flags of "CLK_SET_RATE_PARENT"
from the clock of MT2701 hdmi phy.
Signed-off-b
- On Apr 2, 2019, at 11:23 AM, paulmck paul...@linux.ibm.com wrote:
> On Tue, Apr 02, 2019 at 11:14:40AM -0400, Mathieu Desnoyers wrote:
>> - On Apr 2, 2019, at 10:28 AM, paulmck paul...@linux.ibm.com wrote:
>>
>> > Hello!
>> >
>> > This series prohibits use of DEFINE_SRCU() and DEFINE_S
Brian
On 4/2/19 8:24 AM, Brian Masney wrote:
> On Tue, Apr 02, 2019 at 07:56:55AM -0500, Dan Murphy wrote:
>> This would connect control bank B to control bank A. Or just use a flag to
>> denote to connect them
>> and not use led-sources. But led-sources is the property of choice.
>>
>> led@0 {
Hello!
This series prohibits use of DEFINE_SRCU() and DEFINE_STATIC_SRCU()
by loadable modules. The reason for this prohibition is the fact
that using these two macros within modules requires that the size of
the reserved region be increased, which is not something we want to
be doing all that of
On Tue, Apr 02, 2019 at 07:56:55AM -0500, Dan Murphy wrote:
> This would connect control bank B to control bank A. Or just use a flag to
> denote to connect them
> and not use led-sources. But led-sources is the property of choice.
>
> led@0 {
> reg = <0>;
> led-sources = < 0 1 >;
>
On Tue, Apr 2, 2019 at 9:40 AM Christian König
wrote:
> When ttm_put_pages() tries to figure out whether it's dealing with
> transparent hugepages, it just reads past the bounds of the pages array
> without a check.
>
> v2: simplify the test if enough pages are left in the array (Christian).
>
> S
On Tue, Apr 02, 2019 at 09:56:08PM +0800, Qiang Yu wrote:
> On Tue, Apr 2, 2019 at 7:26 PM Matthew Wilcox wrote:
> >
> > On Tue, Apr 02, 2019 at 01:55:03PM +0800, Qiang Yu wrote:
> > > Thanks, patch is:
> > > Reviewed-by: Qiang Yu
> >
> > This looks like a fairly naive conversion from the old IDR
On 4/2/19 11:45 AM, Pavel Machek wrote:
> On Tue 2019-04-02 08:45:40, Dan Murphy wrote:
>> Hello
>>
>> On 4/1/19 5:30 AM, Brian Masney wrote:
>>> Add device tree support to the lm3630a driver and allow configuring
>>> independently on both banks the mapping mode (linear or exponential),
>>> initial
On Tue, Apr 2, 2019 at 6:47 PM Sean Paul wrote:
> On Tue, Apr 02, 2019 at 06:05:48PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 2, 2019 at 3:24 PM Sean Paul wrote:
> > >
> > > On Tue, Apr 02, 2019 at 09:49:00AM +0200, Daniel Vetter wrote:
> > > > On Mon, Apr 01, 2019 at 09:49:30AM -0400, Sean Pa
On Tue, Apr 2, 2019 at 10:43 PM Gerd Hoffmann wrote:
>
> On Tue, Apr 02, 2019 at 02:09:45PM +0200, Daniel Vetter wrote:
> > On Mon, Apr 1, 2019 at 4:00 PM Bartlomiej Zolnierkiewicz
> > wrote:
> > >
> > >
> > > On 03/14/2019 12:45 PM, Gerd Hoffmann wrote:
> > > > Simply add all pci memory bars to
Hi Andrew,
On Mon, 1 Apr 2019 at 20:38, Christian König
wrote:
>
> Am 29.03.19 um 17:52 schrieb Andrew F. Davis:
> > The docs state the callback is optional but it is not, make it optional.
> >
> > Signed-off-by: Andrew F. Davis
>
> Reviewed-by: Christian König
Thanks for the patch; I will que
On Mon, Apr 1, 2019 at 2:12 PM Robin Murphy wrote:
>
> On 01/04/2019 08:47, Rob Herring wrote:
> > This adds the initial driver for panfrost which supports Arm Mali
> > Midgard and Bifrost family of GPUs. Currently, only the T860 and
> > T760 Midgard GPUs have been tested.
>
> FWIW, on an antique
On Tue, Apr 2, 2019 at 8:24 AM Brian Masney wrote:
>
> On Tue, Apr 02, 2019 at 07:56:55AM -0500, Dan Murphy wrote:
> > This would connect control bank B to control bank A. Or just use a flag to
> > denote to connect them
> > and not use led-sources. But led-sources is the property of choice.
>
On Thu, 14 Mar 2019 at 18:07, Boris Brezillon
wrote:
>
> On Thu, 28 Feb 2019 15:49:07 +0100
> Daniel Vetter wrote:
>
> > The lessor is invariant over a lifetime of a lease, we don't have to
> > grab any locks for that. Speeds up the common case of not being a lease.
> >
> > Cc: Keith Packard
> >
https://bugs.freedesktop.org/show_bug.cgi?id=110258
--- Comment #2 from Ethan ---
I am experiencing the exact same issue on my Dell Inspiron 3185 with a Stoney
Ridge A9-9420e. I have tried multiple kernels and distributions and I
experience the same freeze as described on resume from suspend. (I
Indeed not that important, so patch 5&7 is:
Reviewed-and-tested-by: Qiang Yu
Regards,
Qiang
On Wed, Apr 3, 2019 at 12:57 AM Eric Anholt wrote:
>
> Qiang Yu writes:
>
> > On Tue, Apr 2, 2019 at 6:26 AM Eric Anholt wrote:
> >>
> >> I haven't tested this, but it's a pretty direct port of what I
v3: Fix up drmP and IRQ flag, thanks Sam
v2: Address review from Noralf and Daniel, add maintainers patch
This driver is for the ASPEED BMC SoC's GFX display hardware. This
driver runs on the ARM based BMC systems, unlike the ast driver which
runs on a host CPU and is is for a PCIe graphics device
This driver is for the ASPEED BMC SoC's GFX display hardware. This
driver runs on the ARM based BMC systems, unlike the ast driver which
runs on a host CPU and is is for a PCI graphics device.
Signed-off-by: Joel Stanley
Acked-by: Daniel Vetter
Reviewed-by: Noralf Trønnes
Reviewed-by: Sam Ravnb
This hardware is found inside ASPEED Baseboard Management Controller
(BMC) system on chips. It is called the 'SOC Display Controller' or 'GFX'.
Signed-off-by: Joel Stanley
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index c18f5f10cf91..c3
This describes the ASPEED BMC SoC's display controller.
Signed-off-by: Joel Stanley
Reviewed-by: Andrew Jeffery
---
v3:
Add Andrew's reviewed-by
.../devicetree/bindings/gpu/aspeed-gfx.txt| 41 +++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetre
On Tue, 2 Apr 2019 at 06:26, Sam Ravnborg wrote:
>
> Hi Joel
>
> > index ..fb56e425bd48
> > --- /dev/null
> > +++ b/drivers/gpu/drm/aspeed/aspeed_gfx.h
> > @@ -0,0 +1,104 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +// Copyright 2018 IBM Corporation
> > +
> > +#include
> > +#incl
On 4/2/19 2:52 PM, Manasi Navare wrote:
Some eDP 1.4 panels cannot use the optimized fast and narrow pipe
config approach, but they need to use th maximum supported lane count
for the link training to succeed.
There is a DRM EDID quirk for such panels that gets set after reading
their correspond
On 4/2/19 2:52 PM, Manasi Navare wrote:
For certain eDP 1.4 panels, we need to use max lane count for the
link training to succeed.
This patch adds a EDID quirk for such eDP panels using
their vendor ID and product ID to force using max lane count in the driver.
Cc: Clint Taylor
Cc: Ville Syr
Some eDP 1.4 panels cannot use the optimized fast and narrow pipe
config approach, but they need to use th maximum supported lane count
for the link training to succeed.
There is a DRM EDID quirk for such panels that gets set after reading
their corresponding EDID.
So if it is set, this patch force
For certain eDP 1.4 panels, we need to use max lane count for the
link training to succeed.
This patch adds a EDID quirk for such eDP panels using
their vendor ID and product ID to force using max lane count in the driver.
Cc: Clint Taylor
Cc: Ville Syrjälä
Tested-by: Albert Astals Cid
Tested-
https://bugzilla.kernel.org/show_bug.cgi?id=201497
Daniel Andersson (engyw...@gmail.com) changed:
What|Removed |Added
Kernel Version|4.19 4.20 5.0-rc1 5.0-rc3 |4.19 4.20 5.0-rc1
On Mon, Apr 1, 2019 at 6:41 PM Tom Li wrote:
>
> On Sun, Mar 31, 2019 at 08:08:01PM +0100, Sudip Mukherjee wrote:
> > Technically I donot have any problem with this, you seem to know more
> > about SM712 than I know. But Teddy Wang is also an existing maintainer
> > and I think there should be an
On Mon, Apr 1, 2019 at 6:30 PM Tom Li wrote:
>
> On Sun, Mar 31, 2019 at 07:54:28PM +0100, Sudip Mukherjee wrote:
> > On Fri, Mar 22, 2019 at 01:17:57PM +0800, Yifeng Li wrote:
> > > +video controllers. This series of video controller is a legacy from
> > > ~1998,
> > > +and was used on many clas
On Mon, Apr 1, 2019 at 5:42 PM Tom Li wrote:
>
> On Sun, Mar 31, 2019 at 07:33:33PM +0100, Sudip Mukherjee wrote:
> > Why are you removing existing functionality from the driver? These are
> > supported but were never listed so could not be used. I think you can
> > just add these to vesa_mode_tab
On Mon, Apr 1, 2019 at 5:26 PM Tom Li wrote:
>
> On Sun, Mar 31, 2019 at 07:09:47PM +0100, Sudip Mukherjee wrote:
> > On Fri, Mar 22, 2019 at 01:17:55PM +0800, Yifeng Li wrote:
> > I didnot notice any performace improvement in my system. Infact, I have
> > never seen the performance problem that y
On Tue, Apr 02, 2019 at 02:09:45PM +0200, Daniel Vetter wrote:
> On Mon, Apr 1, 2019 at 4:00 PM Bartlomiej Zolnierkiewicz
> wrote:
> >
> >
> > On 03/14/2019 12:45 PM, Gerd Hoffmann wrote:
> > > Simply add all pci memory bars to struct apertures_struct in
> > > remove_conflicting_pci_framebuffers()
Hi Uma.
Some kerneldoc nits below.
Sam
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -599,6 +599,13 @@ struct drm_connector_state {
>* and the connector bpc limitations obtained from edid.
>*/
> u8 max_bpc;
> +
> + /**
> + * @
Hi Uma.
Noticed a kerneldoc nit while browsign the code.
Maybe try to let kernel doc tell you if there are more.
Sam
>
> /**
> + * drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI AVI infoframe with
> + * HDR metadata from userspace
> + * @f
Enable writing of HDR metadata infoframe to panel.
The data will be provid by usersapace compositors, based
on blending policies and passsed to driver through a blob
property.
v2: Rebase
v3: Fixed a warning message
v4: Addressed Shashank's review comments
v5: Rebase. Added infoframe calculation
HDR metadata requires a infoframe to be set. Due to fastset,
full modeset is not performed hence adding it to update_pipe
to handle that.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_ddi.c | 13 +
1 file changed, 13 insertions(+)
diff --git
This patch enables modeset whenever HDR metadata
needs to be updated to sink.
v2: Addressed Shashank's review comments.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_atomic.c | 14 +-
drivers/gpu/drm/i915/intel_hdmi.c | 9 +
2 fil
From: Ville Syrjälä
This patch enables infoframes on GLK+ to be
used to send HDR metadata to HDMI sink.
v2: Addressed Shashank's review comment.
v3: Addressed Shashank's review comment.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h | 4
This patch series enables HDR support in drm. It basically defines
HDR metadata structures, property to pass content (after blending)
metadata from user space compositors to driver.
Dynamic Range and Mastering infoframe creation and sending.
ToDo:
1. We need to get the color framework in place fo
HDR metadata block is introduced in CEA-861.3 spec.
Parsing the same to get the panel's HDR metadata.
v2: Rebase and added Ville's POC changes to the patch.
v3: No Change
v4: Addressed Shashank's review comments
v5: Addressed Shashank's comment and added his RB.
Signed-off-by: Uma Shankar
Rev
From: Ville Syrjälä
ADD HLG EOTF to the list of EOTF transfer functions supported.
Hybrid Log-Gamma (HLG) is a high dynamic range (HDR) standard.
HLG defines a nonlinear transfer function in which the lower
half of the signal values use a gamma curve and the upper half
of the signal values use a
Attach HDR metadata property to connector object.
v2: Rebase
v3: Updated the property name as per updated name
while creating hdr metadata property
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Enable Dynamic Range and Mastering Infoframe for HDR
content, which is defined in CEA 861.3 spec.
The metadata will be computed based on blending
policy in userspace compositors and passed as a connector
property blob to driver. The same will be sent as infoframe
to panel which support HDR.
Added
This patch adds a blob property to get HDR metadata
information from userspace. This will be send as part
of AVI Infoframe to panel.
It also implements get() and set() functions for HDR output
metadata property.The blob data is received from userspace and
saved in connector state, the same is retu
When the logo is currently drawn on a virtual console, and the console
loglevel is reduced to quiet, logo_shown must be left alone, so that it
the scrolling region on that virtual console is properly reset.
Fixes: 10993504d647 ("fbcon: Silence fbcon logo on 'quiet' boots")
Signed-off-by: Andreas S
On 2019-04-02 10:37 a.m., Andrey Konovalov wrote:
> On Mon, Mar 25, 2019 at 11:21 PM Kuehling, Felix
> wrote:
>> On 2019-03-20 10:51 a.m., Andrey Konovalov wrote:
>>> This patch is a part of a series that extends arm64 kernel ABI to allow to
>>> pass tagged user pointers (with the top byte set to
On Apr 02 2019, Prarit Bhargava wrote:
> On 4/1/19 3:31 PM, Andreas Schwab wrote:
>> On Jan 29 2019, Prarit Bhargava wrote:
>>
>>> @@ -1066,6 +1069,9 @@ static void fbcon_init(struct vc_data *vc, int init)
>>>
>>> cap = info->flags;
>>>
>>> + if (console_loglevel <= CONSOLE_LOGLEVEL_Q
On 01/04/2019 17:06, Liviu Dudau wrote:
On Fri, Mar 29, 2019 at 06:46:21PM +, Robin Murphy wrote:
On 19/03/2019 14:49, Liviu Dudau wrote:
On Tue, Mar 19, 2019 at 01:14:54PM +, Robin Murphy wrote:
[ +Sudeep - just FYI ]
Hi Liviu,
On 27/02/2019 09:40, Liviu Dudau wrote:
Hi Robin,
Sor
On 2019-04-02 10:29 a.m., Paul E. McKenney wrote:
> Having DEFINE_SRCU() or DEFINE_STATIC_SRCU() in a loadable module
> requires that the size of the reserved region be increased, which is
> not something we really want to be doing. This commit therefore removes
> the DEFINE_STATIC_SRCU() from dri
Hi Dave, Daniel,
Same pull as last week, but with a warning fix on top.
The following changes since commit fbac3c48fa6b4cfa43eaae39d5a53269bff7ec5f:
Merge branch 'drm-next-5.1' of git://people.freedesktop.org/~agd5f/linux into
drm-next (2019-02-22 15:56:42 +1000)
are available in the Git rep
Qiang Yu writes:
> On Tue, Apr 2, 2019 at 6:26 AM Eric Anholt wrote:
>>
>> I haven't tested this, but it's a pretty direct port of what I did for
>> v3d.
>>
>> Signed-off-by: Eric Anholt
>> ---
>> drivers/gpu/drm/lima/lima_gem.c | 37 +
>> drivers/gpu/drm/lima/lima_sched.c |
On Tue, Apr 02, 2019 at 06:05:48PM +0200, Daniel Vetter wrote:
> On Tue, Apr 2, 2019 at 3:24 PM Sean Paul wrote:
> >
> > On Tue, Apr 02, 2019 at 09:49:00AM +0200, Daniel Vetter wrote:
> > > On Mon, Apr 01, 2019 at 09:49:30AM -0400, Sean Paul wrote:
> > > > On Fri, Mar 29, 2019 at 08:21:31PM +0100,
On Tue 2019-04-02 08:45:40, Dan Murphy wrote:
> Hello
>
> On 4/1/19 5:30 AM, Brian Masney wrote:
> > Add device tree support to the lm3630a driver and allow configuring
> > independently on both banks the mapping mode (linear or exponential),
> > initial and maximum LED brightness.
> >
> > Driver
https://bugzilla.kernel.org/show_bug.cgi?id=200695
Claude Heiland-Allen (cla...@mathr.co.uk) changed:
What|Removed |Added
Kernel Version|4.17.19, 4.18.5 through |4.17.19, 4.18.
https://bugzilla.kernel.org/show_bug.cgi?id=200695
--- Comment #31 from Claude Heiland-Allen (cla...@mathr.co.uk) ---
Created attachment 282101
--> https://bugzilla.kernel.org/attachment.cgi?id=282101&action=edit
dmesg logs after booting to X with displays connected to both DVI and HDMI
Good ne
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville
>Syrjälä
>Sent: Friday, March 29, 2019 7:35 PM
>To: Shankar, Uma
>Cc: Syrjala, Ville ; liviu.du...@arm.com; intel-
>g...@lists.freedesktop.org; emil.l.veli...@gmail.com; dri-
>de...
On Tue, Apr 02, 2019 at 07:29:31AM -0700, Paul E. McKenney wrote:
> Having DEFINE_SRCU() or DEFINE_STATIC_SRCU() in a loadable module
> requires that the size of the reserved region be increased, which is not
> something we really want to be doing. This commit therefore removes
> the DEFINE_STATIC
On Tue, Apr 2, 2019 at 3:24 PM Sean Paul wrote:
>
> On Tue, Apr 02, 2019 at 09:49:00AM +0200, Daniel Vetter wrote:
> > On Mon, Apr 01, 2019 at 09:49:30AM -0400, Sean Paul wrote:
> > > On Fri, Mar 29, 2019 at 08:21:31PM +0100, Daniel Vetter wrote:
> > > > On Fri, Mar 29, 2019 at 7:10 PM Sean Paul
On Tue, Apr 02, 2019 at 06:36:21PM +0300, Tomi Valkeinen wrote:
> On 21/11/2018 18:09, Sebastian Reichel wrote:
> > Hi,
> >
> > Here is another round of the DSI command mode panel patchset
> > integrating the feedback from PATCHv4. The patches are based
> > on 4.20-rc1 + fixes from Laurent and Ton
Hi Michael,
On Tue, 2019-04-02 at 15:49 +0200, Michael Grzeschik wrote:
> The destroy function in drm_mode_config_cleanup will remove the objects
> in ipu-drm-core by calling its destroy functions if the bind function
> fails. The drm_crtc is also part of the devres allocated ipu_crtc
> object. Th
Hi Sebastian,
On 21/11/2018 18:09, Sebastian Reichel wrote:
> Hi,
>
> Here is another round of the DSI command mode panel patchset
> integrating the feedback from PATCHv4. The patches are based
> on 4.20-rc1 + fixes from Laurent and Tony. I dropped the patches
> for OMAP3 support (it needs a work
Hi Emil,
On Tue, Apr 02, 2019 at 10:43:31AM +0100, Emil Velikov wrote:
> On Tue, 19 Mar 2019 at 21:57, Maxime Ripard wrote:
> > drm_format_num_planes() is basically a lookup in the drm_format_info table
> > plus an access to the num_planes field of the appropriate entry.
> >
> > Most drivers are
On Thu, Mar 28, 2019 at 05:23:39PM +0530, Jagan Teki wrote:
> On Tue, Mar 19, 2019 at 4:26 PM Maxime Ripard
> wrote:
> >
> > On Mon, Mar 11, 2019 at 08:28:22PM +0530, Jagan Teki wrote:
> > > On Mon, Mar 11, 2019 at 7:39 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Thu, Mar 07, 2019 at 09:24
On Thu, Mar 21, 2019 at 08:08:58PM +0530, Jagan Teki wrote:
> On Tue, Mar 19, 2019 at 3:55 PM Maxime Ripard
> wrote:
> >
> > On Mon, Mar 11, 2019 at 09:31:11PM +0530, Jagan Teki wrote:
> > > On Mon, Mar 11, 2019 at 9:07 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Mon, Mar 11, 2019 at 07:06
On Thu, Mar 21, 2019 at 07:40:32PM +0530, Jagan Teki wrote:
> On Tue, Mar 19, 2019 at 4:23 PM Maxime Ripard
> wrote:
> >
> > On Mon, Mar 11, 2019 at 09:36:27PM +0530, Jagan Teki wrote:
> > > On Mon, Mar 11, 2019 at 9:08 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Mon, Mar 11, 2019 at 07:06
Hi,
Le lundi 01 avril 2019 à 11:35 -0700, Eric Anholt a écrit :
> The global list of all debugfs entries for the driver was painful: the
> list couldn't see into the components' structs, so each component had
> its own debugs show function to find the component, then find the
> regset and dump it.
Hi,
On Mon, 2019-04-01 at 11:35 -0700, Eric Anholt wrote:
> One might want to use the VC4 display stack without using Mesa.
> Similar to the debugfs fixes for not having all of the possible
> display bits enabled, make sure you can't oops in vc4 if v3d isn't
> enabled.
>
> v2: Fix matching agains
On Tue, Apr 02, 2019 at 09:49:00AM +0200, Daniel Vetter wrote:
> On Mon, Apr 01, 2019 at 09:49:30AM -0400, Sean Paul wrote:
> > On Fri, Mar 29, 2019 at 08:21:31PM +0100, Daniel Vetter wrote:
> > > On Fri, Mar 29, 2019 at 7:10 PM Sean Paul wrote:
> > > >
> > > > On Fri, Mar 29, 2019 at 04:36:32PM +
https://bugs.freedesktop.org/show_bug.cgi?id=109345
--- Comment #9 from Alex Deucher ---
They are still only partial logs. you should just be able to redirect the
output to a file right after you log in. E.g., `dmesg > dmesg.txt`
--
You are receiving this mail because:
You are the assignee fo
On Tue, Apr 2, 2019 at 7:26 PM Matthew Wilcox wrote:
>
> On Tue, Apr 02, 2019 at 01:55:03PM +0800, Qiang Yu wrote:
> > Thanks, patch is:
> > Reviewed-by: Qiang Yu
>
> This looks like a fairly naive conversion from the old IDR API to the
> XArray API. You should be able to remove mgr->lock entire
Cc: Stephen Rothwell
Cc: Matthew Wilcox
Cc: Daniel Vetter
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_ctx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/lima/lima_ctx.c b/drivers/gpu/drm/lima/lima_ctx.c
index c8d12f7c6894..22fff6caa961 100644
--
Hi Maxime,
On Thu, Mar 21, 2019 at 8:08 PM Jagan Teki wrote:
>
> On Tue, Mar 19, 2019 at 3:55 PM Maxime Ripard
> wrote:
> >
> > On Mon, Mar 11, 2019 at 09:31:11PM +0530, Jagan Teki wrote:
> > > On Mon, Mar 11, 2019 at 9:07 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Mon, Mar 11, 2019 at
Hi Maxime,
On Thu, Mar 21, 2019 at 7:40 PM Jagan Teki wrote:
>
> On Tue, Mar 19, 2019 at 4:23 PM Maxime Ripard
> wrote:
> >
> > On Mon, Mar 11, 2019 at 09:36:27PM +0530, Jagan Teki wrote:
> > > On Mon, Mar 11, 2019 at 9:08 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Mon, Mar 11, 2019 at
On Tue, Apr 2, 2019 at 7:21 PM Matthew Wilcox wrote:
>
> On Tue, Apr 02, 2019 at 10:50:06AM +1100, Stephen Rothwell wrote:
> > +++ b/drivers/gpu/drm/lima/lima_ctx.c
> > @@ -23,7 +23,7 @@ int lima_ctx_create(struct lima_device *dev, struct
> > lima_ctx_mgr *mgr, u32 *id)
> >
On Tue, Apr 02, 2019 at 09:49:00AM +0200, Daniel Vetter wrote:
> On Mon, Apr 01, 2019 at 09:49:30AM -0400, Sean Paul wrote:
> > On Fri, Mar 29, 2019 at 08:21:31PM +0100, Daniel Vetter wrote:
> > > On Fri, Mar 29, 2019 at 7:10 PM Sean Paul wrote:
> > > >
> > > > On Fri, Mar 29, 2019 at 04:36:32PM +
On 02/04/2019 14.21, Laurent Pinchart wrote:
> Hi Peter,
>
> Thank you for the patch.
>
> On Mon, Apr 01, 2019 at 03:33:42PM +0300, Peter Ujfalusi wrote:
>> In case either the HPD gpio is not specified or when the HPD gpio can not
>> be used as interrupt we should tell the core that the HPD nee
https://bugs.freedesktop.org/show_bug.cgi?id=109695
--- Comment #12 from Marek Olšák ---
(In reply to Michel Dänzer from comment #8)
> Mesa doesn't really need explicit thread affinity at all. All it wants is
> that certain sets of threads run on the same CPU module; it doesn't care
> which parti
https://bugs.freedesktop.org/show_bug.cgi?id=110045
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Mon, Apr 01, 2019 at 08:18:13PM +, Jim Zhang wrote:
> Hi Sir/Madam:
>
> I am using the open source Baytrail gpu drm driver.
>
> Linux kernel version 3.10.61:
> Libdrm package: 2.4.97
>
> When calling function
> properties = drmModeObjectGetProperties(drmfd, plane_id,
> DRM_MODE_OBJECT_P
1 - 100 of 189 matches
Mail list logo
