This is the nva3 counterpart to commit beba44b17 (drm/nv84/disp: Fix
HDMI audio regression). The regression happened as a result of
refactoring in commit 8e9e3d2de (drm/nv84/disp: move hdmi control into
core).
Reported-and-tested-by: Max Baldwin
Signed-off-by: Ilia Mirkin
---
The actual
This is the nva3 counterpart to commit beba44b17 (drm/nv84/disp: Fix
HDMI audio regression). The regression happened as a result of
refactoring in commit 8e9e3d2de (drm/nv84/disp: move hdmi control into
core).
Reported-and-tested-by: Max Baldwin
Signed-off-by: Ilia Mirkin
---
The actual
mechanism to load the kernel for the xtensa chips and
provide the necessary interactions to do the rest of the work.
Signed-off-by: Ilia Mirkin
---
v1 -> v2:
- factored out similar logic between vp and bsp into a new xtensa.c, similar
to falcon
- moved firmware loading to init rather than c
mechanism to load the kernel for the xtensa chips and
provide the necessary interactions to do the rest of the work.
Signed-off-by: Ilia Mirkin
---
v1 -> v2:
- factored out similar logic between vp and bsp into a new xtensa.c, similar
to falcon
- moved firmware loading to init rather than c
On Wed, Jun 5, 2013 at 3:05 AM, Maarten Lankhorst
wrote:
> Hey,
>
> Op 04-06-13 20:38, Ilia Mirkin schreef:
>> On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin wrote:
>>> These chipsets include the VP2 engine which is composed of a bitstream
>>> processor (BS
On Wed, Jun 5, 2013 at 3:05 AM, Maarten Lankhorst
wrote:
> Hey,
>
> Op 04-06-13 20:38, Ilia Mirkin schreef:
>> On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin wrote:
>>> These chipsets include the VP2 engine which is composed of a bitstream
>>> processor (BS
On Tue, Jun 4, 2013 at 4:48 PM, Henrik Rydberg wrote:
> Hi Ben,
>
> The new mutexes in nvc0/nv50 (fadb17190/b509656) break resume on my
> MBA3,1. A dead-lock somewhere, perhaps? Reverting fixes the problem.
A bunch of people saw it earlier. Fixed for nv50 (which is what I
assume you have) in
http
On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin wrote:
> These chipsets include the VP2 engine which is composed of a bitstream
> processor (BSP) that decodes H.264 and a video processor (VP) which can
> do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are
> driven by sep
On Tue, Jun 4, 2013 at 4:48 PM, Henrik Rydberg wrote:
> Hi Ben,
>
> The new mutexes in nvc0/nv50 (fadb17190/b509656) break resume on my
> MBA3,1. A dead-lock somewhere, perhaps? Reverting fixes the problem.
A bunch of people saw it earlier. Fixed for nv50 (which is what I
assume you have) in
http
On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin wrote:
> These chipsets include the VP2 engine which is composed of a bitstream
> processor (BSP) that decodes H.264 and a video processor (VP) which can
> do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are
> driven by sep
mechanism to load the kernel for the xtensa chips and
provide the necessary interactions to do the rest of the work.
Signed-off-by: Ilia Mirkin
---
This patch applies on top of nouveau/master (16a41bcc8).
This seems to work for me. There was one boot where my userspace
component didn't work
mechanism to load the kernel for the xtensa chips and
provide the necessary interactions to do the rest of the work.
Signed-off-by: Ilia Mirkin
---
This patch applies on top of nouveau/master (16a41bcc8).
This seems to work for me. There was one boot where my userspace
component didn't work
On Sat, Apr 6, 2013 at 5:01 AM, Ilia Mirkin wrote:
> On Mon, Apr 1, 2013 at 4:14 PM, Christoph Lameter wrote:
>> On Wed, 27 Mar 2013, Ilia Mirkin wrote:
>>
>>> The GPF happens at +160, which is in the argument setup for the
>>> cmpxchg in slab_all
On Mon, Apr 1, 2013 at 4:14 PM, Christoph Lameter wrote:
> On Wed, 27 Mar 2013, Ilia Mirkin wrote:
>
>> The GPF happens at +160, which is in the argument setup for the
>> cmpxchg in slab_alloc_node. I think it's the call to
>> get_freepointer(). There was a si
On Sat, Apr 6, 2013 at 5:01 AM, Ilia Mirkin wrote:
> On Mon, Apr 1, 2013 at 4:14 PM, Christoph Lameter wrote:
>> On Wed, 27 Mar 2013, Ilia Mirkin wrote:
>>
>>> The GPF happens at +160, which is in the argument setup for the
>>> cmpxchg in slab_all
On Mon, Apr 1, 2013 at 4:14 PM, Christoph Lameter wrote:
> On Wed, 27 Mar 2013, Ilia Mirkin wrote:
>
>> The GPF happens at +160, which is in the argument setup for the
>> cmpxchg in slab_alloc_node. I think it's the call to
>> get_freepointer(). There was a si
On Fri, Mar 29, 2013 at 11:22 AM, Michal Hocko wrote:
> On Wed 27-03-13 14:25:36, Ilia Mirkin wrote:
>> Hello,
>>
>> My system died last night apparently due to OOM conditions. Note that
>> I don't have any swap set up, but my understanding is that this is not
On Fri, Mar 29, 2013 at 11:22 AM, Michal Hocko wrote:
> On Wed 27-03-13 14:25:36, Ilia Mirkin wrote:
>> Hello,
>>
>> My system died last night apparently due to OOM conditions. Note that
>> I don't have any swap set up, but my understanding is that this is not
While using chrome, I got the following. It was able to render the bug
to the screen, so at least something was working (and it also made it
to my logs).
[223614.867297] BUG: unable to handle kernel paging request at c90013a0
[223614.867372] IP: [] iowrite32+0x12/0x33
[223614.867427] PGD 1
While using chrome, I got the following. It was able to render the bug
to the screen, so at least something was working (and it also made it
to my logs).
[223614.867297] BUG: unable to handle kernel paging request at c90013a0
[223614.867372] IP: [] iowrite32+0x12/0x33
[223614.867427] PGD 1
501 - 520 of 520 matches
Mail list logo
