On 7/3/20, 2:46 PM, Sam Ravnborg wrote:
>
> Improve the documentation for backlight_device and
> adapt it to kernel-doc style.
>
> The updated documentation is more strict on how locking is used.
> With the update neither update_lock nor ops_lock may be used
> outside the backlight core.
> This
Did you just cherry-pick my change, or were you running the latest
drm-next or drm-fixes code? There do appear to be various MM-related
fixes that may be related to this in drm-fixes when I scroll down the
log looking for nouveau stuff. Shot in the dark, but might be worth
trying with Dave's
On 7/17/20 12:47 PM, Daniel Vetter wrote:
On Fri, Jul 17, 2020 at 11:57:57AM -0700, James Jones wrote:
Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
family of modifiers to handle broken userspace
Xorg modesetting and Mesa drivers.
Tested with Xorg 1.20 modesetting driver,
Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
family of modifiers to handle broken userspace
Xorg modesetting and Mesa drivers. Existing Mesa
drivers are still aware of only these older
format modifiers which do not differentiate
between different variations of the block linear
layout. When the
This doesn't look related.
-James
On 7/17/20 2:30 PM, Kirill A. Shutemov wrote:
On Fri, Jul 17, 2020 at 11:57:57AM -0700, James Jones wrote:
Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
family of modifiers to handle broken userspace
Xorg modesetting and Mesa drivers.
Tested with Xorg 1.20
Hi Daniel,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip linus/master v5.8-rc5 next-20200717]
[cannot apply to arm/drm-armada-devel arm/drm-armada-fixes]
[If your patch is applied to the wrong
Hi Dave, Daniel,
The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407:
Linux 5.8-rc1 (2020-06-14 12:45:04 -0700)
are available in the Git repository at:
git://linuxtv.org/pinchartl/media.git tags/drm-xilinx-dpsub-20200718
for you to fetch changes up to
From: Hyun Kwon
The bindings describe the ZynqMP DP subsystem. They don't support the
interface with the programmable logic (FPGA) or audio yet.
Signed-off-by: Hyun Kwon
Signed-off-by: Laurent Pinchart
Reviewed-by: Rob Herring
Acked-by: Sam Ravnborg
---
Hello,
Here's a new and hopefully last version of the Xilinx ZynqMP DisplayPort
Subsystem driver, the fourth version since I took over v8 of the series
([1]) from Hyun.
This new version is based on top of the dmaengine topic branch that
contains the required dependencies, available at
On Fri, Jul 17, 2020 at 10:43:18AM -0400, Sasha Levin wrote:
> On Fri, Jul 17, 2020 at 02:43:52AM +0200, Karol Herbst wrote:
> > On Fri, Jul 17, 2020 at 1:54 AM Bjorn Helgaas wrote:
> > > On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote:
> > > > On Tue, Jul 7, 2020 at 9:30 PM Karol
On Fri, Jul 17, 2020 at 11:57:57AM -0700, James Jones wrote:
> Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
> family of modifiers to handle broken userspace
> Xorg modesetting and Mesa drivers.
>
> Tested with Xorg 1.20 modesetting driver,
> weston@c46c70dac84a4b3030cd05b380f9f410536690fc,
>
This is a new DRM driver for Intel's KeemBay SOC.
The SoC couples an ARM Cortex A53 CPU with an Intel
Movidius VPU.
This driver is tested with the KMB EVM board which is the refernce baord
for Keem Bay SOC. The SOC's display pipeline is as follows
+--++-+
Hi,
On Fri, Jul 17, 2020 at 1:24 PM Rob Clark wrote:
>
> On Fri, Jul 17, 2020 at 10:39 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Fri, Jul 17, 2020 at 7:46 AM Jordan Crouse
> > wrote:
> > >
> > > On Fri, Jul 17, 2020 at 08:04:18PM +0530, Akhil P Oommen wrote:
> > > > On targets where GMU
On Fri, Jul 17, 2020 at 10:39 AM Doug Anderson wrote:
>
> Hi,
>
> On Fri, Jul 17, 2020 at 7:46 AM Jordan Crouse wrote:
> >
> > On Fri, Jul 17, 2020 at 08:04:18PM +0530, Akhil P Oommen wrote:
> > > On targets where GMU is available, GMU takes over the ownership of GX GDSC
> > > during its
On Fri, Jul 17, 2020 at 03:04:10PM -0400, Lyude Paul wrote:
> Isn't it possible to tell whether a PCI device is connected through
> thunderbolt or not? We could probably get away with just defaulting
> to 100ms for thunderbolt devices without DLL Link Active specified,
> and then default to the
Hi Laurentiu.
On Fri, Jul 17, 2020 at 05:41:27PM +0300, Laurentiu Palcu wrote:
> From: Laurentiu Palcu
>
> This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS).
> Some of its capabilities include:
> * 4K@60fps;
> * HDR10;
> * one graphics and 2 video pipelines;
> *
On Fri, Jul 17, 2020 at 11:57:57AM -0700, James Jones wrote:
> Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
> family of modifiers to handle broken userspace
> Xorg modesetting and Mesa drivers.
>
> Tested with Xorg 1.20 modesetting driver,
> weston@c46c70dac84a4b3030cd05b380f9f410536690fc,
>
Quoting Jisheng Zhang (2020-07-17 07:11:38)
> The i915 doesn't depend on IOSF_MBI, asm/iosf_mbi.h already defines
> isof_mbi_* APIs when ISOF_MBI is disabled.
>
> Don't force IOSF_MBI to allow disabling IOSF_MBI for non SoC platforms.
But it is required for Valleyview/Cherryview and we want to
Hey-just wanted to give some additional context I think Karol missed here. It
should be noted that since the last time me and Karol looked at reverting these,
we've already fixed all of the nasty runtime PM (e.g. runtime D3) issues we
could find. This includes the infamous one that was affecting
It's hard to figure out what systems are actually affected and right now I
don't see a good way of removing those...
But I'd like to see thos getting removed and drivers fixed instead (which
happened at least for nouveau).
And as mentioned before, I prefer people working on fixing issues instead
On Thu, 2020-07-16 at 18:54 -0500, Bjorn Helgaas wrote:
> [+cc Sasha -- stable kernel regression]
> [+cc Patrick, Kai-Heng, LKML]
>
> On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote:
> > On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst wrote:
> > > Hi everybody,
> > >
> > > with the
This should resolve the inability to start X with the new NV format
modifier support in nouveau. FYI, I'm offline next week, but I'll check
in tonight in case there are any review comments. When I'm back, I'll
get the associated userspace fixes cleaned up and out to the appropriate
lists.
Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
family of modifiers to handle broken userspace
Xorg modesetting and Mesa drivers.
Tested with Xorg 1.20 modesetting driver,
weston@c46c70dac84a4b3030cd05b380f9f410536690fc,
gnome & KDE wayland desktops from Ubuntu 18.04,
and sway 1.5
Signed-off-by:
On Thu, Jul 9, 2020 at 4:05 AM Rajendra Nayak wrote:
>
> Add the OPP tables for DSI and MDP based on the perf state/clk
> requirements, and add the power-domains property to specify the
> scalable power domain.
>
> Signed-off-by: Rajendra Nayak
> Reviewed-by: Matthias Kaehlcke
Tested-by: Rob
Hi,
On Fri, Jul 17, 2020 at 7:46 AM Jordan Crouse wrote:
>
> On Fri, Jul 17, 2020 at 08:04:18PM +0530, Akhil P Oommen wrote:
> > On targets where GMU is available, GMU takes over the ownership of GX GDSC
> > during its initialization. So, move the refcount-get on GX PD before we
> > initialize
On Thu, Jul 16, 2020 at 7:51 AM Nicolas Saenz Julienne
wrote:
>
> Aside from being more correct, the non optional version of the function
> prints an error when failing to find the IRQ.
>
> Fixes: eea9b97b4504 ("drm/v3d: Add support for V3D v4.2")
> Signed-off-by: Nicolas Saenz Julienne
> ---
>
Hi Dave,
The following changes since commit fce3a51d9b31312aa12ecb72ffabfc4c7b40bdc6:
drm/tegra: Add zpos property for cursor planes (2020-06-16 19:03:25 +0200)
are available in the Git repository at:
ssh://git.freedesktop.org/git/tegra/linux.git tags/drm/tegra/for-5.9-rc1
for you to
Hello Eugeniu,
On Mon, Jun 15, 2020 at 04:17:23PM +0200, Eugeniu Rosca wrote:
> Hi Jacopo,
>
> On Fri, Jun 12, 2020 at 05:12:09PM +0200, Jacopo Mondi wrote:
> > On Mon, Jun 08, 2020 at 11:44:32AM +0200, Eugeniu Rosca wrote:
> > > FWIW, I seem to hit pre-existing issues in vanilla rcar-du,
> > >
On Fri, Jul 17, 2020 at 08:04:18PM +0530, Akhil P Oommen wrote:
> On targets where GMU is available, GMU takes over the ownership of GX GDSC
> during its initialization. So, move the refcount-get on GX PD before we
> initialize the GMU. This ensures that nobody can collapse the GX GDSC
> once GMU
On Fri, Jul 17, 2020 at 02:43:52AM +0200, Karol Herbst wrote:
On Fri, Jul 17, 2020 at 1:54 AM Bjorn Helgaas wrote:
[+cc Sasha -- stable kernel regression]
[+cc Patrick, Kai-Heng, LKML]
On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote:
> On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst
From: Laurentiu Palcu
The driver is part of DRM subsystem and is located in drivers/gpu/drm/imx/dcss.
Signed-off-by: Laurentiu Palcu
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index dad5a62d21a7..200c5985b41f 100644
--- a/MAINTAINERS
From: Laurentiu Palcu
Hi,
This patchset adds initial DCSS support for iMX8MQ chip. Initial support
includes only graphics plane support (no video planes), no HDR10 capabilities,
no graphics decompression (only linear, tiled and super-tiled buffers allowed).
Support for the rest of the features
From: Laurentiu Palcu
This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS).
Some of its capabilities include:
* 4K@60fps;
* HDR10;
* one graphics and 2 video pipelines;
* on-the-fly decompression of compressed video and graphics;
The reference manual can be found here:
From: Laurentiu Palcu
Add bindings for iMX8MQ Display Controller Subsystem.
Signed-off-by: Laurentiu Palcu
---
.../bindings/display/imx/nxp,imx8mq-dcss.yaml | 104 ++
1 file changed, 104 insertions(+)
create mode 100644
From: Laurentiu Palcu
Currently the drm/imx/ directory is compiled only if DRM_IMX is set. Adding a
new IMX related IP in the same directory would need DRM_IMX to be set, which
would
bring in also IPUv3 core driver...
The current patch would allow adding new IPs in the imx/ directory without
On targets where GMU is available, GMU takes over the ownership of GX GDSC
during its initialization. So, move the refcount-get on GX PD before we
initialize the GMU. This ensures that nobody can collapse the GX GDSC
once GMU owns the GX GDSC. This patch fixes some GMU OOB errors seen
during GPU
On 7/15/2020 12:12 AM, Rob Clark wrote:
On Tue, Jul 14, 2020 at 10:10 AM Matthias Kaehlcke wrote:
On Tue, Jul 14, 2020 at 06:55:30PM +0530, Akhil P Oommen wrote:
On targets where GMU is available, GMU takes over the ownership of GX GDSC
during its initialization. So, take a refcount on the
On Fri, Jul 17, 2020 at 09:32:21AM +0800, miaoqinglang wrote:
>
> 在 2020/7/16 21:34, Thierry Reding 写道:
> > On Thu, Jul 16, 2020 at 05:03:23PM +0800, Qinglang Miao wrote:
> > > From: Yongqiang Liu
> > >
> > > Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
> > >
> > > Signed-off-by:
Am 17.07.20 um 04:27 schrieb Laurent Pinchart:
Hi Christian,
On Mon, Jun 22, 2020 at 11:29:33AM +0200, Daniel Vetter wrote:
On Mon, Jun 22, 2020 at 09:58:44AM +0200, Christian König wrote:
Am 21.06.20 um 04:07 schrieb Laurent Pinchart:
Most of the DRM drivers uAPI headers are licensed under
From: Ville Syrjälä
Add a TODO for plumbing drm_atomic_state all over to ease
the hurdles of accessing additional object states.
Reviewed-by: Daniel Vetter #irc
Signed-off-by: Ville Syrjälä
---
Documentation/gpu/todo.rst | 46 ++
1 file changed, 46
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the minimum allowed
PWM level to 0. But several of these devices specify a non 0 minimum
setting in their VBT.
Change pwm_setup_backlight() to use get_backlight_min_vbt() to get
the
Now that the PWM drivers which we use have been converted to the atomic
PWM API, we can move the i915 panel code over to using the atomic PWM API.
The removes a long standing FIXME and this removes a flicker where
the backlight brightness would jump to 100% when i915 loads even if
using the
Factor the code which checks and drm_dbg_kms-s the VBT PWM frequency
out of get_backlight_max_vbt().
This is a preparation patch for honering the VBT PWM frequency for
devices which use an external PWM controller (devices using
pwm_setup_backlight()).
Acked-by: Jani Nikula
Signed-off-by: Hans
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the period-time passed to
pwm_config() to 21333 ns.
I suspect this was done because many VBTs set the PWM frequency to 200
which corresponds to a period-time of 500 ns, which
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
this commit makes crc_pwm_disable() clear it on disable and makes
crc_pwm_enable() set
In the not-enabled -> enabled path pwm_lpss_apply() needs to get a
runtime-pm reference; and then on any errors it needs to release it
again.
This leads to somewhat hard to read code. This commit introduces a new
pwm_lpss_prepare_enable() helper and moves all the steps necessary for
the
Replace the enable, disable and config pwm_ops with an apply op,
to support the new atomic PWM API.
Signed-off-by: Hans de Goede
---
Changes in v3:
- Keep crc_pwm_calc_clk_div() helper to avoid needless churn
---
drivers/pwm/pwm-crc.c | 89 ++-
1 file
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
I strongly suspect that the BACKLIGHT_EN register at address 0x51 really
controls a separate output-only GPIO which is connected to the LCD panels
Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.
Reviewed-by: Andy Shevchenko
Signed-off-by: Hans de Goede
---
Changes in v5:
- Fix an indentation issue
Changes in v4:
- Use DIV_ROUND_UP when calculating the period and duty_cycle from the
Before this commit a suspend + resume of the LPSS PWM controller
would result in the controller being reset to its defaults of
output-freq = clock/256, duty-cycle=100%, until someone changes
to the output-freq and/or duty-cycle are made.
This problem has been masked so far because the main
According to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency.
So assuming e.g. a 16 bit counter this means that if base_unit is set to 1,
after 65535 input
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets turned off from the _PS3 method of the graphics-card dev:
Method (_PS3, 0, Serialized) // _PS3: Power State 3
{
...
PWMB = PWMC /*
While looking into adding atomic-pwm support to the pwm-crc driver I
noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
there is a clock-divider which divides this with a value between 1-128,
and there are 256 duty-cycle steps.
The pwm-crc code before this commit assumed that a
The CRC PWM controller has a clock-divider which divides the clock with
a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx
defines, this range maps to a register value of 0-127.
So after calculating the clock-divider we must subtract 1 to get the
register value, unless the requested
When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets poked from the _PS0 method of the graphics-card device:
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
If (((Local0 & 0x03) == 0x03))
{
PSAT &= 0xFFFC
Local1 =
Hi All,
Here is v5 of my patch series converting the i915 driver's code for
controlling the panel's backlight with an external PWM controller to
use the atomic PWM API. See below for the changelog.
This series consists of 4 parts:
1. acpi_lpss fixes workarounds for Cherry Trail DSTD nastiness
From: Sharat Masetty
This patch changes the plumbing to send the devfreq recommended opp rather
than the frequency. Also consolidate and rearrange the code in a6xx to set
the GPU frequency and the icc vote in preparation for the upcoming
changes for GPU->DDR scaling votes.
Signed-off-by: Sharat
From: Sharat Masetty
This patch adds the interconnects property for the gpu node and the
opp-peak-kBps property to the opps of the gpu opp table. This should
help enable DDR bandwidth scaling dynamically and proportionally to the
GPU frequency.
Signed-off-by: Sharat Masetty
Signed-off-by:
From: Sharat Masetty
Add opp-peak-kBps bindings to the GPU opp table, listing the peak
GPU -> DDR bandwidth requirement for each opp level. This will be
used to scale the DDR bandwidth along with the GPU frequency dynamically.
Signed-off-by: Sharat Masetty
Reviewed-by: Matthias Kaehlcke
From: Sharat Masetty
This patch adds the interconnects property to the GPU node. This enables
the GPU->DDR path bandwidth voting.
Signed-off-by: Sharat Masetty
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git
This series add support for GPU DDR bandwidth scaling and is based on the
bindings from Georgi [1]. This is mostly a rebase of Sharat's patches [2] on the
tip of msm-next branch.
[1]
https://kernel.googlesource.com/pub/scm/linux/kernel/git/vireshk/pm/+log/opp/linux-next/
[2]
From: Sharat Masetty
Update documentation to list the gpu opp table bindings including the
newly added "opp-peak-kBps" needed for GPU-DDR bandwidth scaling.
Signed-off-by: Sharat Masetty
Acked-by: Rob Herring
Signed-off-by: Akhil P Oommen
---
.../devicetree/bindings/display/msm/gpu.txt
From: Sharat Masetty
This patches replaces the previously used static DDR vote and uses
dev_pm_opp_set_bw() to scale GPU->DDR bandwidth along with scaling
GPU frequency. Also since the icc path voting is handled completely
in the opp driver, remove the icc_path handle and its usage in the
drm
Hi Dave, Daniel,
More stuff for 5.9.
The following changes since commit 9555152beb1143c85c03f9b9de59863cbbe89f4b:
Merge tag 'amd-drm-next-5.9-2020-07-01' of
git://people.freedesktop.org/~agd5f/linux into drm-next (2020-07-02 15:17:31
+1000)
are available in the Git repository at:
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #71 from Anthony Ruhier (anthony.ruh...@gmail.com) ---
Just to give some news, I can confirm that I haven't had any freeze since
Wednesday. Usually, when my system just idled, it would quickly trigger the
bug. That or doing something
On Fri, Jul 17, 2020 at 12:51 PM Lucas Stach wrote:
>
> Am Freitag, den 17.07.2020, 12:45 +0300 schrieb Laurentiu Palcu:
> > Hi Lukas and Daniel,
> >
> > On Fri, Jul 17, 2020 at 11:27:58AM +0200, Daniel Vetter wrote:
> > > On Fri, Jul 17, 2020 at 11:12:39AM +0200, Lucas Stach wrote:
> > > > Am
Filed at https://bugzilla.kernel.org/show_bug.cgi?id=208597
oddly enough I wasn't able to reproduce it on my XPS 9560, will ping
once something breaks.
On Fri, Jul 17, 2020 at 2:43 AM Karol Herbst wrote:
>
> On Fri, Jul 17, 2020 at 1:54 AM Bjorn Helgaas wrote:
> >
> > [+cc Sasha -- stable
Am Freitag, den 17.07.2020, 12:45 +0300 schrieb Laurentiu Palcu:
> Hi Lukas and Daniel,
>
> On Fri, Jul 17, 2020 at 11:27:58AM +0200, Daniel Vetter wrote:
> > On Fri, Jul 17, 2020 at 11:12:39AM +0200, Lucas Stach wrote:
> > > Am Freitag, den 17.07.2020, 10:59 +0200 schrieb Daniel Vetter:
> > > >
Hi Lukas and Daniel,
On Fri, Jul 17, 2020 at 11:27:58AM +0200, Daniel Vetter wrote:
> On Fri, Jul 17, 2020 at 11:12:39AM +0200, Lucas Stach wrote:
> > Am Freitag, den 17.07.2020, 10:59 +0200 schrieb Daniel Vetter:
> > > On Fri, Jul 17, 2020 at 10:18 AM Lucas Stach
> > > wrote:
> > > > Hi
On Fri, Jul 17, 2020 at 11:12:39AM +0200, Lucas Stach wrote:
> Am Freitag, den 17.07.2020, 10:59 +0200 schrieb Daniel Vetter:
> > On Fri, Jul 17, 2020 at 10:18 AM Lucas Stach wrote:
> > > Hi Laurentiu,
> > >
> > > Am Donnerstag, den 09.07.2020, 19:47 +0300 schrieb Laurentiu Palcu:
> > > > From:
Am Freitag, den 17.07.2020, 10:59 +0200 schrieb Daniel Vetter:
> On Fri, Jul 17, 2020 at 10:18 AM Lucas Stach wrote:
> > Hi Laurentiu,
> >
> > Am Donnerstag, den 09.07.2020, 19:47 +0300 schrieb Laurentiu Palcu:
> > > From: Laurentiu Palcu
> > >
> > > Hi,
> > >
> > > This patchset adds initial
On Fri, Jul 17, 2020 at 04:00:36PM +0800, miaoqinglang wrote:
>
>
> 在 2020/7/17 15:06, Daniel Vetter 写道:
> > On Fri, Jul 17, 2020 at 8:40 AM james qian wang (Arm Technology China)
> > wrote:
> > >
> > > On Thu, Jul 16, 2020 at 05:03:33PM +0800, Qinglang Miao wrote:
> > > > From: Liu Shixin
>
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Evan Quan
-Original Message-
From: Qiu Wenbo
Sent: Friday, July 17, 2020 3:10 PM
To: Quan, Evan ; amd-...@lists.freedesktop.org
Cc: Qiu Wenbo ; Deucher, Alexander
; Koenig, Christian ;
Zhou, David(ChunMing) ; David
Leftover from the conversion to the generic fbdev emulation.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index 87821c91a00c..ed77dd5dd5cb 100644
drm_connector_register does nothing before drm_dev_register(), it
is meant for hotpluggable connectors only. Same for the unregister side.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arc/arcpgu_sim.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c
Also remove the now no longer needed build bug on since that's already
not needed anymore with drmm_add_final_kfree. Conversion to managed
drm_device cleanup is easy, the final drm_dev_put() is already the
last thing in both the bind unbind as in the unbind flow.
Also, this relies on component.c
Since aspeed doesn't use devm_kzalloc anymore we can use the managed
mode config cleanup.
Signed-off-by: Daniel Vetter
Cc: Joel Stanley
Cc: Andrew Jeffery
Cc: linux-asp...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 11 ++-
1
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
Signed-off-by: Daniel Vetter
Cc: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c| 4 ++--
drivers/gpu/drm/armada/armada_debugfs.c | 2 +-
drivers/gpu/drm/armada/armada_drm.h | 2
At less than 500 lines total feels like the right thing to do.
Also noticed that the simple wrapper around drm_connector_cleanup can
be dropped.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arc/Makefile | 2 +-
drivers/gpu/drm/arc/arcpgu.h | 39
Simple pipe helpers only have an enable and disable hook, no more
mode_set_nofb. Call it from our enable hook to align with that
conversions.
Atomic helpers always call mode_set_nofb and enable together, so
there's no functional change here.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
Because it is.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
MAINTAINERS | 2 +-
drivers/gpu/drm/Kconfig | 2 --
drivers/gpu/drm/Makefile| 1 -
drivers/gpu/drm/arc/Kconfig
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 2 ++
drivers/gpu/drm/arc/arcpgu_crtc.c | 4 ++--
drivers/gpu/drm/arc/arcpgu_drv.c | 4 +---
3 files
Really not big anymore.
v2: Fixup update function, bug reported by Eugeniy
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arc/Makefile | 2 +-
drivers/gpu/drm/arc/arcpgu.h | 1 -
drivers/gpu/drm/arc/arcpgu_crtc.c | 169 --
With autocleanup through drm_device management we can delete all the
code. Possible now that there's no confusion against devm_kzalloc'ed
structures anymore.
I inlined arcpgu_setup_mode_config because it's tiny and the newly
needed return value handling would have been more ...
Signed-off-by:
- Need to embedded the drm_device, but for now we keep the usual
pointer chasing.
- No more devm_kzalloc, which fixes a lifetime issues on driver
remove.
- No more drm_dev_put, that's done by devm_ now.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h |
Really not worth the function, much less the separate file now that
almost all the code is gone.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arc/Makefile | 2 +-
drivers/gpu/drm/arc/arcpgu.h | 1 -
drivers/gpu/drm/arc/arcpgu_drv.c | 12 +---
That way we can get rid of this final piece of init code, and use the
simple pipe helpers as intended.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu_drv.c | 51 ++--
1 file changed, 16 insertions(+), 35 deletions(-)
diff --git
Removes the last devm_kzalloc, which means we're now prepared to use
drmm_mode_config_cleanup!
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu.h | 1 +
drivers/gpu/drm/arc/arcpgu_sim.c | 14 +-
2 files changed, 2 insertions(+), 13 deletions(-)
It's redundant, drm core guarantees that state->fb is set iff
state->crtc is set.
v2: I had a misconception about simple helpers here and thought they
filter this out. They don't. Issue reported by Eugeniy.
Cc: Eugeniy Paltsev
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
This is a prep step to convert arc over to the simple kms helpers, for
now we just use this as an embedding container to drop all the various
allocations. Big change is the removal of the various devm_kzalloc,
which have the wrong lifetimes anyway.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
Really straighforward, only slight issue is that the sim connector is
created after the pipe is set up, so can't use the helpers perfectly
yet. Subsequent patches will fix that.
Aside from lots of deleting code no functional changes in here.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
On Tue, Jun 09, 2020 at 03:02:14PM +0200, Daniel Vetter wrote:
> Hi Eugeniy,
>
> Very much appreciated, and kinda expected. That 2nd backtrace really
> confuses me, so "something strange is going on" and the bisect looks
> funny is within expectations. Hopefully we can track down what's going
>
On Fri, Jul 17, 2020 at 10:18 AM Lucas Stach wrote:
>
> Hi Laurentiu,
>
> Am Donnerstag, den 09.07.2020, 19:47 +0300 schrieb Laurentiu Palcu:
> > From: Laurentiu Palcu
> >
> > Hi,
> >
> > This patchset adds initial DCSS support for iMX8MQ chip. Initial support
> > includes only graphics plane
Hi Laurentiu,
Am Donnerstag, den 09.07.2020, 19:47 +0300 schrieb Laurentiu Palcu:
> From: Laurentiu Palcu
>
> Hi,
>
> This patchset adds initial DCSS support for iMX8MQ chip. Initial support
> includes only graphics plane support (no video planes), no HDR10 capabilities,
> no graphics
On Fri, Jul 17, 2020 at 09:06:57AM +0200, Daniel Vetter wrote:
> On Fri, Jul 17, 2020 at 8:40 AM james qian wang (Arm Technology China)
> wrote:
> >
> > On Thu, Jul 16, 2020 at 05:03:33PM +0800, Qinglang Miao wrote:
> > > From: Liu Shixin
> > >
> > > Use DEFINE_SHOW_ATTRIBUTE macro to simplify
Add Droid 4 specific compatible value in addition to the
generic one, so that we have the ability to add panel
specific quirks in the future.
Reviewed-by: Laurent Pinchart
Signed-off-by: Sebastian Reichel
---
arch/arm/boot/dts/motorola-mapphone-common.dtsi | 2 +-
1 file changed, 1
The FRD350H54004 panel was marked as having active-high VSYNC and HSYNC
signals, which sorts-of worked, but resulted in the picture fading out
under certain circumstances.
Fix this issue by marking VSYNC and HSYNC signals active-low.
v2: Rebase on drm-misc-next
Fixes: 7b6bd8433609 ("drm/panel:
From: Krishna Manikandan
This change adds the interconnect bindings to the
MDSS node. This will establish Display to DDR path
for bus bandwidth voting.
Changes in v2:
- Change in commit message(Matthias Kaehlcke)
Changes in v3:
- Updated commit message to include
The cleanup series for omapdrm's DSI code got too big. Reviewing
this is not fun and the same goes for keeping track of the change
requests. Let's do the cleanup in smaller steps instead. This is
the first batch, which updates the binding (txt -> yaml) and
modifies the DT slightly.
Changes since
1 - 100 of 140 matches
Mail list logo
