Looks good for me, patch is:
Reviewed-by: Qiang Yu
Regards,
Qiang
On Thu, Aug 20, 2020 at 6:44 PM Viresh Kumar wrote:
>
> dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
> find the OPP table with error -ENODEV (i.e. OPP table not present for
> the device). And we can cal
From: CK Hu
mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
more suitable to place a phy driver into phy driver folder, so move
mtk_hdmi_phy driver into phy driver folder.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/Kconfig
mtk_hdmi_phy is currently placed inside mediatek drm driver, but it's
more suitable to place a phy driver into phy driver folder, so move
mtk_hdmi_phy driver into phy driver folder.
Changes in v5:
- Fixup indent in Kconfig.
- Refine config help message.
- Refine Makefile.
Changes in v4:
- Rebase
From: CK Hu
mtk_hdmi_phy is a part of mtk_hdmi module, but phy driver should be an
independent module rather than be part of drm module, so separate the phy
driver to an independent module.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/Kconfig| 9
Mediatek HDMI phy driver is moved from drivers/gpu/drm/mediatek to
drivers/phy/mediatek, so add the new folder to the Mediatek DRM drivers'
information.
Signed-off-by: Chun-Kuang Hu
Reviewed-by: Matthias Brugger
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/M
From: CK Hu
tz_disabled is used to control mtk_hdmi output signal, but this variable
is stored in mtk_hdmi_phy and mtk_hdmi_phy does not use it. So move
tz_disabled to mtk_hdmi where it's used.
Signed-off-by: CK Hu
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_hdmi.c
https://bugzilla.kernel.org/show_bug.cgi?id=208947
--- Comment #17 from Coleman Kane (ck...@colemankane.org) ---
Created attachment 292061
--> https://bugzilla.kernel.org/attachment.cgi?id=292061&action=edit
Proposed patch (add amdgpu.dp_cll_status bool, default: on)
Attaching a proposed patch
From: Rob Clark
Now that it isn't causing problems to use dma_map/unmap, we can drop the
hack of using dma_sync in certain cases.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/m
https://bugzilla.kernel.org/show_bug.cgi?id=208997
Bug ID: 208997
Summary: WARNING: CPU: 3 PID: 1633 at
drivers/gpu/drm/drm_modeset_lock.c
Product: Drivers
Version: 2.5
Kernel Version: 5.8.0
Hardware: x86-64
Hi Tomi,
On Fri, Aug 21, 2020 at 03:06:59PM +0300, Tomi Valkeinen wrote:
> On 21/08/2020 10:45, Dinghao Liu wrote:
> > pm_runtime_get_sync() increments the runtime PM usage counter
> > even when it returns an error code. However, users of
> > dsi_runtime_get(), a direct wrapper of pm_runtime_get_s
On 2020-08-21 8:07 p.m., Kazlauskas, Nicholas wrote:
> On 2020-08-21 12:57 p.m., Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> Don't check drm_crtc_state::active for this either, per its
>> documentation in include/drm/drm_crtc.h:
>>
>> * Hence drivers must not consult @active in their vario
Hi Josua.
On Fri, Aug 21, 2020 at 03:25:36PM +0200, Ing. Josua Mayer wrote:
> Dear Maintainers, readers ...
>
> While updating the solidrun cubox (dove) running debian from 5.6 to 5.7
> I came across a new crash in etnaviv that did not occur before - and is
> also present in 5.8.0:
>
> [ 33.04
Hi Enric.
On Fri, Aug 21, 2020 at 01:38:09PM +0200, Sam Ravnborg wrote:
> Hi Enric.
>
> >
> > Let me reformulate the question for if it was not clear.
> >
> > What I did is be able to read the EDID every time userspace asks for it (so
> > kernel enables all the required) and Sam is proposing to
On Mon, Jun 15, 2020 at 10:53:20PM +0200, Enric Balletbo i Serra wrote:
> The get_edid() callback can be triggered anytime by an ioctl, i.e
>
> drm_mode_getconnector (ioctl)
> -> drm_helper_probe_single_connector_modes
>-> drm_bridge_connector_get_modes
> -> ps8640_bridge_g
On Mon, Jun 15, 2020 at 10:53:19PM +0200, Enric Balletbo i Serra wrote:
> Print an error message inside ps8640_bridge_vdo_control() function when
> it fails so we can simplify a bit the callers, they will only need to
> check the error code.
>
> Signed-off-by: Enric Balletbo i Serra
Reviewed-by:
Hi Enric.
On Mon, Jun 15, 2020 at 10:53:18PM +0200, Enric Balletbo i Serra wrote:
> Bridge drivers that implement the new model only shall return an error
> from their attach() handler when the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag
> is not set. So make sure we return an error because only the new
>
On Mon, Jun 08, 2020 at 06:16:22AM +0300, Laurent Pinchart wrote:
> Hi Qian,
>
> I forgot to mention, I think the subject line should be
>
> drm/rcar-du: Make DRM_RCAR_WRITEBACK depend on DRM_RCAR_DU
>
> Could you please let me know if you're OK with these two small changes ?
Laurent, this patc
Remove BUG() from ion_sytem_heap.c
this fix the following checkpatch issue:
Avoid crashing the kernel - try using WARN_ON &
recovery code ratherthan BUG() or BUG_ON().
Signed-off-by: Tomer Samara
---
drivers/staging/android/ion/ion_system_heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
The build is currently broken, if COMPILE_TEST=y and PPC_PMAC=n:
linux/drivers/video/fbdev/controlfb.c: In function ‘control_set_hardware’:
linux/drivers/video/fbdev/controlfb.c:276:2: error: implicit declaration of
function ‘btext_update_display’
276 | btext_update_display(p->frame_buff
On Friday, 21 August 2020 15:32:46 CEST Ezequiel Garcia wrote:
> On Thu, 20 Aug 2020 at 19:49, Paul Boddie wrote:
> >
> > It still doesn't work for me. I still get "Input not supported" from my
> > monitor. It is a DVI monitor connected via a HDMI adapter, but EDID
> > probing
> > works and, as I
Remove duplicate semicolons at the end of line.
Signed-off-by: Youling Tang
---
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 2 +-
drivers/gpu/drm/amd/display/dc/dml/display_mode_vba.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vc
Dear Maintainers, readers ...
While updating the solidrun cubox (dove) running debian from 5.6 to 5.7
I came across a new crash in etnaviv that did not occur before - and is
also present in 5.8.0:
[ 33.042453] etnaviv etnaviv: bound f184.gpu (ops gpu_ops [etnaviv])
[ 33.049195] etnaviv-gp
Hi Brain,
On Wed, Aug 19, 2020 at 02:22:04PM +0100, Brian Starkey wrote:
> Hi KyongHo,
>
> On Wed, Aug 19, 2020 at 12:46:26PM +0900, Cho KyongHo wrote:
> > I have seriously considered CPA in our product but we developed our own
> > because of the pool in CPA.
>
> Oh good, I'm glad you considered
On Thu, Aug 20, 2020 at 09:37:12AM -0400, Jim Quinlan wrote:
> On Tue, Aug 18, 2020 at 4:14 AM Andy Shevchenko
> wrote:
> > On Mon, Aug 17, 2020 at 05:53:09PM -0400, Jim Quinlan wrote:
...
> > > +static inline u64 dma_offset_from_dma_addr(struct device *dev,
> > > dma_addr_t dma_addr)
> > > +{
On 2020/08/01 4:38, John Stultz wrote:
On Fri, Jul 31, 2020 at 2:32 AM Kunihiko Hayashi
wrote:
On 2020/07/29 4:17, John Stultz wrote:
Do you have a upstream driver that you plan to make use this new call?
Unfortunately I don't have an upstream driver using this call.
This call is called fro
Dear drm_bridge maintainers,
It's been a while since I send these patches, and I'd like to find a proper
solution.
On 25/6/20 11:21, Enric Balletbo i Serra wrote:
> Hi Sam,
>
> On 24/6/20 9:07, Sam Ravnborg wrote:
>> Hi Enric.
>>
>> On Tue, Jun 23, 2020 at 05:16:43PM +0200, Enric Balletbo i Serr
> Gesendet: Mittwoch, 19. August 2020 um 21:04 Uhr
> Von: "Frank Wunderlich"
> Another way to fix it maybe not enabling it (use the flag in
> mtk_hdmi_phy_power_on) there instead of disabling after enabling it.
>
> Maybe this is less hacky than current way (as ck hu pointed in v2).
seems my last
Hi,
On Tue, Aug 18, 2020 at 10:48:12AM -0600, Rob Herring wrote:
> On Tue, 18 Aug 2020 17:04:15 +0900, Hyesoo Yu wrote:
> > Document devicetree binding for chunk heap on dma heap framework
> >
> > Signed-off-by: Hyesoo Yu
> > ---
> > .../devicetree/bindings/dma-buf/chunk_heap.yaml| 46
> >
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> index 5223498502c4..edadb7a700f1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
> @@ -184,6 +184,9 @@ static int mtk_hdmi_phy_probe(struct pl
Hello,
syzbot found the following issue on:
HEAD commit:ce8056d1 wip: changed copy_from_user where instrumented
git tree: https://github.com/google/kmsan.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=16e7dba190
kernel config: https://syzkaller.appspot.com/x/.
Remove BUG/BUG_ON from androind/ion
-v4:
some changes based on Dan Carpenter review:
- Remove error check at ion_page_pool_remove (conditions are impossible)
- Remove error check at opn_page_pool_alloc
- restore WARN_ON at ion_page_pool_free
- Remove unnece
On 8/21/20 8:28 AM, Tomer Samara wrote:
> Remove BUG() from ion_sytem_heap.c
>
> this fix the following checkpatch issue:
> Avoid crashing the kernel - try using WARN_ON &
> recovery code ratherthan BUG() or BUG_ON().
>
> Signed-off-by: Tomer Samara
> ---
> drivers/staging/android/ion/ion_syste
On 8/22/2020 7:21 AM, Andrew Morton wrote:
> On Wed, 19 Aug 2020 18:53:57 -0700 Dan Williams
> wrote:
>
>>> I think I am missing some important pieces. Bear with me.
>>
>> No worries, also bear with me, I'm going to be offline intermittently
>> until at least mid-September. Hopefully Joao and
pm_runtime_get_sync() increments the runtime PM usage counter
even when it returns an error code. However, users of its
direct wrappers in omapdrm assume that PM usage counter will
not change on error. Thus a pairing decrement is needed on
the error handling path for these wrappers to keep the coun
Le sam. 22 août 2020 à 0:11, Paul Boddie a
écrit :
On Friday, 21 August 2020 15:32:46 CEST Ezequiel Garcia wrote:
On Thu, 20 Aug 2020 at 19:49, Paul Boddie
wrote:
>
> It still doesn't work for me. I still get "Input not supported"
from my
> monitor. It is a DVI monitor connected via
> Hi,
>
> On 21/08/2020 10:45, Dinghao Liu wrote:
> > pm_runtime_get_sync() increments the runtime PM usage counter
> > even when it returns an error code. However, users of
> > dsi_runtime_get(), a direct wrapper of pm_runtime_get_sync(),
> > assume that PM usage counter will not change on error.
BUG_ON() is removed at ion_page_pool.c
Fixes the following issue:
Avoid crashing the kernel - try using WARN_ON & recovery code ratherthan BUG()
or BUG_ON().
Signed-off-by: Tomer Samara
---
drivers/staging/android/ion/ion_page_pool.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
Quoting Rob Clark (2020-08-18 09:31:19)
> From: Rob Clark
>
> This has roughly the same effect as drm_atomic_helper_wait_for_vblanks(),
> basically just ensuring that vblank accounting is enabled so that we get
> valid timestamp/seqn on pageflip events.
>
> Signed-off-by: Rob Clark
> ---
Teste
pm_runtime_get_sync() increments the runtime PM usage counter
even when it returns an error code. However, users of
dsi_runtime_get(), a direct wrapper of pm_runtime_get_sync(),
assume that PM usage counter will not change on error. Thus a
pairing decrement is needed on the error handling path to k
39 matches
Mail list logo
