Hi, Jitao:
On Sun, 2019-05-19 at 17:25 +0800, Jitao Shi wrote:
> mtk_mipi_tx is the phy of mtk_dsi.
> mtk_dsi get the phy(mtk_mipi_tx) in probe().
>
> So, mtk_mipi_tx init should be ahead of mtk_dsi. Or mtk_dsi will
> defer to wait mtk_mipi_tx probe done.
Reviewed-by: CK Hu
>
>
Hi, Jitao:
On Sun, 2019-05-19 at 17:25 +0800, Jitao Shi wrote:
> New DSI IP has shadow register and working reg. The register
> values are writen to shadow register. And then trigger with
> commit reg, the register values will be moved working register.
>
> This fucntion is defualt on. But this
On Fri, May 31, 2019 at 2:54 AM Maxime Ripard wrote:
>
> Hi,
>
> On Thu, May 30, 2019 at 09:48:02PM +0800, Chen-Yu Tsai wrote:
> > On Mon, May 27, 2019 at 8:09 PM Maxime Ripard
> > wrote:
> > >
> > > The Allwinner SoCs have a MIPI-DSI and MIPI-D-PHY controllers supported in
> > > Linux, with a
Hi, Jitao:
On Sun, 2019-05-19 at 19:15 +0800, Jitao Shi wrote:
> Reset dsi HW to default when power on. Prevent the setting differet
> between bootloader and kernel.
>
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 35 ++
> 1 file changed,
Hi Linus,
Nothing too crazy, pretty quiet, maybe too quiet.
amdgpu:
- a fixed version of the raven firmware fix we previously reverted,
- stolen memory fix
imx:
- regression fix
qxl:
- remove a bad warning.
etnaviv:
- VM locking fix.
Dave.
drm-fixes-2019-05-31:
drm etnaviv, imx, amdgpu
Hi Boris,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.2-rc2 next-20190530]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
https://bugs.freedesktop.org/show_bug.cgi?id=110117
--- Comment #12 from Craig ---
yes i should mention most of my static is grey but there are colours in there
as well
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=110117
--- Comment #11 from leo60228 ---
I can reproduce on the same machine, but I get rainbow static, not grey.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
Hi Jitao,
On Sun, May 19, 2019 at 2:27 AM Jitao Shi wrote:
>
> Change the method of frame rate calc which can get more accurate
> frame rate.
>
> data rate = pixel_clock * bit_per_pixel / lanes
> Adjust hfp_wc to adapt the additional phy_data
>
> if MIPI_DSI_MODE_VIDEO_BURST
> hfp_wc =
Hi,
On Thu, May 30, 2019 at 09:48:02PM +0800, Chen-Yu Tsai wrote:
> On Mon, May 27, 2019 at 8:09 PM Maxime Ripard
> wrote:
> >
> > The Allwinner SoCs have a MIPI-DSI and MIPI-D-PHY controllers supported in
> > Linux, with a matching Device Tree binding.
> >
> > Now that we have the DT
On Fri, May 24, 2019 at 03:55:42PM +0530, Jagan Teki wrote:
> On Fri, May 24, 2019 at 2:07 AM Maxime Ripard
> wrote:
> >
> > On Mon, May 20, 2019 at 02:33:09PM +0530, Jagan Teki wrote:
> > > start value in video start delay computation done in below commit
> > > is as per the legacy bsp
Hey, sorry for my late response!
On 2019-05-16 5:40 p.m., Lyude Paul wrote:
>>if (old_pdt != port->pdt && !port->input) {
>> @@ -1220,6 +1268,8 @@ static void drm_dp_add_port(struct drm_dp_mst_branch
>> *mstb,
>>drm_connector_set_tile_property(port->connector);
https://bugs.freedesktop.org/show_bug.cgi?id=110721
alvarex changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #32 from Tom B ---
This is still an issue in 5.1.5. It seems slightly more stable but I'm still
getting the high power usage and no boost clocks.
On a successful boot I see the following in dmesg:
[3.628369] [drm] amdgpu:
From: Colin Ian King
The variable status is initialized with a value that is never read
and status is reassigned several statements later. This initialization
is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
The DSI controller on the MSM8998 SoC is a 6G v2.0.0 controller which is
very similar to the v2.0.1 of SDM845.
Signed-off-by: Jeffrey Hugo
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 21 +
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
2 files changed, 22 insertions(+)
diff --git
The v3.0.0 10nm phy has two different implementations between MSM8998 and
SDM845, which require different timings calculations. Unfortunately, the
hardware designers did not choose to revise the version to account for this
delta so implement a quirk instead.
Signed-off-by: Jeffrey Hugo
---
The MSM8998 dsi phy is 10nm v3.0.0 like SDM845, however there appear to
be minor differences such as the address space location.
Signed-off-by: Jeffrey Hugo
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 ++
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 1 +
The DSI phy on MSM8998 is a 10nm design like SDM845, however it has some
slightly different quirks which need to be handled by drivers. Provide
a separate compatible to assist in handling the specifics.
Signed-off-by: Jeffrey Hugo
---
Documentation/devicetree/bindings/display/msm/dsi.txt | 1 +
Enabling DSI support for the MSM8998 SoC is another step to getting end
to end display going. This will allow the SoC to drive panels that are
integraded on the device (ie not a HDMI port), but won't do much until
we have the display processor feeding the DSI blocks with lines to
scanout.
On Thu, May 30, 2019 at 11:31:12PM +0800, Yuehaibing wrote:
> Hi all,
>
> Friendly ping:
>
> Who can take this?
>
> On 2019/4/17 22:26, Yue Haibing wrote:
> > From: YueHaibing
> >
> > During randconfig builds, I occasionally run into an invalid configuration
> >
> > WARNING: unmet direct
Hi all,
Friendly ping:
Who can take this?
On 2019/4/17 22:26, Yue Haibing wrote:
> From: YueHaibing
>
> During randconfig builds, I occasionally run into an invalid configuration
>
> WARNING: unmet direct dependencies detected for DEVICE_PRIVATE
> Depends on [n]: ARCH_HAS_HMM_DEVICE [=n]
Am 29.05.19 um 21:36 schrieb Daniel Vetter:
On Wed, May 29, 2019 at 04:43:45PM +, Grodzovsky, Andrey wrote:
I don't, sorry.
Should we fix that? Seems like you do plenty of scheduler stuff, so would
make sense I guess ...
Reviewed-by: Christian König for the patch.
And +1 for giving
On Mon, May 27, 2019 at 8:09 PM Maxime Ripard wrote:
>
> The Allwinner SoCs have a MIPI-DSI and MIPI-D-PHY controllers supported in
> Linux, with a matching Device Tree binding.
>
> Now that we have the DT validation in place, let's convert the device tree
> bindings for that controller over to a
In order to support driver hot unbind, some cleanup operations, now
performed on PCI driver remove, must be called later, after all device
file descriptors are closed.
Split out those operations from the tail of pci_driver.remove()
callback and put them into drm_driver.release() which is called
Add COMPILE_TEST support to atmel_lcdfb driver for better compile
testing coverage.
While at it fix improper use of UL (to silence build warnings on
x86_64).
Cc: Alexandre Belloni
Cc: Ludovic Desroches
Signed-off-by: Bartlomiej Zolnierkiewicz
---
v3: fix build warnings on x86_64
v2: add
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #7 from Richard Thier ---
Latest bisect result so far:
Fast mesa version: 17.2.8 (2017 december 22)
Slow mesa version: 18.0.0 (git: 44c7d1aa2ea)
The change that slows the system is between the two.
--
You are receiving this mail
Woohoo! Patches 1-3 are R-b; patch 4 is A-b. Exciting progress! Hoping
to hear what Rob and Steven think :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi,
I have rebase my kernel on latest 5.2-rc2, and my panfrost driver is
no more probing.
The issue is coming from f3617b449d0bcf3b5d80a97f51498dcf7463cf7e
drm/panfrost: Select devfreq
Currently, there is some logic for the driver to work without devfreq.
However, the driver
On 5/8/19 23:42, Rob Clark wrote:
> From: Georgi Djakov
>
Let's put some text in the commit message:
The interconnect API provides an interface for consumer drivers to express
their bandwidth needs in the SoC. This data is aggregated and the on-chip
interconnect hardware is configured to the
On 3/7/2019 3:02 PM, Abhinav Kumar wrote:
On 2019-03-07 13:59, Sean Paul wrote:
On Wed, Mar 06, 2019 at 05:28:54PM -0800, Abhinav Kumar wrote:
When panel probe happens after DSI probe, the DSI probe
is deferred as per current design. In the probe defer path
dsi device is destroyed. This NULL
Similar to Layer Split, but Splitter is used for writeback, which splits
the compiz result to two half parts and then feed them to two scalers.
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 63 +++
Writeback split is also for workaround the size limitation of d71 scaler.
Like layer_split, writeback downscaling also can use two scalers to handle
the scaling half-by-half. The only differnence is writback needs a
standalone component (splitter)'s help to split the composition result.
The data
Writeback split is also for workaround the size limitation of d71 scaler.
Like layer_split, writeback downscaling also can use two scalers to handle
the scaling half-by-half. The only differnence is writback needs a
standalone component (splitter)'s help to split the composition result.
The data
Hi, Hsin-Yi:
On Thu, 2019-05-30 at 17:18 +0800, Hsin-Yi Wang wrote:
> mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), which
> needs
> ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop() is called,
> ovl irq will be disabled. If drm_crtc_wait_one_vblank() is
On Thu, May 23, 2019 at 06:31:15PM -0400, Lyude Paul wrote:
> On Fri, 2019-05-24 at 01:28 +0300, Imre Deak wrote:
> > On Thu, May 23, 2019 at 06:09:56PM -0400, Lyude Paul wrote:
> > > Patch mostly looks good to me, one comment below
> > >
> > > On Fri, 2019-05-24 at 00:24 +0300, Imre Deak wrote:
Quoting Janusz Krzysztofik (2019-05-30 10:24:26)
> In order to support driver hot unbind, some cleanup operations, now
> performed on PCI driver remove, must be called later, after all device
> file descriptors are closed.
>
> Split out those operations from the tail of pci_driver.remove()
>
In order to support driver hot unbind, some cleanup operations, now
performed on PCI driver remove, must be called later, after all device
file descriptors are closed.
Split out those operations from the tail of pci_driver.remove()
callback and put them into drm_driver.release() which is called
Hi,
I do realize more work needs to be done to get a clean hotunplug
solution, however I need your comments to make sure that I'm going in
the right direction.
So far I have no good idea how to resolve pm_runtime_get_sync()
failures on outstanding device file close after successfull driver
mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), which needs
ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop() is called,
ovl irq will be disabled. If drm_crtc_wait_one_vblank() is called after last
irq, it will timeout with this message: "vblank wait timed out
On 30/05/19 01:23, Mauro Carvalho Chehab wrote:
> Sphinx doesn't like orphan documents:
>
> Documentation/accelerators/ocxl.rst: WARNING: document isn't included in
> any toctree
> Documentation/arm/stm32/overview.rst: WARNING: document isn't included in
> any toctree
>
Adds gamma and color-transform support for DOU-IPS.
Adds two caps members fgamma_coeffs and ctm_coeffs to komeda_improc_state.
If color management changed, set gamma and color-transform accordingly.
This patch series depends on:
- https://patchwork.freedesktop.org/series/58710/
-
https://bugs.freedesktop.org/show_bug.cgi?id=108940
--- Comment #21 from l...@greensphere.co.za ---
Exactly Same Issue:
Fatal1ty AB350 Gaming-ITX/ac
AMD Ryzen 5 2400G
Is there anything I can do to help get this bug resolved?
My system remains unstable, with hardware resets the only solution.
Hi, Hsin-Yi:
On Thu, 2019-05-30 at 10:55 +0800, Hsin-Yi Wang wrote:
> On Tue, May 28, 2019 at 4:53 PM CK Hu wrote:
>
> > I think we've already discussed in [1]. I need a reason to understand
> > this is hardware behavior or software bug. If this is a software bug, we
> > need to fix the bug and
* Tony Lindgren [190530 05:47]:
> * Tony Lindgren [190529 08:11]:
> > * Tomi Valkeinen [190529 07:06]:
> > > On 28/05/2019 13:18, Tony Lindgren wrote:
> > >
> > > > > My board is x15 rev A3, attached to AM5 EVM. I've also attached my
> > > > > kernel
> > > > > config.
> > > >
> > > > Strange
Hi Alex et all.
> - Various cleanups
Any chance to persuade one of you guys to sweep through the amd / raedeon
tree and drop use of the deprecated header drmP.h?
Status at the moment (drm-misc-next):
$git grep drmP | cut -d '/' -f 1 | uniq -c | sort -n | tail -n 10
11 meson
12
46 matches
Mail list logo
