Quoting Maxime Ripard (2020-04-24 08:33:56)
> The raspberry_clock_property only takes the clock ID as an argument, but
> now that we have a clock data structure it makes more sense to just pass
> that structure instead.
>
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: linux-...@vger.kernel.org
Quoting Maxime Ripard (2020-04-24 08:33:50)
> The pllb_arm clock was created at probe time, but was never removed if
> something went wrong later in probe, or if the driver was ever removed from
> the system.
>
> Now that we are using clk_hw_register, we can just use its managed variant
clk_hw_re
Quoting Maxime Ripard (2020-04-24 08:33:49)
> The pllb_arm clk_hw pointer in the raspberry_clk structure isn't used
> anywhere but in the raspberrypi_register_pllb_arm.
>
> Let's remove it, this will make our lives easier in future patches.
>
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: lin
Quoting Maxime Ripard (2020-04-24 08:33:47)
> Instead of declaring the clk_init_data and then calling memset on it, just
> initialise properly.
>
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: linux-...@vger.kernel.org
> Acked-by: Nicolas Saenz Julienne
> Signed-off-by: Maxime Ripard
> ---
On Tue, 26 May 2020 10:30:20 -0400
Andrey Grodzovsky wrote:
> On 5/19/20 6:06 AM, Pekka Paalanen wrote:
> > From: Pekka Paalanen
> >
> > Set up the expectations on how hot-unplugging a DRM device should look like
> > to
> > userspace.
> >
> > Written by Daniel Vetter's request and largely based
Quoting dillon min (2020-05-26 20:30:47)
> On Wed, May 27, 2020 at 9:44 AM Stephen Boyd wrote:
> >
> > Quoting dillon.min...@gmail.com (2020-05-24 20:45:45)
> > > From: dillon min
>
> >
> > >
> > > Signed-off-by: dillon min
> >
> > Any Fixes tag?
> ok, will add --fixup in git commit next time,
Hi Maxime,
On Tue, May 26, 2020 at 6:20 PM Maxime Ripard wrote:
> I gave it a try with U-Boot with my latest work and couldn't reproduce it, so
> it
> seems that I fixed it along the way
Is your latest work available in a git branch anywhere that we could
test directly?
Thanks
Daniel
_
Quoting dillon.min...@gmail.com (2020-05-24 20:45:45)
> From: dillon min
>
> ltdc set clock rate crashed
>'post_div_data[]''s pll_num is PLL_I2S, PLL_SAI (number is 1,2). but,
Please write "post_div_data[]'s" if it is possessive. "But" doesn't
start a sentence. This is one sentence, not two.
On Fri, May 22, 2020 at 03:52:36PM +0200, Thomas Zimmermann wrote:
> The malidp driver uses the default implementation for CMA functions; except
> for the .dumb_create callback. The __DRM_GEM_CMA_DRIVER_OPS macro now sets
> these defaults and .dumb_create in struct drm_driver. All remaining
> opera
On Fri, May 22, 2020 at 03:52:35PM +0200, Thomas Zimmermann wrote:
> The komeda driver uses the default implementation for CMA functions; except
> for the .dumb_create callback. The __DRM_GEM_CMA_DRIVER_OPS macro now sets
> these defaults and .dumb_create in struct drm_driver. All remaining
> opera
On Fri, May 22, 2020 at 03:52:28PM +0200, Thomas Zimmermann wrote:
> The arm driver uses the default implementation for CMA functions. The
> DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
> All remaining operations are provided by CMA GEM object functions.
>
> Signed-of
On 2020-05-26 14:00, Souptick Joarder wrote:
This code was using get_user_pages(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages() + release_pages() calls to
pin_user_pages() + unpin_user_pages() calls.
There is some
On Wed, May 13, 2020 at 02:59:02PM -0700, Douglas Anderson wrote:
> The ti-sn65dsi86 MIPI DSI to eDP bridge chip has a dedicated hardware
> HPD (Hot Plug Detect) pin on it, but it's mostly useless for eDP
> because of excessive debouncing in hardware. Specifically there is no
> way to disable the
On Wed, 13 May 2020 14:59:01 -0700, Douglas Anderson wrote:
> This moves the bindings over, based a lot on toshiba,tc358768.yaml.
> Unless there's someone known to be better, I've set the maintainer in
> the yaml as the first person to submit bindings.
>
> Signed-off-by: Douglas Anderson
> Review
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
libdrm 2.4.102, lots of FreeBSD and modetest stuff.
Boram Park (1):
drm mode : fix memory leak when freeing drmModePropertyPtr
Dave Airlie (1):
Bump version to 2.4.102
Emil Velikov (17):
tests: install drmdevice
modetest:
https://bugzilla.kernel.org/show_bug.cgi?id=207901
--- Comment #6 from Maurice Gale (mauricega...@gmail.com) ---
(In reply to Ilia Mirkin from comment #5)
> Does this continue to occur on recent kernels? e.g. 5.6 or 5.7-rc?
>
> It looks like aux port 9 is stuck somehow, not 100% sure that's somet
https://bugzilla.kernel.org/show_bug.cgi?id=207901
Ilia Mirkin (imir...@alum.mit.edu) changed:
What|Removed |Added
CC||imir...@alum.mit.edu
https://bugzilla.kernel.org/show_bug.cgi?id=207901
--- Comment #4 from Maurice Gale (mauricega...@gmail.com) ---
Created attachment 289317
--> https://bugzilla.kernel.org/attachment.cgi?id=289317&action=edit
CPU Information
--
You are receiving this mail because:
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=207901
--- Comment #3 from Maurice Gale (mauricega...@gmail.com) ---
Created attachment 289315
--> https://bugzilla.kernel.org/attachment.cgi?id=289315&action=edit
Config File
--
You are receiving this mail because:
You are watching the assignee of t
https://bugzilla.kernel.org/show_bug.cgi?id=207901
--- Comment #2 from Maurice Gale (mauricega...@gmail.com) ---
Created attachment 289313
--> https://bugzilla.kernel.org/attachment.cgi?id=289313&action=edit
PCI Information
--
You are receiving this mail because:
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=207901
--- Comment #1 from Maurice Gale (mauricega...@gmail.com) ---
Created attachment 289311
--> https://bugzilla.kernel.org/attachment.cgi?id=289311&action=edit
Log file with drm debugging enabled
--
You are receiving this mail because:
You are wa
https://bugzilla.kernel.org/show_bug.cgi?id=207901
Bug ID: 207901
Summary: Nouveau: In a 4 monitor setup, 1-2 displays remains
black after boot
Product: Drivers
Version: 2.5
Kernel Version: 5.3.0-51
Hardware: All
From: Lee Shawn C
So far, max dot clock rate for MST mode rely on physcial
bandwidth limitation. It would caused compatibility issue
if source display resolution exceed MST hub output ability.
For example, source DUT had DP 1.2 output capability.
And MST docking just support HDMI 1.4 spec. When
Something we've been missing for a while with drivers that support MST
is being able to prune modes that can't be set due to bandwidth
limitations. So, let's go ahead and add that. This also adds a new hook
that was needed, mode_valid_ctx, so that we can grab additional locks as
needed when validat
This is just an atomic version of mode_valid, which is intended to be
used for situations where a driver might need to check the atomic state
of objects other than the connector itself. One such example is with
MST, where the maximum possible bandwidth on a connector can change
dynamically irregard
https://bugzilla.kernel.org/show_bug.cgi?id=207899
--- Comment #7 from Alex Deucher (alexdeuc...@gmail.com) ---
Can you try adding amdgpu.ppfeaturemask=0x3fff to the kernel command line
in grub? Does that help?
--
You are receiving this mail because:
You are watching the assignee of the bug
https://bugzilla.kernel.org/show_bug.cgi?id=207899
--- Comment #6 from Blake C Lewis (blake.le...@gmail.com) ---
(In reply to Alex Deucher from comment #4)
> Created attachment 289301 [details]
> possible fix
>
> Does this patch fix the issue?
I haven't compiled a kernel in like 15 years, I comp
On Fri, 15 May 2020 13:49:20 +0800, Xin Ji wrote:
> anx7625: MIPI to DP transmitter DT schema
>
> Signed-off-by: Xin Ji
> ---
> .../bindings/display/bridge/analogix,anx7625.yaml | 95
> ++
> 1 file changed, 95 insertions(+)
> create mode 100644
> Documentation/devicetree/
https://bugzilla.kernel.org/show_bug.cgi?id=207899
--- Comment #5 from Blake C Lewis (blake.le...@gmail.com) ---
Created attachment 289303
--> https://bugzilla.kernel.org/attachment.cgi?id=289303&action=edit
screenshot of block of color noise in chrome
--
You are receiving this mail because:
Y
https://bugzilla.kernel.org/show_bug.cgi?id=207899
--- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) ---
Created attachment 289301
--> https://bugzilla.kernel.org/attachment.cgi?id=289301&action=edit
possible fix
Does this patch fix the issue?
--
You are receiving this mail because:
Yo
https://bugzilla.kernel.org/show_bug.cgi?id=207899
--- Comment #3 from Blake C Lewis (blake.le...@gmail.com) ---
Created attachment 289299
--> https://bugzilla.kernel.org/attachment.cgi?id=289299&action=edit
journalctl -b _COMM=Xorg >xorg
--
You are receiving this mail because:
You are watchin
https://bugzilla.kernel.org/show_bug.cgi?id=207899
--- Comment #2 from Blake C Lewis (blake.le...@gmail.com) ---
Created attachment 289297
--> https://bugzilla.kernel.org/attachment.cgi?id=289297&action=edit
dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug
https://bugzilla.kernel.org/show_bug.cgi?id=207899
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
On Mon, May 25, 2020 at 11:25:13PM -0400, Jonathan Marek wrote:
> This is required for A640 and A650 to be able to share UBWC-compressed
> images with other HW such as display, which expect this configuration.
> Signed-off-by: Jonathan Marek
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 38 +++
https://bugzilla.kernel.org/show_bug.cgi?id=207899
Bug ID: 207899
Summary: AMDGPU large block noise in chrome, on streaming video
pages. CS:GO freezes.
Product: Drivers
Version: 2.5
Kernel Version: 5.6.6-5.6.14
Hardware
On Fri, May 22, 2020 at 06:29:08PM -0400, Jonathan Marek wrote:
> Also skip the newly added HFI set freq path if the GMU is powered down,
> which was missing because of patches crossing paths.
I saw the 5.8 pull later in my inbox so I'm not sure if this made it or not but
it qualifies as a -fix if
Hi Laurent,
On 2020-03-09 20:51, Laurent Pinchart wrote:
> Hello,
>
> This patch series adds i.MX7 support to the mxsfb driver. The eLCDIF
> instance found in the i.MX7 is backward-compatible with the already
> supported LCDC v4, but has extended features amongst which the most
> notable one is a
On 5/19/20 6:06 AM, Pekka Paalanen wrote:
From: Pekka Paalanen
Set up the expectations on how hot-unplugging a DRM device should look like to
userspace.
Written by Daniel Vetter's request and largely based on his comments in IRC and
from
https://nam11.safelinks.protection.outlook.com/?url=h
On 2020-05-26 14:50, Neil Armstrong wrote:
> On 26/05/2020 03:15, Laurent Pinchart wrote:
>> On all platforms except i.MX and Rockchip, the dw-hdmi DT bindings
>> require a video output port connected to an HDMI sink (most likely an
>> HDMI connector, in rare cases another bridges converting HDMI t
Hi,
On Tue, May 26, 2020 at 04:14:48AM +0300, Laurent Pinchart wrote:
> When validating a mode, bridges may need to do so in the context of a
> display, as specified by drm_display_info. An example is the meson
> dw-hdmi bridge that needs to consider the YUV 4:2:0 output format to
> perform clock c
Hi Jonas,
On Mon, May 25, 2020 at 11:08:11AM +, Jonas Karlman wrote:
> Hi,
>
> On 2020-05-15 15:37, Brian Starkey wrote:
> > Hi Ben,
> >
> > On Wed, May 06, 2020 at 03:41:26PM +0100, Ben Davis wrote:
> >> Hi all, any feedback on this patch?
> >> Thanks, Ben
> >> On Wed, Apr 22, 2020 at 12:13
On 5/22/20 3:52 PM, Thomas Zimmermann wrote:
> The stm driver uses the default implementation for CMA functions; except
> for the .dumb_create callback. The __DRM_GEM_CMA_DRIVER_OPS macro now sets
> these defaults and .dumb_create in struct drm_driver. All remaining
> operations are provided by CMA
On Tue, 26 May 2020 04:14:48 +0300
Laurent Pinchart wrote:
> When validating a mode, bridges may need to do so in the context of a
> display, as specified by drm_display_info. An example is the meson
> dw-hdmi bridge that needs to consider the YUV 4:2:0 output format to
> perform clock calculatio
On 26/05/2020 03:14, Laurent Pinchart wrote:
> When validating a mode, bridges may need to do so in the context of a
> display, as specified by drm_display_info. An example is the meson
> dw-hdmi bridge that needs to consider the YUV 4:2:0 output format to
> perform clock calculations.
>
> Bridges
On 26/05/2020 03:15, Laurent Pinchart wrote:
> On all platforms except i.MX and Rockchip, the dw-hdmi DT bindings
> require a video output port connected to an HDMI sink (most likely an
> HDMI connector, in rare cases another bridges converting HDMI to another
> protocol). For those platforms, retr
On 26/05/2020 03:15, Laurent Pinchart wrote:
> Implement the drm_bridge_funcs .detect() and .get_edid() operations, and
> call drm_bridge_hpd_notify() notify to report HPD. This provides the
> necessary API to support disabling connector creation, do so by
> accepting DRM_BRIDGE_ATTACH_NO_CONNECTOR
On 26/05/2020 03:14, Laurent Pinchart wrote:
> The meson-dw-hdmi driver needs to access its own context from the
> .mode_valid() operation. It currently gets it from the dev_private field
> of the drm_device retrieved from the connector, which is a hack. Use the
> private data passed to the .mode_v
On 26/05/2020 03:14, Laurent Pinchart wrote:
> Store the connector that the bridge is currently wired to in the dw_hdmi
> structure. This is currently identical to the connector field, but will
> differ once the driver supports disabling connector creation.
>
> Signed-off-by: Laurent Pinchart
> -
On 26/05/2020 03:14, Laurent Pinchart wrote:
> To prepare for making connector creation optional in the driver, pass
> the drm_connector explicitly to the internal functions that require it.
> The functions that still access the connector from the dw_hdmi structure
> are dw_hdmi_connector_create()
On Tue, May 26, 2020 at 9:39 AM Pekka Paalanen wrote:
>
> On Tue, 26 May 2020 10:01:23 +0530
> Yogish Kulkarni wrote:
>
> > Hi,
> >
> > Is it possible to dynamically change enumeration list of DRM enumeration
> > property ? Motivation behind this question is to understand whether it is
> > possi
Thanks, Daniel & Pekka.
It might be bad idea to destroy and re-create the connector enum property
from HOTPLUG handler in DRM. But if this is done through
DRM_IOCTL_MODE_GETCONNECTOR, there won't be race, right ? From code walk
through it seems that Weston will call this IOCTL for newly connected
Hi Ondrej,
I see you took over this driver submission from
Icenowy.
On Wed, May 13, 2020 at 11:24 PM Ondrej Jirman wrote:
> From: Icenowy Zheng
>
> Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
> Xingbangda, which is used on PinePhone final assembled phones.
>
> It is ba
On Tue, May 26, 2020 at 9:01 AM Marek Szyprowski
wrote:
>
> Hi
>
> On 13.05.2020 15:47, Christoph Hellwig wrote:
> > I've pushed out a branch with the first three patches here:
> >
> > git://git.infradead.org/users/hch/dma-mapping.git dma-sg_table-helper
> >
> > Gitweb:
> >
> >
> > http:/
On Wed, May 13, 2020 at 11:24 PM Ondrej Jirman wrote:
> From: Icenowy Zheng
>
> Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel. It is based on
> Sitronix ST7703 LCD controller.
>
> Add its device tree binding.
>
> Signed-off-by: Icenowy Zheng
> Signed-off-by: Ondrej Jirman
Reviewed-
On Tue, May 26, 2020 at 6:39 AM Tetsuo Handa
wrote:
>
> On 2020/05/26 13:18, Tetsuo Handa wrote:
> > due to mode->crtc_clock <= 0. Thus, somehow initializing mode->crtc_clock >
> > 0 might be able
> > to solve this problem.
>
> Well, I came to think that vkms_enable_vblank() should return an erro
On 2020-05-20 at 09:11:38 -0400, Sean Paul wrote:
> On Mon, May 18, 2020 at 12:41 PM Ramalingam C wrote:
> >
> > On 2020-05-18 at 10:32:09 -0400, Sean Paul wrote:
> > > On Fri, May 15, 2020 at 10:48 AM Ramalingam C
> > > wrote:
> > > >
> > > > On 2020-04-29 at 15:54:46 -0400, Sean Paul wrote:
>
Den 26.05.2020 11.08, skrev dillon min:
> Hi Andy,
>
> Thanks for input.
>
> On Tue, May 26, 2020 at 3:46 PM Andy Shevchenko
> wrote:
>>
>> On Mon, May 25, 2020 at 6:46 AM wrote:
>>>
>>> From: dillon min
>>>
>>> This driver combine tiny/ili9341.c mipi_dbi_interface driver
>>> with m
Op 12-05-2020 om 10:59 schreef Daniel Vetter:
> Design is similar to the lockdep annotations for workers, but with
> some twists:
>
> - We use a read-lock for the execution/worker/completion side, so that
> this explicit annotation can be more liberally sprinkled around.
> With read locks lockd
On 26/05/2020 03:14, Laurent Pinchart wrote:
> Isolate all the code related to connector creation to a new
> dw_hdmi_connector_create() function, to prepare for making connector
> creation optional.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 107 +
On 26/05/2020 03:14, Laurent Pinchart wrote:
> To prepare for making connector creation optional in the driver, pass
> the drm_display_info explicitly to dw_hdmi_support_scdc(). The pointer
> is passed to the callers where required, particularly to the
> dw_hdmi_phy_ops .init() function.
>
> Signe
On 26/05/2020 03:14, Laurent Pinchart wrote:
> Several internal functions take a drm_display_mode argument to configure
> the HDMI encoder or the HDMI PHY. They must not modify the mode, make
> the pointer const to enforce that.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/
On 26/05/2020 03:14, Laurent Pinchart wrote:
> Replace the drm_connector pointer passed to the .mode_valid() function
> with a const drm_display_info pointer, as that's all the function should
> need. Use the display info passed to the bridge .mode_valid() operation
> instead of retrieving it from
On 26/05/2020 03:14, Laurent Pinchart wrote:
> The PHY .init() must not modify the mode it receives. Make the pointer
> const to enfore that.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 4 ++--
>
On 26/05/2020 03:14, Laurent Pinchart wrote:
> The .configure_phy() operation takes a dw_hdmi_plat_data pointer as a
> context argument. This differs from .mode_valid() that takes a custom
> private context pointer, causing possible confusion. Make the
> dw_hdmi_plat_data operations more consistent
On 26/05/2020 03:14, Laurent Pinchart wrote:
> The input_bus_format field of struct dw_hdmi_plat_data is unused. Remove
> it.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 5 +
> include/drm/bridge/dw_hdmi.h | 1 -
> 2 files changed, 1 i
On 26/05/2020 03:14, Laurent Pinchart wrote:
> Platform glue drivers for dw_hdmi may need to access device-specific
> data from their .mode_valid() implementation. They currently have no
> clean way to do so, and one driver hacks around it by accessing the
> dev_private data of the drm_device retri
On Mon, 25 May 2020 11:45:40 +0800, dillon.min...@gmail.com wrote:
> V5's update based on Mark Brown's suggestion, use 'SPI_MASTER_MUST_RX'
> for SPI_SIMPLEX_RX mode on stm32 spi controller.
>
> V5:
> 1 instead of add send dummy data out under SIMPLEX_RX mode,
>add flags 'SPI_CONTROLLER_MUST_T
On Mon, May 25, 2020 at 6:46 AM wrote:
>
> From: dillon min
>
> This driver combine tiny/ili9341.c mipi_dbi_interface driver
> with mipi_dpi_interface driver, can support ili9341 with serial
> mode or parallel rgb interface mode by register configuration.
Noralf told once that this d
On Tue, 26 May 2020 10:01:23 +0530
Yogish Kulkarni wrote:
> Hi,
>
> Is it possible to dynamically change enumeration list of DRM enumeration
> property ? Motivation behind this question is to understand whether it is
> possible to create connector enum property (e.g a property which will list
>
Commit 3a0709928b172a41 ("drm/vkms: Add vblank events simulated by
hrtimers") introduced ret_overrun variable. And that variable was an
unused-but-set-variable until commit 09ef09b4ab95dc40 ("drm/vkms:
WARN when hrtimer_forward_now fails") added WARN_ON(ret_overrun != 1).
Now, syzbot is hitting th
This is required for A640 and A650 to be able to share UBWC-compressed
images with other HW such as display, which expect this configuration.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 38 ++-
1 file changed, 32 insertions(+), 6 deletions(-)
This brings up basic video mode functionality for SM8150 DPU. Command mode
and dual mixer/intf configurations are not working, future patches will
address this. Scaler functionality and multiple planes is also untested.
Signed-off-by: Jonathan Marek
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
Update the UBWC registers to the right values for sm8150 and sm8250.
This removes broken dpu_hw_reset_ubwc, which doesn't work because the
"force blk offset to zero to access beginning of register region" hack is
copied from downstream, where mapped region starts 0x1000 below what is
used in the u
On 2020/05/26 2:00, Daniel Vetter wrote:
> Forgot to add: I did run this quickly with vkms as secondary output.
> Good fireworks show, but there's an entire army of additional splats
> after the first one. The WARN_ON you're removing is only the
> messenger, the real bug is probably one of the late
Le lun. 25 mai 2020 à 2:46, Noralf Trønnes a
écrit :
Den 24.05.2020 23.33, skrev Paul Cercueil:
Le dim. 24 mai 2020 à 23:24, Noralf Trønnes
a écrit :
Den 24.05.2020 22.42, skrev Paul Cercueil:
Le dim. 24 mai 2020 à 22:14, Noralf Trønnes
a
écrit :
Den 24.05.2020 21.5
This isn't something that ever changes between planes, so move it to
dpu_caps struct. Making this change will allow more re-use in the
"SSPP sub blocks config" part of the catalog, in particular when adding
support for SM8150 and SM8250 which have different max_linewidth.
This also sets max_hdeci_
Hi Michael,
On 01. 04. 20 13:30, Michal Simek wrote:
> On 01. 04. 20 12:38, Takashi Iwai wrote:
>> On Wed, 01 Apr 2020 12:35:16 +0200,
>> Michael Ellerman wrote:
>>>
>>> Michal Simek writes:
On 01. 04. 20 4:07, Michael Ellerman wrote:
> Michal Simek writes:
>> Hi,
>>
>> rece
The INTF_INPUT_CTRL feature is not available on sdm845, so don't set it.
This also adds separate feature bits for INTF (based on downstream) instead
of using CTL feature bit for it, and removes the unnecessary NULL check in
the added bind_pingpong_blk function.
Fixes: 73bfb790ac786ca55fa2786a06f5
On 5/25/20 9:23 PM, Dave Airlie wrote:
> On Tue, 26 May 2020 at 13:50, Randy Dunlap wrote:
>>
>> On 5/25/20 4:57 PM, Andrew Morton wrote:
>>> The mm-of-the-moment snapshot 2020-05-25-16-56 has been uploaded to
>>>
>>>http://www.ozlabs.org/~akpm/mmotm/
>>>
>>> mmotm-readme.txt says
>>>
>>> READ
This brings up basic video mode functionality for SM8250 DPU. Command mode
and dual mixer/intf configurations are not working, future patches will
address this. Scaler functionality and multiple planes is also untested.
Signed-off-by: Jonathan Marek
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
Calculate the correct timings for displayport, from downstream driver.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gp
On Mon, 2020-05-25 at 10:39 +0200, Matthias Brugger wrote:
>
> On 25/05/2020 04:27, Dennis-YC Hsieh wrote:
> >
> > On Sun, 2020-05-24 at 20:13 +0200, Matthias Brugger wrote:
> >>
> >> On 24/05/2020 19:31, Dennis-YC Hsieh wrote:
> >>> Hi Matthias,
> >>>
> >>> Thanks for your comment.
> >>>
> >>>
This fixes flushing of INTF_2 and INTF_3 on SM8150 and SM8250 hardware.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu
All DPU versions starting from 4.0 use the sdm845 version, so check for
that instead of checking each version individually. This chooses the right
function for sm8150 and sm8250.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 5 ++---
1 file changed, 2 insertions(+
Hi,
On Mon, May 11, 2020 at 11:12:05AM +0800, Jian-Hong Pan wrote:
> Jian-Hong Pan 於 2020年5月8日 週五 下午2:20寫道：
> >
> > Maxime Ripard 於 2020年5月8日 週五 上午1:22寫道：
> > >
> > > On Mon, May 04, 2020 at 02:35:08PM +0800, Jian-Hong Pan wrote:
> > > > Maxime Ripard 於 2020年4月29日 週三 上午12:21寫道：
> > > > >
> > >
On 2020/05/26 13:18, Tetsuo Handa wrote:
> due to mode->crtc_clock <= 0. Thus, somehow initializing mode->crtc_clock > 0
> might be able
> to solve this problem.
Well, I came to think that vkms_enable_vblank() should return an error to the
caller
when drm_calc_timestamping_constants() failed...
--
发自我的网易邮箱手机智能版
- Original Message -
From: "Daniel Vetter"
To: chenxb_99...@126.com
Cc: "David Airlie" , linux-ker...@vger.kernel.org,
dri-devel@lists.freedesktop.org
Sent: Mon, 25 May 2020 16:34:28 +0200
Subject: Re: [PATCH] drm: fix setting of plane_mask in pan_display_atomic(
These patches bring up SM8150 and SM8250 with basic functionality.
Tested with displayport output (single mixer, video mode case).
I will send patches later to add support for merge3d and dual DSI
configurations, and possibly also patches to fix command mode on
these SoCs (note it is also current
On 2020/05/26 0:21, Daniel Vetter wrote:
> On Mon, May 25, 2020 at 11:38:49PM +0900, Tetsuo Handa wrote:
>> Commit 3a0709928b172a41 ("drm/vkms: Add vblank events simulated by
>> hrtimers") introduced ret_overrun variable. And that variable was an
>> unused-but-set-variable until commit 09ef09b4ab95
On 21/05/20, Colin King wrote:
> From: Colin Ian King
>
> Currently HSD20_IPS is defined as "true" and will always result in a
> non-zero result even if it is defined as "false" because it is an array
> and that will never be zero. Fix this by defining it as an integer 1
> rather than a literal s
Hi
On 13.05.2020 15:47, Christoph Hellwig wrote:
> I've pushed out a branch with the first three patches here:
>
> git://git.infradead.org/users/hch/dma-mapping.git dma-sg_table-helper
>
> Gitweb:
>
>
> http://git.infradead.org/users/hch/dma-mapping.git/shortlog/refs/heads/dma-sg_table-he
On Tue, 21 Apr 2020, Guru Das Srinagesh wrote:
> Since the PWM framework is switching struct pwm_state.period's datatype
> to u64, prepare for this transition by using div_u64 to handle a 64-bit
> dividend instead of a straight division operation.
>
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: J
92 matches
Mail list logo
