On Tue, Jul 21, 2020 at 10:32 AM Sam Ravnborg wrote:
> > +description: |
> > + The Kinetic Technologies KTD253 is a white LED backlight that is
> > + controlled by a single GPIO line. If you just turn on the backlight
> > + it goes to maximum backlight then you can set the level of backlight
>
On Tue, Aug 11, 2020 at 04:26:31PM -0400, Alyssa Rosenzweig wrote:
> The AFBC decoder used in the Rockchip VOP assumes the use of the
> YUV-like colourspace transform (YTR). YTR is lossless for RGB(A)
> buffers, which covers the RGBA8 and RGB565 formats supported in
> vop_convert_afbc_format. Use o
On 8/12/2020 7:03 AM, John Stultz wrote:
On Tue, Aug 11, 2020 at 4:11 PM John Stultz wrote:
On Wed, Mar 20, 2019 at 2:49 AM Rajendra Nayak wrote:
geni serial needs to express a perforamnce state requirement on CX
depending on the frequency of the clock rates. Use OPP table from
DT to regi
Hi Linus,
This is the fixes pull for 5.9-rc1. I had some fixes from the misc
fixes tree come on a later base than drm-next was on, so I had to
backmerge 5.8 into this to make things work for me and CI. However it
totally messed up the diffstat so I didn't bother including it. The
changelog looks f
From: Chandan Uddaraju
Add the needed DP PLL specific files to support
display port interface on msm targets.
The DP driver calls the DP PLL driver registration.
The DP driver sets the link and pixel clock sources.
Changes in v2:
-- Update copyright markings on all relevant files.
-- Use DRM_DE
Configure HPD registers in DP controller and
enable HPD interrupt.
Add interrupt to handle HPD connect and disconnect events.
Changes in v8: None
Signed-off-by: Tanmay Shah
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 18
drivers/gpu/drm/msm/dp/dp_catalog.c | 63 --
dri
From: Jeykumar Sankaran
Add display port support in DPU by creating hooks
for DP encoder enumeration and encoder mode
initialization.
changes in v2:
- rebase on [2] (Sean Paul)
- remove unwanted error checks and
switch cases (Jordan Crouse)
[1] https://lwn.net/Articles
From: Chandan Uddaraju
The constant N value (0x8000) is used by i915 DP
driver. Define this value in dp helper header file
to use in multiple Display Port drivers. Change
i915 driver accordingly.
Change in v6: Change commit message
Signed-off-by: Chandan Uddaraju
Signed-off-by: Vara Reddy
Sig
These patches add Display-Port driver on SnapDragon/msm hardware.
This series also contains device-tree bindings for msm DP driver.
It also contains Makefile and Kconfig changes to compile msm DP driver.
The block diagram of DP driver is shown below:
+-+
HI Laurent,
On 12-08-20, 01:52, Laurent Pinchart wrote:
> Hi Vinod,
>
> On Sun, Aug 02, 2020 at 12:14:09PM +0530, Vinod Koul wrote:
> > On 31-07-20, 23:42, Laurent Pinchart wrote:
> > > On Fri, Jul 31, 2020 at 10:17:44PM +0530, Vinod Koul wrote:
> > > > On 31-07-20, 18:24, Laurent Pinchart wrote:
On Wed, 12 Aug 2020 at 05:34, Dave Airlie wrote:
>
> On Wed, 12 Aug 2020 at 03:11, Christian König
> wrote:
> >
> > Am 11.08.20 um 18:42 schrieb Michel Dänzer:
> > > On 2020-08-11 2:53 p.m., Christian König wrote:
> > >> Am 11.08.20 um 14:52 schrieb Christian König:
> > >>> Am 11.08.20 um 11:24 s
On Tue, Aug 11, 2020 at 4:11 PM John Stultz wrote:
>
> On Wed, Mar 20, 2019 at 2:49 AM Rajendra Nayak wrote:
> >
> > geni serial needs to express a perforamnce state requirement on CX
> > depending on the frequency of the clock rates. Use OPP table from
> > DT to register with OPP framework and u
Dave, Daniel,
vmwgfx fixes pull for 5.9.
The drm_mode_config_reset patches are very important fixing a recently
introduced kernel crash, the others fix various older issues which are
a bit less serious in practice.
(Although still pending a solution for the other crash introduced by
2ddef17678bc2e
Sorry for the slow reply here as well. I've been in the process of
rebasing and reworking the userspace patches. I'm not clear my changes
will address the Jetson Nano issue, but if you'd like to try them, the
latest userspace changes are available here:
https://gitlab.freedesktop.org/mesa/
On Wed, 12 Aug 2020 at 06:07, Lyude Paul wrote:
>
> Now that we've extracted i915's code for reading both the normal DPCD
> caps and extended DPCD caps into a shared helper, let's start using this
> in nouveau to enable us to start checking extended DPCD caps for free.
>
> Signed-off-by: Lyude Pau
On Wed, 12 Aug 2020 at 06:06, Lyude Paul wrote:
>
> This is another bit that we never implemented for nouveau: dongle
> detection. When a "dongle", e.g. an active display adaptor, is hooked up
> to the system and causes an HPD to be fired, we don't actually know
> whether or not there's anything p
On Wed, 12 Aug 2020 at 06:06, Lyude Paul wrote:
>
> Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/nouveau_dp.c | 16 +++-
> 1 file changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
> b/drivers/gpu/dr
On Wed, 12 Aug 2020 at 06:05, Lyude Paul wrote:
>
> Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/nouveau_dp.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
> b/drivers/gpu/drm/nouveau/
From: Rob Clark
For production devices, the debugbus sections will typically be fused
off and empty in the gpu device coredump. But since this may contain
data like cache contents, don't capture it by default.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 3 ++-
d
Hi GVRao,
Thank you for the patch.
On Tue, Aug 11, 2020 at 06:16:16AM +0530, Venkateshwar Rao Gannavarapu wrote:
> The Xilinx MIPI DSI (Display Serial Interface) Transmitter subsystem
> implements the Mobile Industry Processor Interface (MIPI) based display
> interface. It supports the interface
On Wed, Mar 20, 2019 at 2:49 AM Rajendra Nayak wrote:
>
> geni serial needs to express a perforamnce state requirement on CX
> depending on the frequency of the clock rates. Use OPP table from
> DT to register with OPP framework and use dev_pm_opp_set_rate() to
> set the clk/perf state.
>
> Signed
Hi Vinod,
On Sun, Aug 02, 2020 at 12:14:09PM +0530, Vinod Koul wrote:
> On 31-07-20, 23:42, Laurent Pinchart wrote:
> > On Fri, Jul 31, 2020 at 10:17:44PM +0530, Vinod Koul wrote:
> > > On 31-07-20, 18:24, Laurent Pinchart wrote:
> > > > Hello,
> > > >
> > > > This small series fixes a Kconfig de
On 2020-08-11 13:21, Randy Dunlap wrote:
On 8/11/20 12:49 PM, tan...@codeaurora.org wrote:
On 2020-08-07 13:28, Randy Dunlap wrote:
On 8/7/20 1:24 PM, Stephen Boyd wrote:
Quoting Rob Clark (2020-08-07 08:51:48)
On Fri, Aug 7, 2020 at 8:27 AM Randy Dunlap
wrote:
On 8/7/20 12:17 AM, Tanmay S
On Tue, Aug 11, 2020 at 5:08 PM Rob Clark wrote:
>
> From: Rob Clark
>
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:817 dpu_crtc_enable() error:
> uninitialized symbol 'request_bandwidth'.
>
> Reported-by: kernel test robot
Reviewed-by: Sean Paul
> Signed-off-by: Rob Clark
> ---
> drivers/g
From: Rob Clark
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:817 dpu_crtc_enable() error:
uninitialized symbol 'request_bandwidth'.
Reported-by: kernel test robot
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
On Tue, Aug 11, 2020 at 10:24 PM Linus Walleij wrote:
>
> On Mon, Aug 10, 2020 at 3:04 PM Daniel Vetter wrote:
> > On Sun, Aug 09, 2020 at 12:43:22AM +0200, Linus Walleij wrote:
> > > In order to successfully read ID of the MTP panel the
> > > panel MTP control page must be unlocked. Previously
>
Hi GVRao,
Thank you for the patches.
On Tue, Aug 11, 2020 at 06:16:15AM +0530, Venkateshwar Rao Gannavarapu wrote:
> Xilinx DSI-TX subsytem consists of DSI controller core, AXI crossbar
> and D-PHY as sub blocks. DSI TX subsystem driver supports multiple lanes
> upto 4, RGB color formats, video m
On Tue, Aug 11, 2020 at 2:46 AM Venkateshwar Rao Gannavarapu
wrote:
>
> Xilinx DSI-TX subsytem consists of DSI controller core, AXI crossbar
> and D-PHY as sub blocks. DSI TX subsystem driver supports multiple lanes
> upto 4, RGB color formats, video mode and command modes.
>
> DSI-TX driver is im
On Mon, Aug 10, 2020 at 3:04 PM Daniel Vetter wrote:
> On Sun, Aug 09, 2020 at 12:43:22AM +0200, Linus Walleij wrote:
> > In order to successfully read ID of the MTP panel the
> > panel MTP control page must be unlocked. Previously
> > this wasn't encountered because in the setup with this
> > pan
Since other drivers are also going to need to be aware of the sink count
in order to do proper dongle detection, we might as well steal i915's
DP_SINK_COUNT helpers and move them into DRM helpers so that other
dirvers can use them as well.
Note that this also starts using intel_dp_has_sink_count()
Currently in nouveau_connector_ddc_detect() and
nouveau_connector_detect_lvds(), we start the connector probing process
by releasing the previous EDID and informing DRM of the change. However,
since commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector") drm_connector_update_edid_prop
This is another bit that we never implemented for nouveau: dongle
detection. When a "dongle", e.g. an active display adaptor, is hooked up
to the system and causes an HPD to be fired, we don't actually know
whether or not there's anything plugged into the dongle without checking
the sink count. As
We're going to be doing the same probing process in nouveau for
determining downstream DP port capabilities, so let's deduplicate the
work by moving i915's code for handling this into a shared helper:
drm_dp_downstream_read_info().
Note that when we do this, we also do make some functional changes
And of course, we'll also need to read the sink count from other drivers
as well if we're checking whether or not it's supported. So, let's
extract the code for this into another helper.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_helper.c | 20
drivers/gpu/
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index d701f09aea645..bb85d81c25244 100644
--- a/drivers/gpu/drm/nou
Now that we've extracted i915's code for reading both the normal DPCD
caps and extended DPCD caps into a shared helper, let's start using this
in nouveau to enable us to start checking extended DPCD caps for free.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 14 ++
Since DP 1.3, it's been possible for DP receivers to specify an
additional set of DPCD capabilities, which can take precedence over the
capabilities reported at DP_DPCD_REV.
Basically any device supporting DP is going to need to read these in an
identical manner, in particular nouveau, so let's go
Since this actually logs accesses, we should probably always be using
this imho…
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/dr
Currently we perform both short IRQ handling for DP, and connector
reprobing in the HPD IRQ handler. However since we need to grab
connection_mutex in order to reprobe a connector, in theory we could
accidentally block ourselves from handling any short IRQs until after a
modeset completes if a conn
This adds support for querying the maximum clock rate of a downstream
port on a DisplayPort connection. Generally, downstream ports refer to
active dongles which can have their own pixel clock limits.
Note as well, we also start marking the connector as disconnected if we
can't read the DPCD, sinc
To start off: this patch series is less work to review then it looks -
most (but not all) of the nouveau related work has already been reviewed
elsewhere. Most of the reason I'm asking for an RFC here is because this
code pulls a lot of code out of i915 and into shared DP helpers.
Anyway-nouveau's
Since fa3cdf8d0b09 ("drm/nouveau: Reset MST branching unit before
enabling") we've been clearing DP_MST_CTRL before we start enabling MST.
Since then clearing DP_MST_CTRL in nv50_mstm_new() has been unnecessary
and redundant, so let's remove it.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
Just use drm_dp_dpcd_(readb|writeb)() so we get automatic DPCD logging
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers
Just a tiny drive-by cleanup, we can consolidate i915's code for
checking for MST support into a helper to be shared across drivers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/i915/display/intel_dp.c | 18 ++
include/drm/drm_dp_mst_helper.h | 22 ++
While the way we find the associated connector for an encoder is just
fine for legacy modesetting, it's not correct for nv50+ since that uses
atomic modesetting. For reference, see the drm_encoder kdocs.
Fix this by removing nouveau_encoder_connector_get(), and replacing it
with nv04_encoder_get_c
No functional changes.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8db9216d52c69..4030806
For whatever reason we currently unset the EDID for DP CEC support when
responding to the connector being unplugged, instead of just doing it in
nouveau_connector_detect() where we set the CEC EDID. This isn't really
needed and could even potentially cause us to forget to unset the EDID
if the conn
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8a0f7994e1aeb..ee778ddc95fae 100644
--- a/drivers/gpu/drm/nouveau/nouve
Noticed this while going through our DP code - we use an open-coded
version of drm_dp_read_desc() instead of just using the helper, so
change that. This will also let us use quirks in the future if we end up
needing them.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nou
First some backstory here: Currently, we keep track of whether or not
we've enabled MST or not by trying to piggy-back off the MST helpers.
This means that in order to check whether MST is enabled or not, we
actually need to grab drm_dp_mst_topology_mgr.lock.
Back when I originally wrote this, I d
Hi Venkateshwar
On Tue, Aug 11, 2020 at 06:16:15AM +0530, Venkateshwar Rao Gannavarapu wrote:
> Xilinx DSI-TX subsytem consists of DSI controller core, AXI crossbar
> and D-PHY as sub blocks. DSI TX subsystem driver supports multiple lanes
> upto 4, RGB color formats, video mode and command modes.
On 2020-08-07 13:28, Randy Dunlap wrote:
On 8/7/20 1:24 PM, Stephen Boyd wrote:
Quoting Rob Clark (2020-08-07 08:51:48)
On Fri, Aug 7, 2020 at 8:27 AM Randy Dunlap
wrote:
On 8/7/20 12:17 AM, Tanmay Shah wrote:
diff --git a/drivers/gpu/drm/msm/Kconfig
b/drivers/gpu/drm/msm/Kconfig
index ea3
From: kernel test robot
drivers/gpu/drm/i915/gt/gen6_ppgtt.c:263:6-8: ERROR: iterator variable bound on
line 262 cannot be NULL
drivers/gpu/drm/i915/gt/gen6_ppgtt.c:322:7-9: ERROR: iterator variable bound on
line 321 cannot be NULL
Many iterators have the property that the first argument is a
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: 06b108297b5cc24418e91c1103587ac7ca6fd03f
commit: 1d567ec619333e54283dcd02780ab9a71ef86e44 [27/28] drm/i915/gt: Switch to
object allocations for page directories
config: i386-randconfig-c001-20200811 (attached as .config
On Wed, 12 Aug 2020 at 03:11, Christian König
wrote:
>
> Am 11.08.20 um 18:42 schrieb Michel Dänzer:
> > On 2020-08-11 2:53 p.m., Christian König wrote:
> >> Am 11.08.20 um 14:52 schrieb Christian König:
> >>> Am 11.08.20 um 11:24 schrieb Christian König:
> This reverts commit 2ddef17678bc2ea
Hi Vinay.
> >
> > If Laurent or others identify further things to improve we can take
> > it in-tree.
>
> Just one thing, please see below.
>
> > > > >> + d2l_write(tc->i2c, VTIM1, vtime1);
> > > > >> + d2l_write(tc->i2c, HTIM2, htime2);
> > > > >> + d2l_write(tc->i2c, VTIM2,
Some Poco F1 phones have an LCD panel from Tianma, model nt36672a,
with a resolution of 1080x2246 that operates in DSI video mode.
Add the drm panel driver for it.
During testing, Benni Steini helped us fix
the reset sequence timing (from 10ms to 20ms), to get the bootanimation
to work on Androi
The nt36672a panel from Tianma is a FHD+ panel with a resolution of
1080x2246 and 6.18 inches size. It is found in some of the Poco F1
phones.
Signed-off-by: Sumit Semwal
Reviewed-by: Rob Herring
---
v2: remove ports node, making port@0 directly under panel@0 node.
v3: updated to replace port@0
Some Poco F1 phones from Xiaomi have an nt36672a video mode panel; add support
for the same.
Most of the panel data is taken from downstream panel dts, and is converted to
drm-panel based driver by me.
It has been validated with v5.8-rc5 on Poco F1 phone; my tree with other
dependent patches is her
On Thu, Jul 9, 2020 at 8:40 AM Anshuman Gupta wrote:
>
\snip
> > > +static int
> > > +intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port
> > > *intel_dig_port,
> > > + enum transcoder cpu_transcoder,
> > > + bool enable)
> >
On Thu, Jul 9, 2020 at 9:09 AM Anshuman Gupta wrote:
>
> On 2020-07-02 at 20:07:36 +0530, Anshuman Gupta wrote:
> > On 2020-06-30 at 12:48:34 -0400, Sean Paul wrote:
> > > On Tue, Jun 30, 2020 at 10:21 AM Anshuman Gupta
> > > wrote:
> > > >
> > > > On 2020-06-23 at 21:29:05 +0530, Sean Paul wrote
Am 11.08.20 um 18:42 schrieb Michel Dänzer:
On 2020-08-11 2:53 p.m., Christian König wrote:
Am 11.08.20 um 14:52 schrieb Christian König:
Am 11.08.20 um 11:24 schrieb Christian König:
This reverts commit 2ddef17678bc2ea1d20517dd2b4ed4aa967ffa8b.
As it turned out VMWGFX needs a much wider audi
On 2020-08-11 2:53 p.m., Christian König wrote:
> Am 11.08.20 um 14:52 schrieb Christian König:
>> Am 11.08.20 um 11:24 schrieb Christian König:
>>> This reverts commit 2ddef17678bc2ea1d20517dd2b4ed4aa967ffa8b.
>>>
>>> As it turned out VMWGFX needs a much wider audit to fix this.
>>>
>>> Signed-off
On Sat, Aug 08, 2020 at 10:29:11AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Backport note: maybe wait some time for the crashdec MR[1] to look for
> both the old typo'd name and the corrected name to land in mesa 20.2
>
> [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6242
R
On the working system I get:
[3.359749] pwm-backlight backlight: Linked as a consumer to regulator.7
[8.789867] panel-lvds panel: Linked as a consumer to regulator.8
Non-working:
[3.362822] pwm-backlight backlight: Linked as a consumer to regulator.7
[3.362907] pwm-backlight backli
On Tue, 2020-08-11 at 14:50 +, Stefan Birkholz wrote:
> Hello,
>
> we are using the mainline kernel (currently on 4.19.128) successfully on an
> i.MX6DL-based system, but when we try to upgrade to any more recent kernel
> (>5.1) the display output stops working (screen is blank, backlight wo
Hi Daniel,
actually git bisection yielded two subsequent commits 5bf7295fe34a525 and
80acbed9f8fca1db3f, both were bad, but I wasn't clear about what changed in the
imx-drm subsystem in those commits; bisection stopped then. I noticed there was
a transition from using to in
that timespan, bu
On Tue, Aug 11, 2020 at 5:07 PM Stefan Birkholz wrote:
>
> Hello,
>
> we are using the mainline kernel (currently on 4.19.128) successfully on an
> i.MX6DL-based system, but when we try to upgrade to any more recent kernel
> (>5.1) the display output stops working (screen is blank, backlight wor
On Wed, Aug 12, 2020 at 12:02:03AM +0900, Tetsuo Handa wrote:
> On 2020/08/04 21:58, Greg Kroah-Hartman wrote:
> > On Tue, Aug 04, 2020 at 08:15:43PM +0900, Tetsuo Handa wrote:
> >> Do you think this approach is acceptable? Or, do we need to modify
> >> set_origin() ?
> >>
> > I think what you hav
Hello,
we are using the mainline kernel (currently on 4.19.128) successfully on an
i.MX6DL-based system, but when we try to upgrade to any more recent kernel
(>5.1) the display output stops working (screen is blank, backlight works).
The relevant entries from the kernel log seem to be:
[8.
On Thu, Jul 2, 2020 at 10:49 AM Anshuman Gupta wrote:
>
> On 2020-06-30 at 12:48:34 -0400, Sean Paul wrote:
> > On Tue, Jun 30, 2020 at 10:21 AM Anshuman Gupta
> > wrote:
> > >
\snip
> > > > +static bool
> > > > +drm_dp_sideband_parse_query_stream_enc_status(
> > > > +
> On Aug 10, 2020, at 5:49 AM, Daniel Vetter wrote:
>
> On Sat, Aug 08, 2020 at 05:24:53PM +0200, Daniel Vetter wrote:
>> On Sat, Aug 8, 2020 at 1:28 PM Greg KH wrote:
>>>
>>> On Sat, Aug 08, 2020 at 01:02:34PM +0200, Daniel Vetter wrote:
On Sat, Aug 8, 2020 at 12:24 PM Greg KH wrote:
There are a few cases when the flags can change, for example DCC can be
disabled due to a hw limitation in the 3d engine. Modifiers give the
misleading impression that they help with that, but they don't. They don't
really help with anything.
Marek
On Mon., Aug. 10, 2020, 08:30 Christian König, <
Am 11.08.20 um 14:52 schrieb Christian König:
Am 11.08.20 um 11:24 schrieb Christian König:
This reverts commit 2ddef17678bc2ea1d20517dd2b4ed4aa967ffa8b.
As it turned out VMWGFX needs a much wider audit to fix this.
Signed-off-by: Christian König
Dare to give me an rb for this? I already te
Am 11.08.20 um 11:24 schrieb Christian König:
This reverts commit 2ddef17678bc2ea1d20517dd2b4ed4aa967ffa8b.
As it turned out VMWGFX needs a much wider audit to fix this.
Signed-off-by: Christian König
Dare to give me an rb for this? I already tested on amdgpu and it should
be fixing the VMW
Some Poco F1 phones from Xiaomi have an nt36672a video mode panel; add support
for the same.
Most of the panel data is taken from downstream panel dts, and is converted to
drm-panel based driver by me.
It has been validated with v5.8-rc5 on Poco F1 phone; my tree with other
dependent patches is her
The nt36672a panel from Tianma is a FHD+ panel with a resolution of
1080x2246 and 6.18 inches size. It is found in some of the Poco F1
phones.
Signed-off-by: Sumit Semwal
Reviewed-by: Rob Herring
---
v2: remove ports node, making port@0 directly under panel@0 node.
v3: updated to replace port@0
Some Poco F1 phones have an LCD panel from Tianma, model nt36672a,
with a resolution of 1080x2246 that operates in DSI video mode.
Add the drm panel driver for it.
During testing, Benni Steini helped us fix
the reset sequence timing (from 10ms to 20ms), to get the bootanimation
to work on Androi
Hi Prabhakar,
Thank you for the patch.
On Fri, Aug 07, 2020 at 06:49:54PM +0100, Lad Prabhakar wrote:
> The iwg21d comes with a 7" capacitive touch screen, therefore
> add support for it.
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Marian-Cristian Rotariu
>
> ---
> arch/arm/boot/dts/r8a7
From: Guchun Chen
Otherwise, braces are needed when using it.
Signed-off-by: Guchun Chen
Reviewed-by: Christian König
---
include/linux/rwsem.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
index 7e5b2a4eb560..7a5bf5d50489 10
Hi Biju,
Thank you for the patch.
On Mon, Aug 10, 2020 at 04:22:18PM +0100, Biju Das wrote:
> Add the support for enabling optional regulator that may be used as VCC
> source.
>
> Signed-off-by: Biju Das
> ---
> New Patch Ref: Ref:https://patchwork.kernel.org/patch/11705819/
> ---
> drivers/gp
Hi Biju,
Thank you for the patch.
On Mon, Aug 10, 2020 at 04:22:17PM +0100, Biju Das wrote:
> Document optional vcc-supply property that may be used as VCC source.
>
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
> ---
> New patch Ref: Ref:https://patchwork.kernel.org/patch/11705819
Hi Sam,
On Mon, Aug 10, 2020 at 07:54:40PM +0200, Sam Ravnborg wrote:
> Hi Vinay.
>
> Vinay - thanks for following carefully up on the review feedback.
> I know it can be frustrating to wait for feedback.
>
> On Sun, Aug 09, 2020 at 12:30:22AM +0300, Laurent Pinchart wrote:
> > Hi Vinay,
> >
>
This reverts commit 2ddef17678bc2ea1d20517dd2b4ed4aa967ffa8b.
As it turned out VMWGFX needs a much wider audit to fix this.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 19 ---
drivers/gpu/drm/ttm/ttm_bo_util.c | 7 ++-
drivers/gpu/drm/ttm/ttm_bo_v
On Mon, Aug 10, 2020 at 10:11:50AM -0700, Zwane Mwaikambo wrote:
> Hi Folks,
> I know this thread eventually dropped off due to not identifying
> the underlying issue. It's still occuring on 5.8 and in my case it
> happened because the udev device nodes for the DP aux devices were not
> cl
On Tue, Aug 11, 2020 at 10:12:01AM +0200, Sam Ravnborg wrote:
> Hi Thomas.
>
> On Tue, Aug 11, 2020 at 08:59:13AM +0200, Thomas Zimmermann wrote:
> > Hi Sam
> >
> > thanks for taken care of this issue. Alpha is a rare architecture these
> > days. How do you build and test for it?
>
> I am on ubu
Am 11.08.20 um 10:49 schrieb Dave Airlie:
On Tue, 11 Aug 2020 at 18:42, Christian König
wrote:
I've totally missed those and still don't see any reference in any inbox
to the original mail or patch #2 in this series.
I forgot to cc you on the original posting, but they should be on dri-devel
On Tue, 11 Aug 2020 at 18:42, Christian König
wrote:
>
> I've totally missed those and still don't see any reference in any inbox
> to the original mail or patch #2 in this series.
I forgot to cc you on the original posting, but they should be on dri-devel
https://patchwork.freedesktop.org/serie
I've totally missed those and still don't see any reference in any inbox
to the original mail or patch #2 in this series.
But this patch at least looks like it makes a lot of sense.
BTW: Does anybody know why we separate base and offset here? That
distinction seems to be superfluous as well.
Hi Thomas.
On Tue, Aug 11, 2020 at 08:59:13AM +0200, Thomas Zimmermann wrote:
> Hi Sam
>
> thanks for taken care of this issue. Alpha is a rare architecture these
> days. How do you build and test for it?
I am on ubuntu here so I have installed:
apt install gcc-alpha-linux-gnu
And then alpha is
On Tue, Aug 11, 2020 at 10:57:02AM +0300, Dan Carpenter wrote:
> On Mon, Aug 10, 2020 at 08:41:14PM +0200, Marion & Christophe JAILLET wrote:
> >
> > Le 10/08/2020 à 17:42, Dan Carpenter a écrit :
> > > On Sun, Aug 09, 2020 at 10:34:06PM +0200, Christophe JAILLET wrote:
> > > > When '*sgt' is allo
(cc'ing Christian, just in case he misses them). 2 small cleanups.
On Tue, 11 Aug 2020 at 17:47, Dave Airlie wrote:
>
> From: Dave Airlie
>
> The drivers all do the same thing here.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 --
> drivers/gpu/drm/
On Mon, Aug 10, 2020 at 08:41:14PM +0200, Marion & Christophe JAILLET wrote:
>
> Le 10/08/2020 à 17:42, Dan Carpenter a écrit :
> > On Sun, Aug 09, 2020 at 10:34:06PM +0200, Christophe JAILLET wrote:
> > > When '*sgt' is allocated, we must allocated 'sizeof(**sgt)' bytes instead
> > > of 'sizeof(*
From: Dave Airlie
This is always calculated the same, and only used in a couple of places.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ++-
drivers/gpu/drm/radeon/radeon_ttm.c | 7 ---
drivers/gpu/drm/ttm/ttm_bo_util.c | 7 ---
include/drm/ttm/ttm_bo_api.h| 2 --
From: Dave Airlie
The drivers all do the same thing here.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 --
drivers/gpu/drm/drm_gem_vram_helper.c | 6 --
drivers/gpu/drm/nouveau/nouveau_bo.c | 6 --
drivers/gpu/drm/qxl/qxl_ttm.c
> Well how about completely removing the concept of a global TT from TTM?
Yes makes sense to me to try and rip out the global TT from the core
and turn it into a driver optional feature is possible.
Dave.
>
> What TTM should do is managing domains and help with the transitions
> between those do
If you pass a string that is not terminated with a carriage return to
dev_err(), it will eventually be printed with a carriage return, but
not right away, since the kernel will wait for a pr_cont().
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/panel/panel-novatek-nt39016.c | 18 +
Hi Folks,
I know this thread eventually dropped off due to not identifying
the underlying issue. It's still occuring on 5.8 and in my case it
happened because the udev device nodes for the DP aux devices were not
cleaned up whereas the kernel had no association with them. I can
reproduc
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to ha
> > > -static int gxfb_suspend(struct pci_dev *pdev, pm_message_t state)
> > > +static int __maybe_unused gxfb_suspend(struct device *dev)
> > > {
> > > - struct fb_info *info = pci_get_drvdata(pdev);
> > > + struct fb_info *info = dev_get_drvdata(dev);
> > I do not see any dev_set_drvdata() so I
1 - 100 of 123 matches
Mail list logo
