>-Original Message-
>From: dri-devel On Behalf Of
>Bernard Zhao
>Sent: Tuesday, April 21, 2020 7:17 AM
>To: Alex Deucher ; Christian König
>; David (ChunMing) Zhou
>; David Airlie ; Daniel Vetter
>; Tom St Denis ; Ori Messinger
>; Sam Ravnborg ; Bernard
>Zhao ;
On Wed, Apr 22, 2020 at 12:15 AM Thierry Reding
wrote:
> On Wed, Apr 15, 2020 at 02:24:27PM +0200, Linus Walleij wrote:
> > The Tegra DRM drivers includes the legacy GPIO headers
> > and but what it really
> > uses is since only gpio_desc
> > structs are ever referenced.
> >
> > Include the
Hi Adrian,
On Wed, Apr 22, 2020 at 01:15:41PM +0300, Adrian Ratiu wrote:
> On Wed, 22 Apr 2020, Laurent Pinchart wrote:
> > On Wed, Apr 22, 2020 at 03:58:33AM +0300, Laurent Pinchart wrote:
> >> On Tue, Apr 21, 2020 at 07:16:07PM +0300, Adrian Ratiu wrote:
> >>> This provides an example DT
On Wed, 22 Apr 2020, Laurent Pinchart
wrote:
Hi Adrian,
On Wed, Apr 22, 2020 at 01:15:41PM +0300, Adrian Ratiu wrote:
On Wed, 22 Apr 2020, Laurent Pinchart wrote:
> On Wed, Apr 22, 2020 at 03:58:33AM +0300, Laurent Pinchart
> wrote:
>> On Tue, Apr 21, 2020 at 07:16:07PM +0300, Adrian
Hello,
On Tue, Apr 21, 2020 at 02:34:59PM +0200, Daniel Vetter wrote:
> > > Also, of course, let me know if yu're not happy with the
> > > __kthread_queue_work() changes/kthread_worker usage in drm_vblank_work as
> > > well
> >
> > Just glanced over it and I still wonder whether it needs to be
Hi,
On Wed, Apr 22, 2020 at 3:23 AM Stephen Boyd wrote:
>
> Quoting Douglas Anderson (2020-04-20 22:06:17)
> > The ti-sn65dsi86 MIPI DSI to eDP bridge chip has 4 pins on it that can
> > be used as GPIOs in a system. Each pin can be configured as input,
> > output, or a special function for the
Hi all,
On Tue, 21 Apr 2020 09:10:25 +0300 Tomi Valkeinen wrote:
>
> On 21/04/2020 04:52, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the drm-misc tree got a conflict in:he drm-misc
> > tree with the drm-misc-fixes tree
> >
> >drivers/gpu/drm/tidss/tidss_encoder.c
> >
> >
Hi Dave, Daniel,
Fixes for 5.7.
The following changes since commit 4da858c086433cd012c0bb16b5921f6fafe3f803:
Merge branch 'linux-5.7' of git://github.com/skeggsb/linux into drm-fixes
(2020-04-16 15:40:02 +1000)
are available in the Git repository at:
Hi Joe.
> >
> > > I would also be great if you or someone else could:
> > > - teach get_maintainers about .yaml file listed maintainers
> >
> > It already does to some extent. IIRC, there's a mode to extract email
> > addresses from files.
>
> --file-emails
>
> > I was hoping that the
https://bugzilla.kernel.org/show_bug.cgi?id=206987
--- Comment #9 from Cyrax (ev...@hotmail.com) ---
Created attachment 288679
--> https://bugzilla.kernel.org/attachment.cgi?id=288679=edit
dmesg output
And again.
--
You are receiving this mail because:
You are watching the assignee of the
https://bugzilla.kernel.org/show_bug.cgi?id=206987
Cyrax (ev...@hotmail.com) changed:
What|Removed |Added
Kernel Version|5.6.4 |5.6.5
--
You are receiving
Hi all,
Today's linux-next merge of the amdgpu tree got a conflict in:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
between commit:
09b974e8983a ("drm/amd/amdgpu_dm/mst: Remove ->destroy_connector() callback")
from the drm tree and commit:
c33f212c0c92
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #3 from Duncan (1i5t5.dun...@cox.net) ---
CCed the two from MAINTAINERS bugzi would let me add. It wouldn't let me add
amd-gfx@ or david1.zhou@, and Alex's gmail address according to bugzi isn't
what's in MAINTAINERS.
--
You are
Hi Hadar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on sparc/master]
[also build test ERROR on stm32/stm32-next linus/master v5.7-rc2 next-20200422]
[cannot apply to sparc-next/master]
[if your patch is applied to the wrong git tree, please drop us a note to help
On Wed, 2020-04-22 at 15:02 -0500, Rob Herring wrote:
> On Mon, Apr 20, 2020 at 12:59 PM Sam Ravnborg wrote:
> > Hi Adrian
> >
> > On Mon, Apr 20, 2020 at 02:19:24PM +0300, Adrian Ratiu wrote:
> > > Hello,
> > >
> > > I got confused while doing the txt -> yaml conversion at [1] and it's
> > >
Update the gmu_pdc registers for A640 and A650.
Some of the RSCC registers on A650 are in a separate region.
Note this also changes the address of these registers:
RSCC_TCS1_DRV0_STATUS
RSCC_TCS2_DRV0_STATUS
RSCC_TCS3_DRV0_STATUS
Based on the values in msm-4.14 and msm-4.19 kernels.
On Tue, 21 Apr 2020, Dan Carpenter wrote:
> Hi Kernel Janitors,
>
> Here is another idea that someone could work on, fixing the
> IS_ERR_OR_NULL() checks in the xen driver.
>
> The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
> display frontend" from Apr 3, 2018, leads to the
Add Adreno 640 and 650 GPU info to the gpulist.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 24 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 2 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 10 +
3 files changed, 35
MSM Mobile Display Subsytem (MDSS) encapsulates sub-blocks
like DPU display controller, DSI etc. Add YAML schema
for the device tree bindings for the same.
Signed-off-by: Krishna Manikandan
Changes in v2:
- Changed dpu to DPU (Sam Ravnborg)
- Fixed indentation issues (Sam
From: Jason Gunthorpe
There is no reason for a user to select this or not directly - it should
be selected by drivers that are going to use the feature, similar to how
CONFIG_HMM_MIRROR works.
Currently all drivers provide a feature kconfig that will disable use of
DEVICE_PRIVATE in that
Sure, this seems to be a lot more professional than my previous modification.
My original intention is to make the code easier to read, and I learned a lot
from
submitting these patches. Thank you very much for all your guidance!
Regards,
Bernard
发件人：Felix Kuehling
发送日期：2020-04-22 10:27:16
Fix issues reported by checkpatch. No functional changes.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Daniel Thompson
---
drivers/video/backlight/led_bl.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/led_bl.c
On Tue, Apr 21, 2020 at 07:57:12PM -0700, Guru Das Srinagesh wrote:
> [REQUEST]
>
> Would it be possible for the patches that have already received Acked-by's in
> this series to be accepted and applied to the tree? I lost an Acked-by (in
> intel-panel.c) because it had a merge conflict with a
From: Michał Winiarski
Control nodes are no longer with us.
While we still need to preserve render nodes numbering, there's no need
to reserve the range formerly used for control. Let's repurpose it to be
used by primary and remove control remains from the code entirely.
References:
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: Jingoo Han
Cc: Bartlomiej Zolnierkiewicz
Cc:
> There is no need to if check again,
Thanks for this information.
* Should the function name be mentioned in this commit message?
* Would you like to adjust the patch subject another bit?
> maybe we could merge into the above else branch.
I suggest to reconsider this wording.
Are you still
This function allows pinning iova to a specific page range (for a6xx GMU).
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/msm_drv.h | 6 +-
drivers/gpu/drm/msm/msm_gem.c | 28 +---
drivers/gpu/drm/msm/msm_gem_vma.c | 6 --
3 files changed, 30
Fixes coccicheck warning:
drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c:103:23-30: WARNING opportunity
for kmemdup
drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c:113:22-29: WARNING opportunity
for kmemdup
Fixes: 22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to replace "secure
boot"")
VRAM manager and DRM MM when init failed, there is no operaction
to free kzalloc memory & remove device file.
This will lead to memleak & cause stability issue.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 24
1 file changed, 19
Adreno 640 and 650 GPUs need some registers set differently.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 14 +++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 56 ++-
2 files changed, 61 insertions(+), 9 deletions(-)
diff --git
Add HFI v2 code paths required by Adreno 640 and 650 GPUs.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 66 ---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 7 ++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +-
drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 117
Newer GPUs have different GMU firmware path.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 135 +++---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 11 ++
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 6 +
3 files changed, 136 insertions(+), 16
* Tony Lindgren [200421 10:39]:
> See for example the standard 8250 uart for am335x with:
>
> $ git grep -B20 -A10 uart0 arch/arm/boot/dts/am33xx-l4.dtsi
>
> The 8250 device configuration is described in the standard 8250
> dts binding, and the am335x module in the ti-sysc binding.
> The are
发件人："Christian König"
发送日期：2020-04-21 22:53:47
收件人："赵军奎"
抄送人：Alex Deucher ,"David (ChunMing) Zhou"
,David Airlie ,Daniel Vetter
,Tom St Denis ,Ori Messinger
,Sam Ravnborg
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org,opensource.ker...@vivo.com
It forgot to call bochs_hw_fini() to release related resources when
bochs_pci_probe() fail. eg: io virtual address get by ioremap().
Fixes: 81da8c3b8d3df6 ("drm/bochs: add drm_driver.release callback.")
CC: Andy Shevchenko
Signed-off-by: Dejin Zheng
---
drivers/gpu/drm/bochs/bochs_drv.c | 1 +
There is no need to if check again, maybe we could merge
into the above else branch.
Signed-off-by: Bernard Zhao
Changes since V1:
*commit message improve
*code style refactoring
Changes since V2:
*code style adjust
Changes since V3:
*find the best way to merge unnecessary if/else check
From: Jason Gunthorpe
This is just an alias for HMM_PFN_ERROR, nothing cares that the error was
because of a special page vs any other error case.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 -
drivers/gpu/drm/nouveau/nouveau_svm.c | 1 -
From: "Christian König"
Date: 2020-04-21 15:41:27
To: 1587181464-114215-1-git-send-email-bern...@vivo.com,Felix Kuehling
,Alex Deucher ,"David
(ChunMing) Zhou" ,David Airlie ,Daniel
Vetter
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org
Cc:
* H. Nikolaus Schaller [200421 17:31]:
> > Am 21.04.2020 um 16:15 schrieb Tony Lindgren :
> > Note that on omaps there are actually SoC module specific registers.
>
> Ah, I see. This is of course a difference that the TI glue logic has
> its own registers in the same address range as the sgx and
From: Jason Gunthorpe
Since amdgpu does not use the snapshot mode of hmm_range_fault() a
successful return already proves that all entries in the pfns are
HMM_PFN_VALID, there is no need to check the return result of
hmm_device_entry_to_page().
Signed-off-by: Jason Gunthorpe
---
> But i have to say there are so many code not follow the kernel code-style in
> amdgpu module.
> And also the ./scripts/checkpatch.pl did not throw any warning or error.
Will such information become more interesting for further evolution
in the affected software areas?
Regards,
Markus
This flag sets IOMMU_PRIV, which is required for some a6xx GMU objects.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/msm_gem.c | 3 +++
drivers/gpu/drm/msm/msm_gem.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
On 4/21/20 12:30 PM, Jordan Crouse wrote:
On Mon, Apr 20, 2020 at 10:03:08AM -0400, Jonathan Marek wrote:
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 68 ---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 7 ++
drivers/gpu/drm/msm/adreno/a6xx_gpu.c |
On 4/21/20 14:51, Dan Carpenter wrote:
> It turns out there aren't that many of these in xen.
>
> $ grep IS_ERR_OR_NULL drivers/gpu/drm/xen/ -Rn
> drivers/gpu/drm/xen/xen_drm_front_kms.c:63: if (IS_ERR_OR_NULL(fb))
> drivers/gpu/drm/xen/xen_drm_front_gem.c:86: if (IS_ERR_OR_NULL(xen_obj))
On 4/21/20 13:45, Dan Carpenter wrote:
> Hi Kernel Janitors,
Hi
>
> Here is another idea that someone could work on, fixing the
> IS_ERR_OR_NULL() checks in the xen driver.
>
> The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
> display frontend" from Apr 3, 2018, leads to the
The code that maps the LED default brightness to backlight levels has
two issues: 1) if the default brightness is the first backlight level
(usually 0), the code fails to find it, and 2) when the code fails to
find a backlight level, it ends up using max_brightness + 1 as the
default brightness.
There's no need to set 'levels' to NULL.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Daniel Thompson
---
drivers/video/backlight/led_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
index
Hi,
Changes in v3:
- "backlight: led_bl: fix led -> backlight brightness mapping": Simplify
the for loop as suggested by Daniel
Changes in v2:
- Drop "backlight: led_bl: rewrite led_bl_parse_levels()". The patch
changed the behavior, and the new behavior may not be wanted. So lets
drop
led_bl does not lock 'led_access' when calling led_sysfs_disable and
led_sysfs_enable, causing the below WARN. Add the locking.
WARNING: CPU: 0 PID: 223 at drivers/leds/led-core.c:353
led_sysfs_disable+0x4c/0x5c
Signed-off-by: Tomi Valkeinen
Reviewed-by: Daniel Thompson
---
On 22/04/2020 10:19, Jason Yan wrote:
Fix the following coccicheck warning:
drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c:461:15-32: WARNING:
Comparison to bool
drivers/video/fbdev/omap2/omapfb/dss/dispc.c:891:5-35: WARNING:
Comparison of 0/1 to bool variable
Signed-off-by: Jason Yan
---
Hi Inki,
On 22.04.2020 06:36, Inki Dae wrote:
> 20. 4. 22. 오후 12:37에 Inki Dae 이(가) 쓴 글:
>> 20. 4. 21. 오후 5:09에 Marek Szyprowski 이(가) 쓴 글:
>>> On 21.04.2020 09:38, Inki Dae wrote:
20. 4. 7. 오후 10:42에 Marek Szyprowski 이(가) 쓴 글:
> Explicitly check if the imported buffer has been mapped as
On Wed, Apr 22, 2020 at 09:51:14AM +0300, Tomi Valkeinen wrote:
> The code that maps the LED default brightness to backlight levels has
> two issues: 1) if the default brightness is the first backlight level
> (usually 0), the code fails to find it, and 2) when the code fails to
> find a backlight
On Tue, 21 Apr 2020, Dan Carpenter wrote:
> On Tue, Apr 21, 2020 at 05:29:02PM +0200, Julia Lawall wrote:
> >
> >
> > On Tue, 21 Apr 2020, Dan Carpenter wrote:
> >
> > > Hi Kernel Janitors,
> > >
> > > Here is another idea that someone could work on, fixing the
> > > IS_ERR_OR_NULL() checks in
Maybe we could reduce the mutex_lock(>lock)`s protected code area,
and no need to protect pr_debug.
Signed-off-by: Bernard Zhao
Changes since V1:
*commit message improve
Changes since V2:
*move comment along with the mutex_unlock
Changes since V3:
*lock protect the if check, there is some
[REQUEST]
Would it be possible for the patches that have already received Acked-by's in
this series to be accepted and applied to the tree? I lost an Acked-by (in
intel-panel.c) because it had a merge conflict with a new change that came in
after I rebased to tip. I wasn't sure earlier about
On Tue, Apr 21, 2020 at 09:51:37AM +0300, Joonas Lahtinen wrote:
> Quoting Sultan Alsawaf (2020-04-20 19:15:14)
> > On Mon, Apr 20, 2020 at 11:21:42AM +0300, Joonas Lahtinen wrote:
> > > So it seems that the patch got pulled into v5.6 and has been backported
> > > to v5.5 but not v5.4.
> >
> >
From: Jason Gunthorpe
hmm_vma_walk->last is supposed to be updated after every write to the
pfns, so that it can be returned by hmm_range_fault(). However, this is
not done consistently. Fortunately nothing checks the return code of
hmm_range_fault() for anything other than error.
More
From: Jason Gunthorpe
The API is a bit complicated for the uses we actually have, and
disucssions for simplifying have come up a number of times.
This small series removes the customizable pfn format and simplifies the
return code of hmm_range_fault()
All the drivers are adjusted to process in
This is required for a650 to work.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 15 +++
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 1 +
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 4
3 files changed, 20 insertions(+)
diff --git
>> But i have to say there are so many code not follow the kernel code-style in
>> amdgpu module.
>> And also the ./scripts/checkpatch.pl did not throw any warning or error.
>
> That is unfortunately true, yes. But we try to push new code through the
> usual code review and improve things as we
>>> There is no need to if check again, maybe we could merge
>>> into the above else branch.
I find also this commit message still improvable (besides the mentioned
implementation details around coding style concerns).
How will corresponding review comments be taken better into account?
Regards,
> Am 21.04.2020 um 16:15 schrieb Tony Lindgren :
>
> * Maxime Ripard [200421 11:22]:
>> On Tue, Apr 21, 2020 at 11:57:33AM +0200, Philipp Rossak wrote:
>>> I had a look on genpd and I'm not really sure if that fits.
>>>
>>> It is basically some bit that verify that the clocks should be
Hi,
On Tue, Apr 21, 2020 at 11:57:33AM +0200, Philipp Rossak wrote:
> On 20.04.20 09:38, Maxime Ripard wrote:
> > Hi,
> >
> > On Fri, Apr 17, 2020 at 02:09:06PM +0200, Philipp Rossak wrote:
> > > > > I'm a bit skeptical on that one since it doesn't even list the
> > > > > interrupts connected to
From: Randy Dunlap
Fix help text: indent one tab + 2 spaces; end a sentence with a
period; and collapse short lines of text to one line.
Fixes: 23c61b4599c4 ("drm/amd: Fix Kconfig indentation")
Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
Signed-off-by: Randy Dunlap
Cc: Harry
Make the code a bit more readable by using a common
error handling pattern.
With that done the patch is Reviewed-by: Christian König
.
Signed-off-by: Bernard Zhao
Changes since V1:
*commit message improve
*code style refactoring
Changes since V2:
*code style adjust
Changes since V3:
*find the
From: "Christian König"
Date: 2020-04-21 19:22:49
To: Bernard Zhao ,Alex Deucher
,"David (ChunMing) Zhou" ,David
Airlie ,Daniel Vetter ,Tom St Denis
,Ori Messinger ,Sam Ravnborg
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org
Cc:
This gives more fine-grained control over how memory is allocated over the
DMA api. In particular, it allows using an address range or pinning to
a fixed address.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 115 ++
On 4/16/20 6:22 PM, Chun-Kuang Hu wrote:
> Hi, Matthias:
>
> Matthias Brugger 於 2020年3月26日 週四 下午11:45寫道：
>>
>>
>>
>> On 26/03/2020 15:51, CK Hu wrote:
>>> Hi, Matthias:
>>>
>>> On Thu, 2020-03-26 at 12:54 +0100, Matthias Brugger wrote:
Hi CK,
On 26/03/2020 00:05, CK Hu wrote:
On Tue, Apr 21, 2020 at 09:38:09AM -0700, Sultan Alsawaf wrote:
> Why hasn't this bug got any attention:
> https://gitlab.freedesktop.org/drm/intel/issues/1412
>
> That seems like a showstopper.
Indeed, pretty shocking. It's worth mentioning that the reporter of said
bug, after significant time
Hi!
On Tue, Apr 21, 2020 at 01:04:05AM +, Joel Stanley wrote:
> On Mon, 20 Apr 2020 at 18:38, Christophe Leroy
> wrote:
> > _ALIGN_DOWN() is specific to powerpc
> > ALIGN_DOWN() is generic and does the same
> >
> > Replace _ALIGN_DOWN() by ALIGN_DOWN()
>
> This one is a bit less obvious.
> -Original Message-
> From: Rob Herring
> Sent: Monday, 20 April 2020 23:37
>
> On Mon, Apr 13, 2020 at 04:35:53PM +0300, Hadar Gat wrote:
> > Both of_platform.h and of_device.h were included each other.
> > In of_device.h, removed unneeded #include to of_platform.h and added
> >
diff --git a/drivers/misc/cxl/Kconfig b/drivers/misc/cxl/Kconfig
index 39eec9031487..a62795079d9c 100644
--- a/drivers/misc/cxl/Kconfig
+++ b/drivers/misc/cxl/Kconfig
@@ -19,6 +19,7 @@ config CXL
select CXL_BASE
select CXL_AFU_DRIVER_OPS
select CXL_LIB
+ select
发件人："Christian König"
发送日期：2020-04-21 21:02:27
收件人："赵军奎"
抄送人：Alex Deucher ,"David (ChunMing) Zhou"
,David Airlie ,Daniel Vetter
,Tom St Denis ,Ori Messinger
,Sam Ravnborg
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org,opensource.ker...@vivo.com
There is no need to if check again, maybe we could merge
into the above else branch.
Signed-off-by: Bernard Zhao
Changes since V1:
*commit message improve
*code style refactoring
Changes since V2:
*code style adjust
Link for V1:
*https://lore.kernel.org/patchwork/patch/1226587/
---
From: Jason Gunthorpe
Presumably the intent here was that hmm_range_fault() could put the data
into some HW specific format and thus avoid some work. However, nothing
actually does that, and it isn't clear how anything actually could do that
as hmm_range_fault() provides CPU addresses which must
Hi,
On 21.04.20 13:21, Maxime Ripard wrote:
Hi,
On Tue, Apr 21, 2020 at 11:57:33AM +0200, Philipp Rossak wrote:
On 20.04.20 09:38, Maxime Ripard wrote:
Hi,
On Fri, Apr 17, 2020 at 02:09:06PM +0200, Philipp Rossak wrote:
I'm a bit skeptical on that one since it doesn't even list the
Since the PWM framework is switching struct pwm_state.duty_cycle's
datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
to handle a 64-bit dividend.
To: Jani Nikula
Cc: Joonas Lahtinen
Cc: David Airlie
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: "Ville Syrjälä"
Cc:
From: Bernard Zhao
Date: 2020-04-21 10:07:50
To: Alex Deucher ,"Christian König"
,"David (ChunMing) Zhou" ,David
Airlie ,Daniel Vetter ,Lyude Paul
,Sam Ravnborg ,Bernard Zhao
,"José Roberto de Souza" ,Andrzej
Pietrasiewicz
Hi,
On 20.04.20 09:38, Maxime Ripard wrote:
Hi,
On Fri, Apr 17, 2020 at 02:09:06PM +0200, Philipp Rossak wrote:
I'm a bit skeptical on that one since it doesn't even list the
interrupts connected to the GPU that the binding mandates.
I think he left it out for a future update.
But best he
Maybe we could reduce the mutex_lock(>lock)`s protected code area,
and no need to protect pr_debug.
Signed-off-by: Bernard Zhao
Changes since V1:
*commit message improve
Changes since V2:
*move comment along with the mutex_unlock
Link for V1:
*https://lore.kernel.org/patchwork/patch/1226588/
* Maxime Ripard [200421 11:22]:
> On Tue, Apr 21, 2020 at 11:57:33AM +0200, Philipp Rossak wrote:
> > I had a look on genpd and I'm not really sure if that fits.
> >
> > It is basically some bit that verify that the clocks should be enabled or
> > disabled.
>
> No, it can do much more than
For the code logic, an alarm is thrown after failure, but the
code continues to run and returns successfully, so to the caller
the if check and return branch will never run.
The change is to make the code a bit more readable.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/arm/hdlcd_crtc.c | 4
From: "Christian König"
Date: 2020-04-21 16:06:03
To: 1587180037-113840-1-git-send-email-bern...@vivo.com,Felix Kuehling
,Alex Deucher ,"David
(ChunMing) Zhou" ,David Airlie ,Daniel
Vetter
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org
Cc:
On Tue, Apr 21, 2020 at 11:04:13AM +0300, Joonas Lahtinen wrote:
> Quoting Sultan Alsawaf (2020-04-20 18:42:16)
> > On Mon, Apr 20, 2020 at 12:02:39PM +0300, Joonas Lahtinen wrote:
> > > I think the the patch should be dropped for now before the issue is
> > > properly addressed. Either by
> The "if(!encoder)" branch return the same value 0 of the success
> branch, maybe return -EINVAL is more better.
I suggest to improve the commit message.
* Are you still unsure about the next changes?
Am 22.04.20 um 02:56 schrieb 赵军奎:
发件人："Christian König"
发送日期：2020-04-21 22:53:47
收件人："赵军奎"
抄送人：Alex Deucher ,"David (ChunMing) Zhou" ,David Airlie
,Daniel Vetter ,Tom St Denis ,Ori Messinger
,Sam Ravnborg
On Wed, 22 Apr 2020, Laurent Pinchart
wrote:
Hi Adrian,
Hi Laurent,
On Wed, Apr 22, 2020 at 03:58:33AM +0300, Laurent Pinchart
wrote:
On Tue, Apr 21, 2020 at 07:16:07PM +0300, Adrian Ratiu wrote:
> This provides an example DT binding for the MIPI DSI host
> controller present on the
AFBC has a mode that allows use of AFBC with an uncompressed buffer,
we add a new modifier to support this mode.
Signed-off-by: Ben Davis
---
include/uapi/drm/drm_fourcc.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
https://bugzilla.kernel.org/show_bug.cgi?id=205291
--- Comment #10 from K J Petrie (kernel.b...@kjpetrie.co.uk) ---
Looks like I need to recompile with CONFIG_PM_ADVANCED_DEBUG, I suspect.
--
You are receiving this mail because:
You are watching the assignee of the bug.
From: Karol Herbst
[ Upstream commit 434fdb51513bf3057ac144d152e6f2f2b509e857 ]
Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.
Depending on the used kernel there might be messages like those in
From: Binu R S
a) Adds new format modifiers for Intel Gen-12
- I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS
- I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS
b) Generated using make headers_install
c) Generated from drm-next
Signed-off-by: Binu R S
---
include/drm/drm_fourcc.h | 54
DRM_FORMAT_NV15 is a 2 plane format suitable for linear and 16x16
block-linear memory layouts. The format is similar to P010 with 4:2:0
sub-sampling but has no padding between components. Instead, luminance
and chrominance samples are grouped into 4s so that each group is packed
into an integer
On Wed, 22 Apr 2020, Laurent Pinchart
wrote:
Hi Adrian,
Hi Laurent,
On Tue, Apr 21, 2020 at 07:16:06PM +0300, Adrian Ratiu wrote:
This adds support for the Synopsis DesignWare MIPI DSI v1.01
host controller which is embedded in i.MX 6 SoCs. Based on
following patches, but
From: Karol Herbst
[ Upstream commit 434fdb51513bf3057ac144d152e6f2f2b509e857 ]
Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.
Depending on the used kernel there might be messages like those in
https://bugzilla.kernel.org/show_bug.cgi?id=205291
--- Comment #9 from K J Petrie (kernel.b...@kjpetrie.co.uk) ---
Well, it'll take time to patch and recompile the kernel, but in the meantime
here is all the contents of the power directories:
AMD Radeon GPU
cat
On Mon, Apr 20, 2020 at 06:04:29PM +0300, Hadar Gat wrote:
> Both of_platform.h and of_device.h were included each other.
> In of_device.h, removed unneeded #include to of_platform.h
> and added include to of_platform.h in the files that needs it.
>
> Signed-off-by: Hadar Gat
> Reported-by:
From: Binu R S
a) Adds new format modifiers for Format modifier for Intel Gen-12
- I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS
- I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS
b) Generated using make headers_install
c) Taken from drm-next
Signed-off-by: Binu R S
---
include/drm/drm_fourcc.h |
From: Aditya Swarup
From: Aditya Swarup
This function sets the VRR property for connector based
on the platform support, EDID monitor range and DP sink
DPCD capability of outputing video without msa
timing information.
v4:
* Rebase (Mansi)
v3:
* intel_dp_is_vrr_capable can be used for
From: Manasi Navare
From: Manasi Navare
DP sink device sets the Ignore MSA bit in its
DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to
ignore the MSA video timing parameters and its ability to support
seamless video timing change over a range of timing exposed by
DisplayID and
From: Bhanuprakash Modem
[Why]
It's useful to know the min and max vrr range for IGT testing.
[How]
Expose the min and max vfreq for the connector via a debugfs file
on the connector, "vrr_range".
Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
v4:
* Rebase (Bhanu)
* Remove
1 - 100 of 126 matches
Mail list logo
