https://bugs.freedesktop.org/show_bug.cgi?id=109499
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=109923
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110405
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=108890
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=106527
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=103887
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=108034
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=100109
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=108882
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=102491
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=107266
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=97220
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=97548
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=97221
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=96906
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=109978
Martin Peres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=107898
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|REOPENED
https://bugs.freedesktop.org/show_bug.cgi?id=111877
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=111881
Martin Peres changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=106571
Martin Peres changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
On 11/18/19 1:46 AM, Jan Kara wrote:
> On Thu 14-11-19 21:53:18, John Hubbard wrote:
>> There are four locations in gup.c that have a fair amount of code
>> duplication. This means that changing one requires making the same
>> changes in four places, not to mention reading the same code four
>> tim
On Mon, Nov 18, 2019 at 11:02:32PM +0300, Dmitry Osipenko wrote:
> Add initial interconnect nodes that allow display controller driver
> to perform memory bandwidth requests using interconnect API.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/memory/tegra/tegra20.c | 14 ++
> 1
On Mon, Nov 18, 2019 at 11:02:30PM +0300, Dmitry Osipenko wrote:
[...]
> diff --git a/include/soc/tegra/mc.h b/include/soc/tegra/mc.h
> index 1238e35653d1..593954324259 100644
> --- a/include/soc/tegra/mc.h
> +++ b/include/soc/tegra/mc.h
> @@ -141,6 +141,11 @@ struct tegra_mc_reset_ops {
>
On Mon, Nov 18, 2019 at 11:02:30PM +0300, Dmitry Osipenko wrote:
> All NVIDIA Tegra SoCs have identical topology in regards to memory
> interconnection between memory clients and memory controllers.
> The memory controller (MC) and external memory controller (EMC) are
> providing memory clients wit
On Mon, Nov 18, 2019 at 11:02:29PM +0300, Dmitry Osipenko wrote:
> Add interconnect properties to the memory controller, external memory
> controller and the display controller nodes to describe interconnection
> of these nodes.
>
> Signed-off-by: Dmitry Osipenko
> ---
> arch/arm/boot/dts/tegra1
On Mon, Nov 18, 2019 at 11:02:26PM +0300, Dmitry Osipenko wrote:
> Define interconnect IDs for memory controller (MC), external memory
> controller (EMC), external memory (EMEM) and memory clients of display
> controllers (DC).
>
> Signed-off-by: Dmitry Osipenko
> ---
> include/dt-bindings/inter
On Mon, Nov 18, 2019 at 11:02:20PM +0300, Dmitry Osipenko wrote:
> External memory controller is interconnected with memory controller and
> with external memory. Document new interconnect property which designates
> external memory controller as interconnect provider.
>
> Signed-off-by: Dmitry Os
On Mon, Nov 18, 2019 at 11:02:18PM +0300, Dmitry Osipenko wrote:
> Hello,
>
I like this, thanks for looking into this.
> This series brings initial support for memory interconnect to Tegra20,
> Terga30 and Tegra124 SoCs. The interconnect provides are quite generic
> and should be suitable for al
On 19/11/2019 01:05, Tony Lindgren wrote:
* Sebastian Reichel [191117 07:11]:
We can simply use the atomic helper for
handling the dirtyfb callback.
...
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
-void omap_crtc_flush(struct drm_crtc *crtc)
+static voi
On 11/18/19 2:16 AM, Jan Kara wrote:
> On Thu 14-11-19 21:53:26, John Hubbard wrote:
>> /*
>> - * NOTE on FOLL_LONGTERM:
>> + * FOLL_PIN and FOLL_LONGTERM may be used in various combinations with each
>> + * other. Here is what they mean, and how to use them:
>> *
>> * FOLL_LONGTERM indicates
https://bugs.freedesktop.org/show_bug.cgi?id=112308
--- Comment #4 from Kai-Heng Feng ---
(In reply to Alex Deucher from comment #3)
> Created attachment 145993 [details] [review]
> fix test
>
> Does this patch fix the issue?
No, the same issue persists.
--
You are receiving this mail because
On Mon, Nov 18, 2019 at 4:32 PM Stephen Boyd wrote:
>
> Quoting Rob Clark (2019-11-18 15:40:38)
> > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> > b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> > index 39a26dd63674..2af91ed7ed0c 100644
> > --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> > +++ b/
On 2019/11/18 下午11:45, Cornelia Huck wrote:
On Mon, 18 Nov 2019 18:59:23 +0800
Jason Wang wrote:
[Note: I have not looked into the reworked architecture of this *at all*
so far; just something that I noted...]
This sample driver creates mdev device that simulate virtio net device
over virtio
On 2019/11/18 下午11:17, Greg KH wrote:
On Mon, Nov 18, 2019 at 06:59:23PM +0800, Jason Wang wrote:
+static void mvnet_device_release(struct device *dev)
+{
+ dev_dbg(dev, "mvnet: released\n");
+}
We used to have documentation in the kernel source tree that said that
whenever anyone did th
On 2019/11/19 上午4:28, Jason Gunthorpe wrote:
On Mon, Nov 18, 2019 at 03:27:13PM -0500, Michael S. Tsirkin wrote:
On Mon, Nov 18, 2019 at 01:41:00PM +, Jason Gunthorpe wrote:
On Mon, Nov 18, 2019 at 06:59:21PM +0800, Jason Wang wrote:
+struct bus_type mdev_virtio_bus_type;
+
+struct mdev_v
On 2019/11/18 下午9:41, Jason Gunthorpe wrote:
On Mon, Nov 18, 2019 at 06:59:21PM +0800, Jason Wang wrote:
+struct bus_type mdev_virtio_bus_type;
+
+struct mdev_virtio_device {
+ struct mdev_device mdev;
+ const struct mdev_virtio_ops *ops;
+ u16 class_id;
+};
This seems to sha
Hi Kalyan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tegra-drm/drm/tegra/for-next]
[also build test ERROR on v5.4-rc8 next-20191118]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #239 from Shmerl ---
*llvm10 I mean
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freed
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #238 from Shmerl ---
(In reply to Tobias Frisch from comment #237)
> - linux 5.3.11-arch1-1
> - mesa 19.2.4-1
>
That's really not a good idea. You'd need 5.4 with that flip patch applied and
Mesa 20 (i.e. master) with llvm 20 if yo
Hi Kalyan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tegra-drm/drm/tegra/for-next]
[cannot apply to v5.4-rc8 next-20191118]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '-
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #237 from Tobias Frisch ---
Hardware:
- Asus ROG Crosshair VI Extreme
- AMD Ryzen 7 2700X
- Sapphire Radeon RX 5700
Software:
- linux 5.3.11-arch1-1
- mesa 19.2.4-1
I just tried to encounter some hangs again which occur relative ra
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: c749b504bf85eee2edc857c4549d83d34730113c
commit: 8d47a4e3262de5f749806245d087dc8aa5ae2253 [852/868] drm/dsc: Update
drm_dsc to reflect native 4.2.0 DSC spec
config: riscv-defconfig (attached as .config)
compiler: ri
https://bugs.freedesktop.org/show_bug.cgi?id=111659
--- Comment #8 from Brad Campbell ---
I'm running out of ideas. I assume from the complete lack of interest I'm
either putting this in the wrong place or everyone is concentrating on new
hardware.
Recap. This is happening on two separate and di
On 11/18/19 3:58 AM, Jan Kara wrote:
> On Thu 14-11-19 21:53:33, John Hubbard wrote:
>> Add tracking of pages that were pinned via FOLL_PIN.
>>
>> As mentioned in the FOLL_PIN documentation, callers who effectively set
>> FOLL_PIN are required to ultimately free such pages via put_user_page().
>> T
Hi Fabrizio,
Thank you for the patch.
On Wed, Nov 13, 2019 at 03:51:32PM +, Fabrizio Castro wrote:
> At this point in time, compatible string "thine,thc63lvdm83d" is
> backed by the lvds-codec driver, and the documentation contained
> in thine,thc63lvdm83d.txt is basically the same as the one
Hi Animesh,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on v5.4-rc8 next-20191118]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest
Hi Fabrizio,
Thank you for the patch.
On Wed, Nov 13, 2019 at 03:51:31PM +, Fabrizio Castro wrote:
> The lvds-codec driver is a generic stub for transparent LVDS
> encoders and decoders.
> It's good practice to list a device specific compatible string
s/good practice/mandatory/
> before the
Hi Fabrizio,
Thank you for the patch.
On Wed, Nov 13, 2019 at 03:51:30PM +, Fabrizio Castro wrote:
> The iwg20d comes with an LCD panel from Emerging Display
> Technologies Corporation (EDT), therefore enable what's
> required to support it.
>
> Signed-off-by: Fabrizio Castro
Acked-by: Lau
Hi Fabrizio,
Thank you for the patch.
On Wed, Nov 13, 2019 at 03:51:28PM +, Fabrizio Castro wrote:
> The DS90CF384A from TI is a transparent LVDS receiver (decoder),
> and therefore it is compatible with the lvds-codec driver and
> bindings.
>
> Document the ti,ds90cf384a compatible string w
On Mon, Nov 18, 2019 at 03:40:38PM -0800, Rob Clark wrote:
> From: Rob Clark
>
> Previously, if the freq were overriden (ie. via sysfs), it would get
> reset to max on resume.
Devfreq goes to sleep assuming that the hardware will still be at the same
frequency when it wakes up but the GMU sneaks
Hi Fabrizio,
Thank you for the patch.
On Wed, Nov 13, 2019 at 03:51:29PM +, Fabrizio Castro wrote:
> The iwg20d comes with a 7" capacitive touch screen, therefore
> add support for it.
>
> Signed-off-by: Fabrizio Castro
Acked-by: Laurent Pinchart
I expect Geert to pick this up.
> ---
>
Hi Fabrizio,
Thank you for the patch.
On Wed, Nov 13, 2019 at 03:51:27PM +, Fabrizio Castro wrote:
> In an effort to repurpose lvds-encoder.c to also serve the
> function of LVDS decoders, we ended up defining a new "generic"
> compatible string ("lvds-decoder"), therefore adapt the dt schema
Hi Fabrizio,
Thank you for the patch.
On Wed, Nov 13, 2019 at 03:51:26PM +, Fabrizio Castro wrote:
> The probe function needs to get ahold of the panel device tree
> node, and it achieves that by using a combination of
> of_graph_get_port_by_id, of_get_child_by_name, and
> of_graph_get_remote
Hi Fabrizio,
Thank you for the patch.
On Wed, Nov 13, 2019 at 03:51:25PM +, Fabrizio Castro wrote:
> Add support for transparent LVDS decoders by adding a new
> compatible string ("lvds-decoder") to the driver.
> This patch also adds member connector_type to struct lvds_codec,
> and that's be
Hi Fabrizio,
Thank you for the patch.
On Wed, Nov 13, 2019 at 03:51:24PM +, Fabrizio Castro wrote:
> lvds-encoder.c implementation is also suitable for LVDS decoders,
> not just LVDS encoders.
> Instead of creating a new driver for addressing support for
> transparent LVDS decoders, repurpose
Hi Fabrizio,
Thank you for the patch.
On Wed, Nov 13, 2019 at 03:51:23PM +, Fabrizio Castro wrote:
> Compatible string "ti,sn75lvds83" is being used by device tree
> rk3188-bqedison2qc.dts, but it's not documented anywhere, therefore
> document it within lvds-transmitter.yaml.
>
> Signed-off
Hi Fabrizio,
Thank you for the patch.
On Wed, Nov 13, 2019 at 03:51:22PM +, Fabrizio Castro wrote:
> ti,ds90c185.txt documents LVDS encoders using the same driver
> as the one documented by lvds-transmitter.yaml.
> Since the properties listed in ti,ds90c185.txt are the same
> as the ones list
Hi Fabrizio,
Thank you for the patch.
On Wed, Nov 13, 2019 at 03:51:21PM +, Fabrizio Castro wrote:
> Add documentation for property powerdown-gpios. The property is
> optional.
>
> Signed-off-by: Fabrizio Castro
Reviewed-by: Laurent Pinchart
> ---
> v3->v4:
> * New patch
> ---
> .../dev
Hi Fabrizio,
Thank you for the patch.
On Wed, Nov 13, 2019 at 03:51:20PM +, Fabrizio Castro wrote:
> Convert the lvds-transmitter binding to DT schema format using
> json-schema.
>
> Signed-off-by: Fabrizio Castro
Reviewed-by: Laurent Pinchart
> ---
> v3->v4:
> * Fixed the description of
From: Rob Clark
Previously, if the freq were overriden (ie. via sysfs), it would get
reset to max on resume.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 8 ++--
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 3 +++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --
On Wed, Nov 13, 2019 at 03:51:32PM +, Fabrizio Castro wrote:
> At this point in time, compatible string "thine,thc63lvdm83d" is
> backed by the lvds-codec driver, and the documentation contained
> in thine,thc63lvdm83d.txt is basically the same as the one
> contained in lvds-codec.yaml (generic
On Wed, 13 Nov 2019 15:51:28 +, Fabrizio Castro wrote:
> The DS90CF384A from TI is a transparent LVDS receiver (decoder),
> and therefore it is compatible with the lvds-codec driver and
> bindings.
>
> Document the ti,ds90cf384a compatible string with the dt-bindings.
> No driver change requir
On Wed, 13 Nov 2019 15:51:27 +, Fabrizio Castro wrote:
> In an effort to repurpose lvds-encoder.c to also serve the
> function of LVDS decoders, we ended up defining a new "generic"
> compatible string ("lvds-decoder"), therefore adapt the dt schema
> to allow for the new compatible string.
>
On Wed, 13 Nov 2019 15:51:23 +, Fabrizio Castro wrote:
> Compatible string "ti,sn75lvds83" is being used by device tree
> rk3188-bqedison2qc.dts, but it's not documented anywhere, therefore
> document it within lvds-transmitter.yaml.
>
> Signed-off-by: Fabrizio Castro
>
> ---
> v3->v4:
> * N
On Wed, 13 Nov 2019 15:51:22 +, Fabrizio Castro wrote:
> ti,ds90c185.txt documents LVDS encoders using the same driver
> as the one documented by lvds-transmitter.yaml.
> Since the properties listed in ti,ds90c185.txt are the same
> as the ones listed in lvds-transmitter.yaml, absorb the dt-bin
On Wed, 13 Nov 2019 15:51:21 +, Fabrizio Castro wrote:
> Add documentation for property powerdown-gpios. The property is
> optional.
>
> Signed-off-by: Fabrizio Castro
>
> ---
> v3->v4:
> * New patch
> ---
> .../devicetree/bindings/display/bridge/lvds-transmitter.yaml | 5
> +
>
On Wed, 13 Nov 2019 15:51:20 +, Fabrizio Castro wrote:
> Convert the lvds-transmitter binding to DT schema format using
> json-schema.
>
> Signed-off-by: Fabrizio Castro
>
> ---
> v3->v4:
> * Fixed the description of property "compatible" according to Laurent's
> comments
> v2->v3:
> * Ext
On Mon, Nov 18, 2019 at 09:03:20PM +0100, Daniel Vetter wrote:
> On Mon, Nov 18, 2019 at 8:24 PM Sean Paul wrote:
> > On Fri, Nov 15, 2019 at 01:52:53PM +0200, Jani Nikula wrote:
> > > On Thu, 14 Nov 2019, Wambui Karuga wrote:
> > > > This adds a new DRM_DEV_WARN helper macro for warnings log out
On 11/18/19 3:23 PM, John Stultz wrote:
> Just wanted to resend v16 with a few minor changes.
>
> This patchset implements per-heap devices which can be opened
> directly and then an ioctl is used to allocate a dmabuf from the
> heap.
>
> The interface is similar, but much simpler then IONs, only
On Mon, Nov 18, 2019 at 01:41:00PM +, Jason Gunthorpe wrote:
> On Mon, Nov 18, 2019 at 06:59:21PM +0800, Jason Wang wrote:
> > +struct bus_type mdev_virtio_bus_type;
> > +
> > +struct mdev_virtio_device {
> > + struct mdev_device mdev;
> > + const struct mdev_virtio_ops *ops;
> > + u16 cl
Applied. Thanks!
Alex
On Mon, Nov 18, 2019 at 3:15 AM Quan, Evan wrote:
>
> Reviewed-by: Evan Quan
>
> > -Original Message-
> > From: Chen Wandun
> > Sent: Monday, November 18, 2019 4:04 PM
> > To: Quan, Evan ; Deucher, Alexander
> > ; amd-...@lists.freedesktop.org; linux-
> > ker...@
Add generic helper dmabuf ops for dma heaps, so we can reduce
the amount of duplicative code for the exported dmabufs.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
C
Add very trivial allocation and import test for dma-heaps,
utilizing the vgem driver as a test importer.
A good chunk of this code taken from:
tools/testing/selftests/android/ion/ionmap_test.c
Originally by Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Just wanted to resend v16 with a few minor changes.
This patchset implements per-heap devices which can be opened
directly and then an ioctl is used to allocate a dmabuf from the
heap.
The interface is similar, but much simpler then IONs, only
providing an ALLOC ioctl.
Also, I've provided relati
From: "Andrew F. Davis"
This framework allows a unified userspace interface for dma-buf
exporters, allowing userland to allocate specific types of memory
for use in dma-buf sharing.
Each heap is given its own device node, which a user can allocate
a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
This patch adds system heap to the dma-buf heaps framework.
This allows applications to get a page-allocator backed dma-buf
for non-contiguous memory.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin Cr
This adds a CMA heap, which allows userspace to allocate
a dma-buf of contiguous memory out of a CMA region.
This code is an evolution of the Android ION implementation, so
thanks to its original author and maintainters:
Benjamin Gaignard, Laura Abbott, and others!
NOTE: This patch only adds th
https://bugs.freedesktop.org/show_bug.cgi?id=112303
--- Comment #2 from Icy_Thought ---
(In reply to Alex Deucher from comment #1)
> Does it work with kernel 5.4? There were several fixes for resume that were
> added (which will be making their way back to stable kernels).
Can't answer this que
Am 18.11.19 um 18:52 schrieb Andrey Grodzovsky:
Problem:
Due to a race between drm_sched_cleanup_jobs in sched thread and
drm_sched_job_timedout in timeout work there is a possiblity that
bad job was already freed while still being accessed from the
timeout thread.
Fix:
Instead of just peeking a
On Mon, Nov 18, 2019 at 8:24 PM Sean Paul wrote:
> On Fri, Nov 15, 2019 at 01:52:53PM +0200, Jani Nikula wrote:
> > On Thu, 14 Nov 2019, Wambui Karuga wrote:
> > > This adds a new DRM_DEV_WARN helper macro for warnings log output that
> > > include
> > > device pointers. It also includes the use
On Fri, Nov 15, 2019 at 01:52:53PM +0200, Jani Nikula wrote:
> On Thu, 14 Nov 2019, Wambui Karuga wrote:
> > This adds a new DRM_DEV_WARN helper macro for warnings log output that
> > include
> > device pointers. It also includes the use of the DRM_DEV_WARN macro in
> > drm/rockchip to replace de
During phy compliance auto test mode source need to read
requested test pattern from sink through DPCD. After processing
the request source need to set the pattern. So set/get method
added in drm layer as it is DP protocol.
v1: As per review feedback from Manasi on RFC version,
- added dp revision
Problem:
Due to a race between drm_sched_cleanup_jobs in sched thread and
drm_sched_job_timedout in timeout work there is a possiblity that
bad job was already freed while still being accessed from the
timeout thread.
Fix:
Instead of just peeking at the bad job in the mirror list
remove it from th
Applied. Thanks!
Alex
On Mon, Nov 18, 2019 at 1:56 AM Quan, Evan wrote:
>
> Reviewed-by: Evan Quan
>
> -Original Message-
> From: Colin King
> Sent: Friday, November 15, 2019 5:48 PM
> To: Rex Zhu ; Quan, Evan ; Deucher,
> Alexander ; Koenig, Christian
> ; Zhou, David(ChunMing) ;
>
On Mon, Nov 18, 2019 at 3:37 AM Frederick Lawler wrote:
>
> Commit 8c0d3a02c130 ("PCI: Add accessors for PCI Express Capability")
> added accessors for the PCI Express Capability so that drivers didn't
> need to be aware of differences between v1 and v2 of the PCI
> Express Capability.
>
> Replace
On Mon, Nov 18, 2019 at 6:25 PM Thomas Hellstrom wrote:
>
> On Mon, 2019-11-18 at 11:35 +0100, Daniel Vetter wrote:
> > No need for stubs, dma-buf.c takes care of that.
> >
> > Aside, not having a ->release callback smelled like refcounting leak
> > somewhere. It will also score you a WARN_ON back
Currently when setting a frequency in panfrost_devfreq_target the
returned frequency is the actual frequency that the clock driver reports
(the return of clk_get_rate()). However, where the provided OPPs don't
precisely match the frequencies that the clock actually achieves devfreq
will then compla
Applied. thanks!
Alex
On Mon, Nov 18, 2019 at 10:07 AM zhengbin wrote:
>
> Fixes coccicheck warning:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c:64:13-31: WARNING: dma_alloc_coherent
> use in ih -> ring already zeroes out memory, so memset is not needed
>
> Reported-by: Hulk Robot
> Signed-of
On Mon, 2019-11-18 at 11:35 +0100, Daniel Vetter wrote:
> No need for stubs, dma-buf.c takes care of that.
>
> Aside, not having a ->release callback smelled like refcounting leak
> somewhere. It will also score you a WARN_ON backtrace in dma-buf.c on
> every export. But then I found that ttm_devi
On Sun, Nov 17, 2019 at 6:54 PM Sam Bobroff wrote:
>
> A couple of notes:
> - Initial discussion:
> https://lists.freedesktop.org/archives/dri-devel/2019-November/244090.html
> - I have only tested the case that uses r600_irq_init(), but they are all very
> similar.
>
> Cheers,
> Sam.
>
> Patc
Applied the series. Thanks!
Alex
On Fri, Nov 15, 2019 at 9:56 AM zhengbin wrote:
>
> zhengbin (6):
> drm/radeon: remove set but not used variable 'size','relocs_chunk'
> drm/radeon: remove set but not used variable 'backbias_response_time'
> drm/radeon: remove set but not used variable 'd
On Mon, Nov 18, 2019 at 3:44 AM Kalyan Thota wrote:
>
> Add changes to setup display datapath on SC7180 target
>
> changes in v1:
> 1) add changes to support ctl_active on SC7180 target
> 2) while selecting the number of mixers in the topology
> consider the interface width.
>
> This patch has dep
On Mon, Nov 18, 2019 at 11:40:26AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > > > Is any move buffer good enough to trigger this, i.e. will SYSTEM ->
> > > > > VRAM
> > > > > work too? That'll be easier because all I need to do is map the
> > > > > buffer
> > > > > to a crtc to force pinning t
dma-buf implementation. Also, the patch set will start to compile
once linux-next is open for 5.6.
Cheers, Daniel
>
> url:
> https://github.com/0day-ci/linux/commits/Daniel-Vetter/Retire-dma_buf_k-un-map/20191118-184537
> base: git://anongit.freedesktop.org/drm-intel for-linu
https://bugs.freedesktop.org/show_bug.cgi?id=112308
--- Comment #3 from Alex Deucher ---
Created attachment 145993
--> https://bugs.freedesktop.org/attachment.cgi?id=145993&action=edit
fix test
Does this patch fix the issue?
--
You are receiving this mail because:
You are the assignee for th
On Sun, Nov 17, 2019 at 06:48:23AM -0500, Brian Masney wrote:
> Some A3xx and all A4xx Adreno GPUs do not have GMEM inside the GPU core
> and must use the On Chip MEMory (OCMEM) in order to be functional.
> There's a separate interconnect path that needs to be setup to OCMEM.
> Add support for this
Hello Daniel,
On Mon, 18 Nov 2019 at 16:05, Daniel Vetter wrote:
>
> Hi all,
>
> Way back when we created the dma-buf spec it made sense to have kmap/unmap
> interfaces, since 32bit kernels with limited vmalloc space were still
> rather ubiquitous. But that idea (like many others) never caught on
Instead of only setting mode->specified on false on an early exit and
leaving e.g. mode->bpp_specified and mode->refresh_specified as is,
lets be consistent and just zero out the entire passed in struct at
the top of drm_mode_parse_command_line_for_connector()
Changes in v3:
-Drop "mode->specified
If the new video=... panel_orientation option is set for a connector, honor
it and setup a matching "panel orientation" property on the connector.
BugLink: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83
Acked-by: Maxime Ripard
Signed-off-by: Hans de Goede
---
drivers/gpu/drm
Sometimes we want to override a connector's panel_orientation from the
kernel commandline. Either for testing and for special cases, e.g. a kiosk
like setup which uses a TV mounted in portrait mode.
Users can already specify a "rotate" option through a video= kernel cmdline
option. But that only s
1 - 100 of 205 matches
Mail list logo
