Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
mm/memory.c
between commit:
327e9fd48972 ("mm: Split huge pages on write-notify or COW")
from the drm tree and commit:
de0b1f32cbeb ("userfaultfd: wp: hook userfault handler to write protection
fault")
from
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
include/linux/huge_mm.h
between commit:
9a9731b18c9b ("mm: Add vmf_insert_pfn_xxx_prot() for huge page-table entries")
from the drm tree and commit:
7b6b88969e9d ("mm: merge parameters for
Hi Linus,
This is the second pull, it has some changes to mm in it that should
all have acks on them. The first dax constify arg patch got an ack on
the list from Matthew Wilcox and Dan Williams after the MR was sent,
but I didn't think it was worth a resend for that.
This adds support for
On Thu, 2020-04-02 at 15:53 +0200, Mauro Carvalho Chehab wrote:
> I liked one of the suggestions of using "%p4cc" (or maybe something
> similar, if having a number there is a problem, like "%pAcc" or "%pfcc")
Using a number is not a problem.
___
On Thu, 2020-04-02 at 11:34 +0300, Jani Nikula wrote:
> On Wed, 01 Apr 2020, Sakari Ailus wrote:
> > Add a printk modifier %ppf (for pixel format) for printing V4L2 and DRM
> > pixel formats denoted by 4ccs. The 4cc encoding is the same for both so
> > the same implementation can be used.
>
>
Hi all,
On Wed, 18 Mar 2020 13:50:34 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> arch/arm/configs/omap2plus_defconfig
>
> between commit:
>
> 98c2cc359f8f ("ARM: omap2plus_defconfig: Update for moved and dropped
> options")
>
> from
drm_local_map.offset is not only used for resource_size_t but also
dma_addr_t which may be of different sizes.
Reported-by: Nathan Chancellor
Fixes: 8e4ff9b56957 ("drm: Remove the dma_alloc_coherent wrapper for internal
usage")
Signed-off-by: Chris Wilson
Cc: Dave Airlie
Cc: Nathan Chancellor
Hi Dave and Daniel,
Here goes drm-intel-next-fixes-2020-04-02:
Only gvt fixes on this round:
- Fix non-privilege access warning (Tina)
- Fix display port type (Tina)
- BDW cmd parser missed SWTESS_BASE_ADDRESS (Yan)
- Bypass length check of LRI (Yan)
- Fix one klocwork warning (Tina)
Thanks,
On Thu, Apr 2, 2020 at 1:33 PM Nathan Chancellor
wrote:
>
> This fixes it but I am not sure if it is proper or not (could be
> problematic if CONFIG_PHYS_ADDR_T_64BIT is set but
> CONFIG_ARCH_DMA_ADDR_T_64BIT is not, not sure if that is possible) so I
> figured I'd report it and let you guys deal
On Thu, Apr 02, 2020 at 12:56:04PM -0500, Daniel Dadap wrote:
> I'll check one of the eDP-based systems I've been experimenting on to see if
> setting the VGA_SWITCHER_NEEDS_EDP_CONFIG capability in the handler is
> sufficient to make i915 avoid poking the AUX channel when it's mux-switched
>
Am Donnerstag, den 02.04.2020, 18:07 +0100 schrieb Robert Beckett:
> commit 4900dda90af2cb13bc1d4c12ce94b98acc8fe64e upstream
>
> Due to async need_flush updating via other buffer mapping, checking
> gpu->need_flush in 3 places within etnaviv_buffer_queue can cause GPU
> hangs.
>
> This occurs
From: Lucas Stach
commit 4900dda90af2cb13bc1d4c12ce94b98acc8fe64e upstream
If a MMU is shared between multiple GPUs, all of them need to flush their
TLBs, so a single marker that gets reset on the first flush won't do.
Replace the flush marker with a sequence number, so that it's possible to
From: Lucas Stach
commit 4900dda90af2cb13bc1d4c12ce94b98acc8fe64e upstream
If a MMU is shared between multiple GPUs, all of them need to flush their
TLBs, so a single marker that gets reset on the first flush won't do.
Replace the flush marker with a sequence number, so that it's possible to
From: Lucas Stach
commit 4900dda90af2cb13bc1d4c12ce94b98acc8fe64e upstream
If a MMU is shared between multiple GPUs, all of them need to flush their
TLBs, so a single marker that gets reset on the first flush won't do.
Replace the flush marker with a sequence number, so that it's possible to
commit 4900dda90af2cb13bc1d4c12ce94b98acc8fe64e upstream
Due to async need_flush updating via other buffer mapping, checking
gpu->need_flush in 3 places within etnaviv_buffer_queue can cause GPU
hangs.
This occurs due to need_flush being false for the first 2 checks in that
function, so that the
Hi Ville.
On Thu, Apr 02, 2020 at 04:13:10PM +0300, Ville Syrjälä wrote:
> On Tue, Mar 03, 2020 at 01:52:27PM +0100, Heiko Stuebner wrote:
> > Hi,
> >
> > Am Montag, 2. März 2020, 21:34:24 CET schrieb Ville Syrjala:
> > > From: Ville Syrjälä
> > >
> > > The currently listed dotclock disagrees
https://bugzilla.kernel.org/show_bug.cgi?id=207047
Artemis Tosini (m...@artem.ist) changed:
What|Removed |Added
Status|NEW |RESOLVED
On Thu, Apr 2, 2020 at 4:31 PM Lukas Wunner wrote:
>
> On Thu, Apr 02, 2020 at 03:13:26PM +0200, Daniel Vetter wrote:
> > On Thu, Apr 2, 2020 at 2:58 PM Pekka Paalanen wrote:
> > > On Thu, 2 Apr 2020 13:39:25 +0200 Lukas Wunner wrote:
> > > > Note that vga_switcheroo is currently controlled via
On Thu, Apr 02, 2020 at 03:13:26PM +0200, Daniel Vetter wrote:
> On Thu, Apr 2, 2020 at 2:58 PM Pekka Paalanen wrote:
> > On Thu, 2 Apr 2020 13:39:25 +0200 Lukas Wunner wrote:
> > > Note that vga_switcheroo is currently controlled via debugfs.
> > > That is a historic artefact. The kernel has
Em Thu, 02 Apr 2020 11:34:48 +0300
Jani Nikula escreveu:
> On Wed, 01 Apr 2020, Sakari Ailus wrote:
> > Add a printk modifier %ppf (for pixel format) for printing V4L2 and DRM
> > pixel formats denoted by 4ccs. The 4cc encoding is the same for both so
> > the same implementation can be used.
On Thu, Apr 2, 2020 at 2:58 PM Pekka Paalanen wrote:
>
> On Thu, 2 Apr 2020 13:39:25 +0200
> Lukas Wunner wrote:
>
> > Note that vga_switcheroo is currently controlled via debugfs.
> > That is a historic artefact. The kernel has since gained a
> > mux subsystem in drivers/mux/ which could be
On Tue, Mar 03, 2020 at 01:52:27PM +0100, Heiko Stuebner wrote:
> Hi,
>
> Am Montag, 2. März 2020, 21:34:24 CET schrieb Ville Syrjala:
> > From: Ville Syrjälä
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
Hi, Matthias:
Matthias Brugger 於 2020年4月1日 週三 下午11:53寫道：
>
>
>
> On 01/04/2020 04:16, Chunfeng Yun wrote:
> > On Tue, 2020-03-31 at 23:57 +0800, Chun-Kuang Hu wrote:
> >> From: CK Hu
> >>
> >> tz_disabled is used to control mtk_hdmi output signal, but this variable
> >> is stored in
On Thu, 2 Apr 2020 13:39:25 +0200
Lukas Wunner wrote:
> Note that vga_switcheroo is currently controlled via debugfs.
> That is a historic artefact. The kernel has since gained a
> mux subsystem in drivers/mux/ which could be used to represent
> the display mux in a standardized way in regular
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: cade363a69762c57ffb58f91b47670df7ca520bf
commit: f0b7c5c4d7beea0cd83b2f8659faf9fd406137e6 [9/10] Merge remote-tracking
branch 'drm-intel/topic/core-for-CI' into drm-tip
config: x86_64-allyesconfig (attached as .config)
compiler:
Hi Daniel (another one!),
On Thu, 2 Apr 2020 at 08:18, Daniel Dadap wrote:
> > I primarily asked about vgaswitcheroo since you didn't mention it at all.
>
> I had actually anticipated that vga-switcheroo would likely be
> suggested, and my first draft of my initial message had a lengthy
>
On Thu, Apr 02, 2020 at 01:39:25PM +0200, Lukas Wunner wrote:
> First of all, there's DPCD byte 3 bit 6 (NO_AUX_HANDSHAKE_LINK_TRAINING)
> which is documented as follows:
>
> Does not require AUX CH handshake when the link configuration is
> already known. [...] The known-good drive
On Fri, Mar 27, 2020 at 04:25:19PM -0500, Daniel Dadap wrote:
> A number of hybrid GPU notebook computer designs with dual (integrated plus
> discrete) GPUs are equipped with multiplexers (muxes) that allow display
> panels to be driven by either the integrated GPU or the discrete GPU.
>
On Thu, Apr 2, 2020 at 12:57 PM Daniel Stone wrote:
>
> On Thu, 2 Apr 2020 at 11:40, Laurent Pinchart
> wrote:
> > The R-Car DU driver creates a zpos property, ranging from 1 to 7, for
> > all the overlay planes, but leaves the primary plane without a zpos
> > property. The DRM/KMS API doesn't
Hi Laurent,
On Thu, Apr 2, 2020 at 12:42 PM Laurent Pinchart
wrote:
> The R-Car DU driver creates a zpos property, ranging from 1 to 7, for
> all the overlay planes, but leaves the primary plane without a zpos
> property. The DRM/KMS API doesn't clearly specify if this is acceptable,
> of it the
On Thu, Apr 02, 2020 at 12:53:25PM +0300, Laurent Pinchart wrote:
> The example code showing how to use the managed resource API calls
> kfree() on the wrong pointer. Fix it.
>
> Fixes: d33b58d0115e ("drm: Garbage collect drm_dev_fini")
Actually goes back to the original doc patch adding these,
On Wed, Apr 1, 2020 at 11:07 PM Arnd Bergmann wrote:
>
> On Tue, Mar 31, 2020 at 7:51 PM Segher Boessenkool
> wrote:
> >
> > On Tue, Mar 31, 2020 at 08:56:23AM +0200, Christophe Leroy wrote:
> > > While we are at it, can we also remove the 601 ? This one is also full
> > > of workarounds and
On Thu, 2 Apr 2020 at 11:40, Laurent Pinchart
wrote:
> The R-Car DU driver creates a zpos property, ranging from 1 to 7, for
> all the overlay planes, but leaves the primary plane without a zpos
> property. The DRM/KMS API doesn't clearly specify if this is acceptable,
> of it the property is
The R-Car DU driver creates a zpos property, ranging from 1 to 7, for
all the overlay planes, but leaves the primary plane without a zpos
property. The DRM/KMS API doesn't clearly specify if this is acceptable,
of it the property is mandatory for all planes when exposed for some of
the planes.
On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote:
> I have no attachment to 40x, and I'd certainly be happy to have less
> code in the tree, we struggle to keep even the modern platforms well
> maintained.
>
> At the same time I don't want to render anyone's hardware obsolete
>
The example code showing how to use the managed resource API calls
kfree() on the wrong pointer. Fix it.
Fixes: d33b58d0115e ("drm: Garbage collect drm_dev_fini")
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Thu, Apr 2, 2020 at 11:39 AM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> On Thu, Apr 02, 2020 at 07:17:40AM +0200, Daniel Vetter wrote:
> > On Thu, Apr 2, 2020 at 2:50 AM Laurent Pinchart wrote:
> > > On Mon, Mar 23, 2020 at 03:49:18PM +0100, Daniel Vetter wrote:
> > > > A few things:
> > > > -
Hi Daniel,
On Thu, Apr 02, 2020 at 07:17:40AM +0200, Daniel Vetter wrote:
> On Thu, Apr 2, 2020 at 2:50 AM Laurent Pinchart wrote:
> > On Mon, Mar 23, 2020 at 03:49:18PM +0100, Daniel Vetter wrote:
> > > A few things:
> > > - Update the example driver in the documentation.
> > > - We can drop the
Moi,
On Thu, Apr 02, 2020 at 11:34:48AM +0300, Jani Nikula wrote:
> On Wed, 01 Apr 2020, Sakari Ailus wrote:
> > Add a printk modifier %ppf (for pixel format) for printing V4L2 and DRM
> > pixel formats denoted by 4ccs. The 4cc encoding is the same for both so
> > the same implementation can be
On Wed, 01 Apr 2020, Sakari Ailus wrote:
> Add a printk modifier %ppf (for pixel format) for printing V4L2 and DRM
> pixel formats denoted by 4ccs. The 4cc encoding is the same for both so
> the same implementation can be used.
I'm not going to take a strong stand in one way or the other
On Thu, 02 Apr 2020, Daniel Vetter wrote:
> On Thu, Apr 2, 2020 at 8:23 AM Jani Nikula
> wrote:
>>
>> On Thu, 02 Apr 2020, Pankaj Bharadiya
>> wrote:
>> > Now we have new struct drm_device based drm_WARN* macros. These are
>> > preferred over the regular WARN* macros.
>> >
>> > Remove WARN_ON
Hi Martin
Am 02.04.20 um 09:39 schrieb Martin Blumenstingl:
> Hi Thomas,
>
> On Thu, Apr 2, 2020 at 9:26 AM Thomas Zimmermann wrote:
>>
>> Hi,
>>
>> building lima and panfrost drivers from drm-tip, I currently get the
>> following linker error
>>
>> > make clean
>> > make
>> [...]
>> LD
Hi Andy,
Thanks for the review.
On Wed, Apr 01, 2020 at 06:13:32PM +0300, Andy Shevchenko wrote:
> On Wed, Apr 01, 2020 at 04:13:51PM +0200, Hans Verkuil wrote:
> > On 4/1/20 4:05 PM, Sakari Ailus wrote:
> > > Add a printk modifier %ppf (for pixel format) for printing V4L2 and DRM
> > > pixel
On Thu, Apr 2, 2020 at 8:23 AM Jani Nikula wrote:
>
> On Thu, 02 Apr 2020, Pankaj Bharadiya
> wrote:
> > Now we have new struct drm_device based drm_WARN* macros. These are
> > preferred over the regular WARN* macros.
> >
> > Remove WARN_ON and WARN_ON_ONCE overriedes to avoid any temptations
Hi,
building lima and panfrost drivers from drm-tip, I currently get the
following linker error
> make clean
> make
[...]
LD vmlinux.o
arm-suse-linux-gnueabi-ld: drivers/gpu/drm/panfrost
/panfrost_devfreq.o: in function
`of_devfreq_cooling_register_power':
With this patch series I am trying to remove GPU address dependency in
TTM and moving GPU address calculation to individual drm drivers. This
cleanup will simplify introduction of drm_mem_region/domain work started
by Brian Welty[1].
It would be nice if someone test this for nouveau. Rest of the
On 4/1/20 1:46 AM, Daniel Vetter wrote
On Wed, Apr 1, 2020 at 3:58 AM Daniel Dadap wrote:
On 3/31/20 2:32 AM, Daniel Vetter wrote:
Since I see no mention of this anywhere in your mail ... have you
tried looking at drivers/gpu/vga/vga_switcheroo.c? This also supports
switching of just
Hi Hans,
Thank you for the review.
On Wed, Apr 01, 2020 at 04:13:51PM +0200, Hans Verkuil wrote:
> On 4/1/20 4:05 PM, Sakari Ailus wrote:
> > Add a printk modifier %ppf (for pixel format) for printing V4L2 and DRM
> > pixel formats denoted by 4ccs. The 4cc encoding is the same for both so
> >
This change adds the interconnect bindings to the
MDSS node. This will establish Display to DDR path
for bus bandwidth voting.
Changes in v2:
- Change in commit message
Signed-off-by: Krishna Manikandan
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 3 +++
1 file changed, 3 insertions(+)
Calculate GPU offset within vmwgfx driver itself without depending on
bo->offset.
Signed-off-by: Nirmoy Das
Acked-by: Christian König
Acked-by: Thomas Hellstrom
Tested-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2
On Wed, 1 Apr 2020, John B. Wyatt IV wrote:
> Fix 2 parenthesis alignment issues.
Please try to find a way to describe what you have done that doesn't
involve the word "Fix". What have you done and why?
julia
>
> Reported by checkpatch.
>
> Signed-off-by: John B. Wyatt IV
> ---
>
Move the bus clock to mdp device node,in order
to facilitate bus band width scaling on sc7180
target.
The parent device MDSS will not vote for bus bw,
instead the vote will be triggered by mdp device
node. Since a minimum vote is required to turn
on bus clock, move the clock node to mdp device
Michal Simek writes:
> On 01. 04. 20 4:07, Michael Ellerman wrote:
>> Michal Simek writes:
>>> Hi,
>>>
>>> recently we wanted to update xilinx intc driver and we found that function
>>> which we wanted to remove is still wired by ancient Xilinx PowerPC
>>> platforms. Here is the thread about it.
GPU address should belong to driver not in memory management.
This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver.
Signed-off-by: Nirmoy Das
Acked-by: Huang Rui
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 22 ++--
Hi Andrey,
On Wed, Apr 01, 2020 at 01:59:27PM +0300, Andrey Lebedev wrote:
> Hello Maxime,
>
> Since Linus' merge window is now open, do I have to do anything to get this
> merged into the mainline kernel?
You don't have to do anything, it's already on its way to Linus:
On 01. 04. 20 12:38, Takashi Iwai wrote:
> On Wed, 01 Apr 2020 12:35:16 +0200,
> Michael Ellerman wrote:
>>
>> Michal Simek writes:
>>> On 01. 04. 20 4:07, Michael Ellerman wrote:
Michal Simek writes:
> Hi,
>
> recently we wanted to update xilinx intc driver and we found that
This change adds support to scale src clk and bandwidth as
per composition requirements.
Interconnect registration for bw has been moved to mdp
device node from mdss to facilitate the scaling.
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 106
This change adds support to scale src clk and bandwidth as
per composition requirements.
Interconnect registration for bw has been moved to mdp
device node from mdss to facilitate the scaling.
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 106 +
Fix 2 parenthesis alignment issues.
Reported by checkpatch.
Signed-off-by: John B. Wyatt IV
---
drivers/staging/android/ion/ion_page_pool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/ion/ion_page_pool.c
On 3/18/20 11:45 AM, Lukasz Luba wrote:
The overhauled Energy Model (EM) framework support also devfreq devices.
The unified API interface of the EM can be used in the thermal subsystem to
not duplicate code. The power table now is taken from EM structure and
there is no need to maintain
On 4/1/20 3:14 AM, Pekka Paalanen wrote:
On Tue, 31 Mar 2020 20:59:39 -0500
Daniel Dadap wrote:
On 3/30/20 10:11 AM, Jani Nikula wrote:
On Fri, 27 Mar 2020, Daniel Dadap wrote:
A number of hybrid GPU notebook computer designs with dual (integrated
plus discrete) GPUs are equipped with
Switch over to GEM VRAM's implementation to retrieve bo->offset.
Signed-off-by: Nirmoy Das
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/bochs/bochs_kms.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
Fix 2 parenthesis alignment issues.
Reported by checkpatch.
Signed-off-by: John B. Wyatt IV
---
drivers/staging/android/ion/ion_page_pool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/ion/ion_page_pool.c
Define interconnects for display driver for
sc7180 target.
Signed-off-by: Krishna Manikandan
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index ea1b0cd..31fed6d 100644
Calculate GPU offset in radeon_bo_gpu_offset without depending on
bo->offset.
Signed-off-by: Nirmoy Das
Reviewed-and-tested-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/drm/radeon/radeon_object.h | 16 +++-
drivers/gpu/drm/radeon/radeon_ttm.c
On 3/18/20 11:45 AM, Lukasz Luba wrote:
The Energy Model framework supports both: CPUs and devfreq devices. Drop
the CPU specific interface with cpumask and add struct device. Add also a
return value. This new interface provides easy way to create a simple
Energy Model, which then might be
Hello Maxime,
Since Linus' merge window is now open, do I have to do anything to get
this merged into the mainline kernel?
On 2/20/20 7:25 PM, Maxime Ripard wrote:
On Wed, Feb 19, 2020 at 08:08:58PM +0200, Andrey Lebedev wrote:
From: Andrey Lebedev
A20 SoC (found in Cubieboard 2 among
Move the bus clock to mdp device node,in order
to facilitate bus band width scaling on sc7180
target.
The parent device MDSS will not vote for bus bw,
instead the vote will be triggered by mdp device
node. Since a minimum vote is required to turn
on bus clock, move the clock node to mdp device
On Wed, Apr 01, 2020 at 04:13:51PM +0200, Hans Verkuil wrote:
> On 4/1/20 4:05 PM, Sakari Ailus wrote:
> > Add a printk modifier %ppf (for pixel format) for printing V4L2 and DRM
> > pixel formats denoted by 4ccs. The 4cc encoding is the same for both so
> > the same implementation can be used.
Store ttm bo->offset in struct nouveau_bo instead.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv50/base507c.c |
On 2020-03-31 21:30, Doug Anderson wrote:
Hi,
On Tue, Mar 31, 2020 at 6:58 AM Kalyan Thota
wrote:
"The PM core always increments the runtime usage counter
before calling the ->suspend() callback and decrements it
after calling the ->resume() callback"
DPU and DSI are managed as runtime
This patch removes slot->gpu_offset which is not required as
VRAM and PRIV slot are in separate PCI bar.
This patch also removes unused qxl_bo_gpu_offset()
Signed-off-by: Nirmoy Das
Acked-by: Christian König
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h| 6 ++
Calculate GEM VRAM bo's offset within vram-helper without depending on
bo->offset.
Signed-off-by: Nirmoy Das
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_vram_helper.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git
GPU address handling is device specific and should be handle by its device
driver.
Signed-off-by: Nirmoy Das
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 7 ---
include/drm/ttm/ttm_bo_api.h| 2 --
include/drm/ttm/ttm_bo_driver.h | 1 -
3 files changed, 10
Am 01.04.20 um 20:42 schrieb Nirmoy Das:
Store ttm bo->offset in struct nouveau_bo instead.
Signed-off-by: Nirmoy Das
Acked-by: Christian König
It would indeed be better if one of the nouveau maintainer could take a
look since this is the last driver blocking this change.
On the other
On Thu, 02 Apr 2020, Pankaj Bharadiya
wrote:
> Now we have new struct drm_device based drm_WARN* macros. These are
> preferred over the regular WARN* macros.
>
> Remove WARN_ON and WARN_ON_ONCE overriedes to avoid any temptations to
> use them in the future.
Well, since they are overrides of
Now we have new struct drm_device based drm_WARN* macros. These are
preferred over the regular WARN* macros.
Remove WARN_ON and WARN_ON_ONCE overriedes to avoid any temptations to
use them in the future.
Suggested-by: Jani Nikula
Signed-off-by: Pankaj Bharadiya
---
77 matches
Mail list logo
