Am 09.09.2020 07:29 schrieb Huacai Chen :
Though RADEON_GEM_GTT_WC is initially used for GTT, but this flag is
bound to drm_arch_can_wc_memory(), and if arch doesn't support WC, then
VRAM should not use WC.
NAK, If System memory supports WC is completely independent from the VRAM BAR.
Though AMDGPU_GEM_CREATE_CPU_GTT_USWC is initially used for GTT, but
this flag is bound to drm_arch_can_wc_memory(), and if arch doesn't
support WC, then VRAM should not use WC.
Signed-off-by: Huacai Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 --
1 file changed, 4
Though RADEON_GEM_GTT_WC is initially used for GTT, but this flag is
bound to drm_arch_can_wc_memory(), and if arch doesn't support WC, then
VRAM should not use WC.
Signed-off-by: Huacai Chen
---
drivers/gpu/drm/radeon/radeon_object.c | 14 ++
1 file changed, 10 insertions(+), 4
On Thu, 13 Aug 2020 at 06:50, Jeremy Cline wrote:
>
> Commit d32656373857 ("drm/nouveau/therm/gp100: initial implementation of
> new gp1xx temperature sensor") added support for reading finer-grain
> temperatures, but continued to report temperatures in 1 degree Celsius
> increments via
Hi Daniel,
Thanks for this work.
This change works smoothly to me. However, there is a check in the vkms_exit
that doesn't look very good. Please, see inline comment.
On 09/04, Daniel Vetter wrote:
> This means we also need to slightly restructure the exit code, so that
> final cleanup of the
Chun-Kuang Hu 於 2020年9月3日 週四 上午6:06寫道：
>
> Even though cmdq client is created successfully, without the cmdq event,
> cmdq could not work correctly, so use CPU when fail to get cmdq event.
Applied to mediatek-drm-fixes [1].
[1]
On Sat, 22 Aug 2020 18:32:45 +0200, Paul Cercueil wrote:
> Add documentation for the Device Tree node for LCD panels based on the
> NewVision NV3052C controller.
>
> v2: - Support backlight property
> - Add *-supply properties for the 5 different power supplies.
> Either they must all
Hi Neil,
I love your patch! Perhaps something to improve:
[auto build test WARNING on iommu/next]
[also build test WARNING on soc/for-next linus/master v5.9-rc4 next-20200908]
[cannot apply to xlnx/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On 2020-09-08 13:11, Rob Clark wrote:
On Tue, Sep 8, 2020 at 12:44 PM wrote:
On 2020-09-07 10:04, Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
Reviewed-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 81
> 1 file
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.10
head: 11bc98bd71fe2e0cb572988519e51bca9d58a18a
commit: 02f23f5f7c4bad0bea5ed1685d78280df0295478 [606/607] drm/amdgpu/gmc9:
print client id string for mmhub
config: x86_64-randconfig-r031-20200908 (attached as .config)
compiler
https://bugzilla.kernel.org/show_bug.cgi?id=208825
Jon Tourville (jontourvi...@me.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
On Tue, Sep 8, 2020 at 12:44 PM wrote:
>
> On 2020-09-07 10:04, Rob Clark wrote:
> > From: Rob Clark
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 81
> > 1 file changed, 12 insertions(+), 69 deletions(-)
> >
> > diff --git
On 2020-09-07 04:07, Daniel Vetter wrote:
> On Mon, Sep 07, 2020 at 10:06:08AM +0200, Daniel Vetter wrote:
>> On Sat, Sep 05, 2020 at 11:50:05AM -0400, Alex Deucher wrote:
>>> On Thu, Sep 3, 2020 at 9:22 PM Luben Tuikov wrote:
Convert to using devm_drm_dev_alloc(),
as
On 2020-09-07 10:04, Rob Clark wrote:
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 81
1 file changed, 12 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
On 2020-09-07 04:06, Daniel Vetter wrote:
> On Sat, Sep 05, 2020 at 11:50:05AM -0400, Alex Deucher wrote:
>> On Thu, Sep 3, 2020 at 9:22 PM Luben Tuikov wrote:
>>>
>>> Convert to using devm_drm_dev_alloc(),
>>> as drm_dev_init() is going away.
>>>
>>> Signed-off-by: Luben Tuikov
>>
>> I think we
On 2020-09-05 11:50, Alex Deucher wrote:
> On Thu, Sep 3, 2020 at 9:22 PM Luben Tuikov wrote:
>>
>> Convert to using devm_drm_dev_alloc(),
>> as drm_dev_init() is going away.
>>
>> Signed-off-by: Luben Tuikov
>
> I think we can drop the final drm_put in the error case? I think the
> unwinding
Hi Daniel,
On Mon, Sep 07, 2020 at 01:22:25AM -0700, Daniel Vetter wrote:
> Gets rid of drmm_add_final_kfree, which I want to unexport so that it
> stops confusion people about this transitional state of rolling drm
> managed memory out.
>
> This also fixes the missing drm_dev_put in the error
On 2020-09-07 10:04, Rob Clark wrote:
From: Rob Clark
We could get a vblank event racing with the current atomic commit,
resulting in sending the pageflip event to userspace early, causing
tearing. On the other hand, complete_commit() ensures that the
pending flush is complete.
Friendly ping, does anyone care to review/comment?
On Tue, Aug 18, 2020 at 5:05 PM Sean Paul wrote:
>
> From: Sean Paul
>
> Mostly a rebase on drm-tip.
>
> New changes:
> - Use the new trace_array_init_printk() call init the global trace buffers.
> - Add patch 13 to the set to pipe atomic
On Tue, Sep 1, 2020 at 4:27 AM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> On Mon, Aug 24, 2020 at 05:04:58PM -0600, Rob Herring wrote:
> > 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:
On Tue, 2020-08-18 at 10:58 -0700, Zwane Mwaikambo wrote:
> On Wed, 12 Aug 2020, Lyude Paul wrote:
>
> > On Wed, 2020-08-12 at 16:10 +0200, Daniel Vetter wrote:
> > > On Wed, Aug 12, 2020 at 12:16 AM Zwane Mwaikambo
> > > wrote:
> > > > On Tue, 11 Aug 2020, Daniel Vetter wrote:
> > > >
> > > >
With the nitpicks addressed (note there were a couple of other spots where we
wanted to use Return: in the kdocs, but I didn't bother pointing all of them
out), all but patch 07 is:
Reviewed-by: Lyude Paul
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
>
On Fri, Sep 4, 2020 at 2:51 PM Harald Arnesen wrote:
>
> Still doesn't work without the three reverts
> (763fedd6a216, 9e0f9464e2ab, 7ac2d2536dfa)...
So this didn't make rc4, but it's in my tree now.
Harald, I'm assuming things work for you again now with the current
git tree, but it is always
The pull request you sent on Tue, 8 Sep 2020 16:22:25 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-09-08
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6f6a73c8b715d59594d48450a734297ab21f
Thank you!
--
Deet-doot-dot, I am a bot.
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add helpers to determine whether the DFP supports
> YCbCr 4:2:0 passthrough or YCbCr 4:4:4->4:2:0 conversion.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_helper.c | 44
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The downstream facing port caps in the DPCD can give us a hint
> as to what kind of display mode the sink can use if it doesn't
> have an EDID. Use that information to pick a suitable mode.
>
> Signed-off-by:
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> DP 1.3 adds some extra control knobs for DP->HDMI protocol conversion.
> Let's use that to configure the "HDMI mode" (ie. infoframes vs. not)
> based on the capabilities of the sink.
>
> Signed-off-by: Ville
In the function intel_vgpu_reg_rw_edid of kvmgt.c, pos can be equal
to NULL for GPUs that do not properly support EDID. In those cases, when
pos gets passed to the handle_edid functions, it gets added a short offset
then it's dereferenced in memcpy's, leading to NULL pointer
dereference kernel
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add helpers to get the TMDS clock limits for HDMI/DVI downstream
> facing ports.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_helper.c | 116
>
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add helpers to get the TMDS clock limits for HDMI/DVI downstream
> facing ports.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_helper.c | 116
>
>>> + release_mem_region(range.start, range_len());
>>
>> remove_memory() does a release_mem_region_adjustable(). Don't you
>> actually want to release the *unaligned* region you requested?
>>
> Isn't it what we're doing here?
> (The release_mem_region_adjustable() is using the same
>
Hi Vinay,
On Tue, Sep 08, 2020 at 11:22:48PM +0530, Vinay Simha B N wrote:
> laurent,
>
> Please review or give some feedback.
I'm sorry, I have very little time these days :-( Maybe Neil can provide
feedback ?
> On Tue, Aug 25, 2020 at 7:57 PM Vinay Simha B N wrote:
>
> > laurent,
> >
> >
BTW - we started using drm_dp_downstream_max_clock() in nouveau, so you'll
need to update the function call there too.
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We want to differentiate between the DFP dotclock and TMDS clock
> limits. Let's convert the
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Deal with more cases in drm_dp_downstream_max_bpc():
> - DPCD 1.0 -> assume 8bpc for non-DP
> - DPCD 1.1+ DP (or DP++ with DP sink) -> allow anything
> - DPCD 1.1+ TMDS -> check the caps, assume 8bpc if the value
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Deal with more cases in drm_dp_downstream_max_bpc():
> - DPCD 1.0 -> assume 8bpc for non-DP
> - DPCD 1.1+ DP (or DP++ with DP sink) -> allow anything
> - DPCD 1.1+ TMDS -> check the caps, assume 8bpc if the value
On Fri, 2020-09-04 at 14:53 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add a few helpers to let us better identify which kind of DFP
> we're dealing with.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_helper.c | 60 +
>
Hi Laurent,
On 08/09/2020 16:52, Laurent Pinchart wrote:
> Hi Kieran,
>
> On Tue, Sep 08, 2020 at 04:42:58PM +0100, Kieran Bingham wrote:
>> On 06/08/2020 03:26, Laurent Pinchart wrote:
>>> When creating a frame buffer, the driver verifies that the pitches for
>>> the chroma planes match the
Hi Dave and Daniel,
The following changes since commit ce5c207c6b8dd9cdeaeeb2345b8a69335c0d98bf:
Merge tag 'v5.9-rc4' into drm-next (2020-09-08 14:41:40 +1000)
are available in the Git repository at:
git://linuxtv.org/pinchartl/media.git tags/du-next-20200908
for you to fetch changes up
On 08/09/2020 16:44, Logan Gunthorpe wrote:
On 2020-09-08 9:28 a.m., Tvrtko Ursulin wrote:
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h
b/drivers/gpu/drm/i915/i915
index b7b59328cb76..9367ac801f0c 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.h
+++
Hi Kieran,
On Tue, Sep 08, 2020 at 04:42:58PM +0100, Kieran Bingham wrote:
> On 06/08/2020 03:26, Laurent Pinchart wrote:
> > When creating a frame buffer, the driver verifies that the pitches for
> > the chroma planes match the luma plane. This is done incorrectly for
> > fully planar YUV
Hi Laurent,
On 06/08/2020 03:26, Laurent Pinchart wrote:
> When creating a frame buffer, the driver verifies that the pitches for
> the chroma planes match the luma plane. This is done incorrectly for
> fully planar YUV formats, without taking horizontal subsampling into
> account. Fix it.
>
>
Hi,
On 27/08/2020 22:36, Logan Gunthorpe wrote:
On 2020-08-23 6:04 p.m., Tom Murphy wrote:
I have added a check for the sg_dma_len == 0 :
"""
} __sgt_iter(struct scatterlist *sgl, bool dma) {
struct sgt_iter s = { .sgp = sgl };
+ if (sgl && sg_dma_len(sgl) == 0)
+
Add a pgtbl_quirks entry in the compatible specific table to permit specyfying
IOMMU
quirks for platforms.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/panfrost/panfrost_device.h | 3 +++
drivers/gpu/drm/panfrost/panfrost_mmu.c| 1 +
2 files changed, 4 insertions(+)
diff --git
This adds the required GPU quirks, including the quirk in the PWR registers at
the GPU
reset time and the IOMMU quirk for shareability issues observed on G52 in
Amlogic G12B SoCs.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 18 ++
1 file
The T820, G31 & G52 GPUs integrated by Amlogic in the respective GXM, G12A/SM1
& G12B
SoCs needs a quirk in the PWR registers at the GPU reset time.
The coherency integration of the IOMMU in the Mali-G52 found in the Amlogic
G12B SoCs
is broken and leads to constant and random faults from the
The coherency integration of the IOMMU in the Mali-G52 found in the Amlogic
G12B SoCs
is broken and leads to constant and random faults from the IOMMU.
Disabling shareability completely fixes the issue.
Signed-off-by: Neil Armstrong
---
drivers/iommu/io-pgtable-arm.c | 7 ---
The T820, G31 & G52 GPUs integratewd by Amlogic in the respective GXM, G12A/SM1
& G12B
SoCs needs a quirk in the PWR registers at the GPU reset time.
Since the documentation of the GPU cores are not public, we do not know what
does these
values, but they permit having a fully functional GPU
The T820, G31 & G52 GPUs integratewd by Amlogic in the respective GXM, G12A/SM1
& G12B
SoCs needs a quirk in the PWR registers at the GPU reset time.
This adds a callback in the device compatible struct of permit this.
Signed-off-by: Neil Armstrong
---
Hi Morimoto-san,
On 08/09/2020 01:35, Kuninori Morimoto wrote:
>
> From: Kuninori Morimoto
>
> This patch adds DU device nodes for R-Car M3-W+ (r8a77961) SoC.
> This patch was tested on R-Car M3-W+ Salvator-XS board.
>
> Signed-off-by: Kuninori Morimoto
Reviewed-by: Kieran Bingham
> ---
Hi Morimoto-san,
On 08/09/2020 01:34, Kuninori Morimoto wrote:
>
> From: Kuninori Morimoto
>
> This patch adds VSP device nodes for R-Car M3-W+ (r8a77961) SoC.
> This patch was tested on R-Car M3-W+ Salvator-XS board.
>
> Signed-off-by: Kuninori Morimoto
Thanks, I think this is better now
Hi Morimoto-san,
On 08/09/2020 01:34, Kuninori Morimoto wrote:
>
> From: Kuninori Morimoto
>
> This patch adds FCP device nodes for R-Car M3-W+ (r8a77961) SoC.
> This patch was tested on R-Car M3-W+ Salvator-XS board.
>
> Signed-off-by: Kuninori Morimoto
Reviewed-by: Kieran Bingham
> ---
Hi Morimoto-san,
On 08/09/2020 01:34, Kuninori Morimoto wrote:
>
> From: Kuninori Morimoto
>
> This patch adds R-Car M3-W+ (R8A77961) support which has
> compatible to R-Car M3-W (R8A77960).
With the "which is compatible with" as suggested-by Laurent:
Reviewed-by: Kieran Bingham
>
>
Hi Laurent,
On 08/09/2020 15:46, Laurent Pinchart wrote:
> On Tue, Sep 08, 2020 at 05:43:25PM +0300, Laurent Pinchart wrote:
>> Hi Kieran,
>>
>> On Tue, Sep 08, 2020 at 03:18:20PM +0100, Kieran Bingham wrote:
>>> On 08/09/2020 01:34, Kuninori Morimoto wrote:
From: Kuninori Morimoto
On Tue, Sep 08, 2020 at 05:43:25PM +0300, Laurent Pinchart wrote:
> Hi Kieran,
>
> On Tue, Sep 08, 2020 at 03:18:20PM +0100, Kieran Bingham wrote:
> > On 08/09/2020 01:34, Kuninori Morimoto wrote:
> > > From: Kuninori Morimoto
> > >
> > > required is "renesas,r8a7795-hdmi", instead of
Hi Kieran,
On Tue, Sep 08, 2020 at 03:18:20PM +0100, Kieran Bingham wrote:
> On 08/09/2020 01:34, Kuninori Morimoto wrote:
> > From: Kuninori Morimoto
> >
> > required is "renesas,r8a7795-hdmi", instead of "renesas,r8a7795-dw-hdmi"
>
> Hrm, technically the driver will currently only match on :
Hi Morimoto-san,
On 08/09/2020 01:34, Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> This patch adds R-Car M3-W+ (R8A77961) SoC bindings.
>
> Signed-off-by: Kuninori Morimoto
> Reviewed-by: Geert Uytterhoeven
Reviewed-by: Kieran Bingham
> ---
>
Hi Morimoto-san,
On 08/09/2020 01:34, Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> required is "renesas,r8a7795-hdmi", instead of "renesas,r8a7795-dw-hdmi"
Hrm, technically the driver will currently only match on :
"renesas,rcar-gen3-hdmi"
But I see how the '-dw-' has probably
The lcdif IP does not support a framebuffer pitch (stride) other than
framebuffer width. Check for equality and reject the framebuffer
otherwise.
This prevents a distorted picture when using 640x800 and running the
Mesa graphics stack. Mesa tries to use a cache aligned stride, which
leads at that
Hi Laurent,
On 07/08/2020 22:22, Laurent Pinchart wrote:
> The DU driver handles non-visible planes (fully clipped by the display's
> boundaries) by considering them as disabled. It thus disables the plane
> at the hardware level when the plane if moved off-screen. However, if
> the plane was
Hi,
On 9/8/20 1:04 PM, Stephen Rothwell wrote:
Hi Hans,
On Tue, 8 Sep 2020 10:22:06 +0200 Hans de Goede wrote:
On 9/8/20 6:00 AM, Stephen Rothwell wrote:
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/display/intel_panel.c
between commit:
Hi Stefan,
On Tue, Sep 8, 2020 at 9:56 AM Stefan Agner wrote:
>
> The lcdif IP does not support a framebuffer pitch (stride) other than
> framebuffer width. Check for equality and reject the framebuffer
> otherwise.
>
> This prevents a distorted picture when using 640x800 and running the
> Mesa
Hi Stefan,
Thank you for the patch.
On Tue, Sep 08, 2020 at 02:55:58PM +0200, Stefan Agner wrote:
> The lcdif IP does not support a framebuffer pitch (stride) other than
> framebuffer width. Check for equality and reject the framebuffer
> otherwise.
>
> This prevents a distorted picture when
The lcdif IP does not support a framebuffer pitch (stride) other than
framebuffer width. Check for equality and reject the framebuffer
otherwise.
This prevents a distorted picture when using 640x800 and running the
Mesa graphics stack. Mesa tires to use a cache aligned stride, which
leads at that
Hi Morimoto-san,
On 08/09/2020 01:34, Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> Document the R-Car M3-W+ (R8A77961) SoC in the R-Car DU bindings.
>
> Signed-off-by: Kuninori Morimoto
Reviewed-by: Kieran Bingham
> ---
> Documentation/devicetree/bindings/display/renesas,du.txt
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.10
head: 11bc98bd71fe2e0cb572988519e51bca9d58a18a
commit: 02f23f5f7c4bad0bea5ed1685d78280df0295478 [606/607] drm/amdgpu/gmc9:
print client id string for mmhub
config: ia64-randconfig-r014-20200908 (attached as .config)
compiler
On Tue, Sep 08, 2020 at 03:33:04PM +0300, Laurent Pinchart wrote:
> On Tue, Sep 08, 2020 at 02:29:02PM +0200, Daniel Vetter wrote:
> > On Tue, Sep 8, 2020 at 2:07 PM Stefan Agner wrote:
> > > On 2020-09-08 10:48, Daniel Vetter wrote:
> > >> On Tue, Sep 08, 2020 at 11:18:25AM +0300, Tomi Valkeinen
On 2020-09-08 14:33, Laurent Pinchart wrote:
> On Tue, Sep 08, 2020 at 02:29:02PM +0200, Daniel Vetter wrote:
>> On Tue, Sep 8, 2020 at 2:07 PM Stefan Agner wrote:
>> > On 2020-09-08 10:48, Daniel Vetter wrote:
>> >> On Tue, Sep 08, 2020 at 11:18:25AM +0300, Tomi Valkeinen wrote:
>> >>> On
On Tue, Sep 08, 2020 at 02:29:02PM +0200, Daniel Vetter wrote:
> On Tue, Sep 8, 2020 at 2:07 PM Stefan Agner wrote:
> > On 2020-09-08 10:48, Daniel Vetter wrote:
> >> On Tue, Sep 08, 2020 at 11:18:25AM +0300, Tomi Valkeinen wrote:
> >>> On 08/09/2020 10:55, Stefan Agner wrote:
> On
On Tue, Sep 8, 2020 at 2:07 PM Stefan Agner wrote:
>
> On 2020-09-08 10:48, Daniel Vetter wrote:
> > On Tue, Sep 08, 2020 at 11:18:25AM +0300, Tomi Valkeinen wrote:
> >> Hi,
> >>
> >> On 08/09/2020 10:55, Stefan Agner wrote:
> >> > On 2020-09-07 20:18, Daniel Vetter wrote:
> >> >> On Mon, Sep 07,
Hi,
On 08/09/2020 10:55, Stefan Agner wrote:
> On 2020-09-07 20:18, Daniel Vetter wrote:
>> On Mon, Sep 07, 2020 at 07:17:12PM +0300, Laurent Pinchart wrote:
>>> Hi Stefan,
>>>
>>> Thank you for the patch.
>>>
>>> On Mon, Sep 07, 2020 at 06:03:43PM +0200, Stefan Agner wrote:
The lcdif IP
On Tue, Sep 08, 2020 at 10:48:55AM +0200, Daniel Vetter wrote:
> On Tue, Sep 08, 2020 at 11:18:25AM +0300, Tomi Valkeinen wrote:
> > On 08/09/2020 10:55, Stefan Agner wrote:
> > > On 2020-09-07 20:18, Daniel Vetter wrote:
> > >> On Mon, Sep 07, 2020 at 07:17:12PM +0300, Laurent Pinchart wrote:
> >
On 2020-09-08 10:48, Daniel Vetter wrote:
> On Tue, Sep 08, 2020 at 11:18:25AM +0300, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 08/09/2020 10:55, Stefan Agner wrote:
>> > On 2020-09-07 20:18, Daniel Vetter wrote:
>> >> On Mon, Sep 07, 2020 at 07:17:12PM +0300, Laurent Pinchart wrote:
>> >>> Hi Stefan,
On Mon, Sep 07, 2020 at 08:14:38PM +0200, Daniel Vetter wrote:
> On Mon, Sep 07, 2020 at 03:00:26PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We update the timestamping constants per-crtc explicitly in
> > intel_crtc_update_active_timings(). Furtermore the helper will
> > use
On 8/19/20 8:56 PM, Vaibhav Gupta wrote:
> Linux Kernel Mentee: Remove Legacy Power Management.
>
> The purpose of this patch series is to upgrade power management in video fbdev
> drivers. This has been done by upgrading .suspend() and .resume() callbacks.
>
> The upgrade makes sure that the
On 8/25/20 6:56 AM, Joe Perches wrote:
> Use semicolons and braces.
>
> Signed-off-by: Joe Perches
Applied to drm-misc-next tree, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/tgafb.c | 12
> 1
On 8/25/20 9:47 AM, Mathieu Malaterre wrote:
> On Tue, Aug 25, 2020 at 9:27 AM Dinghao Liu wrote:
>>
>> When radeon_kick_out_firmware_fb() fails, info should be
>> freed just like the subsequent error paths.
>>
>> Fixes: 069ee21a82344 ("fbdev: Fix loading of module radeonfb on PowerMac")
>>
On 8/24/20 7:44 PM, Alex Dewar wrote:
> par->vgapass is a u8, so if we are assuming that buf is at least
> PAGE_SIZE then the extra checking is pointless.
>
> Signed-off-by: Alex Dewar
Applied to drm-misc-next tree, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute
[ added linux-fbdev ML to Cc: ]
On 8/24/20 4:51 PM, Bilal Wasim wrote:
> fbcon doc mentions FRAMEBUFFER_CONSOLE option to be under
> Device Drivers->Graphics Support->Frame buffer Devices->
> Console display driver support->Framebuffer Console Support,
> while its under Device Drivers->Graphics
On 8/27/20 3:00 PM, Jason Yan wrote:
> This addresses the following gcc warning with "make W=1":
>
> drivers/video/fbdev/kyro/STG4000InitDevice.c: In function
> ‘ProgramClock’:
> drivers/video/fbdev/kyro/STG4000InitDevice.c:123:6: warning: variable
> ‘ulBestVCO’ set but not used
On 8/26/20 10:54 PM, Julia Lawall wrote:
> From: kernel test robot
>
> Use kobj_to_dev() instead of container_of()
>
> Generated by: scripts/coccinelle/api/kobj_to_dev.cocci
>
> Fixes: a2fc3718bc22 ("coccinelle: api: add kobj_to_dev.cocci script")
> CC: Denis Efremov
> Signed-off-by:
On Tue, Sep 08, 2020 at 12:02:53PM +0200, Gerd Hoffmann wrote:
> > > > The comments I've found suggest very much not ... Or is that all very
> > > > old stuff only that no one cares about anymore?
> > >
> > > I think these days it is possible to override dma_ops per device, which
> > > in turn
On 8/30/20 1:55 PM, Mike Rapoport wrote:
> From: Mike Rapoport
>
> The only in-tree user for mbx driver for Intel 2700G graphics chip was
> cm-x270 platform. Since this platform was removed by the commit
> 9d3239147d6d ("ARM: pxa: remove Compulab pxa2xx boards") there is no
> point to keep the
On 9/7/20 9:02 AM, Vaibhav Gupta wrote:
> Linux Kernel Mentee: Remove Legacy Power Management.
>
> The original goal of the patch series is to upgrade the power management
> framework of radeonfb fbdev driver. This has been done by upgrading .suspend()
> and .resume() callbacks.
>
> The
On 8/27/20 3:00 PM, Jason Yan wrote:
> This addresses the following gcc warning with "make W=1":
>
> drivers/video/fbdev/kyro/STG4000InitDevice.c: In function
> ‘SetCoreClockPLL’:
> drivers/video/fbdev/kyro/STG4000InitDevice.c:247:6: warning: variable
> ‘ulCoreClock’ set but not used
On 8/5/20 12:28 PM, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a pr_err message. Fix it.
>
> Signed-off-by: Colin Ian King
Applied to drm-misc-next tree, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
>
Hi,
On 8/10/20 11:21 AM, kernel test robot wrote:
> From: kernel test robot
>
> drivers/video/fbdev/core/fbcon.c:3509:8-16: WARNING: use scnprintf or sprintf
> drivers/video/fbdev/core/fbcon.c:3484:8-16: WARNING: use scnprintf or sprintf
>
>
> From Documentation/filesystems/sysfs.txt:
>
On 8/5/20 4:52 PM, t...@redhat.com wrote:
> From: Tom Rix
>
> Clang static analysis reports this representative error
>
> init.c:2501:18: warning: Array access (from variable 'queuedata') results
> in a null pointer dereference
> templ |= ((queuedata[i] & 0xc0) << 3);
>
> This is the
[ added dri-devel ML to Cc: ]
On 7/27/20 10:40 PM, Rob Herring wrote:
> On Fri, 24 Jul 2020 17:22:18 -0300, Rodrigo Alencar wrote:
>> This patch provides support for displays like VGM128064B0W10,
>> which requires a column offset of 2, i.e., its segments starts
>> in SEG2 and ends in SEG129.
>>
On 7/23/20 7:02 PM, Colin King wrote:
> From: Colin Ian King
>
> The pixclock is being set locally because it is being passed as a
> pass-by-value argument rather than pass-by-reference, so the computed
> pixclock is never being set in var->pixclock. Fix this by passing
> by reference.
>
>
On 7/13/20 10:05 AM, Evgeny Novikov wrote:
> smtcfb_pci_probe() does not handle ioremap() errors for case 0x720. The
> patch fixes that exactly like for case 0x710/2.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Evgeny Novikov
Applied to drm-misc-next
[ added dri-devel ML to Cc: ]
On 7/7/20 9:47 PM, Dan Carpenter wrote:
> On Tue, Jul 07, 2020 at 03:26:03PM -0400, George Kennedy wrote:
>> A fb_ioctl() FBIOPUT_VSCREENINFO call with invalid xres setting
>> or yres setting in struct fb_var_screeninfo will result in a
>> KASAN:
On Tue, Sep 08, 2020 at 11:39:10AM +0200, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann
Btw going all in on devm_drm_dev_alloc and managed functions might be good
cleanup for virtio.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 5 +++--
> 1 file changed, 3
On Wed, 26 Aug 2020, Linus Walleij wrote:
> The Tosa backlight LCDE driver was converted to use GPIO descriptors
> in 0b0cb52bd80eda76c4b9921f5cf9c1b709d44e83
> ("video: backlight: tosa: Use GPIO lookup table") but
> still includes rather than .
> Fix it.
>
> Cc: Arnd Bergmann
> Cc: Robert
On Mon, Sep 7, 2020 at 11:01 AM Nicolas Saenz Julienne
wrote:
>
> Hi Jim, sorry I'm a little late to the party, but was on vacation.
>
> On Thu, 2020-09-03 at 13:32 -0400, Jim Quinlan wrote:
> > On Wed, Sep 2, 2020 at 8:52 PM Nathan Chancellor
> > wrote:
> > > On Wed, Sep 02, 2020 at 05:36:29PM
On Mon, Sep 7, 2020 at 5:16 AM Lorenzo Pieralisi
wrote:
>
> On Thu, Aug 27, 2020 at 09:29:59AM -0400, Jim Quinlan wrote:
> > On Thu, Aug 27, 2020 at 2:35 AM Christoph Hellwig wrote:
> > >
> > > On Tue, Aug 25, 2020 at 10:40:27AM -0700, Florian Fainelli wrote:
> > > > Hi,
> > > >
> > > > On
Hi Hans,
On Tue, 8 Sep 2020 10:22:06 +0200 Hans de Goede wrote:
>
> On 9/8/20 6:00 AM, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the drm-intel tree got a conflict in:
> >
> >drivers/gpu/drm/i915/display/intel_panel.c
> >
> > between commit:
> >
> >f8bd54d21904
On 22.08.20 01:21, 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/or
On Tue, Sep 08, 2020 at 10:57:21AM +0200, Daniel Vetter wrote:
> On Tue, Sep 08, 2020 at 08:47:41AM +0200, Gerd Hoffmann wrote:
> > These days dma ops can be overridden per device, and the virtio core
>
> "can be overridden" or "are"?
Didn't happen yet, so scratch this one for now ...
take
> > > The comments I've found suggest very much not ... Or is that all very
> > > old stuff only that no one cares about anymore?
> >
> > I think these days it is possible to override dma_ops per device, which
> > in turn allows virtio to deal with the quirks without the rest of the
> > kernel
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index fa79688013b7..4be04eaf7f37 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++
1 - 100 of 148 matches
Mail list logo
