We need to set vop config done after update line flag config, it's a
new requirement for chips newer than rk3368.
Since we would only use line flag irq for vact_end, let's move it to
vop_crtc_enable.
Signed-off-by: Jeffy Chen
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 4 ++--
driv
Hi,
> > That is done using the RADEON_TILING_SWAP_{16,32}BIT flag mentioned in
> > another thread?
>
> Right.
>
>
> > What about dumb bos? You've mentioned the swap flag isn't used for
> > those. Which implies they are in little endian byte order (both gpu and
> > cpu view).
>
> Right, AFA
https://bugs.freedesktop.org/show_bug.cgi?id=100785
--- Comment #12 from Hi-Angel ---
(EDIT: replaced tabs with space in the table)
So, actually there're 4 different combinations:
| usual run | nosb |
HEAD | fails | passes|
HEAD eb8aa93c03 rever
https://bugs.freedesktop.org/show_bug.cgi?id=100785
--- Comment #11 from Hi-Angel ---
So, actually there're 4 different combinations:
| usual run | nosb |
HEAD | fails | passes|
HEAD eb8aa93c03 reverted |
https://bugs.freedesktop.org/show_bug.cgi?id=100785
--- Comment #10 from Hi-Angel ---
Not sure why, but I can't get it passing with "nosb" anymore :(
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
d
https://bugs.freedesktop.org/show_bug.cgi?id=100785
--- Comment #9 from Hi-Angel ---
Hmm, wait. Now for some reason it fails with nosb also.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@
https://bugs.freedesktop.org/show_bug.cgi?id=100785
--- Comment #8 from Hi-Angel ---
Created attachment 131063
--> https://bugs.freedesktop.org/attachment.cgi?id=131063&action=edit
ps,vs,nosb dump HEAD with reverted eb8aa93c03
--
You are receiving this mail because:
You are the assignee for t
https://bugs.freedesktop.org/show_bug.cgi?id=100785
--- Comment #7 from Hi-Angel ---
Created attachment 131062
--> https://bugs.freedesktop.org/attachment.cgi?id=131062&action=edit
ps,vs,nosb dump HEAD
--
You are receiving this mail because:
You are the assignee for the bug.__
Hi, Jose Abreu:
Thanks for your patch, it works fine on RK3399 / RK3368。
在 2017年04月26日 19:04, Jose Abreu 写道:
Hi,
On 24-04-2017 08:46, 郑阳 wrote:
Hi, Laurent Pinchart:
在 2017年03月04日 01:20, Laurent Pinchart 写道:
From: Kieran Bingham
The DWC HDMI TX controller interfaces with a companion PHY.
On 04/26/2017 12:36 AM, Wei Yongjun wrote:
From: Wei Yongjun
The error return code PTR_ERR(mc) is always 0 since mc is
equal to 0 in this error handling case.
Thank you! I've merged the patch in my tree.
Ben.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm2
On 26/04/17 09:11 PM, Gerd Hoffmann wrote:
> Hi,
>
Just to reiterate, this won't work for the radeon driver, which programs
the GPU to use (effectively, per the current definition that these are
little endian GPU formats) DRM_FORMAT_XRGB with pre-R600 and
DRM_FORMAT_BGRX8
Now that we have a callback to check if crtc supports a given mode
we can use it in arcpgu so that we restrict the number of probbed
modes to the ones we can actually display.
This is specially useful because arcpgu crtc is responsible to set
a clock value in the commit() stage but unfortunatelly
On Tue, Apr 25, 2017 at 12:20:49PM -0600, Logan Gunthorpe wrote:
> This is a prep patch to add a new error code to libiscsi. We want to
> rework some kmap calls to be able to fail. When we do, we'd like to
> use this error code.
The kmap case in iscsi_tcp_segment_map can already fail. Please add
On 26/04/17 02:59 AM, wrote:
> Good to know that somebody is working on this. Those problems troubled
> us as well.
Thanks Christian. It's a daunting problem and a there's a lot of work to
do before we will ever be where we need to be so any help, even an ack,
is greatly appreciated.
Logan
_
On Tue 25-04-17 21:03:32, Chris Wilson wrote:
> On Tue, Apr 25, 2017 at 06:41:20PM +0200, Michal Hocko wrote:
> > Hi,
> > I have just experienced X being shut down once with 4.11-rc2 and 2 times
> > with 4.11-rc6 kernel. I do not remember seeing something like this
> > before but it is quite possi
On Mon, 2017-04-24 at 15:48 +0300, Ville Syrjälä wrote:
>
> > I've a patch for iio-sensor-proxy which fixes the rotation under
> > Xorg /
> > Wayland when using a desktop environment which honors iio-sensor-
> > proxy's
> > rotation detection:
> > https://github.com/hadess/iio-sensor-proxy/pull/
Some crtc's may have restrictions in the mode they can display. In
this patch a new callback (crtc->mode_valid()) is introduced that
is called at the same stage of connector->mode_valid() callback.
This shall be implemented if the crtc has some sort of restriction
so that we don't probe modes that
On Sun, 2017-04-23 at 18:11 +0200, Hans de Goede wrote:
> From: Ville Syrjala
>
> If a connector added through drm_fb_helper_add_one_connector() has
> a crtc attached and that crtc has a rotation configured make the
> fbdev inherit the crtc's rotation.
>
> This is useful on e.g. some tablets whi
On Wed, Apr 26, 2017 at 2:50 PM, Maxime Ripard
wrote:
> Hi Chen-Yu,
>
> On Fri, Apr 21, 2017 at 11:17:17PM +0800, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard
>> wrote:
>> > The earlier Allwinner SoCs (A10, A10s, A20, A31) have an embedded HDMI
>> > controller.
>
On Sun, 2017-04-23 at 18:11 +0200, Hans de Goede wrote:
> From: Ville Syrjala
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 344f238..63623dd 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -418,6 +418,7 @
On Tue, 2017-04-25 at 09:51 +0200, Maarten Lankhorst wrote:
> On 21-04-17 07:51, Dhinakaran Pandiyan wrote:
> > From: "Pandiyan, Dhinakaran"
> >
> > Use the added helpers to track MST link bandwidth for atomic modesets.
> > Link bw is acquired in the ->atomic_check() phase when CRTCs are being
> >
Le mercredi 26 avril 2017 à 18:52 +0200, Tobias Jakobi a écrit :
> Hello again,
>
>
> Nicolas Dufresne wrote:
> > Le mercredi 26 avril 2017 à 01:21 +0300, Sakari Ailus a écrit :
> > > Hi Marek,
> > >
> > > On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski wrote:
> > > > Hi Laurent,
> >
On 26/04/17 01:44 AM, Christoph Hellwig wrote:
> I think we'll at least need a draft of those to make sense of these
> patches. Otherwise they just look very clumsy.
Ok, I'll work up a draft proposal and send it in a couple days. But
without a lot of cleanup such as this series it's not going t
Le mercredi 26 avril 2017 à 01:21 +0300, Sakari Ailus a écrit :
> Hi Marek,
>
> On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski wrote:
> > Hi Laurent,
> >
> > On 2017-04-20 12:25, Laurent Pinchart wrote:
> > > Hi Marek,
> > >
> > > (CC'ing Sakari Ailus)
> > >
> > > Thank you for the
Le mercredi 26 avril 2017 à 21:31 +0200, Tobias Jakobi a écrit :
> I'm pretty sure you have misread Marek's description of the patchset.
> The picture processor API should replaced/deprecate the IPP API that is
> currently implemented in the Exynos DRM.
>
> In particular this affects the following
Hi,
On 24-04-2017 08:46, 郑阳 wrote:
> Hi, Laurent Pinchart:
>
> 在 2017年03月04日 01:20, Laurent Pinchart 写道:
>> From: Kieran Bingham
>>
>> The DWC HDMI TX controller interfaces with a companion PHY. While
>> Synopsys provides multiple standard PHYs, SoC vendors can also
>> integrate
>> a custom PHY.
On Tue, Apr 25, 2017 at 12:21:02PM -0600, Logan Gunthorpe wrote:
> Straightforward conversion to the new helper, except due to the lack
> of error path, we have to use SG_MAP_MUST_NOT_FAIL which may BUG_ON in
> certain cases in the future.
>
> Signed-off-by: Logan Gunthorpe
> Cc: Boris Ostrovsky
This patchset introduces a new callback for crtc, called mode_valid()
that is responsible to limit the number of probbed modes. Just like
connector->mode_valid(), this new callback is called at mode probbing
stage so that we can validate the mode.
This is specially useful because arcpgu crtc is re
On Tue, Apr 25, 2017 at 12:20:48PM -0600, Logan Gunthorpe wrote:
> This patch introduces functions which kmap the pages inside an sgl.
> These functions replace a common pattern of kmap(sg_page(sg)) that is
> used in more than 50 places within the kernel.
>
> The motivation for this work is to eve
This adds support for enabling automatic clockgating on nvidia GPUs for
Fermi and later generations. This saves a little bit of power, bringing
my fermi GPU's power consumption from ~28.3W on idle to ~27W, and my
kepler's idle power consumption from ~23.6W to ~21.65W.
Similar to how the nvidia dri
https://bugs.freedesktop.org/show_bug.cgi?id=93826
--- Comment #45 from DesiOtaku ---
I can confirm this bug also affects A12-9800E APU when you use the integrated
graphic card's port.
--
You are receiving this mail because:
You are the assignee for the bug._
This adds support for enabling automatic clockgating on nvidia GPUs for
Fermi and later generations. This saves a little bit of power, bringing
my fermi GPU's power consumption from ~28.3W on idle to ~27W, and my
kepler's idle power consumption from ~23.6W to ~21.65W.
Similar to how the nvidia dri
https://bugs.freedesktop.org/show_bug.cgi?id=100785
--- Comment #6 from Timothy Arceri ---
Thanks. Looks like a bug in sb optimisations so the output of
R600_DEBUG=vs,ps,nosb on HEAD would also be useful.
--
You are receiving this mail because:
You are the assignee for the bug.
The existing drm_gem_prime_import function uses the underlying
struct device of a drm_device for attaching to a dma_buf. Some drivers
(notably vgem) may not have an underlying device structure. Offer
an alternate function to attach using a platform device associated
with drm_device.
Signed-off-by:
Enable the GEM dma-buf import interfaces in addition to the export
interfaces. This lets vgem be used as a test source for other allocators
(e.g. Ion).
Signed-off-by: Laura Abbott
---
v2: Don't require vgem allocated buffers to existing in memory before importing.
---
drivers/gpu/drm/vgem/vgem_d
The vgem driver is currently registered independent of any actual
device. Some usage of the dmabuf APIs require an actual device structure
to do anything. Register a dummy platform device for use with dmabuf.
Signed-off-by: Laura Abbott
---
v2: Store the platform device in the platformdev field i
Hi,
This is v2 of my proposal to add dma_buf import functions for vgem.
Big changes from v1:
- A device is required for dma_buf attach to work. The existing vgem driver
intentionally does not use one as it provides a good way to test the DRM
framework. This approach instead puts a dummy platform
On Sun, Apr 23, 2017 at 7:33 PM, Mario Kleiner
wrote:
> At dot clocks > approx. 250 Mhz, some of these calcs will overflow and
> cause miscalculation of latency watermarks, and for some overflows also
> divide-by-zero driver crash. Make calcs more overflow resistant.
>
> This is a direct port of t
On Sun, Apr 23, 2017 at 7:02 PM, Mario Kleiner
wrote:
> This apparently got lost when implementing the new DCE-6 support
> and would cause failures in pageflip scheduling and timestamping.
>
> Signed-off-by: Mario Kleiner
> Cc: Alex Deucher
> Cc: sta...@vger.kernel.org
Applied. thanks!
Alex
https://bugs.freedesktop.org/show_bug.cgi?id=100802
Bug ID: 100802
Summary: [regression] mostly blank graphics on Faeria
Product: Mesa
Version: 17.0
Hardware: Other
OS: All
Status: NEW
Severity: normal
On Wed, Apr 26, 2017 at 10:43:31PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 12, 2017 at 10:55:29AM +0800, Jeffy Chen wrote:
> > After unbinding drm, the user space may still owns the drm dev fd, and
> > may still be able to call drm ioctl.
> >
> > We're using an unplugged state to prevent somethi
https://bugs.freedesktop.org/show_bug.cgi?id=100800
--- Comment #1 from Alex Deucher ---
Please attach your xorg log and dmesg output.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.
On Wed, Apr 12, 2017 at 10:55:29AM +0800, Jeffy Chen wrote:
> After unbinding drm, the user space may still owns the drm dev fd, and
> may still be able to call drm ioctl.
>
> We're using an unplugged state to prevent something like that, so let's
> reuse it here.
>
> Also drop drm_unplug_dev, be
Hey,
Nicolas Dufresne wrote:
> Le mercredi 26 avril 2017 à 18:52 +0200, Tobias Jakobi a écrit :
>> Hello again,
>>
>>
>> Nicolas Dufresne wrote:
>>> Le mercredi 26 avril 2017 à 01:21 +0300, Sakari Ailus a écrit :
Hi Marek,
On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski w
On Wed, 2017-04-26 at 00:49 +0200, Karol Herbst wrote:
> Hi Lyude,
>
> thanks for the great work. Just a view comments inline.
>
> 2017-04-25 20:38 GMT+02:00 Lyude :
> > This adds support for enabling automatic clockgating on nvidia GPUs
> > for
> > Fermi and later generations. This saves a littl
On Wed, Apr 26, 2017 at 03:56:54PM +0300, Jyri Sarha wrote:
> On 04/24/17 19:55, Ville Syrjälä wrote:
> >> In fact we have plane specific YCbCr to RGB CSC (only preoffset
> >> possible), then (per crtc) gamma table, and finally a (per crtc) RGB to
> >> YCbCr CSC with optional post offset (so it can
On Tue, Apr 25, 2017 at 4:19 PM, Christian König
wrote:
> From: Christian König
>
> Most BIOS don't enable this because of compatibility reasons.
>
> Manually enable a 64bit BAR of 64GB size so that we have
> enough room for PCI devices.
> +static void pci_amd_enable_64bit_bar(struct pci_dev *de
Linus Walleij writes:
> On Mon, Apr 24, 2017 at 9:45 PM, Eric Anholt wrote:
>
>> This is required for the panel to work on bcm911360, where CLCDCLK is
>> the fixed 200Mhz AXI41 clock. The rate set is still passed up to the
>> CLCDCLK, for platforms that have a settable rate on that one.
>>
>> S
Hi Dave,
Updated pull request to fix the all-modconfig build on 32bit arm
builds.
This pull request includes the latest updates on Mali DP, adding
support for colour management, plane scaling and power management.
The patches have trickled into the mailing list since February, and
have baked on l
On Tue, Apr 25, 2017 at 4:19 PM, Christian König
wrote:
> From: Christian König
>
> This allows device drivers to request resizing their BARs.
>
> The function only tries to reprogram the windows of the bridge directly above
> the requesting device and only the BAR of the same type (usually mem,
Linus Walleij writes:
> On Mon, Apr 24, 2017 at 9:45 PM, Eric Anholt wrote:
>> +static long pl111_clk_div_round_rate(struct clk_hw *hw, unsigned long rate,
>> +unsigned long *prate)
>> +{
>> + int div = pl111_clk_div_choose_div(hw, rate, prate, true);
>
Hello again,
Nicolas Dufresne wrote:
> Le mercredi 26 avril 2017 à 01:21 +0300, Sakari Ailus a écrit :
>> Hi Marek,
>>
>> On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski wrote:
>>> Hi Laurent,
>>>
>>> On 2017-04-20 12:25, Laurent Pinchart wrote:
Hi Marek,
(CC'ing Sakari
This patch removes old code related to the old api and transforms the
functions for the new api. It also adds the .write and .read operations.
Signed-off-by: Oscar Salvador
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 722 +++-
1 file changed, 249 insertions(+), 473
This patch creates a special group attributes for attrs like "*auto_point*".
We check if we have support for them, and if we do, we gather them all in
an attribute_group's structure which is the parameter regarding special groups
of hwmon_device_register_with_info.
Signed-off-by: Oscar Salvador
-
This patch replaces the symbolic permissions with the numeric ones,
and adds me to the authors too.
Signed-off-by: Oscar Salvador
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
This patch introduces the nouveau_hwmon_ops structure, sets up
.is_visible and .read_string operations and adds all the functions
for these operations.
This is also a preparation for the next patches, where most of the
work is being done.
This code doesn't interacture with the old one.
It's just to
This is a preparation for the next patches. It just adds the sensors with
their possible configurable settings and then fills the struct
hwmon_channel_info
with all this information.
Signed-off-by: Oscar Salvador
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 72 +
This v5 drops a check for attr_set.
Versions:
v1 -> v2:
* Keep temp attrs as read only
v2 -> v3:
* Code fix-ups: struct and string as const and add return within switch
due to fallthrough
* Add Signed-off-by to all commits
v3 -> v4:
* Rever const to struct
On Tue, Apr 25, 2017 at 4:19 PM, Christian König
wrote:
> From: Christian König
>
> Just the defines and helper functions to read the possible sizes of a BAR and
> update it's size.
>
> See
> https://pcisig.com/sites/default/files/specification_documents/ECN_Resizable-BAR_24Apr2008.pdf
> and PCI
https://bugs.freedesktop.org/show_bug.cgi?id=100800
abitt...@opensuse.org changed:
What|Removed |Added
Hardware|Other |x86-64 (AMD64)
O
https://bugs.freedesktop.org/show_bug.cgi?id=100800
Bug ID: 100800
Summary: With KMS:No link with displayport and A6-3600 APU from
4.4.x to 4.11.0.rc8, unless nomodeset kernel boot
parameter
Product: DRI
Version:
On Wed, Apr 26, 2017 at 04:40:13PM +0300, Imre Deak wrote:
> plane_state can't be NULL anywhere in this function, so the NULL check
> at the end is redundant, remove it.
>
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/drm_plane_helper.c | 10 --
Hello everyone,
Nicolas Dufresne wrote:
> Le mercredi 26 avril 2017 à 01:21 +0300, Sakari Ailus a écrit :
>> Hi Marek,
>>
>> On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski wrote:
>>> Hi Laurent,
>>>
>>> On 2017-04-20 12:25, Laurent Pinchart wrote:
Hi Marek,
(CC'ing Saka
Am 26.04.2017 um 11:57 schrieb Dave Airlie:
On 26 April 2017 at 18:45, Christian König wrote:
Am 26.04.2017 um 05:28 schrieb Dave Airlie:
Okay I've gone around the sun with these a few times, and
pretty much implemented what I said last week.
This is pretty much a complete revamp.
1. sync ob
Am 26.04.2017 um 16:46 schrieb Andres Rodriguez:
When a timeout of zero is specified, the caller is only interested in
the fence status.
In the current implementation, dma_fence_default_wait will always call
schedule_timeout() at least once for an unsignaled fence. This adds a
significant overhe
When a timeout of zero is specified, the caller is only interested in
the fence status.
In the current implementation, dma_fence_default_wait will always call
schedule_timeout() at least once for an unsignaled fence. This adds a
significant overhead to a fence status query.
Avoid this overhead by
On Tue, Apr 25, 2017 at 09:56:53PM +0200, Arnd Bergmann wrote:
> On 32-bit machines, we can't divide 64-bit integers:
>
> drivers/gpu/drm/arm/malidp_crtc.o: In function `malidp_crtc_atomic_check':
> malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3c0): undefined reference to
> `__aeabi_uldivmod'
On Wed, Apr 26, 2017 at 11:00:09AM +0900, Michel Dänzer wrote:
> On 25/04/17 06:52 PM, Ville Syrjälä wrote:
> > On Tue, Apr 25, 2017 at 12:18:52PM +0900, Michel Dänzer wrote:
> >> On 24/04/17 03:25 PM, Gerd Hoffmann wrote:
> >>> +#ifdef __BIG_ENDIAN
> >>> + switch (bpp) {
> >>> + case 8:
> >>> +
On 2017-04-26 06:13 AM, Christian König wrote:
Am 26.04.2017 um 11:59 schrieb Dave Airlie:
On 26 April 2017 at 17:20, Christian König
wrote:
NAK, I'm wondering how often I have to reject that change. We should
probably add a comment here.
Even with a zero timeout we still need to enable sig
On Mon, Apr 24, 2017 at 9:45 PM, Eric Anholt wrote:
> This is required for the panel to work on bcm911360, where CLCDCLK is
> the fixed 200Mhz AXI41 clock. The rate set is still passed up to the
> CLCDCLK, for platforms that have a settable rate on that one.
>
> Signed-off-by: Eric Anholt
I li
> uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth)
> {
> uint32_t fmt;
> #ifdef __BIG_ENDIAN
> enum { LITTLE_ENDIAN = 0 };
> #else
> enum { LITTLE_ENDIAN = 1 };
> #endif
> /* ... */
>
> (using an enum for
plane_state can't be NULL anywhere in this function, so the NULL check
at the end is redundant, remove it.
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_plane_helper.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gp
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Julien Isorce (julien.iso...@gmail.com) changed:
What|Removed |Added
CC||julien.iso...@gma
https://bugzilla.kernel.org/show_bug.cgi?id=90861
Julien Isorce (julien.iso...@gmail.com) changed:
What|Removed |Added
CC||julien.iso...@gma
Regards
Shashank
On 4/26/2017 6:26 PM, Jyri Sarha wrote:
On 04/24/17 19:55, Ville Syrjälä wrote:
In fact we have plane specific YCbCr to RGB CSC (only preoffset
possible), then (per crtc) gamma table, and finally a (per crtc) RGB to
YCbCr CSC with optional post offset (so it can be used eithe
On Wednesday, 2017-04-26 07:53:10 +0200, Gerd Hoffmann wrote:
> On Di, 2017-04-25 at 12:18 +0900, Michel Dänzer wrote:
> > On 24/04/17 03:25 PM, Gerd Hoffmann wrote:
> > > Return correct fourcc codes on bigendian. Drivers must be adapted to
> > > this change.
> > >
> > > Signed-off-by: Gerd Hoffm
On 04/24/17 19:55, Ville Syrjälä wrote:
>> In fact we have plane specific YCbCr to RGB CSC (only preoffset
>> possible), then (per crtc) gamma table, and finally a (per crtc) RGB to
>> YCbCr CSC with optional post offset (so it can be used either as CSC or
>> CTM).
> So with that plane hw you could
Hi,
> >> Just to reiterate, this won't work for the radeon driver, which programs
> >> the GPU to use (effectively, per the current definition that these are
> >> little endian GPU formats) DRM_FORMAT_XRGB with pre-R600 and
> >> DRM_FORMAT_BGRX with >= R600.
> >
> > Hmm, ok, how does bi
Am 26.04.2017 um 11:59 schrieb Dave Airlie:
On 26 April 2017 at 17:20, Christian König wrote:
NAK, I'm wondering how often I have to reject that change. We should
probably add a comment here.
Even with a zero timeout we still need to enable signaling, otherwise some
fence will never signal if
On 26 April 2017 at 17:20, Christian König wrote:
> NAK, I'm wondering how often I have to reject that change. We should
> probably add a comment here.
>
> Even with a zero timeout we still need to enable signaling, otherwise some
> fence will never signal if userspace just polls on them.
>
> If a
On 26 April 2017 at 18:45, Christian König wrote:
> Am 26.04.2017 um 05:28 schrieb Dave Airlie:
>>
>> Okay I've gone around the sun with these a few times, and
>> pretty much implemented what I said last week.
>>
>> This is pretty much a complete revamp.
>>
>> 1. sync objects are self contained dr
On 26/04/17 02:53 PM, Gerd Hoffmann wrote:
> On Di, 2017-04-25 at 12:18 +0900, Michel Dänzer wrote:
>> On 24/04/17 03:25 PM, Gerd Hoffmann wrote:
>>> Return correct fourcc codes on bigendian. Drivers must be adapted to
>>> this change.
>>>
>>> Signed-off-by: Gerd Hoffmann
>>
>> Just to reiterate,
On 2017年04月26日 11:28, Dave Airlie wrote:
From: Dave Airlie
Sync objects are new toplevel drm object, that contain a
pointer to a fence. This fence can be updated via command
submission ioctls via drivers.
There is also a generic wait obj API modelled on the vulkan
wait API (with code modelle
Am 25.04.2017 um 20:20 schrieb Logan Gunthorpe:
This patch introduces functions which kmap the pages inside an sgl.
These functions replace a common pattern of kmap(sg_page(sg)) that is
used in more than 50 places within the kernel.
The motivation for this work is to eventually safely support sg
Am 26.04.2017 um 05:28 schrieb Dave Airlie:
Okay I've gone around the sun with these a few times, and
pretty much implemented what I said last week.
This is pretty much a complete revamp.
1. sync objects are self contained drm objects, they
have a file reference so can be passed between process
https://bugzilla.kernel.org/show_bug.cgi?id=195581
--- Comment #3 from Lutz Vieweg (l...@5t9.de) ---
BTW: Is there a reason why the EDID is read anew every time one uses "xrandr
--ouput ... --mode ... --rate ..." to just switch the refresh rate, and also
when switching between X11 and the text con
https://bugzilla.kernel.org/show_bug.cgi?id=195581
--- Comment #2 from Lutz Vieweg (l...@5t9.de) ---
Indeed, https://bugs.freedesktop.org/show_bug.cgi?id=100375 looks like it is
the same issue.
I cannot say whether this is a regression from an older kernel, because I only
recently put this AMD RX
https://bugs.freedesktop.org/show_bug.cgi?id=100785
--- Comment #5 from Hi-Angel ---
Created attachment 131044
--> https://bugs.freedesktop.org/attachment.cgi?id=131044&action=edit
ps,vs dump HEAD with reverted eb8aa93c03
--
You are receiving this mail because:
You are the assignee for the bu
https://bugs.freedesktop.org/show_bug.cgi?id=100785
--- Comment #4 from Hi-Angel ---
Created attachment 131043
--> https://bugs.freedesktop.org/attachment.cgi?id=131043&action=edit
ps,vs dump HEAD
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=100785
--- Comment #3 from Hi-Angel ---
(In reply to Timothy Arceri from comment #2)
> Does it work if you set:
>
> R600_DEBUG=nosb
Yeah, this way it does pass.
> Also it would be helpful if you could attach a before and after shader dump
> using.
>
On 2017年04月26日 11:28, Dave Airlie wrote:
From: Dave Airlie
This just splits out the fence depenency checking into it's
own function to make it easier to add semaphore dependencies.
Reviewed-by: Christian König
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 85 +++
NAK, I'm wondering how often I have to reject that change. We should
probably add a comment here.
Even with a zero timeout we still need to enable signaling, otherwise
some fence will never signal if userspace just polls on them.
If a caller is only interested in the fence status without enab
92 matches
Mail list logo
