--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/1ce54374/attachment.html>
L attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/853649dc/attachment-0001.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/bb4ab4c8/attachment.html>
are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/321755bf/attachment.html>
The commit [4fdbc678fe4d: drm: sti: add HQVDP plane] added the select
of CONFIG_FW_LOADER_USER_HELPER_FALLBACK by some unwritten reason.
But this config is known to be harmful, and is present only for
compatibility reason for an old exotic system that mandates udev
interaction which isn't supposed
On Wed, Oct 7, 2015 at 1:23 PM, Arnd Bergmann wrote:
> On Wednesday 07 October 2015 13:04:06 Arnd Bergmann wrote:
>> On Wednesday 07 October 2015 11:45:02 Russell King - ARM Linux wrote:
>> > On Wed, Oct 07, 2015 at 12:41:21PM +0200, Arnd Bergmann wrote:
>> > > The virtgpu driver prints the last_s
On Fri, 16 Oct 2015, Daniel Vetter wrote:
> On Fri, Oct 16, 2015 at 03:33:02AM -0700, Adam Richter wrote:
>> In Linux 4.3-rc5, there is an error case in drm_dp_get_branch_device
>> that returns without releasing mgr->lock, resulting a spew of kernel
>> messages about a kernel work function possibl
but for an industrial environment it
may not be ok.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/cdee5153/attachment.html>
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/97a2b8b9/attachment-0001.html>
ameter radeon.lockup_timeout=2 to increase
the timeout to 20 seconds.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments
On Sun, Oct 18, 2015 at 05:07:06PM +0100, Chris Wilson wrote:
> On Sun, Oct 18, 2015 at 02:07:13PM +0100, Chris Wilson wrote:
> > > I couldn't spot the difference either. I am beginning to suspect it is
> > > gcc as
> > >
> > > diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
On Fri, Oct 16, 2015 at 10:12:04PM +0200, Philipp Zabel wrote:
> From: CK Hu
>
> This patch adds an initial DRM driver for the Mediatek MT8173 DISP
> subsystem. It currently supports two fixed output streams from the
> OVL0/OVL1 sources to the DSI0/DPI0 sinks, respectively.
>
> Signed-off-by: CK
On Wed, Oct 07, 2015 at 01:23:07PM +0200, Arnd Bergmann wrote:
> > I haven't checked all architectures, but I assume what happens is that
> > 64-bit ones just #define atomic64_t atomic_long_t, so they don't have
> > to provide three sets of functions.
>
> scratch that, I just looked at all the ar
During testing we observed that the last cacheline was not being flushed
from a
mb()
for (addr = addr & -clflush_size; addr < end; addr += clflush_size)
clflushopt();
mb()
loop (where the initial addr and end were not cacheline aligned).
Changing the loop
On Monday 19 October 2015 11:37:00 Ralf Baechle wrote:
> On Wed, Oct 07, 2015 at 01:23:07PM +0200, Arnd Bergmann wrote:
>
> > > I haven't checked all architectures, but I assume what happens is that
> > > 64-bit ones just #define atomic64_t atomic_long_t, so they don't have
> > > to provide three
On Mon, Oct 19, 2015 at 10:58:55AM +0100, Chris Wilson wrote:
> During testing we observed that the last cacheline was not being flushed
> from a
>
> mb()
> for (addr = addr & -clflush_size; addr < end; addr += clflush_size)
> clflushopt();
> mb()
>
> loop (where t
On Monday 19 October 2015 09:34:15 Geert Uytterhoeven wrote:
> On Wed, Oct 7, 2015 at 1:23 PM, Arnd Bergmann wrote:
> > static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u)
> >
> > which truncates the result to 32 bit.
>
> Woops.
>
> See also my unanswered question in "atomic
t part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/a6fe7bdb/attachment.html>
t was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/9cdace2e/attachment-0001.bin>
On Mon, Oct 19, 2015 at 10:44:41AM +0100, David Woodhouse wrote:
> On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
> > On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
> > > On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> > > > On Fri, Oct 16, 2015 at 11:57:50P
On Mon, Oct 19, 2015 at 12:11 PM, Arnd Bergmann wrote:
> On Monday 19 October 2015 09:34:15 Geert Uytterhoeven wrote:
>> On Wed, Oct 7, 2015 at 1:23 PM, Arnd Bergmann wrote:
>> > static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u)
>> >
>> > which truncates the result to 32 bi
On Mon, Oct 19, 2015 at 12:16:12PM +0200, Borislav Petkov wrote:
> On Mon, Oct 19, 2015 at 10:58:55AM +0100, Chris Wilson wrote:
> > Adding a barrier() into clflushopt() is enough for GCC to dtrt, but
> > solving why GCC is not seeing the constraints from the alternative_io()
> > would be smarter..
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/7164ec0f/attachment.html>
On Mon, Oct 19, 2015 at 12:05:29PM +0100, Chris Wilson wrote:
> In order to add the clobbers, I had to adjust the macro slightly:
>
> +#define alternative_output(oldinstr, newinstr, feature, output)\
> + asm volatile (ALTERNATIVE(oldinstr, newinstr, feature) \
> +
archives/dri-devel/attachments/20151019/1ce4062c/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/be0f5fa9/attachment-0001.html>
Hi Gustavo,
Please ping~ and re-base on top of exynos-drm-next.
Thanks,
Inki Dae
2015ë
09ì 05ì¼ 05:15ì Gustavo Padovan ì´(ê°) ì´ ê¸:
> From: Gustavo Padovan
>
> Hi,
>
> This series adds proper runtime PM suport to CRTCs and Encoders, so
> now instead of relying on 'suspended' or 'ena
Dave,
could you please pick this patch up as a fix for 4.3? It fixes a
regression introduced in this cycle by the stricter parameter validation
in the DW HDMI driver. Philipp is on holiday this week, so I guess he
won't be able to pick it up.
Thanks,
Lucas
Am Donnerstag, den 15.10.2015, 15:42 +0
Hi,
How about combining patch 5 and 6?
Patch 5 just introduces new internal API but these API aren't used
anywhere in patch 5.
Thanks,
Inki Dae
2015ë
10ì 13ì¼ 16:00ì Joonyoung Shim ì´(ê°) ì´ ê¸:
> The buffer allocation using DMA mapping API can't support non-continuous
> buffer on n
The armada DRM driver keeps some old platform data compatibility in the
probe function that makes moving to the generic drm_of_component_probe()
a bit more complicated that it should. Refactor the probe function to do
the platform_data processing after the generic probe (and only if that
fails). Th
Changelog:
v2: Rebased the patchset on top of drm-next rather than Linus' latest -rc
A few drivers in drivers/gpu/drm are component-enabled and use quite similar
code sequences to probe for their encoder slaves at the remote end of the ports.
Move the code into a "generic" function and remove it f
The generic function is functionally equivalent to the driver's
imx_drm_platform_probe(). Use the generic function and reduce the
overall code size.
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/imx/imx-drm-core.c | 54 +-
1 file changed, 1 insertion(+), 53 d
A lot of component based DRM drivers use a variant of the same code
as the probe function. They bind the crtc ports in the first iteration
and then scan through the child nodes and bind the encoders attached
to the remote endpoints. Factor the common code into a separate
function called drm_of_comp
Use the generic drm_of_component_probe() function to probe for components.
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 86 ++---
1 file changed, 6 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/
On Mon, Oct 19, 2015 at 01:21:50PM +0100, Liviu Dudau wrote:
> A lot of component based DRM drivers use a variant of the same code
> as the probe function. They bind the crtc ports in the first iteration
> and then scan through the child nodes and bind the encoders attached
> to the remote endpoint
On 10/16/15 16:51, Arnaud Pouliquen wrote:
>> After reading the ELCE Audio mini conf minutes [1] I gather that HDMI
>> audio was not discussed after all.
>>
>> My conclusion from the Lars-Peter's latest mail [2] related to the
>> subject is that the wind is currently blowing slightly in favour of m
On Mon, Oct 19, 2015 at 01:25:37PM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 01:21:50PM +0100, Liviu Dudau wrote:
> > A lot of component based DRM drivers use a variant of the same code
> > as the probe function. They bind the crtc ports in the first iteration
> > and then sc
Just like the other checks the crtc coordinates need to use goto out.
This fixes a framebuffer leak introduced by commit 3968be946a057baa.
"drm: Make integer overflow checking cover universal cursor updates (v2)"
Cc: Matt Roper
Fixes: 3968be946a057baa
Signed-off-by: Maarten Lankhorst
---
diff -
Hi Dave,
drm-intel-next-2015-10-10:
- dmc fixes from Animesh (not yet all) for deeper sleep states
- piles of prep patches from Ville to make mmio functions type-safe
- more fbc work from Paulo all over
- w/a shuffling from Arun Siluvery
- first part of atomic watermark updates from Matt and Ville
On Sun, 18 Oct 2015 19:16:42 +0200,
Russell King - ARM Linux wrote:
>
> On Sun, Oct 18, 2015 at 09:43:29PM +0530, Vinod Koul wrote:
> > Right but can I ask why you didn't try making video as component and then
> > CEC, audio and others receive the notification over this.
>
> Okay, I think I see w
Currently a single type of surface is allocated in a specific BAR.
This also changes from userspace driver to the kernel one.
This way it could happen that allocation are failing even if there are
plenty of space in the other BAR.
For instance this can happen trying to change resolution as the old
Instead of relaying on surface type use the actual placement.
This allow to have different placement for a single type of
surface.
Signed-off-by: Frediano Ziglio
---
drivers/gpu/drm/qxl/qxl_cmd.c | 2 +-
drivers/gpu/drm/qxl/qxl_drv.h | 9 -
2 files changed, 9 insertions(+), 2 deletions(-
If memory is not enough in the default BAR for a type try other BAR
this allow better memory usage and avoid memory allocation failure
if a BAR is quite small and other is quite unused.
Signed-off-by: Frediano Ziglio
---
drivers/gpu/drm/qxl/qxl_object.c | 11 +++
1 file changed, 7 insert
Hi Dave,
More drm-misc for 4.4.
- fb refcount fix in atomic fbdev
- various locking reworks to reduce drm_global_mutex and dev->struct_mutex
- rename docbook to gpu.tmpl and include vga_switcheroo stuff, plus more
vga_switcheroo (Lukas Wunner)
- viewport check fixes for atomic drivers from Ville
On Mon, Oct 19, 2015 at 02:02:58PM +0100, Liviu Dudau wrote:
> On Mon, Oct 19, 2015 at 01:25:37PM +0100, Russell King - ARM Linux wrote:
> > Please don't move this into here, it's completely inappropriate. Just
> > because something makes use of this does not mean they only support
> > 32-bit DMA.
On Mon, Oct 19, 2015 at 04:10:32PM +0300, Jyri Sarha wrote:
> On 10/16/15 16:51, Arnaud Pouliquen wrote:
> >- For IEC standard controls (could be added in core/pcm_iec958.c)
> >
>
> Oh, I did not even realize that there are predefined special kcontrols for
> handling the status bits. Adding those
On Mon, Oct 19, 2015 at 03:14:52PM +0200, Maarten Lankhorst wrote:
> Just like the other checks the crtc coordinates need to use goto out.
>
> This fixes a framebuffer leak introduced by commit 3968be946a057baa.
> "drm: Make integer overflow checking cover universal cursor updates (v2)"
>
> Cc: M
On Mon, Oct 19, 2015 at 02:26:38PM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 02:02:58PM +0100, Liviu Dudau wrote:
> > On Mon, Oct 19, 2015 at 01:25:37PM +0100, Russell King - ARM Linux wrote:
> > > Please don't move this into here, it's completely inappropriate. Just
> > > b
;ve disabled dpm via the kernel command line.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/75eb6ada/attachment-0001.html>
On Mon, Oct 19, 2015 at 02:32:55PM +0100, Liviu Dudau wrote:
> On Mon, Oct 19, 2015 at 02:26:38PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Oct 19, 2015 at 02:02:58PM +0100, Liviu Dudau wrote:
> > > On Mon, Oct 19, 2015 at 01:25:37PM +0100, Russell King - ARM Linux wrote:
> > > > Please do
On Mon, Oct 19, 2015 at 02:26:38PM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 02:02:58PM +0100, Liviu Dudau wrote:
> > On Mon, Oct 19, 2015 at 01:25:37PM +0100, Russell King - ARM Linux wrote:
> > > Please don't move this into here, it's completely inappropriate. Just
> > > b
On Mon, Oct 19, 2015 at 04:42:25PM +0200, Daniel Vetter wrote:
> On Mon, Oct 19, 2015 at 02:26:38PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Oct 19, 2015 at 02:02:58PM +0100, Liviu Dudau wrote:
> > > On Mon, Oct 19, 2015 at 01:25:37PM +0100, Russell King - ARM Linux wrote:
> > > > Please
On 19 October 2015 at 15:50, Russell King - ARM Linux
wrote:
> On Mon, Oct 19, 2015 at 04:42:25PM +0200, Daniel Vetter wrote:
>> On Mon, Oct 19, 2015 at 02:26:38PM +0100, Russell King - ARM Linux wrote:
>> > On Mon, Oct 19, 2015 at 02:02:58PM +0100, Liviu Dudau wrote:
>> > > On Mon, Oct 19, 2015 a
On Mon, Oct 19, 2015 at 03:50:27PM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 04:42:25PM +0200, Daniel Vetter wrote:
> > On Mon, Oct 19, 2015 at 02:26:38PM +0100, Russell King - ARM Linux wrote:
> > > On Mon, Oct 19, 2015 at 02:02:58PM +0100, Liviu Dudau wrote:
> > > > On Mon,
The armada DRM driver keeps some old platform data compatibility in the
probe function that makes moving to the generic drm_of_component_probe()
a bit more complicated that it should. Refactor the probe function to do
the platform_data processing after the generic probe (and only if that
fails). Th
Use the generic drm_of_component_probe() function to probe for components.
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 81 +++--
1 file changed, 6 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/
A lot of component based DRM drivers use a variant of the same code
as the probe function. They bind the crtc ports in the first iteration
and then scan through the child nodes and bind the encoders attached
to the remote endpoints. Factor the common code into a separate
function called drm_of_comp
Changelog:
v3: Removed the call to dma_set_coherent_mask() from the generic
drm_of_component_probe(). Also changes to shorten lines over 80 chars long.
v2: Rebased the patchset on top of drm-next rather than Linus' latest -rc
A few drivers in drivers/gpu/drm are component-enabled and use quite
The generic function is functionally equivalent to the driver's
imx_drm_platform_probe(). Use the generic function and reduce the
overall code size.
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/imx/imx-drm-core.c | 55 +++---
1 file changed, 4 insertions(+), 51
On Thu, Oct 8, 2015 at 12:12 PM, Alex Deucher wrote:
> This patch set implements support for i2s audio and new AMD GPUs.
> The i2s codec is fed by a DMA engine on the GPU. To handle this
> we create mfd cells which we hang the i2s codec and DMA engine on.
> Because of this, this patch set covers
On Mon, Oct 19, 2015 at 04:07:47PM +0100, Liviu Dudau wrote:
> A lot of component based DRM drivers use a variant of the same code
> as the probe function. They bind the crtc ports in the first iteration
> and then scan through the child nodes and bind the encoders attached
> to the remote endpoint
On Mon, Oct 19, 2015 at 04:07:48PM +0100, Liviu Dudau wrote:
> The generic function is functionally equivalent to the driver's
> imx_drm_platform_probe(). Use the generic function and reduce the
> overall code size.
Looks fine, thanks.
Acked-by: Russell King
--
FTTC broadband for 0.8mile line:
On Mon, Oct 19, 2015 at 04:07:50PM +0100, Liviu Dudau wrote:
> The armada DRM driver keeps some old platform data compatibility in the
> probe function that makes moving to the generic drm_of_component_probe()
> a bit more complicated that it should. Refactor the probe function to do
> the platform
On Mon, Oct 19, 2015 at 04:04:27PM +0100, Emil Velikov wrote:
> Unlike Daniel, I carry little to no weight here, yet bashing on people
> if they don't get things correct the first time is inconsiderable.
> We are people - we can misread/misinterpret things, have a headache
> and/or just a bad day.
On Mon, Oct 19, 2015 at 04:17:14PM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 04:07:50PM +0100, Liviu Dudau wrote:
> > The armada DRM driver keeps some old platform data compatibility in the
> > probe function that makes moving to the generic drm_of_component_probe()
> > a bit
option).
On which source tree this patch must be applied?
--
Thomas DEBESSE
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachme
s mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/9e75e6b5/attachment.html>
On 19 October 2015 at 16:30, Russell King - ARM Linux
wrote:
> On Mon, Oct 19, 2015 at 04:10:56PM +0200, Tomeu Vizoso wrote:
>> On 19 October 2015 at 15:18, Russell King - ARM Linux
>> wrote:
>> > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
>> >> ... If a device is available and
Commit bf89209a6d ("drm/mga200g: Hold a proper reference for
cursor_set") clearly didn't take the call site in
drm_fb_helper.c:restore_fbdev_mode() into account, which passes NULL
for file_priv and hence causes drm_gem_object_lookup() to fault. Move
the lookup back to before "obj" is actually need
I can only guess that instead of testm/testn (which are either
uninitialized or have pre-determined values at the end of the preceding
loops) n and m were meant to be used by commit e829d7ef9f
("drm/mgag200: Add support for a new rev of G200e"). In any event the
compiler is right in warning that te
On 18 October 2015 at 21:53, Mark Brown wrote:
> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
>> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
>> > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
>
>> > > I can't see adding calls like this a
On Mon, Oct 19, 2015 at 4:44 AM, David Woodhouse wrote:
> On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
>> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
>> > On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
>> > > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Gr
re
Size: 5691 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/98eff440/attachment-0001.bin>
On 19 October 2015 at 15:18, Russell King - ARM Linux
wrote:
> On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
>> ... If a device is available and has
>> a compatible driver, but it cannot be probed because a dependency
>> isn't going to be available, that's an error and is going to
non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/b4bad635/attachment-0001.sig>
Hello Yakir,
On 10/10/2015 05:35 PM, Yakir Yang wrote:
>
> Hi all,
>
>The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> share the same IP, so a lot of parts can be re-used. I split the common
> code into bridge directory, then rk3288 and exynos only need to keep
> some p
ture
Size: 473 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/f1d7d9d1/attachment-0001.sig>
next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/f1e07573/attachment.bin>
On Sun, Oct 18, 2015 at 11:29 AM, Geliang Tang wrote:
> s/regsiter/register/
>
> Signed-off-by: Geliang Tang
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/include/atombios.h | 2 +-
> drivers/gpu/drm/radeon/cayman_blit_shaders.c| 2 +-
> drivers/gpu/drm/radeon/evergreen_blit
On Mon, Oct 19, 2015 at 04:27:18AM -0600, Jan Beulich wrote:
> Commit bf89209a6d ("drm/mga200g: Hold a proper reference for
> cursor_set") clearly didn't take the call site in
> drm_fb_helper.c:restore_fbdev_mode() into account, which passes NULL
> for file_priv and hence causes drm_gem_object_loo
On Fri, Oct 09, 2015 at 01:54:58PM +0300, Jani Nikula wrote:
> On Thu, 08 Oct 2015, Daniel Vetter wrote:
> > On Thu, Oct 08, 2015 at 12:22:31PM -0400, Adam Jackson wrote:
> >> On Thu, 2015-10-08 at 11:43 +0300, ville.syrjala at linux.intel.com wrote:
> >> > From: Ville Syrjälä
> >> >
> >> > ED
https://bugzilla.kernel.org/show_bug.cgi?id=106271
Bug ID: 106271
Summary: Switch between AMD hybrid graphics (HD 8650G / HD
8970M) makes hardware reset.
Product: Drivers
Version: 2.5
Kernel Version: 4.2.3
Hardware: x86
https://bugzilla.kernel.org/show_bug.cgi?id=106271
--- Comment #1 from Aneroid ---
Created attachment 190541
--> https://bugzilla.kernel.org/attachment.cgi?id=190541&action=edit
glxinfo
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=106271
--- Comment #2 from Aneroid ---
Created attachment 190551
--> https://bugzilla.kernel.org/attachment.cgi?id=190551&action=edit
dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Mon, Oct 19, 2015 at 06:08:52PM +, Smith, Gary K wrote:
> FYI - this shouldn't block the commits, but should be optimized later (fairly
> soon).
>
> I believe the current implementation ends up executing
> while (count < CHV_DEGAMMA_MAX_VALS) {
> // Do
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151019/7abddf13/attachment-0001.html>
el so I can use my distro tools to recompile the
kernel and do it cleanly, applying the patch on the official Ubuntu kernel
tree.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://li
From: Rob Clark
Still quite rough around the edges, but now it's at the point of sorta-
kinda-working-sometimes. So I guess time to get wider feedback.
The initial goal is to figure out things that glsl_to_nir does
differently from tgsi_to_nir, so we can fix them up and have better
likelyhood o
Otherwise, passing -1 gets you:
error: invalid conversion from 'int' to 'nir_variable_mode' [-fpermissive]
Signed-off-by: Rob Clark
---
src/glsl/nir/nir.c | 4
src/glsl/nir/nir.h | 1 +
src/glsl/nir/nir_lower_io.c | 2 +-
src/mesa/drivers/dri/i96
The goal is to allow the pipe driver to request something other than
TGSI, but detect whether what is getting is TGSI vs what it requested.
The pipe drivers will always have to support TGSI (and convert that into
whatever it is that they prefer), but in some cases we should be able to
skip the TGSI
---
src/gallium/include/pipe/p_defines.h | 1 +
src/gallium/include/pipe/p_state.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index 29b0bfb..0dbc54c 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src
For now under debug flag, since only suitable for debugging/testing.
---
src/gallium/drivers/freedreno/freedreno_screen.c | 5 +++-
src/gallium/drivers/freedreno/freedreno_util.h | 1 +
.../drivers/freedreno/ir3/ir3_compiler_nir.c | 15 ++-
src/gallium/drivers/freedreno/ir3/i
When coming directly from glsl_to_nir (rather than via TGSI where
information about, for example, mat4's is lost), both const_index
fields will be used (vs. tgsi_to_nir where the 2nd is always zero).
For example:
decl_var uniform INTERP_QUALIFIER_NONE mat4 ModelViewProjectionMatrix (0, 0)
dec
Complete hack just for debugging. It isn't intended that mixing and
matching glsl->tgsi->nir vs glsl->nir between shader stages should
actually work.
---
src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/drivers/freedreno/ir
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 223 -
src/mesa/state_tracker/st_program.c| 43 +-
2 files changed, 260 insertions(+), 6 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
ind
We can get the tokens from variant->shader so drop the extra arg. This
will make things easier to support either getting TGSI or NIR as input.
---
src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/src/gallium/dr
On Mon, Oct 19, 2015 at 3:47 PM, Rob Clark wrote:
> Also, there is some trivial shader variant handling in mesa st which
> would have to be ported to NIR. Or, perhaps, just somehow expose the
> shader key to the driver. (Currently most drivers are doing much more
> variant handling within the dr
https://bugzilla.kernel.org/show_bug.cgi?id=106291
Bug ID: 106291
Summary: amdgpu fails GPU reset when resuming from suspend
Product: Drivers
Version: 2.5
Kernel Version: 4.2.3
Hardware: x86-64
OS: Linux
Tree:
On 10/18/15 18:02, Vinod Koul wrote:
> Jyri's approach to add generic IEC code makes sense and drives reuse. I kind
> of didn't like adding rates and formats for DAIs, if they are placeholders
> then it is okay but otherwise we should read and set them from ELD. Also I
The idea is to provide all p
On Wed, Sep 30, 2015 at 08:56:26AM +0200, Daniel Vetter wrote:
> > The warning on boot seems to be gone as of rc3, but I can now trigger this
> > pretty easily..
>
> http://patchwork.freedesktop.org/patch/60618/
Back from several weeks of travel.. I tried again with rc6, and
I'm still seei
1 - 100 of 122 matches
Mail list logo
