commit ff1e8fb68ea0 ("drm/bridge: analogix-anx78xx: Avoid drm_dp_link helpers")
stores the max link rate in a u8, overflowing it.
This will probably prevent the link training from working properly.
I've not tested this patch beyond a simple compile test since I do not own
any devices containing an
commit ff1e8fb68ea0 ("drm/bridge: analogix-anx78xx: Avoid drm_dp_link helpers")
changed the link training logic to remove use of drm_dp_link helpers. However
the new logic stores the maximum link rate in a u8, overflowing it.
This commit changes the logic to store the max link rate in a unsigned in
On Wed, Jan 8, 2020 at 1:23 PM Nicolas Boichat wrote:
>
> Hi!
>
> Sorry for the long delay since https://patchwork.kernel.org/patch/11132381/,
> finally got around to give this a real try.
>
> The main purpose of this series is to upstream the dts change and the binding
> document, but I wanted to
On Tue, 10 Dec 2019 16:45:34 +0100,
Takashi Iwai wrote:
>
> Hi,
>
> this is a patch set for updating ALSA PCM API usages in dw-hdmi
> driver. I already tried to "fix" the driver some time ago but it was
> utterly wrong. So this is a combination of the revised patch and
> another cleanup patch.
https://bugzilla.kernel.org/show_bug.cgi?id=206141
Bug ID: 206141
Summary: VCE UVD ring test failed -110
Product: Drivers
Version: 2.5
Kernel Version: 5.4.6
Hardware: x86-64
OS: Linux
Tree: Mainline
On Wed, 08 Jan 2020, Julian Stecklina
wrote:
> On Wed, 2020-01-08 at 12:24 +0200, Jani Nikula wrote:
>> On Mon, 06 Jan 2020, Julian Stecklina
>>
>> wrote:
> [...]
>> > + /* Hypervisor-specific device state. */
>> > + void *vdev;
>>
>> I have no clue about the relative merits of the patch, bu
The header is only required FreeBSD and GNU libc
2.30 starts to warn about Linux specific header
deprecation. Only include for FreeBSD.
Signed-off-by: Seung-Woo Kim
---
xf86drmMode.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/xf86drmMode.c b/xf86drmMode.c
index
Hi Rob,
On Fri, Jan 03, 2020 at 04:27:58PM +0100, Maxime Ripard wrote:
> The Allwinner SoCs have a display engine composed of several controllers
> assembled differently depending on the SoC, the number and type of output
> they have, and the additional features they provide. A number of those are
Am 08.01.20 um 18:51 schrieb Alex Deucher:
On Wed, Jan 8, 2020 at 12:39 PM Kees Cook wrote:
On Wed, Jan 08, 2020 at 01:56:47PM +0100, Christian König wrote:
Am 07.01.20 um 20:25 schrieb Tianlin Li:
Right now several architectures allow their set_memory_*() family of
functions to fail, but cal
Hi,
On 09/01/2020 10:10, Takashi Iwai wrote:
> On Tue, 10 Dec 2019 16:45:34 +0100,
> Takashi Iwai wrote:
>>
>> Hi,
>>
>> this is a patch set for updating ALSA PCM API usages in dw-hdmi
>> driver. I already tried to "fix" the driver some time ago but it was
>> utterly wrong. So this is a combinat
On Thu, Jan 09, 2020 at 10:10:09AM +0100, Takashi Iwai wrote:
> On Tue, 10 Dec 2019 16:45:34 +0100,
> Takashi Iwai wrote:
> >
> > Hi,
> >
> > this is a patch set for updating ALSA PCM API usages in dw-hdmi
> > driver. I already tried to "fix" the driver some time ago but it was
> > utterly wrong
Hi
Am 09.01.20 um 11:15 schrieb Christian König:
> Am 08.01.20 um 18:51 schrieb Alex Deucher:
>> On Wed, Jan 8, 2020 at 12:39 PM Kees Cook wrote:
>>> On Wed, Jan 08, 2020 at 01:56:47PM +0100, Christian König wrote:
Am 07.01.20 um 20:25 schrieb Tianlin Li:
> Right now several architecture
https://bugzilla.kernel.org/show_bug.cgi?id=194731
Janpieter Sollie (janpieter.sol...@dommel.be) changed:
What|Removed |Added
Status|NEW |RESOLVED
On Wed, Jan 08, 2020 at 02:52:02PM +0200, Jani Nikula wrote:
> On Mon, 06 Jan 2020, Pankaj Bharadiya
> wrote:
> > Device specific WARN* calls include device information in the
> > backtrace, so we know what device the warnings originate from.
> >
> > Covert all the calls of WARN* with device spec
This patch adds support for the 14 inch BOE NV140FHM-N49 eDP panel to
the panel-simple driver. The panel is used by the Pinebook Pro.
Resending with changed CCs due to lack of feedback.
Tobias Schramm (1):
drm/panel: Add support for BOE NV140FHM-N49 panel to panel-simple
drivers/gpu/drm/panel
This patch adds support for the BOE NV140FHM-N49 panel to the panel-simple
driver. The panel is used by the pine64 Pinebook Pro.
Signed-off-by: Tobias Schramm
---
drivers/gpu/drm/panel/panel-simple.c | 35
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/dr
On 07/01/2020 23:06, Martin Blumenstingl wrote:
> If devfreq_recommended_opp() fails we need to undo
> dev_pm_opp_of_add_table() by calling dev_pm_opp_of_remove_table() (just
> like we do it in the other error-path below).
>
> Fixes: f3ba91228e8e91 ("drm/panfrost: Add initial panfrost driver")
> S
On 07/01/2020 23:06, Martin Blumenstingl wrote:
> dev_pm_opp_set_rate() needs a reference to the regulator which should be
> updated when updating the GPU frequency. The name of the regulator has
> to be passed at initialization-time using dev_pm_opp_set_regulators().
> Add the call to dev_pm_opp_s
On Wed, Jan 8, 2020 at 9:05 PM Krzysztof Kozlowski wrote:
> The ioreadX() and ioreadX_rep() helpers have inconsistent interface. On
> some architectures void *__iomem address argument is a pointer to const,
> on some not.
>
> Implementations of ioreadX() do not modify the memory under the address
On 08/01/2020 05:23, Nicolas Boichat wrote:
Hi!
Sorry for the long delay since https://patchwork.kernel.org/patch/11132381/,
finally got around to give this a real try.
The main purpose of this series is to upstream the dts change and the binding
document, but I wanted to see how far I could pr
On 08/01/2020 05:23, Nicolas Boichat wrote:
It is useful to know which component cannot be powered on.
Signed-off-by: Nicolas Boichat
Looks like helpful error reporting.
Reviewed-by: Steven Price
---
Was useful when trying to probe bifrost GPU, to understand what
issue we are facing.
--
On Tue, Jan 07, 2020 at 04:32:08PM -0800, Manasi Navare wrote:
> Adaptive Sync is a VESA feature so add a DRM core helper to parse
> the EDID's detailed descritors to obtain the adaptive sync monitor range.
> Store this info as part fo drm_display_info so it can be used
> across all drivers.
> This
On 09/01/2020 12:01 pm, Steven Price wrote:
On 08/01/2020 05:23, Nicolas Boichat wrote:
Hi!
Sorry for the long delay since
https://patchwork.kernel.org/patch/11132381/,
finally got around to give this a real try.
The main purpose of this series is to upstream the dts change and the
binding
On Thu, Jan 09, 2020 at 01:10:33PM +, Robin Murphy wrote:
> On 09/01/2020 12:01 pm, Steven Price wrote:
> > On 08/01/2020 05:23, Nicolas Boichat wrote:
> >> Hi!
> >>
> >> Sorry for the long delay since
> >> https://patchwork.kernel.org/patch/11132381/,
> >> finally got around to give this a re
Explict management of the GPU's core stacks is only necessary in the
case of a broken integration with the PDC. Since there are no known
platforms which have such a broken integration let's remove the explict
control from the driver since this apparently causes problems on other
platforms and will
Hi Dave & Daniel,
Happy New Year, now back from the holiday break.
A bunch of important fixes. Further fixes for the power/perf
regressions caused by the past security fixes. Then fix for
user reported GPU hang regression. Revert to avoid screen flicker
caused by HDA audio. Then missing two W/A a
Quoting Joonas Lahtinen (2020-01-09 15:34:58)
> Hi Dave & Daniel,
>
> Happy New Year, now back from the holiday break.
>
> A bunch of important fixes. Further fixes for the power/perf
> regressions caused by the past security fixes. Then fix for
> user reported GPU hang regression. Revert to avoi
Thank you,
Reviewed-by: Mikita Lipski
On 1/8/20 10:24 PM, Alex Deucher wrote:
the parameter is the mst manager, not the port.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst
Hi Tobias.
We need binding schema before we can apply this patch.
See patch below.
Please review/ack the patch, then we can process your panel-simple
patch.
Sam
On Thu, Jan 09, 2020 at 12:29:51PM +0100, Tobias Schramm wrote:
> This patch adds support for the 14 inch BOE NV140FHM-N49 eDP
On 08/01/2020 05:23, Nicolas Boichat wrote:
When there is a single power domain per device, the core will
ensure the power domains are all switched on.
However, when there are multiple ones, as in MT8183 Bifrost GPU,
we need to handle them in driver code.
Signed-off-by: Nicolas Boichat
---
T
On 08/01/2020 05:23, Nicolas Boichat wrote:
For testing only, the driver doesn't really work yet, AFAICT.
Signed-off-by: Nicolas Boichat
It does work (at least on the Hikey960), we just don't have any public user
space driver for it... ;)
Reviewed-by: Steven Price
---
drivers/gpu/drm/p
On 08/01/2020 22:52, Nicolas Boichat wrote:
On Wed, Jan 8, 2020 at 9:23 PM Mark Brown wrote:
On Wed, Jan 08, 2020 at 01:23:34PM +0800, Nicolas Boichat wrote:
Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
regulator for their SRAM, let's add support for that.
+ pfdev-
Hi Linus.
On Thu, Jan 09, 2020 at 08:28:15AM +0100, Linus Walleij wrote:
> The Sony ACX424AKP is a command/videomode DSI panel for
> mobile devices. It is used on the ST-Ericsson HREF520
> reference design. We support video mode by default, but
> it is possible to switch the panel into command mod
If the current eDP link rate, as read from hw, provides a
higher bandwidth than the standard link rates, then add the
current link rate to the link_rates array for consideration
in future mode-sets.
These initial current eDP link settings have been set up by
firmware during boot, so they should wo
Hi Christoph,
Am 09.01.20 um 15:14 schrieb Christoph Hellwig:
Hi Woody,
sorry for the late reply, I've been off to a vacation over the holidays.
On Sat, Dec 14, 2019 at 10:17:15PM -0500, Woody Suwalski wrote:
Regression in 5.4 kernel on 32-bit Radeon IBM T40
triggered by
commit 33b3ad3788aba8
On Thu, 09 Jan 2020, Seung-Woo Kim wrote:
> The header is only required FreeBSD and GNU libc
> 2.30 starts to warn about Linux specific header
> deprecation. Only include for FreeBSD.
>
> Signed-off-by: Seung-Woo Kim
> ---
> xf86drmMode.c |2 ++
> 1 files changed, 2 insertions(+), 0 delet
read_current_link_settings_on_detect() on eDP 1.4+ may use the
edp_supported_link_rates table which is set up by
detect_edp_sink_caps(), so that function needs to be called first.
Signed-off-by: Mario Kleiner
Cc: Martin Leung
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +-
1 file chan
If the current eDP link settings, as read from hw, provide a higher
bandwidth than the verified_link_cap ones (= reported_link_cap), then
override verified_link_cap with current settings.
These initial current eDP link settings have been set up by
firmware during boot, so they should work on the e
Hi and happy new year!
Since i now have a MBP 2017 to play with, with a 10 bit Retina panel,
and Polaris gpu, i'm trying to get it to get 10 bits, and found one
small bug [fix: patch1], and a quirk of Apples Retina eDP sink, for
which i propose patch2 as solution. I sent a similar patch to i915 to
On Tue, 07 Jan 2020, Manasi Navare wrote:
> Adaptive Sync is a VESA feature so add a DRM core helper to parse
> the EDID's detailed descritors to obtain the adaptive sync monitor range.
> Store this info as part fo drm_display_info so it can be used
> across all drivers.
> This part of the code is
On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> If the current eDP link rate, as read from hw, provides a
> higher bandwidth than the standard link rates, then add the
> current link rate to the link_rates array for consideration
> in future mode-sets.
>
> These initial current eD
Hi Tobias.
We need binding schema before we can apply this patch.
Knew I forgot something
See patch below.
Please review/ack the patch, then we can process your panel-simple
patch.
LGTM, thanks!
Sam
On Thu, Jan 09, 2020 at 12:29:51PM +0100, Tobias Schramm wrote:
This patch adds supp
On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > If the current eDP link rate, as read from hw, provides a
> > higher bandwidth than the standard link rates, then add the
> > current link rate to the link_rates array
On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
wrote:
>
> If the current eDP link rate, as read from hw, provides a
> higher bandwidth than the standard link rates, then add the
> current link rate to the link_rates array for consideration
> in future mode-sets.
>
> These initial current eDP link s
Hi Tobias.
On Thu, Jan 09, 2020 at 12:29:52PM +0100, Tobias Schramm wrote:
> This patch adds support for the BOE NV140FHM-N49 panel to the panel-simple
> driver. The panel is used by the pine64 Pinebook Pro.
>
> Signed-off-by: Tobias Schramm
Applied to drm-misc-next togher with the bindings pat
On Thu, Jan 9, 2020 at 4:27 PM Ville Syrjälä
wrote:
> On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > If the current eDP link rate, as read from hw, provides a
> > higher bandwidth than the standard link rates, then add the
> > current link rate to the link_rates array for cons
On Thu, Jan 09, 2020 at 02:14:42PM +, Steven Price wrote:
> On 08/01/2020 22:52, Nicolas Boichat wrote:
> > That'd be a bit awkward to match, though... Currently all bifrost
> > share the same compatible "arm,mali-bifrost", and it'd seem
> > weird/wrong to match "mediatek,mt8183-mali" in this
On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä
wrote:
> On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > > The panel reports 10 bpc color depth in its EDID, and the UEFI
> > > firmware chooses link settings at boot
On Thu, Jan 09, 2020 at 05:38:15PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > > If the current eDP link rate, as read from hw, provides a
> > > higher bandwidth than the standard
Le jeu. 9 janv. 2020 à 17:29, Benjamin GAIGNARD
a écrit :
>
>
> On 12/3/19 5:49 PM, Benjamin Gaignard wrote:
> > Le mer. 20 nov. 2019 à 00:28, Benjamin Gaignard
> > a écrit :
> >> Exported functions prototypes are missing in drm_fb_cma_helper.c
> >> Include drm_fb_cma_helper to fix that issue.
>
On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote:
> On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä
> wrote:
>
> > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> > > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote:
> > > > The panel reports 10 bpc color d
On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher wrote:
> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
> wrote:
> >
> > If the current eDP link rate, as read from hw, provides a
> > higher bandwidth than the standard link rates, then add the
> > current link rate to the link_rates array for consider
On 09/01/2020 16:28, Mark Brown wrote:
On Thu, Jan 09, 2020 at 02:14:42PM +, Steven Price wrote:
On 08/01/2020 22:52, Nicolas Boichat wrote:
That'd be a bit awkward to match, though... Currently all bifrost
share the same compatible "arm,mali-bifrost", and it'd seem
weird/wrong to match "
On Wed, Jan 8, 2020 at 4:52 PM Nicolas Boichat wrote:
>
> On Wed, Jan 8, 2020 at 9:23 PM Mark Brown wrote:
> >
> > On Wed, Jan 08, 2020 at 01:23:34PM +0800, Nicolas Boichat wrote:
> >
> > > Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
> > > regulator for their SRAM, let's add
Instead of defining KVMGT per-device state in struct intel_vgpu
directly, add an indirection. This makes the GVT code oblivious of
what state KVMGT needs to keep.
The intention here is to eventually make it possible to build
hypervisor backends for the mediator, without having to touch the
mediato
So far, the KVMGT code just included the whole i915 driver and GVT
internals to do its job. Change this to have a single public header
that defines the interface via accessor functions.
Some ugly things:
a) The handle member of intel_vgpu should be in kvmgt_vdev and the
generic code should just p
Now that the GVT interface to hypervisors does not depend on i915/GVT
internals anymore, we can move the headers to the global include/.
This makes out-of-tree modules for hypervisor integration possible.
Cc: Zhenyu Wang
Signed-off-by: Julian Stecklina
---
drivers/gpu/drm/i915/gvt/gvt.h
This variable is used nowhere, so remove it.
Cc: Zhenyu Wang
Signed-off-by: Julian Stecklina
---
drivers/gpu/drm/i915/gvt/gvt.h | 2 --
drivers/gpu/drm/i915/gvt/kvmgt.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index
These patch series removes the dependency of i915/gvt hypervisor
backends on the driver internals of the i915 driver. Instead, we add a
small public API that hypervisor backends can use.
This enables out-of-tree hypervisor backends for the Intel graphics
virtualization and simplifies development.
On Fri, Jan 3, 2020 at 9:28 AM Maxime Ripard wrote:
>
> The Allwinner SoCs have a display engine composed of several controllers
> assembled differently depending on the SoC, the number and type of output
> they have, and the additional features they provide. A number of those are
> supported in L
From: Christophe Leroy
> Sent: 08 January 2020 08:49
...
> And as pointed by Arnd, the volatile is really only necessary for the
> dereference itself, should the arch use dereferencing.
I've had trouble with some versions of gcc and reading of 'volatile unsigned
char *'.
It tended to follow the m
Hi Krzysztof,
> The ioreadX() helpers have inconsistent interface. On some architectures
> void *__iomem address argument is a pointer to const, on some not.
>
> Implementations of ioreadX() do not modify the memory under the
> address so they can be converted to a "const" version for const-safe
Add a compatible string for the GiantPlus GPM740B0 3" QVGA TFT LCD
panel, and remove the old giantplus,gpm740b0.txt documentation which is
now obsolete.
Signed-off-by: Paul Cercueil
---
.../bindings/display/panel/giantplus,gpm940b0.txt| 12
.../bindings/display/panel/panel-simpl
Replace the open coded calculation with the more concise and readable
DIV_ROUND_UP macro.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/dr
Hi Thomas Zimmermann:
I will modify this patch and send v2 as you suggested.
Thank you very much.
Best
-邮件原件-
发件人: Thomas Zimmermann [mailto:tzimmerm...@suse.de]
发送时间: 2020年1月8日 16:49
收件人: tiantao (H) ; Chenfeng (puck)
; airl...@linux.ie; dan...@ffwll.ch;
kra...@redhat
This replaces the printk and struct device based logging macros with the
new struct drm_device style based logging macros i915/intel_device_info.c.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/intel_device_info.c | 25 +---
1 file changed, 14 insertions(+), 11 deleti
On 12/6/19 12:26 PM, Hans Verkuil wrote:
> Add a missing 'depends on DRM' for the DRM_DP_CEC config
> option. Without that enabling DRM_DP_CEC will force CEC_CORE
> to =y instead of =m if DRM=m as well.
>
> Signed-off-by: Hans Verkuil
Daniel, can you review this? It's annoying that the cec core
Hi Robin,
On Wed, Jan 8, 2020 at 12:18 PM Robin Murphy wrote:
>
> On 07/01/2020 11:06 pm, Martin Blumenstingl wrote:
> > Decouple the check to see whether we want to enable devfreq for the GPU
> > from dev_pm_opp_set_regulators(). This is preparation work for adding
> > back support for regulator
As the if statement only checks for the value of the offset_name
variable, it can be replaced by the more conscise BUG_ON macro for error
reporting.
v2: format expression to less than 80 characters for each line.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 6 ++---
This converts the use of printk based logging macros in i915/intel_gvt.c
with the new struct drm_device based logging macros.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/intel_gvt.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
On Wed, Jan 08, 2020 at 01:28:34AM +0800, Chen-Yu Tsai wrote:
> On Wed, Jan 8, 2020 at 1:00 AM Maxime Ripard wrote:
> >
> > The DRC needs to run at 300MHz to be functional. This was done so far
> > using assigned-clocks in the device tree, but that is easy to forget, and
> > dosen't provide any ot
Patches 1,2,3,6 are:
Reviewed-by: Alyssa Rosenzweig
The remaining patches in the series are Acked-by.
Reportedly the kernel should work on certain Bifrost boards more or less
as-is, but I'm not positive about the details. It's possible some of
these are G72-specific or MT-specific issue
Hi Geert,
Le 08/01/2020 à 09:43, Geert Uytterhoeven a écrit :
Hi Christophe,
On Wed, Jan 8, 2020 at 9:35 AM Christophe Leroy wrote:
Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit :
On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven wrote:
On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven
A-b
On Thu, Jan 09, 2020 at 01:31:04PM +, Steven Price wrote:
> Explict management of the GPU's core stacks is only necessary in the
> case of a broken integration with the PDC. Since there are no known
> platforms which have such a broken integration let's remove the explict
> control from th
There might be some comp that doesn't have funcs, eg. hdmi-connector.
Check for comp->funcs otherwise there will be NULL pointer dereference
crash.
Fixes: bd3de8cd782b ("drm/mediatek: Add gamma property according to hardware
capability")
Fixes: 7395eab077f9 ("drm/mediatek: Add ctm property suppor
Replace the use of printk based logging macros with the struct
drm_device based macros in i915/i915_vgpu.c
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/i915_vgpu.c | 41 +++-
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915
add mode_valid function, and we can also use it to make suse the resolution
is valid.
Signed-off-by: Tian Tao
Signed-off-by: Gong junjie
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/h
On 2020-01-09 16:18, Jani Nikula wrote:
On Thu, 09 Jan 2020, Seung-Woo Kim wrote:
The header is only required FreeBSD and GNU libc
2.30 starts to warn about Linux specific header
deprecation. Only include for FreeBSD.
Signed-off-by: Seung-Woo Kim
---
xf86drmMode.c |2 ++
1 files cha
Replace the use of printk and struct device based logging macros with
the new struct drm_device based logging macros in i915/intel_csr.c
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/intel_csr.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git
On 1/7/20 2:24 PM, Thomas Zimmermann wrote:
> Hi
>
> Am 10.12.19 um 11:24 schrieb Benjamin Gaignard:
>> Some variables are set but never used. To avoid warning when compiling
>> with W=1 and keep the algorithm like it is tag theses variables
>> with _maybe_unused macro.
>>
>> Signed-off-by: Benja
Replace the use of printk based logging macros with the new struct
drm_device based logging macro in i915/intel_memory_region.c.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/intel_memory_region.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915
On 1/8/20 6:42 PM, Daniel Vetter wrote:
> On Wed, Jan 08, 2020 at 01:08:47PM +0100, Hans Verkuil wrote:
>> On 12/6/19 12:26 PM, Hans Verkuil wrote:
>>> Add a missing 'depends on DRM' for the DRM_DP_CEC config
>>> option. Without that enabling DRM_DP_CEC will force CEC_CORE
>>> to =y instead of =m i
> On Jan 8, 2020, at 6:56 AM, Christian König wrote:
>
> Am 07.01.20 um 20:25 schrieb Tianlin Li:
>> Right now several architectures allow their set_memory_*() family of
>> functions to fail, but callers may not be checking the return values.
>> If set_memory_*() returns with an error, call-site
Fix build error:
lib/crypto/chacha.c: In function chacha_permute:
lib/crypto/chacha.c:65:1: warning: the frame size of 3384 bytes is larger than
2048 bytes [-Wframe-larger-than=]
}
^
Reported-by: Hulk Robot
Signed-off-by: Chen Zhou
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 1 +
1 file chan
On Wed 08 Jan 10:48 PST 2020, Jordan Crouse wrote:
> On Tue, Jan 07, 2020 at 05:38:42PM -0800, Rob Clark wrote:
> > From: Rob Clark
> >
> > Since zap firmware can be device specific, allow for a firmware-name
> > property in the zap node to specify which firmware to load, similarly to
> > the sc
Fix build error:
drivers/gpu/drm/i915/gt/intel_ggtt.c: In function ggtt_restore_mappings:
drivers/gpu/drm/i915/gt/intel_ggtt.c:1239:3: error:
implicit declaration of function wbinvd_on_all_cpus; did you mean
wrmsr_on_cpus? [-Werror=implicit-function-declaration]
wbinvd_on_all_cpus();
Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit :
On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven wrote:
Hi Krzysztof,
On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven wrote:
On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski wrote:
The ioread8/16/32() and others have inconsistent i
On 12/3/19 5:49 PM, Benjamin Gaignard wrote:
> Le mer. 20 nov. 2019 à 00:28, Benjamin Gaignard
> a écrit :
>> Exported functions prototypes are missing in drm_fb_cma_helper.c
>> Include drm_fb_cma_helper to fix that issue.
>>
> Gentle ping to reviewers.
> Thanks,
> Benjamin
I know that removing
This patchset continues the conversion to using the new struct
drm_device based logging macros in drm/i915.
Wambui Karuga (5):
drm/i915: conversion to new logging macros in i915/i915_vgpu.c
drm/i915: conversion to new logging macros in i915/intel_csr.c
drm/i915: conversion to new logging mac
add mode_valid function, we can make sure the resolution is valid.
Signed-off-by: Tian Tao
Signed-off-by: Gong junjie
Reviewed-by: Thomas Zimmermann
---
v2: declare hibmc_crtc_mode_valid as static.
Modify the return value of hibmc_crtc_mode_valid .
---
drivers/gpu/drm/hisilicon/hi
Add a compatible string for the Sharp LS020B1DD01D 2" HQVGA TFT LCD
panel, and remove the old sharp,ls020b1dd01d.txt documentation which is
now obsolete.
Signed-off-by: Paul Cercueil
---
.../bindings/display/panel/panel-simple.yaml | 2 ++
.../bindings/display/panel/sharp,ls020b1dd01d.t
* Matthijs van Duin [200106 10:07]:
> On Sun, Jan 05, 2020 at 12:37:04PM -0800, Tony Lindgren wrote:
> > 4. The issue I'm seeing with stellarium on droid4 may be a stride
> >issue as about one out of 3 or 4 frames is OK and aligning to
> >512 also fixes the issue maybe because it happens t
On 2020/1/8 21:44, Jani Nikula wrote:
> On Wed, 08 Jan 2020, Chen Zhou wrote:
>> Fix build error:
>> lib/crypto/chacha.c: In function chacha_permute:
>> lib/crypto/chacha.c:65:1: warning: the frame size of 3384 bytes is larger
>> than 2048 bytes [-Wframe-larger-than=]
>> }
>> ^
>
> IMO this n
This adds preliminary IOMMU support for the MDP5 on msm8974. It appears
that the qcom-iommu driver in upstream can be used on this SoC. I marked
this patch as a RFC since the frame buffer becomes corrupted when I boot
the Nexus 5 phone with this patch:
https://raw.githubusercontent.com/masneyb/nex
On Thu, Jan 9, 2020 at 12:31 PM Steven Price wrote:
>
> On 07/01/2020 23:06, Martin Blumenstingl wrote:
> > dev_pm_opp_set_rate() needs a reference to the regulator which should be
> > updated when updating the GPU frequency. The name of the regulator has
> > to be passed at initialization-time us
On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä
wrote:
> On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote:
> > On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä <
> ville.syrj...@linux.intel.com>
> > wrote:
> >
> > > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrjälä wrote:
> > > > On T
On Thu, Jan 09, 2020 at 06:57:14PM +0100, Mario Kleiner wrote:
> On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä
> wrote:
>
> > On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote:
> > > On Thu, Jan 9, 2020 at 4:38 PM Ville Syrjälä <
> > ville.syrj...@linux.intel.com>
> > > wrote:
> > >
>
On 2020-01-09 10:20 a.m., Mario Kleiner wrote:
> read_current_link_settings_on_detect() on eDP 1.4+ may use the
> edp_supported_link_rates table which is set up by
> detect_edp_sink_caps(), so that function needs to be called first.
>
> Signed-off-by: Mario Kleiner
> Cc: Martin Leung
Reviewed-b
On 2020-01-09 10:20 a.m., Mario Kleiner wrote:
> If the current eDP link settings, as read from hw, provide a higher
> bandwidth than the verified_link_cap ones (= reported_link_cap), then
> override verified_link_cap with current settings.
>
> These initial current eDP link settings have been set
Hi Miquel.
On Thu, Jan 09, 2020 at 07:40:36PM +0100, Miquel Raynal wrote:
> Satoz is a Chinese TFT manufacturer.
> Website: http://www.sat-sz.com/English/index.html
>
> Add the compatible for its SAT050AT40H12R2 5.0 inch LCD panel.
>
> Signed-off-by: Miquel Raynal
Applied this and the followin
1 - 100 of 123 matches
Mail list logo
