Hi all,
On Mon, 12 Oct 2020 15:15:27 +1100 Stephen Rothwell
wrote:
>
> On Wed, 23 Sep 2020 15:13:36 +1000 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> > drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> >
> > between commit:
> >
> >
Hi Marek,
On Sat, Oct 10, 2020 at 10:47:05AM +0200, Marek Vasut wrote:
> On 10/10/20 1:58 AM, Laurent Pinchart wrote:
> > Hi Marek,
>
> Hi,
>
> > On Wed, Oct 07, 2020 at 10:40:26AM +0200, Marek Vasut wrote:
> >> On 10/7/20 3:24 AM, Laurent Pinchart wrote:
> >>
> >> [...]
> >>
> >>> +
Hi Neil,
Thanks for your review, please see my reply inline.
> -Original Message-
> From: Neil Armstrong
> Sent: Friday, October 9, 2020 2:10 AM
> To: Chrisanthus, Anitha ; dri-
> de...@lists.freedesktop.org; devicet...@vger.kernel.org; Vetter, Daniel
>
> Cc: Dea, Edmund J ;
Completely zoned out on Ccing these patches to stable before submitting them,
but once they hit the mainline kernel you should be able to ask Greg to backport
them if you need. Anyway, pushed to drm-intel-next-queued. Thanks for the
patches!
On Fri, 2020-10-09 at 16:57 +0800, Aaron Ma wrote:
>
On Mon, Oct 12, 2020 at 09:02:54PM +0100, Matthew Wilcox wrote:
> On Mon, Oct 12, 2020 at 12:53:54PM -0700, Ira Weiny wrote:
> > On Mon, Oct 12, 2020 at 05:44:38PM +0100, Matthew Wilcox wrote:
> > > On Mon, Oct 12, 2020 at 09:28:29AM -0700, Dave Hansen wrote:
> > > > kmap_atomic() is always
Hello,
This small patch series fixes format switching for the primary plane,
and adds support for the RGB888 format. There's not much else to tell,
please see individual patches for details.
Laurent Pinchart (2):
drm: mxsfb: Fix format changes for primary plane
drm: mxsfb: Add RGB888 support
The primary plane's format is configured in registers that have no
shadow support for live updates. They require the display to be fully
reconfigured in order to be updated. Force a mode set when the primary
plane format changes to ensure this.
Signed-off-by: Laurent Pinchart
---
The primary plane can support the packed 24-bit RGB888 format. Enable
it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 5 +
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 7 +++
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
On Wed, Oct 07, 2020 at 03:06:38PM +0530, Tejas Upadhyay wrote:
> Recently we came across requirement to identify EHL and JSL
> platform to program them differently. Thus Split the basic
> platform definition, macros, and PCI IDs to differentiate
> between EHL and JSL platforms. Also,
On Mon, 2020-10-12 at 22:02 +, Vivi, Rodrigo wrote:
> > On Oct 12, 2020, at 2:47 PM, Lyude Paul wrote:
> >
> > Just pushed this, but it's not in drm-tip because it would seem that
> > rebuilding
> > drm-tip has failed, and the conflict doesn't appear to be from any of the
> > patches I
> On Oct 12, 2020, at 2:47 PM, Lyude Paul wrote:
>
> Just pushed this, but it's not in drm-tip because it would seem that
> rebuilding
> drm-tip has failed, and the conflict doesn't appear to be from any of the
> patches I pushed so I'm getting the feeling from the DRM maintainer docs I
>
Just pushed this, but it's not in drm-tip because it would seem that rebuilding
drm-tip has failed, and the conflict doesn't appear to be from any of the
patches I pushed so I'm getting the feeling from the DRM maintainer docs I
should probably let one of the drm-misc-folks handle the conflict.
Hi! Thanks for the catch, just one comment down below
On Fri, 2020-10-09 at 21:11 +0300, Alexander Kapshuk wrote:
> This oops manifests itself on the following hardware:
> 01:00.0 VGA compatible controller: NVIDIA Corporation G98M [GeForce G 103M]
> (rev a1)
>
> Oct 09 14:17:46 lp-sasha kernel:
From: kernel test robot
drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c:608:2-3: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
Fixes: b4a7db71ea06 ("drm/amdgpu: add per device user friendly xgmi events for
vega20")
CC: Jonathan Kim
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next
head: 02c3d98ce25b3e4f0b8e830be054c8f4f7f944c1
commit: b4a7db71ea060218529e6a4c660c37687ecb5669 [286/376] drm/amdgpu: add per
device user friendly xgmi events for vega20
config: x86_64-randconfig-c002-20201012 (attached as .config
On Mon, Oct 12, 2020 at 05:44:38PM +0100, Matthew Wilcox wrote:
> On Mon, Oct 12, 2020 at 09:28:29AM -0700, Dave Hansen wrote:
> > kmap_atomic() is always preferred over kmap()/kmap_thread().
> > kmap_atomic() is _much_ more lightweight since its TLB invalidation is
> > always CPU-local and never
Integer scaling (IS) is a nearest-neighbor upscaling technique that
simply scales up the existing pixels by an integer
(i.e., whole number) multiplier.Nearest-neighbor (NN) interpolation
works by filling in the missing color values in the upscaled image
with that of the coordinate-mapped nearest
GEN >= 10 hardware supports the programmable scaler filter.
Attach scaling filter property for CRTC and plane for GEN >= 10
hardwares and program scaler filter based on the selected filter
type.
changes since v3:
* None
changes since v2:
* Use updated functions
* Add ps_ctrl var to contain the
Add documentation for newly introduced KMS plane and CRTC scaling
filter properties.
changes since v3:
* None
changes since v1:
* None
changes since RFC:
* Add separate documentation for plane and CRTC.
Reviewed-by: Uma Shankar
Signed-off-by: Pankaj Bharadiya
---
Documentation/gpu/drm-kms.rst
Introduce scaler registers and bit fields needed to configure the
scaling filter in prgrammed mode and configure scaling filter
coefficients.
changes since v3:
* None
changes since v2:
* Change macro names to CNL_* and use +(set)*8 instead of adding
another trip through _PICK_EVEN (Ville).
Introduce per-plane and per-CRTC scaling filter properties to allow
userspace to select the driver's default scaling filter or
Nearest-neighbor(NN) filter for upscaling operations on CRTC and
plane.
Drivers can set up this property for a plane by calling
drm_plane_create_scaling_filter() and for
Earlier, I kept this series on hold since we wanted to have a
reference userspace implementation in place.
Now, Sameer has implemented Integer scaling in Kodi Retro gaming
framework which demonstrate how Integer scaling gives distinctive
look to pixel art games when played on higher resolution
On Mon, 2020-10-12 at 13:50 -0400, Sean Paul wrote:
> On Tue, Sep 22, 2020 at 11:36 AM Lyude Paul wrote:
> > On Tue, 2020-09-22 at 09:39 -0400, Sean Paul wrote:
> > > On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul wrote:
> > > > So if I understand this correctly, it sounds like that some Pixelbooks
On Tue, Sep 22, 2020 at 11:36 AM Lyude Paul wrote:
>
> On Tue, 2020-09-22 at 09:39 -0400, Sean Paul wrote:
> > On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul wrote:
> > > So if I understand this correctly, it sounds like that some Pixelbooks
> > > boot up
> > > with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB
On Mon, Oct 12, 2020 at 07:03:51PM +0530, Akhil P Oommen wrote:
> On 10/10/2020 12:06 AM, m...@chromium.org wrote:
> > Hi Akhil,
> >
> > On Thu, Oct 08, 2020 at 10:39:07PM +0530, Akhil P Oommen wrote:
> > > Register GPU as a devfreq cooling device so that it can be passively
> > > cooled by the
v3 includes the Signed-off-by and Acked-by lines in the commit. No
other changes.
At this point, I'd need some help from a maintainer/committer to merge
this, I understand.
Daniel Vetter, are you happy to do this or does this work differently?
Many thanks,
Matteo
On Mon, Oct 12, 2020 at
Add ABGR format with 10-bit components packed in 64-bit per pixel.
This format can be used to handle
VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 on little-endian
architectures.
Signed-off-by: Matteo Franchin
Reviewed-by: Brian Starkey
Acked-by: Daniel Vetter
---
drivers/gpu/drm/drm_fourcc.c
On 10/12/20 9:19 AM, Eric Biggers wrote:
> On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
>>> And I still don't really understand. After this patchset, there is still
>>> code
>>> nearly identical to the above (doing a temporary mapping just for a memcpy)
>>> that
>>> would still be
On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
> >
> > And I still don't really understand. After this patchset, there is still
> > code
> > nearly identical to the above (doing a temporary mapping just for a memcpy)
> > that
> > would still be using kmap_atomic().
>
> I don't
On Mon, Oct 12, 2020 at 7:35 AM Daniel Vetter wrote:
>
> On Sun, Oct 11, 2020 at 07:09:34PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Unfortunately, due to an dev_pm_opp locking interaction with
> > mm->mmap_sem, we need to do pm get before aquiring obj locks,
> > otherwise we can have
On 9/25/20 4:16 PM, Yannick Fertre wrote:
> Compute new timings to get a framerate of 50fps with a pixel clock
> @54Mhz.
>
> Signed-off-by: Yannick Fertre
> ---
> drivers/gpu/drm/panel/panel-raydium-rm68200.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff
Hi, Jitao:
Jitao Shi 於 2020年10月10日 週六 下午3:09寫道：
>
> Changes since v3:
> - Revert v2, for v2 will cause some bridge ic no output. the cause
>the video linetime doesn't match display mode from get mode.
> - Make sure the horizontal_frontporch_byte and horizontal_backporch_byte
>are > 0.
Am 12.10.20 um 16:14 schrieb Daniel Vetter:
On Mon, Oct 12, 2020 at 10:57:57AM +0200, Christian König wrote:
Ping? Anybody any more comments on this?
Otherwise I'm going to push it to drm-misc-next by tomorrow or so.
tbh the entire coherency/caching topic is imo a giantic mess in
drivers/gpu
On Mon, Oct 12, 2020 at 7:40 AM Daniel Vetter wrote:
>
> On Sun, Oct 11, 2020 at 07:09:49PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Any cross-device sync use-cases *must* use explicit sync. And if there
> > is only a single ring (no-preemption), everything is FIFO order and
> >
On Sun, Oct 11, 2020 at 07:09:49PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Any cross-device sync use-cases *must* use explicit sync. And if there
> is only a single ring (no-preemption), everything is FIFO order and
> there is no need to implicit-sync.
>
> Mesa should probably just
On Sun, Oct 11, 2020 at 07:09:34PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Unfortunately, due to an dev_pm_opp locking interaction with
> mm->mmap_sem, we need to do pm get before aquiring obj locks,
> otherwise we can have anger lockdep with the chain:
tbh this sounds like a bug in that
On Mon, Oct 12, 2020 at 11:51:30AM +0100, Chris Wilson wrote:
> On some processors (such as arch/x86), accessing a page via a WC PAT is
> bypassed if the page is physically tagged in the CPU cache, and the
> access is serviced by the cache instead -- which leads to incoherency
> should the
On Mon, Oct 12, 2020 at 02:40:58PM +0200, Neil Armstrong wrote:
> Hi,
>
> On 12/10/2020 13:24, Thomas Zimmermann wrote:
> > Hi
> >
> > On Sat, 10 Oct 2020 01:21:56 +0200 Daniel Vetter
> > wrote:
> >
> >> Hooray for generic fbdev support, making this a oneliner. We just
> >> needed to fix
Hi "Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on staging/staging-testing linus/master v5.9
next-20201012]
[cannot apply to mmotm/master]
[If your patch is applied to the wrong git tree, kindly dr
On Mon, Oct 12, 2020 at 04:03:28PM +0200, Niklas Schnelle wrote:
> Hi Daniel,
>
> freshly back from my vacation I've just taken a look at your patch.
> First thanks for this fix and the detailed commit description.
> Definitely makes sense to fix this and you can add my
>
> Acked-by: Niklas
Quoting Daniel Vetter (2020-10-12 15:12:50)
> On Mon, Oct 12, 2020 at 03:01:09PM +0100, Chris Wilson wrote:
> > Quoting Daniel Vetter (2020-10-12 14:55:07)
> > > On Mon, Oct 12, 2020 at 12:49 PM Chris Wilson
> > > wrote:
> > > > Quoting Daniel Vetter (2020-10-09 17:16:06)
> > > > > On Fri, Oct
On Mon, Oct 12, 2020 at 10:57:57AM +0200, Christian König wrote:
> Ping? Anybody any more comments on this?
>
> Otherwise I'm going to push it to drm-misc-next by tomorrow or so.
tbh the entire coherency/caching topic is imo a giantic mess in
drivers/gpu (mostly because we're half-fighting
On Mon, Oct 12, 2020 at 03:01:09PM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2020-10-12 14:55:07)
> > On Mon, Oct 12, 2020 at 12:49 PM Chris Wilson
> > wrote:
> > > Quoting Daniel Vetter (2020-10-09 17:16:06)
> > > > On Fri, Oct 9, 2020 at 12:21 PM Chris Wilson
> > > > wrote:
> > > >
On Mon, Oct 12, 2020 at 12:25:09PM +0200, Paul Cercueil wrote:
> Fix a badly reverted commit. The revert commit was cherry-picked from
> drm-misc-next to drm-misc-next-fixes, and in the process some unrelated
> code was added.
>
> Fixes: a3fb64c00d44 "Revert "gpu/drm: ingenic: Add option to mmap
Hi "Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on staging/staging-testing linus/master
hnaz-linux-mm/master v5.9 next-20201012]
[cannot apply to mmotm/master]
[If your patch is applied to the wrong git
Quoting Daniel Vetter (2020-10-12 14:55:07)
> On Mon, Oct 12, 2020 at 12:49 PM Chris Wilson
> wrote:
> > Quoting Daniel Vetter (2020-10-09 17:16:06)
> > > On Fri, Oct 9, 2020 at 12:21 PM Chris Wilson
> > > wrote:
> > > >
> > > > vgem is a minimalistic driver that provides shmemfs objects to
>
On Mon, Oct 12, 2020 at 12:49 PM Chris Wilson wrote:
> Quoting Daniel Vetter (2020-10-09 17:16:06)
> > On Fri, Oct 9, 2020 at 12:21 PM Chris Wilson
> > wrote:
> > >
> > > vgem is a minimalistic driver that provides shmemfs objects to
> > > userspace that may then be used as an in-memory surface
On Mon, Oct 12, 2020 at 12:47 PM Marek Szyprowski
wrote:
>
> Hi Jason,
>
> On 09.10.2020 14:48, Jason Gunthorpe wrote:
> > On Fri, Oct 09, 2020 at 02:37:23PM +0200, Mauro Carvalho Chehab wrote:
> >
> >> I'm not a mm/ expert, but, from what I understood from Daniel's patch
> >> description is that
From: Karol Herbst
commit c3e0276c31ca8c7b8615da890727481260d4676f upstream.
Previously the code relied on device->pri to be NULL and to fail probing
later. We really should just return an error inside nvkm_device_ctor for
unsupported GPUs.
Fixes: 24d5ff40a732 ("drm/nouveau/device: rework mmio
From: Karol Herbst
commit d10285a25e29f13353bbf7760be8980048c1ef2f upstream.
other drivers seems to do something similar
Signed-off-by: Karol Herbst
Cc: dri-devel
Cc: Dave Airlie
Cc: sta...@vger.kernel.org
Signed-off-by: Dave Airlie
Link:
From: Karol Herbst
commit d10285a25e29f13353bbf7760be8980048c1ef2f upstream.
other drivers seems to do something similar
Signed-off-by: Karol Herbst
Cc: dri-devel
Cc: Dave Airlie
Cc: sta...@vger.kernel.org
Signed-off-by: Dave Airlie
Link:
From: Karol Herbst
commit d10285a25e29f13353bbf7760be8980048c1ef2f upstream.
other drivers seems to do something similar
Signed-off-by: Karol Herbst
Cc: dri-devel
Cc: Dave Airlie
Cc: sta...@vger.kernel.org
Signed-off-by: Dave Airlie
Link:
On 10/10/2020 12:06 AM, m...@chromium.org wrote:
Hi Akhil,
On Thu, Oct 08, 2020 at 10:39:07PM +0530, Akhil P Oommen wrote:
Register GPU as a devfreq cooling device so that it can be passively
cooled by the thermal framework.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/msm_gpu.c |
On Thu, Oct 08, 2020 at 08:02:09PM +, Patchwork wrote:
> == Series Details ==
>
> Series: rm/i915: Add support for LTTPR non-transparent link training mode
> (rev2)
> URL : https://patchwork.freedesktop.org/series/82449/
> State : success
Thanks for the reviews, patchset is pushed to
On 10/10, Daniel Vetter wrote:
> The only thing we support is xrgb.
>
> Signed-off-by: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Melissa Wen
> Cc: Haneen Mohammed
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/vkms/vkms_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
On 30/09/2020 11:43, Daniel Vetter wrote:
> On Tue, Sep 29, 2020 at 01:51:36PM -0700, Peter Collingbourne wrote:
>> On Tue, Sep 29, 2020 at 11:44 AM Daniel Vetter wrote:
>>>
>>> On Tue, Sep 29, 2020 at 7:49 PM Peter Collingbourne wrote:
On Tue, Sep 29, 2020 at 9:52 AM Daniel Vetter
Hi,
On 12/10/2020 13:24, Thomas Zimmermann wrote:
> Hi
>
> On Sat, 10 Oct 2020 01:21:56 +0200 Daniel Vetter
> wrote:
>
>> Hooray for generic fbdev support, making this a oneliner. We just
>> needed to fix preferred_depth fixed and the vmap support added first.
>>
>> Signed-off-by: Daniel
Hi Daniel,
Thanks for this patch.
It took me a while to understand the update.
I run some tests and it looks good to me.
On 10/10, Daniel Vetter wrote:
> Inspired by a patch by Chris Wilson for vgem. Plus this gives us vmap
> at the gem bo level, which we need for generic fbdev emulation.
>
>
Hi Maxime,
On 10/8/20 8:25 PM, Maxime Ripard wrote:
> The code that assigns HVS channels during atomic_check is starting to grow
> a bit big, let's move it into a separate function.
>
> Signed-off-by: Maxime Ripard
Thanks for this patch set, I checked all patches well works.
All patches:
op us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/mm-mmap-fix-fput-in-error-path-v2/20201012-165336
base: git://anongit.freedesktop.org/drm-intel for-linux
On Mon, Oct 12, 2020 at 04:57:24AM -0700, Bernard Zhao wrote:
> Functions armada_drm_crtc_atomic_flush &
> armada_drm_crtc_atomic_enable don`t use the second parameter.
> So we may get warning like :
> warning: unused parameter ‘***’ [-Wunused-parameter].
> This change is to fix the compile
Hi
On Sat, 10 Oct 2020 01:21:56 +0200 Daniel Vetter
wrote:
> Hooray for generic fbdev support, making this a oneliner. We just
> needed to fix preferred_depth fixed and the vmap support added first.
>
> Signed-off-by: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Melissa Wen
> Cc: Haneen
On Sat, 10 Oct 2020 01:21:55 +0200 Daniel Vetter
wrote:
> Inspired by a patch by Chris Wilson for vgem. Plus this gives us vmap
> at the gem bo level, which we need for generic fbdev emulation.
>
> Luckily shmem also tracks ->vaddr, so we just need to adjust the code
> all over a bit to make
On Mon, 12 Oct 2020 11:59:03 +0100 Chris Wilson
wrote:
> Quoting Daniel Vetter (2020-10-10 00:21:55)
> > Inspired by a patch by Chris Wilson for vgem. Plus this gives us vmap
> > at the gem bo level, which we need for generic fbdev emulation.
> >
> > Luckily shmem also tracks ->vaddr, so we
On Sat, 10 Oct 2020 01:21:54 +0200 Daniel Vetter wrote:
> The only thing we support is xrgb.
>
> Signed-off-by: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Melissa Wen
> Cc: Haneen Mohammed
> Cc: Daniel Vetter
Acked-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/vkms/vkms_drv.c | 2
Quoting Daniel Vetter (2020-10-10 00:21:55)
> Inspired by a patch by Chris Wilson for vgem. Plus this gives us vmap
> at the gem bo level, which we need for generic fbdev emulation.
>
> Luckily shmem also tracks ->vaddr, so we just need to adjust the code
> all over a bit to make this fit.
>
>
vgem is a minimalistic driver that provides shmemfs objects to
userspace that may then be used as an in-memory surface and transported
across dma-buf to other drivers. Since vgem's introduction,
drm_gem_shmem_helper now provides the same shmemfs facilities and so we
can trim vgem to wrap the
On some processors (such as arch/x86), accessing a page via a WC PAT is
bypassed if the page is physically tagged in the CPU cache, and the
access is serviced by the cache instead -- which leads to incoherency
should the physical page itself be accessed using DMA. In order to
prevent the false
Quoting Daniel Vetter (2020-10-09 17:16:06)
> On Fri, Oct 9, 2020 at 12:21 PM Chris Wilson wrote:
> >
> > vgem is a minimalistic driver that provides shmemfs objects to
> > userspace that may then be used as an in-memory surface and transported
> > across dma-buf to other drivers. Since it's
Hi Jason,
On 09.10.2020 14:48, Jason Gunthorpe wrote:
> On Fri, Oct 09, 2020 at 02:37:23PM +0200, Mauro Carvalho Chehab wrote:
>
>> I'm not a mm/ expert, but, from what I understood from Daniel's patch
>> description is that this is unsafe *only if* __GFP_MOVABLE is used.
> No, it is
kernel test robot reported build errors (undefined references)
that didn't make much sense. After reproducing them, there is also
a Kconfig warning that is the root cause of the build errors, so
fix that Kconfig problem.
Fixes this Kconfig warning:
WARNING: unmet direct dependencies detected for
On 2020/10/12 13:28, Ira Weiny wrote:
> On Sat, Oct 10, 2020 at 10:20:34AM +0800, Coly Li wrote:
>> On 2020/10/10 03:50, ira.we...@intel.com wrote:
>>> From: Ira Weiny
>>>
>>> These kmap() calls are localized to a single thread. To avoid the over
>>> head of global PKRS updates use the new
Set link rate by using OPP set rate api so that CX level will be set
accordingly based on the link rate.
Changes in v2:
-- remove dev from dp_ctrl_put() parameters
-- Add more information to commit message
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 27
Connection state is not set correctly happen when either failure of link
train due to cable unplugged in the middle of aux channel reading or
cable plugged in while in suspended state. This patch fixes these problems.
This patch also replace ST_SUSPEND_PENDING with ST_DISPLAY_OFF.
Changes in V2:
On 2020-10-06 00:31, Rajendra Nayak wrote:
On 10/4/2020 3:56 AM, Kuogee Hsieh wrote:
Set link rate by using OPP set rate api so that CX level will be set
accordingly based on the link rate.
Changes in v2:
-- remove dev from dp_ctrl_put() parameters
-- address review comments
This needs to go
During suspend, dp host controller and hpd block are disabled due to
both ahb and aux clock are disabled. Therefore hpd plug/unplug interrupts
will not be generated. At dp_pm_resume(), reinitialize both dp host
controller and hpd block so that hpd plug/unplug interrupts will be
generated and
-ira.we...@intel.com wrote: -
>To: "Andrew Morton" , "Thomas Gleixner"
>, "Ingo Molnar" , "Borislav
>Petkov" , "Andy Lutomirski" , "Peter
>Zijlstra"
>From: ira.we...@intel.com
>Date: 10/09/2020 09:52PM
>Cc: "Ira Weiny" , "Mike Marciniszyn"
>, "Dennis Dalessandro"
>, "Doug Ledford" ,
On 2020/10/10 4:52, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> The kmap() calls in this FS are localized to a single thread. To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
>
> Cc: Damien Le Moal
> Cc: Naohiro Aota
> Signed-off-by: Ira Weiny
> ---
>
Ping? Anybody any more comments on this?
Otherwise I'm going to push it to drm-misc-next by tomorrow or so.
Thanks,
Christian.
Am 08.10.20 um 11:31 schrieb Christian König:
All drivers can determine the tt caching state at creation time,
no need to do this on the fly during every validation.
Patch "495c10cc1c0c CHROMIUM: dma-buf: restore args..."
adds a workaround for a bug in mmap_region.
As the comment states ->mmap() callback can change
vma->vm_file and so we might call fput() on the wrong file.
Revert the workaround and proper fix this in mmap_region.
v2: drop the extra if in
Add the new vma_set_file() function to allow changing
vma->vm_file with the necessary refcount dance.
v2: add more users of this.
v3: add missing EXPORT_SYMBOL, rebase on mmap cleanup,
add comments why we drop the reference on two occasions.
v4: make it clear that changing an anonymous vma is
Am 10.10.20 um 00:25 schrieb Jason Gunthorpe:
On Fri, Oct 09, 2020 at 03:04:20PM -0700, Andrew Morton wrote:
On Fri, 9 Oct 2020 17:03:37 +0200 "Christian König"
wrote:
Patch "495c10cc1c0c CHROMIUM: dma-buf: restore args..."
adds a workaround for a bug in mmap_region.
As the comment states
Am 09.10.20 um 17:14 schrieb Jason Gunthorpe:
On Fri, Oct 09, 2020 at 05:03:38PM +0200, Christian König wrote:
+/*
+ * Change backing file, only valid to use during initial VMA setup.
+ */
+void vma_set_file(struct vm_area_struct *vma, struct file *file)
+{
+ if (file)
+
On Fri, 9 Oct 2020 17:20:18 +0300
Ville Syrjälä wrote:
> On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote:
> > On Fri, 9 Oct 2020 16:10:25 +0300
> > Ville Syrjälä wrote:
> >
> > > On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote:
> > > > Hi,
> > > >
> > > > On
On Fri, Oct 09, 2020 at 06:30:36PM -0700, Eric Biggers wrote:
> On Sat, Oct 10, 2020 at 01:39:54AM +0100, Matthew Wilcox wrote:
> > On Fri, Oct 09, 2020 at 02:34:34PM -0700, Eric Biggers wrote:
> > > On Fri, Oct 09, 2020 at 12:49:57PM -0700, ira.we...@intel.com wrote:
> > > > The kmap() calls in
Hi Neil/Anitha.
On Fri, Oct 09, 2020 at 11:09:45AM +0200, Neil Armstrong wrote:
> Hi,
>
> On 09/10/2020 03:03, Anitha Chrisanthus wrote:
> > This patch adds bindings for Intel KeemBay Display
> >
> > v2: review changes from Rob Herring
> >
> > Signed-off-by: Anitha Chrisanthus
> > ---
> >
86 matches
Mail list logo
