On 26 May 2015 at 00:59, Richard Weinberger wrote:
> Hi!
>
> drivers/gpu/drm/drm_lock.c is the only remaining user of block_all_signals():
It's the only user of it, ever. The API was introduced for the drm locking code.
No other user will ever exist. Just to clear up the an API exists with
one u
On 26 May 2015 at 02:50, Oleg Nesterov wrote:
> On 05/25, Richard Weinberger wrote:
>>
>> Is this functionality still in use/needed?
>
> All I can say it doesn't work.
>
>> Otherwise we could get rid of block_all_signals() and unpuzzle the signaling
>> code a bit. :-)
>
> Yes. I do not even re
This is especially true when variables or functions are just called dsm without
precising the v1.
Signed-off-by: Pierre Moreau
---
drm/nouveau/nouveau_acpi.c | 64 +++---
drm/nouveau/nouveau_acpi.h | 4 +--
drm/nouveau/nouveau_drm.c | 4 +--
drm/nouveau
This makes it clearer when reading the function name, as well as following the
names of the related ACPI function.
Signed-off-by: Pierre Moreau
---
drm/nouveau/nouveau_acpi.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drm/nouveau/nouveau_acpi.
Signed-off-by: Pierre Moreau
---
drm/nouveau/nouveau_acpi.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index 1f18018..36f4a40 100644
--- a/drm/nouveau/nouveau_acpi.c
+++ b/drm/nouveau/nouveau_acpi.c
@@ -61,11
Signed-off-by: Pierre Moreau
---
drm/nouveau/nouveau_acpi.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index 36f4a40..073f7d7 100644
--- a/drm/nouveau/nouveau_acpi.c
+++ b/drm/nouveau/nouveau_acpi.c
@@ -88
Most _DSM will return an integer value of 0x8002 when given an unknown
UUID, revision ID or function ID. Checking locally allows us to differentiate
that case from other ACPI errors, and to not report a "failed to evaluate _DSM"
if 0x8002 is returned which was confusing.
Signed-off-by: Pie
Signed-off-by: Pierre Moreau
---
drm/nouveau/nouveau_acpi.c | 8
drm/nouveau/nouveau_vga.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index 7aeaf7d..104d291 100644
--- a/drm/nouveau/nouveau_acpi.c
+++
Signed-off-by: Pierre Moreau
---
drm/nouveau/nouveau_acpi.c | 53 --
drm/nouveau/nouveau_acpi.h | 2 ++
drm/nouveau/nouveau_drm.c | 6 --
drm/nouveau/nouveau_vga.c | 10 +
4 files changed, 63 insertions(+), 8 deletions(-)
diff --git a/d
Signed-off-by: Pierre Moreau
---
drm/nouveau/nouveau_acpi.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
index 3d6a1ea..5d63621 100644
--- a/drm/nouveau/nouveau_acpi.c
+++ b/drm/nouveau/nouveau_acpi.c
@@
nts/20150526/0946d19f/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/9c93bc81/attachment.html>
> On 26 May 2015, at 00:39, Ilia Mirkin wrote:
>
>> On Mon, May 25, 2015 at 6:22 PM, Pierre Moreau
>> wrote:
>> Most _DSM will return an integer value of 0x8002 when given an unknown
>> UUID, revision ID or function ID. Checking locally allows us to differentiate
>> that case from other
On Tue, May 26, 2015 at 1:10 AM, Pierre Moreau wrote:
>> On 26 May 2015, at 00:39, Ilia Mirkin wrote:
>>
>>> On Mon, May 25, 2015 at 6:22 PM, Pierre Moreau
>>> wrote:
>>> Most _DSM will return an integer value of 0x8002 when given an unknown
>>> UUID, revision ID or function ID. Checking lo
On Mon, May 25, 2015 at 7:32 AM, Jani Nikula
wrote:
>> I'm not sure what is the approved way of fixing this. Perhaps
>> disabling CONFIG_DRM_I915_WERROR when CONFIG_COMPILE_TEST=y.
>
> Maybe the answer right now is to just drop that config. Daniel?
Agreed, that little experiment doesn't seem to
On 22 May 2015 at 02:54, Thomas Hellstrom wrote:
> On 05/21/2015 06:07 PM, Daniel Vetter wrote:
>> On Thu, May 21, 2015 at 11:58:30AM -0400, Rob Clark wrote:
>>> For actual sharing of buffers with other drivers (ie. actual hardware)
>>> we'll need to pimp things out a bit better to deal w/ caching
On Mon, May 25, 2015 at 02:06:13PM +0100, Daniel Stone wrote:
> On 22 May 2015 at 15:34, Daniel Vetter wrote:
> > On Fri, May 22, 2015 at 01:34:54PM +0100, Daniel Stone wrote:
> >> - /* FIXME: Mode prop is missing, which also controls ->enable. */
> >> if (property == config->prop_active
On Tue, May 26, 2015 at 9:39 AM, Geert Uytterhoeven
wrote:
> JFYI, when comparing v4.1-rc5[1] to v4.1-rc4[3], the summaries are:
> - build errors: +52/-28
+ /home/kisskb/slave/src/arch/arm/mm/dump.c: error:
'L_PTE_MT_BUFFERABLE' undeclared here (not in a function): => 81:10
+ /home/kisskb/
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150526/a1fc2d54/attachment.html>
> On 26 May 2015, at 07:17, Ilia Mirkin wrote:
>
> On Tue, May 26, 2015 at 1:10 AM, Pierre Moreau
> wrote:
>>> On 26 May 2015, at 00:39, Ilia Mirkin wrote:
>>>
On Mon, May 25, 2015 at 6:22 PM, Pierre Moreau
wrote:
Most _DSM will return an integer value of 0x8002 when giv
m(nouveau_dsm_priv.dhandle,
>> NOUVEAU_DSM_OPTIMUS_FLAGS,
>> - 0x3, &result);
>> + 0x3, NULL);
>> nouveau_evaluate_optimus_dsm(nouveau_dsm_priv.dhandle,
>>
au_is_optimus() || nouveau_has_mux() || nouveau_has_gmux()))
>> runtime = true;
>> vga_switcheroo_register_client(dev->pdev, &nouveau_switcheroo_ops,
>> runtime);
>> - if (runtime && nouveau_has_mux() && !nouveau_is_optimus())
>> +if (runtime && (nouveau_has_mux() || nouveau_has_gmux()) &&
>> !nouveau_is_optimus())
>> vga_switcheroo_init_domain_pm_ops(drm->dev->dev,
>> &drm->vga_pm_domain);
>> }
>> @@ -112,11 +113,12 @@ nouveau_vga_fini(struct nouveau_drm *drm)
>> if (nouveau_runtime_pm == 1)
>> runtime = true;
>> -if ((nouveau_runtime_pm == -1) && (nouveau_is_optimus() ||
>> nouveau_has_mux()))
>> +if ((nouveau_runtime_pm == -1) &&
>> +(nouveau_is_optimus() || nouveau_has_mux() || nouveau_has_gmux()))
>> runtime = true;
>>
>
> You could maybe factorize a bit here by adding nouveau_has_optimus(). What do
> you think?
I was thinking of something like that, but I wasnât sure about the name.
Using optimus seems tricky, because you could have nouveau_is_optimus(): false
but nouveau_has_optimus(): trueâ¦
>
>> vga_switcheroo_unregister_client(dev->pdev);
>> -if (runtime && nouveau_has_mux() && !nouveau_is_optimus())
>> +if (runtime && (nouveau_has_mux() || nouveau_has_gmux()) &&
>> !nouveau_is_optimus())
>> vga_switcheroo_fini_domain_pm_ops(drm->dev->dev);
>> vga_client_register(dev->pdev, NULL, NULL, NULL);
>> }
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/6e2572b2/attachment-0001.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/5a15f8ee/attachment.html>
On Wed, May 20, 2015 at 4:07 PM, Arnd Bergmann wrote:
> On Wednesday 20 May 2015 15:10:24 Alexandre Courbot wrote:
>> The lack of IOMMU API support can make nouveau_platform_probe_iommu()
>> fail to compile because struct iommu_ops is then empty. Fix this by
>> skipping IOMMU probe in that case -
bed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/aa8aab29/attachment.html>
From: Michel Dänzer
The value was much too low, which could cause the userspace visible
vblank counter to move backwards when the hardware counter wrapped
around.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_irq_kms.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletio
From: Michel Dänzer
dev->max_vblank_count contains the largest value that can be represented
by the hardware counter. When the hardware counter wraps around, we have
to add that value + 1 to get the same value as if the hardware counter
didn't wrap around.
Signed-off-by: Michel Dänzer
---
dr
Nice catch! Both patches in this series are Reviewed-by: Christian König
On 26.05.2015 10:53, Michel Dänzer wrote:
> From: Michel Dänzer
>
> dev->max_vblank_count contains the largest value that can be represented
> by the hardware counter. When the hardware counter wraps around, we have
> t
nt was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/1b2b63d0/attachment-0001.html>
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/47ed76d6/attachment.html>
plane_state->crtc shouldn't be assigned directly, but instead use
drm_atomic_set_crtc_for_plane, which also takes care of updating the
plane_mask on each CRTC's state.
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/drm_plane_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
di
From: Michel Dänzer
drm_vblank_pre/post_modeset work fine for the radeon driver even though
it uses hardware counters, including suspend/resume.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/drm_irq.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/dr
plane_state->crtc shouldn't be assigned directly, but instead use
drm_atomic_set_crtc_for_plane, which also takes care of updating the
plane_mask on each CRTC's state.
v2: First patch sent by mistake; this one checks the return value.
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/drm_plane_he
plane_state->crtc shouldn't be assigned directly, but instead use
drm_atomic_set_crtc_for_plane, which also takes care of updating the
plane_mask on each CRTC's state.
v2: First patch sent by mistake; this one checks the return value.
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/drm_plane_he
Hi David,
On Thu, 21 May 2015 11:06:56 +0200
David Dueck wrote:
> drm_panel supports querying timing ranges. If the supplied mode does
> not work with the hlcdc we query the panel and try to find a suitable
> mode.
This patch looks good to me.
Philip, Thierry, could you confirm this is the cor
freedesktop.org/archives/dri-devel/attachments/20150526/5540fb58/attachment-0001.html>
ed, so a kernel downgrade seems like a good place to start.
--
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/20150526/618a211a/attachment.html>
From: Christian König
It is theoretically possible that a swapped out BO gets the
same GTT address, but different backing pages while being swapped in.
Instead just use another VA state to note updated areas.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 4 ++-
dr
On 23.05.2015 21:06, Christian König wrote:
> On 23.05.2015 20:58, Christian König wrote:
>> From: Christian König
>>
>> It is theoretically possible that a swapped out BO gets the
>> same GTT address, but different backing pages while being swapped in.
>>
>> Instead just use another VA state t
On Tue, May 26, 2015 at 05:53:38PM +0900, Michel Dänzer wrote:
> From: Michel Dänzer
>
> dev->max_vblank_count contains the largest value that can be represented
> by the hardware counter. When the hardware counter wraps around, we have
> to add that value + 1 to get the same value as if the ha
return -EINVAL;
> + }
> + }
> +
> return 0;
> }
>
> --
> 2.1.4
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/a08da836/attachment-0001.sig>
On Tue, May 26, 2015 at 02:38:44PM +0200, Thierry Reding wrote:
> On Wed, May 20, 2015 at 04:53:53PM +0200, Daniel Vetter wrote:
> > Unfortunately old userspace didn't clear this properly, but since
> > we've added fb modifiers that's fixed. Checking properly that unused
> > fields is important for
I'm thinking of re-writing this patch to just OR the different returned retval
and test for individual bits directly in the final conditionals.
So this would give something like:
int retval = 0;
while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, pdev)) != NULL) {
vga_count++;
Hi,
a week ago I experienced problems on the skylake platform and got the
adivce to try out the drm-intel-nightly branch. I tried and it was a
success.
So after the initial "git clone" of the tree I tried to keep updated by
doing a "git pull" from time to time, but what's really strange is that
I
On Sun, May 24, 2015 at 3:26 PM, Maarten Lankhorst
wrote:
> Op 23-05-15 om 08:45 schreef Alexandre Courbot:
>> On Fri, May 22, 2015 at 3:23 AM, Martin Peres
>> wrote:
>>> On 21/05/2015 11:47, Ben Skeggs wrote:
On 21 May 2015 at 16:08, Alexandre Courbot wrote:
> Add a flag allowing Nouv
Add a new helper, to be used later for blob property management, that
sets the mode for a CRTC state, as well as updating the CRTC enable/active
state at the same time.
v2: Do not touch active/mode_changed in CRTC state. Document return
value. Remove stray drm_atomic_set_mode_prop_for_crtc dec
s/functons/functions in the commit message.
On 05/26/2015 12:22 AM, Pierre Moreau wrote:
> This makes it clearer when reading the function name, as well as following the
> names of the related ACPI function.
>
> Signed-off-by: Pierre Moreau
> ---
> drm/nouveau/nouveau_acpi.c | 25 ++
On 05/26/2015 12:22 AM, Pierre Moreau wrote:
> Signed-off-by: Pierre Moreau
> ---
> drm/nouveau/nouveau_acpi.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c
> index 36f4a40..073f7d7 100644
> --- a/dr
On 05/26/2015 12:22 AM, Pierre Moreau wrote:
> Signed-off-by: Pierre Moreau
> ---
> drm/nouveau/nouveau_acpi.c | 53
> --
> drm/nouveau/nouveau_acpi.h | 2 ++
> drm/nouveau/nouveau_drm.c | 6 --
> drm/nouveau/nouveau_vga.c | 10 +
> >
> > Christophe
> >
>
> Are you asking if just removing the loop would fix the issue?
> So you are proposing a first patch that add the argument always
> passing true and another that change some calls to false? It make
> sense but still the loop should be removed.
Sorry, I was not clear, removing the loop is fine, I was not suggesting
to keep it.
Christophe
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/f94c5771/attachment.sig>
On 05/26/2015 12:22 AM, Pierre Moreau wrote:
> Most _DSM will return an integer value of 0x8002 when given an unknown
> UUID, revision ID or function ID. Checking locally allows us to differentiate
> that case from other ACPI errors, and to not report a "failed to evaluate
> _DSM"
> if 0x800
On Tue, May 26, 2015 at 02:36:48PM +0100, Daniel Stone wrote:
> Add a new helper, to be used later for blob property management, that
> sets the mode for a CRTC state, as well as updating the CRTC enable/active
> state at the same time.
>
> v2: Do not touch active/mode_changed in CRTC state. Docum
On Tue, May 26, 2015 at 03:09:04PM +0200, Rainer Koenig wrote:
> Hi,
>
> a week ago I experienced problems on the skylake platform and got the
> adivce to try out the drm-intel-nightly branch. I tried and it was a
> success.
>
> So after the initial "git clone" of the tree I tried to keep updated
On Tue, May 26, 2015 at 6:24 AM, Christian König
wrote:
> From: Christian König
>
> It is theoretically possible that a swapped out BO gets the
> same GTT address, but different backing pages while being swapped in.
>
> Instead just use another VA state to note updated areas.
>
> Signed-off-by:
On Tue, May 26, 2015 at 5:14 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> drm_vblank_pre/post_modeset work fine for the radeon driver even though
> it uses hardware counters, including suspend/resume.
>
> Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm
Hello,
This patch set fixes a crash in the R-Car DU driver (1/3) and adds two other
small cleanups (2/3 and 3/3). Please see individual patches for details.
Laurent Pinchart (3):
drm: rcar-du: Fix crash with groups that have less than 9 planes
drm: rcar-du: Clarify error message when encoder
Commit 917de180379d ("drm: rcar-du: Implement universal plane support")
made the number of planes per group dynamic, but didn't update all loops
over the planes array, resulting in out-of-bound accesses on DU
instances that have an odd number of CRTCs (such as the R8A7790). Fix
it.
Fixes: 917de180
A failure to initialize an encoder currently prints an error message in
the kernel log without mentioning which encoder failed to initialize. To
help debugging initialization issues print the encoder DT node name.
This requires moving the error message to the rcar_du_encoders_init_one
function and
The function returns 1 on success, and either 0 or a negative error code
on failure. As the 0 and negative values don't need to be differentiated
by the caller, convert it to the usual scheme of returning 0 on success
and a negative error code on failure.
Signed-off-by: Laurent Pinchart
---
driv
On Tue, 26 May 2015, Daniel Vetter wrote:
> On Tue, May 26, 2015 at 03:09:04PM +0200, Rainer Koenig wrote:
>> Hi,
>>
>> a week ago I experienced problems on the skylake platform and got the
>> adivce to try out the drm-intel-nightly branch. I tried and it was a
>> success.
>>
>> So after the ini
On Mon, May 25, 2015 at 01:29:44PM +0300, Andrey Ryabinin wrote:
> for_each_*_in_state validate array index after
> access to array elements, thus perform out of bounds read.
>
> Fix this by validating index in the first place and read
> array element iff validation was successful.
>
> Fixes: df6
uro Rossi
--
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/20150526/5df78d1e/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/823ecf50/attachment-0001.html>
g/archives/dri-devel/attachments/20150526/94be4a07/attachment.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/c5680d4c/attachment.html>
l/attachments/20150526/c8ca9083/attachment.html>
Only the first three patches are meant for serious review.
The ASoC part should be ready for review in other respects but the
EDID SADs handling is waiting for Russell King's DRM ELD helper
patches. There is a copy-pasted not-to-be-merged patch with the same
functionality in the patch series.
The
If an ASoC component device does not have a device tree node, use its
parent's node instead, when looking for a matching DAI based on a
device tree reference.
This allows video device drivers to register a separate child device
for their ASoC side audio functionality.
Signed-off-by: Jyri Sarha
-
The hdmi stub codec has not been used since refactoring of OMAP HDMI
audio support.
Signed-off-by: Jyri Sarha
---
sound/soc/codecs/Kconfig | 4 --
sound/soc/codecs/Makefile | 2 -
sound/soc/codecs/hdmi.c | 109 --
3 files changed, 115 deletions(
From: Jean-Francois Moine
Two kinds of ports may be declared in a DT graph of ports: video and audio.
This patch accepts the port value from a video port as an alternative
to the video-ports property.
It also accepts audio ports in the case the transmitter is not used as
a slave encoder.
The new
This patch is mostly just a copy paste from Russel King's generic
patchs[1] for the same thing. The patche is included only for testing
purposes. Do not merge!
[1] http://lists.freedesktop.org/archives/dri-devel/2015-April/080525.html
Signed-off-by: Jyri Sarha
---
sound/soc/codecs/hdmi-codec.c
The hdmi-codec is a platform device driver to be registered from
drivers of external HDMI encoders with I2S and/or spdif interface. The
driver in turn registers an ASoC codec for the encoder's audio
functionality.
The structures and definitions in the API header are mostly redundant
copies of simi
This patch is here to demonstrate how to use the ASoC hdmi-codec to
implement ASoC codec API in tda998x driver.
I do not have proper documentation for tda998x family chips so I lack
the necessary information for making a decent binding for audio part
of the chip. In stead I use binding from Jean-F
This patch is here only to demonstrate HDMI codec functionality on
Beaglebone-Black.
Adds mcasp0_pins, clk_mcasp0_fixed, clk_mcasp0, mcasp0, sound node,
and changes the tda19988 node to follow the new binding.
Signed-off-by: Jyri Sarha
---
arch/arm/boot/dts/am335x-boneblack.dts | 78 +++
ttachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/011cc123/attachment.html>
On 26/05/2015 16:23, Alexandre Courbot wrote:
> On Sun, May 24, 2015 at 3:26 PM, Maarten Lankhorst
> wrote:
>> Op 23-05-15 om 08:45 schreef Alexandre Courbot:
>>> On Fri, May 22, 2015 at 3:23 AM, Martin Peres
>>> wrote:
On 21/05/2015 11:47, Ben Skeggs wrote:
> On 21 May 2015 at 16:08, A
l/attachments/20150526/dace950c/attachment.html>
ceiving 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/20150526/c78c8ae3/attachment.html>
On Tue, May 26, 2015 at 5:01 PM, Laurent Pinchart
wrote:
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -640,14 +640,14 @@ static int rcar_du_encoders_init_one(struct
> rcar_du_device *rcdu,
> of_node_put(connector);
>
> if (!ret)
On 26/05/15 19:06, Martin Peres wrote:
> On 26/05/2015 16:23, Alexandre Courbot wrote:
>> On Sun, May 24, 2015 at 3:26 PM, Maarten Lankhorst
>> wrote:
>>> Op 23-05-15 om 08:45 schreef Alexandre Courbot:
On Fri, May 22, 2015 at 3:23 AM, Martin Peres
wrote:
> On 21/05/2015 11:47, Ben
On 05/26/2015 02:46 PM, Pierre Moreau wrote:
> I'm thinking of re-writing this patch to just OR the different returned
> retval and test for individual bits directly in the final conditionals.
> So this would give something like:
>
>
> int retval = 0;
>
> while ((pdev = pci_get_class(PCI_CLASS_D
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/9340a0c5/attachment.html>
/dri-devel/attachments/20150526/8b0c1500/attachment-0001.html>
||
--
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/20150526/5b0ac9c7/attachment.html>
Hi!
Debian 8 based system. X suddenly froze. Not quite reproducible, I'm afraid.
Pavel
[331445.592203] ftdi_sio 5-2:1.0: device disconnected
[331447.063345] r8169 :03:00.0 eth0: link up
[331447.930260] PM: resume of devices comp
https://bugzilla.kernel.org/show_bug.cgi?id=98751
--- Comment #10 from Alex Deucher ---
Created attachment 178001
--> https://bugzilla.kernel.org/attachment.cgi?id=178001&action=edit
possible fix
Does the attached patch help?
--
You are receiving this mail because:
You are watching the assig
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/009cddcf/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=98751
--- Comment #11 from Mikkel Oscar Lyderik ---
It's working for me!
--
You are receiving this mail because:
You are watching the assignee of the bug.
68051/
--
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/20150526/8cf8e1e0/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150526/4fd0b95d/attachment.html>
dia, fglrx, vboxvideo
--
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/20150526/dba03662/attachment-0001.html>
Enabling audio may enable different pll dividers. Don't share
plls if the monitors differ in audio support.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=98751
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_crtc.c | 4 +++-
1 file changed, 3 in
The amdgpu driver has been out now for over a month. We've integrated
the feedback we have received so far. I'd like to get the driver upstream
for kernel 4.2.
Patches 1-28 just add register headers and are too big to send out.
Patches 35, 38, 39 add the core of the driver and are also a bit big
This header defines the ioctl interface to the driver.
v2: remove stale tiling defines
v3: add appropriate padding
v4: remove executable bits on header
Acked-by: Christian König
Acked-by: Jammy Zhou
Signed-off-by: Alex Deucher
---
include/uapi/drm/amdgpu_drm.h | 590 +
This header provides for format for the GCA blocks
clear state (i.e., default state). Each GCA version
has a specific clear state.
Acked-by: Christian König
Acked-by: Jammy Zhou
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/clearstate_defs.h | 44
1
This header provides the smc message interface for the driver.
Acked-by: Christian König
Acked-by: Jammy Zhou
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/ppsmc.h | 196 +
1 file changed, 196 insertions(+)
create mode 100644 drivers/gpu/drm/a
This header defines asic families and attributes.
Acked-by: Christian König
Acked-by: Jammy Zhou
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_family.h | 62 ++
1 file changed, 62 insertions(+)
create mode 100644 drivers/gpu/drm/amd/amdgpu/amdg
This is the main header file for amdgpu.
v2: remove stable comments
Acked-by: Christian König
Acked-by: Jammy Zhou
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2387 +++
1 file changed, 2387 insertions(+)
create mode 100644 drivers/gp
Use readb() and memcpy_fromio() accessors instead.
Ported from radeon commit:
f2c9e560b406f2f6b14b345c7da33467dee9cdf2
Acked-by: Christian König
Acked-by: Jammy Zhou
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 10 +++---
1 file changed, 7 insertions(+), 3 d
Acked-by: Christian König
Acked-by: Jammy Zhou
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 83 +
1 file changed, 83 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index
1 - 100 of 151 matches
Mail list logo
