On 7/25/19 5:52 AM, Yue Hu wrote:
From: Yue Hu
Since governor name is defined by DEVFREQ framework internally, use the
macro definition instead of using the name directly.
Signed-off-by: Yue Hu
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/msm/msm_gpu.c | 3 ++-
drivers/gpu
The drm_format_info doesn't have any cpp or block_size (both are zero)
information for arm only afbc format YU08/YU10. we need to compute it
by ourselves.
Signed-off-by: Lowry Li (Arm Technology China)
---
.../drm/arm/display/komeda/komeda_format_caps.c| 23 ++
.../drm/ar
Initialize and enable output polling on Komeda.
Signed-off-by: Lowry Li (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
b/drivers/gpu/drm/arm/display/komeda/komeda_
Hi Artur,
On 7/23/19 15:20, Artur Świgoń wrote:
> This patch adds interconnect functionality to the exynos-bus devfreq
> driver.
>
> The SoC topology is a graph (or, more specifically, a tree) and most of its
> edges are taken from the devfreq parent-child hierarchy (cf.
> Documentation/devicetre
This patch adds the checks for vrefresh, crtc_hdisplay and crtc_vdisplay.
Signed-off-by: Lowry Li (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/display/k
Hi Andrzej.
After reading through the series a few more comments.
1) The subject of this patch could be improved.
Consider something like:
drm: add ddc link in sysfs created by drm_connector
This spells out much better what the patch achieve.
2) The purpsoe of drm_connector.ddc is to
Current DRM-CORE accepts the writeback_job with a empty fb, but that
is an invalid job for HW, so need to skip it when commit it to HW.
Signed-off-by: Lowry Li (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 2 +-
drivers/gpu/drm/arm/display/komeda/komeda_wb
On Thu 2019-07-25 13:21:12, Brendan Higgins wrote:
> On Wed, Jul 24, 2019 at 12:31 AM Petr Mladek wrote:
> >
> > On Mon 2019-07-22 16:54:10, Stephen Boyd wrote:
> > > Quoting Brendan Higgins (2019-07-22 15:30:49)
> > > > On Mon, Jul 22, 2019 at 1:03 PM Stephen Boyd wrote:
> > > > >
> > > > >
> >
Quoting Chenbo Feng (2019-06-13 23:34:07)
> From: Greg Hackmann
>
> This patch adds complimentary DMA_BUF_SET_NAME ioctls, which lets
> userspace processes attach a free-form name to each buffer.
>
> This information can be extremely helpful for tracking and accounting
> shared buffers. For ex
If the panel is wrapped in a panel_bridge it gets prepar()ed before the
upstream DSI bridge which can cause hangs (e.g. with imx-nwl since clocks
are not enabled yet). To avoid this move the panel's first DSI access to
enable() so the upstream bridge can prepare the DSI host controller in
it's pre_
This makes it symmetric with the panel init happening in enable().
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
b/drivers/gpu/
If the panel is wrapped in a panel_bridge it gets prepar()ed before the
upstream DSI bridge which can cause hangs (e.g. with imx-nwl since clocks
are not enabled yet). To avoid this move the panel's first DSI access to
enable() so the upstream bridge can prepare the DSI host controller in
it's pre_
Most of them had these already but two mere missing. This eases
debugging.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
b/drivers/g
Hi Guido.
A few comments follows.
Sam
On Wed, Jul 24, 2019 at 05:52:25PM +0200, Guido Günther wrote:
> The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
>
> Signed-off-by: Guido Günther
> ---
> .../bindings/display/bridge/imx-nwl-dsi.txt | 89 +++
On 26/07/2019 10:15, Steven Price wrote:
On 25/07/2019 22:11, Rob Herring wrote:
On Thu, Jul 25, 2019 at 7:08 AM Robin Murphy
wrote:
Hi Rob,
On 25/07/2019 02:10, Rob Herring wrote:
[...]
@@ -328,6 +427,18 @@ static irqreturn_t panfrost_mmu_irq_handler(int
irq, void *data)
ac
On 25/07/2019 02:09, Rob Herring wrote:
> If a driver does its own management of pages, the shmem helper object's
> pages array could be allocated when a SG table is not. There's not
> really any good reason to tie putting pages with having a SG table when
> freeing the object, so just put pages i
Hi Emil Velikov:
First of all, thank you for your comments.
> + struct gpio_desc *enable_gpio;
> + struct gpio_desc *pp33_gpio;
> + struct gpio_desc *pp18_gpio;
DT claims that these gpios are required, yet one is using the optional gpio
API.
Is the code off, or does the DT need
Hi there!
I try the kernel 5.3.0-050300rc1-generic and almost everything works
perfectly, except there's no sound in HDMI!!!
Pavucontrol show me device unplugged!
But I have now work properly NIC and GPU!
lspci
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h
(Models 60h-6fh) P
Awesome, thanks for the update! I will wait for the next upstrem...
Besides this minor problem everything is wonderful!
Even retroarch works now!
With 4.18.x 5.1.x and 5.2.x freeze the entire system when access amdgpu...
Thanks a lot!
---
Gilberto Nunes Ferreira
(47) 3025-5907
(47) 99676-7530 - W
On 25/07/2019 17:13, Alyssa Rosenzweig wrote:
>> Either we should prevent mapping of HEAP objects
>
> I'm good with that. AFAIK, HEAP objects shouldn't be (CPU) mmapped
> anyway in normal use; if you need them mapped (for debugging etc), it's
> no big deal to just.. not set the HEAP flag in debug
On 25/07/2019 22:28, Rob Herring wrote:
On Thu, Jul 25, 2019 at 9:35 AM Steven Price wrote:
On 25/07/2019 15:59, Steven Price wrote:
[...]
It would appear that in the following call sgt==NULL:
ret = sg_alloc_table_from_pages(sgt, pages + page_offset,
On 25/07/2019 02:09, Rob Herring wrote:
> Setting the GPU VA when creating the GEM object doesn't allow for any
> conditional adjustments. In preparation to support adjusting the
> mapping, restructure the GEM object creation to map the GEM object after
> we've created the base shmem object.
>
> C
It is unclear why max-memory-bandwidth should be set for CLCD on the
fast model. Removing that property allows allocating and using 32bpp
buffers, which may be desirable on certain platforms such as
Android.
Reported-by: Ruben Ayrapetyan
Signed-off-by: Kevin Brodsky
---
Changes in v2:
- Remove
On 25/07/2019 02:10, Rob Herring wrote:
> The midgard/bifrost GPUs need to allocate GPU heap memory which is
> allocated on GPU page faults and not pinned in memory. The vendor driver
> calls this functionality GROW_ON_GPF.
>
> This implementation assumes that BOs allocated with the
> PANFROST_BO_
Remove duplicated include.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 193d6f1..a14
Hi there
> What about other versions (eg. v4.19) ?
> Which is the last working version ?
The only series that works properly is 4.15.x
> Could you also try 5.3 ?
I will, ASAP!
>> Oh! By the way, the network card r8169 are work wonderful!
>Didn't you say (above) that it does not work ?
>Or is it
On 25/07/2019 02:10, Rob Herring wrote:
> Executable buffers have an alignment restriction that they can't cross
> 16MB boundary as the GPU program counter is 24-bits. This restriction is
> currently not handled and we just get lucky. As current userspace
> assumes all BOs are executable, that has
at 00:03, wrote:
-Original Message-
From: Daniel Vetter On Behalf Of Daniel Vetter
Sent: Wednesday, July 24, 2019 6:49 AM
To: Kai-Heng Feng
Cc: dri-devel@lists.freedesktop.org; Anthony Wong; Limonciello, Mario
Subject: Re: OLED panel brightness support
[EXTERNAL EMAIL]
On Tue, Jul
> Sorry, I was being sloppy again![1] I meant CPU mmapped.
No worries, just wanted to check :)
> Apparently the blob in some cases creates a SAME_VA GROW_ON_GPF buffer -
> since SAME_VA means permanently mapped on the CPU this translated to
> mmapping a HEAP object. Why it does this I've no idea
On 7/24/19 6:14 PM, Jason Gunthorpe wrote:
On Tue, Jul 23, 2019 at 02:05:06PM -0700, Ralph Campbell wrote:
The hmm_mirror_ops callback function sync_cpu_device_pagetables() passes
a struct hmm_update which is a simplified version of struct
mmu_notifier_range. This is unnecessary so replace hmm_
> Either we should prevent mapping of HEAP objects
I'm good with that. AFAIK, HEAP objects shouldn't be (CPU) mmapped
anyway in normal use; if you need them mapped (for debugging etc), it's
no big deal to just.. not set the HEAP flag in debug builds.
Or do you mean GPU mapping?
signature.asc
De
Hi,
Am Mittwoch, 24. Juli 2019, 14:33:06 CEST schrieb Linus Walleij:
> On Tue, Jul 23, 2019 at 5:19 PM Fabian Vogt wrote:
>
> > I gave the series a try (virtual CX and TP so far, will do on a real CX
> > later):
> > OOPS with a nullptr deref during probe.
> > This diff which just moves some lin
On 25/07/2019 02:09, Rob Herring wrote:
> Panfrost has a need for pages allocated on demand via GPU page faults.
> When releasing the pages, the only thing preventing using
> drm_gem_put_pages() is needing to skip over unpopulated pages, so allow
> for skipping over NULL struct page pointers.
>
>
It may be desirable on certain platforms, such as Android, to
use 32bpp buffers. Since there is no clear bandwidth limit for the
CLCD component on the fast model, let's increase
max-memory-bandwidth to allow using 32bpp buffers.
Reported-by: Ruben Ayrapetyan
Signed-off-by: Kevin Brodsky
---
arc
On 25/07/2019 16:15, Robin Murphy wrote:
Hi Kevin,
Hi Robin,
On 25/07/2019 15:50, Kevin Brodsky wrote:
It may be desirable on certain platforms, such as Android, to
use 32bpp buffers. Since there is no clear bandwidth limit for the
CLCD component on the fast model, let's increase
max-memory-
On 25/07/2019 15:59, Steven Price wrote:
[...]
> It would appear that in the following call sgt==NULL:
>> ret = sg_alloc_table_from_pages(sgt, pages + page_offset,
>> NUM_FAULT_PAGES, 0, SZ_2M, GFP_KERNEL);
>
> Which means we've ended up with a BO with bo-
On Wed, Jul 24, 2019 at 08:52:51AM +0200, Christoph Hellwig wrote:
> Hi Jérôme, Ben and Jason,
>
> below is a series against the hmm tree which fixes up the mmap_sem
> locking in nouveau and while at it also removes leftover legacy HMM APIs
> only used by nouveau.
>
> The first 4 patches are a bu
This series is:
Acked-by: Alyssa Rosenzweig
On Wed, Jul 24, 2019 at 07:09:56PM -0600, Rob Herring wrote:
> This series adds new BO allocation flags PANFROST_BO_HEAP and
> PANFROST_BO_NOEXEC. The heap allocations are paged in on GPU page faults.
>
> This is based on drm-misc-next. A branch is he
On 25/07/2019 22:11, Rob Herring wrote:
On Thu, Jul 25, 2019 at 7:08 AM Robin Murphy wrote:
Hi Rob,
On 25/07/2019 02:10, Rob Herring wrote:
[...]
@@ -328,6 +427,18 @@ static irqreturn_t panfrost_mmu_irq_handler(int irq, void
*data)
access_type = (fault_status >> 8) & 0x3;
The bridge might have special requirmentes on the input bus. This
is e.g. used by the imx-nwl bridge.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/
The bridge might have special requirmentes on the input bus. This
is e.g. used by the imx-nwl bridge.
Robert, maybe you can add this patch to your 'Improvements and fixes for mxsfb
DRM driver' since it depends on the first patch in this series anyway?
Tested with 'Improvements and fixes for mxsfb
On Thu, Jul 25, 2019 at 04:32:24PM +0200, Sam Ravnborg wrote:
> There was no users left - so drop the code to support EARLY_FB_BLANK.
Why are we using a different noun for the subject and description?
> This patch removes the support in backlight,
> and drop the notifier in fbmem.
>
> That EARLY
Hi Guido.
Following some trivial comments.
As for the overall design I already commented on that in the binding.
(bridge versus display controller)
That it can work on top of mxsfb is a good indication that it is a
bridge but I just do not see the full picture.
In general the code looked clean an
Hi Guido.
On Fri, Jul 26, 2019 at 11:21:42AM +0200, Guido Günther wrote:
> This makes it symmetric with the panel init happening in enable().
>
> Signed-off-by: Guido Günther
> ---
> drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletio
From: Thierry Reding
Failing to find a panel-timing node is not an error in all cases, so do
not output an error message in that case. Instead turn it into a debug
message and make the drivers that care about it output an error message
of their own.
Signed-off-by: Thierry Reding
---
drivers/gp
https://bugs.freedesktop.org/show_bug.cgi?id=111224
Bug ID: 111224
Summary: Wireless Network Deployment
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priorit
https://bugs.freedesktop.org/show_bug.cgi?id=111224
sushanthpandiri changed:
What|Removed |Added
URL||https://www.fieldengineer.c
Hi Guido.
On Fri, Jul 26, 2019 at 11:21:40AM +0200, Guido Günther wrote:
> If the panel is wrapped in a panel_bridge it gets prepar()ed before the
> upstream DSI bridge which can cause hangs (e.g. with imx-nwl since clocks
> are not enabled yet). To avoid this move the panel's first DSI access to
On Thu, 25 Jul 2019 at 14:44, Chanwoo Choi wrote:
>
> 2019년 7월 24일 (수) 오전 8:09, Artur Świgoń 님이 작성:
> >
> > This patch adds a new static function, exynos_bus_profile_init(), extracted
> > from exynos_bus_probe().
> >
> > Signed-off-by: Artur Świgoń
> > ---
> > drivers/devfreq/exynos-bus.c | 106
On Thu, 25 Jul 2019 at 14:51, Chanwoo Choi wrote:
>
> 2019년 7월 24일 (수) 오전 8:07, Artur Świgoń 님이 작성:
> >
> > This patch adds minor improvements to the exynos-bus driver.
> >
> > Signed-off-by: Artur Świgoń
> > ---
> > drivers/devfreq/exynos-bus.c | 49
> > 1 f
On 19. 7. 26. 오후 7:42, Krzysztof Kozlowski wrote:
> On Thu, 25 Jul 2019 at 14:44, Chanwoo Choi wrote:
>>
>> 2019년 7월 24일 (수) 오전 8:09, Artur Świgoń 님이 작성:
>>>
>>> This patch adds a new static function, exynos_bus_profile_init(), extracted
>>> from exynos_bus_probe().
>>>
>>> Signed-off-by: Artur Św
On 2019-07-26 11:49, Guido Günther wrote:
> The bridge might have special requirmentes on the input bus. This
> is e.g. used by the imx-nwl bridge.
>
> Signed-off-by: Guido Günther
Looks good to me.
Reviewed-by: Stefan Agner
That is similar to what I sent for the imx DRM driver:
https://lkm
On 19. 7. 26. 오후 7:45, Krzysztof Kozlowski wrote:
> On Thu, 25 Jul 2019 at 14:51, Chanwoo Choi wrote:
>>
>> 2019년 7월 24일 (수) 오전 8:07, Artur Świgoń 님이 작성:
>>>
>>> This patch adds minor improvements to the exynos-bus driver.
>>>
>>> Signed-off-by: Artur Świgoń
>>> ---
>>> drivers/devfreq/exynos-bu
Hi Sam,
thanks for your comments!
On Fri, Jul 26, 2019 at 11:23:15AM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> A few comments follows.
>
> Sam
>
> On Wed, Jul 24, 2019 at 05:52:25PM +0200, Guido Günther wrote:
> > The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
> >
Hi Daniel.
On Fri, Jul 26, 2019 at 10:50:16AM +0100, Daniel Thompson wrote:
> On Thu, Jul 25, 2019 at 04:32:24PM +0200, Sam Ravnborg wrote:
> > There was no users left - so drop the code to support EARLY_FB_BLANK.
>
> Why are we using a different noun for the subject and description?
I fat-finger
When fall-through warnings was enabled by default the following warning
was starting to show up:
../drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c: In function
‘sun6i_dsi_transfer’:../drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:992:6: warning:
this statement may fall through [-Wimplicit-fallthrough=]
if (m
When fall-through warnings was enabled by default the following warnings
was starting to show up:
../drivers/video/fbdev/sh_mobile_lcdcfb.c: In function
‘sh_mobile_lcdc_channel_fb_init’:
../drivers/video/fbdev/sh_mobile_lcdcfb.c:2086:22: warning: this statement may
fall
through [-Wimplicit-fall
When fall-through warnings was enabled by default the following warning
was starting to show up:
../drivers/gpu/drm/sun4i/sun4i_tcon.c: In function
‘sun4i_tcon0_mode_set_dithering’:
../drivers/gpu/drm/sun4i/sun4i_tcon.c:316:7: warning: this statement may fall
through [-Wimplicit-fallthrough=]
Now that the latex_documents are handled automatically, we can
remove those extra conf.py files.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/admin-guide/conf.py | 10 --
Documentation/core-api/conf.py | 10 --
Documentation/crypto/conf.py | 10 --
On Thu, Jul 25, 2019 at 06:02:08PM -0400, Paul Cercueil wrote:
> The board now uses the simple-audio-card driver.
>
> Signed-off-by: Paul Cercueil
> Tested-by: Artur Rojek
Acked-by: Mark Brown
signature.asc
Description: PGP signature
___
dri-devel
Hi Thierry.
On Fri, Jul 26, 2019 at 12:18:49PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Failing to find a panel-timing node is not an error in all cases, so do
> not output an error message in that case. Instead turn it into a debug
> message and make the drivers that care about i
Some files got renamed but probably due to some merge conflicts,
a few references still point to the old locations.
Signed-off-by: Mauro Carvalho Chehab
Acked-by: Wolfram Sang # I2C part
Reviewed-by: Jerry Hoemann # hpwdt.rst
---
Documentation/RCU/rculist_nulls.txt | 2 +-
D
Hi
On 2019-07-25 15:13, Chanwoo Choi wrote:
> 2019년 7월 24일 (수) 오전 8:07, Artur Świgoń 님이 작성:
>> This patch adds two fields tp the Exynos4412 DTS:
>>- parent: to declare connections between nodes that are not in a
>> parent-child relation in devfreq;
>>- #interconnect-cells: required by
Hi Sam,
W dniu 26.07.2019 o 08:37, Sam Ravnborg pisze:
Hi Andrzej.
Patch looks good, but one kernel-doc detail.
Thanks, I will address both issues you found, in v6.
Andrzej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.f
https://bugzilla.kernel.org/show_bug.cgi?id=204181
Frank Steinborn (stei...@nognu.de) changed:
What|Removed |Added
CC||stei...@nognu.de
---
Hi Josef, Daniel et al.
The driver that triggered this reply is a driver that adds parallel
support to ili9341 in a dedicated panel driver.
The issue here is that we already have a tiny driver that supports the
ili9341 controller - but with a slightly different configuration.
The ili9341 supports
Hi Navid.
On Wed, Jul 24, 2019 at 02:55:34PM -0500, Navid Emamdoost wrote:
> The following function calls may fail and return NULL, so the null check
> is added.
> of_graph_get_next_endpoint
> of_graph_get_remote_port_parent
> of_graph_get_remote_port
>
> Update: Thanks to Sam Ravnborg, for sugge
Hi Jeffrey.
On Mon, Jul 08, 2019 at 09:56:47AM -0700, Jeffrey Hugo wrote:
> The Lenovo Miix 630 laptop can be found with one of two panels - a BOE
> or Sharp option. This likely provides options during manufacturing.
>
> These panels connect via eDP, however they sit behind a DSI to eDP
> bridge
On Fri, Jul 26, 2019 at 01:27:25PM +0200, Sam Ravnborg wrote:
> Hi Daniel.
>
> On Fri, Jul 26, 2019 at 10:50:16AM +0100, Daniel Thompson wrote:
> > On Thu, Jul 25, 2019 at 04:32:24PM +0200, Sam Ravnborg wrote:
> > > There was no users left - so drop the code to support EARLY_FB_BLANK.
> >
> > Why
Hi Lowry,
On Fri, Jul 26, 2019 at 07:51:02AM +, Lowry Li (Arm Technology China) wrote:
> The drm_format_info doesn't have any cpp or block_size (both are zero)
> information for arm only afbc format YU08/YU10. we need to compute it
> by ourselves.
>
> Signed-off-by: Lowry Li (Arm Technology C
We were already using the generic functions in our debugfs code, do the
same in jh057n_shutdown. This was suggested by Sam Ravnborg.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers
If the panel is wrapped in a panel_bridge it gets prepar()ed before the
upstream DSI bridge which can cause hangs (e.g. with imx-nwl since clocks
are not enabled yet). To avoid this move the panel's first DSI access to
enable() so the upstream bridge can prepare the DSI host controller in
it's pre
If the panel is wrapped in a panel_bridge it gets prepar()ed before the
upstream DSI bridge which can cause hangs (e.g. with imx-nwl since clocks
are not enabled yet). To avoid this move the panel's first DSI access to
enable() so the upstream bridge can prepare the DSI host controller in
it's pre_
Most of them had these already but two mere missing. This eases
debugging.
Signed-off-by: Guido Günther
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-rocktech
This makes it symmetric with the panel init happening in enable().
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
b/drivers/gpu/drm/p
On Fri, Jul 26, 2019 at 08:00:29AM +, Lowry Li (Arm Technology China) wrote:
> Initialize and enable output polling on Komeda.
>
> Signed-off-by: Lowry Li (Arm Technology China)
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --gi
Hi Derek.
On Wed, Jul 24, 2019 at 03:15:19PM -0700, dbasehore . wrote:
> Hi Sam, thanks for pointing out the potential conflict.
>
> On Tue, Jul 23, 2019 at 2:19 AM Sam Ravnborg wrote:
> >
> > Hi Derek.
> >
> > On Tue, Jul 09, 2019 at 07:16:57PM -0700, Derek Basehore wrote:
> > > Devicetree syst
Hi Sam,
On Fri, Jul 26, 2019 at 12:25:29PM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> On Fri, Jul 26, 2019 at 11:21:40AM +0200, Guido Günther wrote:
> > If the panel is wrapped in a panel_bridge it gets prepar()ed before the
> > upstream DSI bridge which can cause hangs (e.g. with imx-nwl since cl
On 2019-07-07 20:18, Laurent Pinchart wrote:
> If an enable GPIO is declared in the firmware, assert it when enabling
> the bridge and deassert it when disabling it.
>
> Signed-off-by: Laurent Pinchart
This also comes in handy for the ADV7123, which has a power save pin.
Looks good to me.
Revi
This is a note to let you know that I've just added the patch titled
dma-buf: balance refcount inbalance
to the 4.14-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:
dma-buf-balance-ref
This is a note to let you know that I've just added the patch titled
dma-buf: balance refcount inbalance
to the 5.1-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:
dma-buf-balance-refc
This is a note to let you know that I've just added the patch titled
dma-buf: balance refcount inbalance
to the 4.19-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:
dma-buf-balance-ref
On 2019-07-07 20:18, Laurent Pinchart wrote:
> Create a new simple_bridge_info structure that stores information about
> the bridge model, and store the bridge timings in there, along with the
> connector type. Use that new structure for of_device_id data. This
> enables support for non-VGA bridges
This is a note to let you know that I've just added the patch titled
dma-buf: balance refcount inbalance
to the 5.2-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:
dma-buf-balance-refc
On Wed, Jul 24, 2019 at 9:53 PM Yue Hu wrote:
>
> From: Yue Hu
>
> Since governor name is defined by DEVFREQ framework internally, use the
> macro definition instead of using the name directly.
>
> Signed-off-by: Yue Hu
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 3 ++-
> drivers/gpu/
On Fri, Jul 26, 2019 at 5:47 AM Mauro Carvalho Chehab
wrote:
>
> Some files got renamed but probably due to some merge conflicts,
> a few references still point to the old locations.
>
> Signed-off-by: Mauro Carvalho Chehab
> Acked-by: Wolfram Sang # I2C part
> Reviewed-by: Jerry Hoemann # hpwd
From: Ralph Campbell
[ Upstream commit d304654bd79332ace9ac46b9a3d8de60acb15da3 ]
In nouveau_dmem_pages_alloc(), the drm->dmem->mutex is unlocked before
calling nouveau_dmem_chunk_alloc() as shown when CONFIG_PROVE_LOCKING
is enabled:
[ 1294.871933] =
[ 1294.
From: Yongxin Liu
[ Upstream commit 09b90e2fe35faeace2488234e2a7728f2ea8ba26 ]
In nouveau_conn_reset(), if connector->state is true,
__drm_atomic_helper_connector_destroy_state() will be called,
but the memory pointed by asyc isn't freed. Memory leak happens
in the following function __drm_atomi
From: Yongxin Liu
[ Upstream commit 09b90e2fe35faeace2488234e2a7728f2ea8ba26 ]
In nouveau_conn_reset(), if connector->state is true,
__drm_atomic_helper_connector_destroy_state() will be called,
but the memory pointed by asyc isn't freed. Memory leak happens
in the following function __drm_atomi
From: Yongxin Liu
[ Upstream commit 09b90e2fe35faeace2488234e2a7728f2ea8ba26 ]
In nouveau_conn_reset(), if connector->state is true,
__drm_atomic_helper_connector_destroy_state() will be called,
but the memory pointed by asyc isn't freed. Memory leak happens
in the following function __drm_atomi
From: Nicholas Kazlauskas
[ Upstream commit 5fdb7c4c7f2691efd760b0b0dc00da4a3699f1a6 ]
[Why]
In order to give pin notifications to the sound driver from DM we need
to know whether audio is enabled on a stream and what pin it's using
from DC.
[How]
Expose the instance via stream status if it's a
https://bugs.freedesktop.org/show_bug.cgi?id=111227
Bug ID: 111227
Summary: Mesa trunk 3.9
Product: Mesa
Version: 19.0
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=111211
--- Comment #2 from Bráulio Barros de Oliveira ---
Created attachment 144871
--> https://bugs.freedesktop.org/attachment.cgi?id=144871&action=edit
dmesg
dmesg attached, see amdgpu stacktrace in it
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=111211
--- Comment #3 from Bráulio Barros de Oliveira ---
Created attachment 144872
--> https://bugs.freedesktop.org/attachment.cgi?id=144872&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=111211
--- Comment #4 from Bráulio Barros de Oliveira ---
I'm using latest KDE from Archlinux
BTW, Kernel 5.2.1 was fine
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-deve
From: Sean Paul
Fixes the following warnings:
../drivers/gpu/drm/drm_dp_mst_topology.c:1593: warning: Excess function
parameter 'drm_connector' description in 'drm_dp_mst_connector_late_register'
../drivers/gpu/drm/drm_dp_mst_topology.c:1613: warning: Excess function
parameter 'drm_connector'
Hi Thierry, Hi Dave,
On 2018-09-07 01:31, Stefan Agner wrote:
> On 26.07.2018 06:36, Stefan Agner wrote:
>> If the GPIO subsystem is not ready make sure to return -EPROBE_DEFER
>> instead of silently continuing without HPD.
>>
>> Reported-by: Marcel Ziswiler
>> Signed-off-by: Stefan Agner
>
> I
On Fri, Jul 26, 2019 at 08:13:00AM +, Lowry Li (Arm Technology China) wrote:
> Current DRM-CORE accepts the writeback_job with a empty fb, but that
> is an invalid job for HW, so need to skip it when commit it to HW.
>
> Signed-off-by: Lowry Li (Arm Technology China)
Hm, this sounds a bit li
On Fri, Jul 26, 2019 at 07:41:35AM -0600, Rob Herring wrote:
> On Fri, Jul 26, 2019 at 5:47 AM Mauro Carvalho Chehab
> wrote:
> >
> > Some files got renamed but probably due to some merge conflicts,
> > a few references still point to the old locations.
> >
> > Signed-off-by: Mauro Carvalho Chehab
On Fri, Jul 26, 2019 at 6:36 AM Sam Ravnborg wrote:
>
> Hi Jeffrey.
>
> On Mon, Jul 08, 2019 at 09:56:47AM -0700, Jeffrey Hugo wrote:
> > The Lenovo Miix 630 laptop can be found with one of two panels - a BOE
> > or Sharp option. This likely provides options during manufacturing.
> >
> > These pa
1 - 100 of 203 matches
Mail list logo
