date:20150311

Re: [Nouveau] Bug or not?

2015-03-11 Thread Pierre Moreau

Hi Evan,

I didn't know there were so many different versions of acpidump in the wild! :D
So apparently, you'll need to replace the first command by 'acpidump -b -t DSDT 
-o dsdt.dat' - we need the DSDT table in binary format for iasl to disassemble.

Regards,

Pierre



> On 12 Mar 2015, at 06:47, Evan Foss  wrote:
> 
> Hi Pierre,
> 
> No worries about the response time. I remember when the features
> matrix was mostly todo's. Clearly you folks have put in a ton of work.
> I would feel bad about trying to shove a developer into my problem and
> I do not have the time right now to join the development team. Besides
> my day job I am currently writing a library to interpret BSDL files
> (JTAG).
> 
> I am having a bit of trouble with acpidump which is telling me there
> is no -n option. The acpidump I am running is from a package called
> pmtools. Is that the correct thing? I am in gentoo and used the
> following ebuild to do the install.
> 
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-power/pmtools/pmtools-20110323-r1.ebuild?view=markup
> which pulls this source
> https://github.com/anyc/pmtools/
> 
> I see your point about using the intel instead of the nVidia GPU.
> 
> Many thanks for your help,
> -Evan
> 
>> On Wed, Mar 11, 2015 at 3:52 PM, Pierre Moreau  wrote:
>> Hi Evan!
>> 
>> Sorry for taking so long before answering...
>> Thanks for the greps! It appears you have a newer version of apple_gmux than 
>> I have, so let's see if something also changed in the _DSM method. Could you 
>> please run - as root - `acpidump -b -n DSDT` which will create a file named 
>> dsdt.dat containing the DSDT table, and then run `iasl -d dsdt.dat` and send 
>> me the resulting dsdt.dsl file?
>> That way I will have the uuid, the available functions and their version for 
>> your _DSM method.
>> 
>> Regarding bringing the clocks down, you could add a fake performance level 
>> in the vbios but I'm not sure if it would be a good move. You should rather 
>> power off the NVidia card and only use the Intel one - using vgaswitcheroo, 
>> see [1]; once I have that dsdt.dsl file, I should be able to add support for 
>> auto-powering down the NVidia card. Or you could try to motivate some 
>> developers - or if you want to give it a try - to investigate / add support 
>> for power and/or clock gating.
>> 
>> Regards,
>> 
>> Pierre
>> 
>> [1]: 
>> http://nouveau.freedesktop.org/wiki/Optimus/#checkingthecurrentpowerstate
>> 
>> 
>> - Mail original -
>>> The first grep of dmesg is for the apple info so you know exactly
>>> what
>>> box I have. The second is to show that I am booting in EFI mode and
>>> not some bogus bios compatibility thing. The third is to show the
>>> gmux
>>> version. The fourth is to answer the question you actually asked.
>>> 
>>> $ cat /proc/version
>>> Linux version 3.19.0 (root@turingatlarge) (gcc version 4.7.3 (Gentoo
>>> 4.7.3-r1 p1.4, pie-0.5.5) ) #3 SMP Sun Feb 15 01:09:59 EST 2015
>>> 
>>> -- $ dmesg|grep Apple
>>> [0.00] efi: EFI v1.10 by Apple
>>> [0.00] DMI: Apple Inc. MacBookPro9,1/Mac-4B7AC7E43945597E,
>>> BIOS MBP91.88Z.00D3.B08.1208081132 08/08/2012
>>> [0.00] ACPI: XSDT 0x8CD8E1C0 B4 (v01 APPLE
>>> Apple00    0113)
>>> [0.00] ACPI: FACP 0x8CD8C000 F4 (v04 APPLE
>>> Apple00   Loki 005F)
>>> [0.00] ACPI: HPET 0x8CD8B000 38 (v01 APPLE
>>> Apple00  0001 Loki 005F)
>>> [0.00] ACPI: APIC 0x8CD8A000 BC (v02 APPLE
>>> Apple00  0001 Loki 005F)
>>> [0.00] ACPI: SBST 0x8CD88000 30 (v01 APPLE
>>> Apple00  0001 Loki 005F)
>>> [0.00] ACPI: ECDT 0x8CD87000 53 (v01 APPLE
>>> Apple00  0001 Loki 005F)
>>> [0.00] ACPI: MCFG 0x8CD89000 3C (v01 APPLE
>>> Apple00  0001 Loki 005F)
>>> [3.091740] usb 3-1.1: Manufacturer: Apple Inc.
>>> [3.410516] usb 4-1.8.1: Manufacturer: Apple Inc.
>>> [3.581141] usb 4-1.8.2: Manufacturer: Apple Computer, Inc.
>>> [3.777265] usb 4-1.8.3: Product: Apple Internal Keyboard /
>>> Trackpad
>>> [3.777267] usb 4-1.8.3: Manufacturer: Apple Inc.
>>> [3.782615] input: Apple Inc. Apple Internal Keyboard / Trackpad
>>> as
>>> /devices/pci:00/:00:1d.0/usb4/4-1/4-1.8/4-1.8.3/4-1.8.3:1.0/0003:05AC:0252.0002/input/input13
>>> [3.833440] apple 0003:05AC:0252.0002: input,hidraw0: USB HID
>>> v1.11
>>> Keyboard [Apple Inc. Apple Internal Keyboard / Trackpad] on
>>> usb-:00:1d.0-1.8.3/input0
>>> [4.091248] apple 0003:05AC:0252.0003: hidraw2: USB HID v1.11
>>> Device [Apple Inc. Apple Internal Keyboard / Trackpad] on
>>> usb-:00:1d.0-1.8.3/input1
>>> [4.319509] usb 4-1.8.1.3: Manufacturer: Apple Inc.
>>> [4.457798] input: Apple Computer, Inc. IR Receiver as
>>> /devices/pci:00/:00:1d.0/usb4/4-1/4-1.8/4-1.8.2/4-1.8.2:1.0/0003:05AC:8242.0001/input/input18
>>> [4.509982] appleir 0003:05AC:

Re: [Nouveau] Bug or not?

2015-03-11 Thread Evan Foss

Oh vgaswitcharoo is how I tried doing the GPU switch and check the
current setting (on/off) of each GPU.

On Thu, Mar 12, 2015 at 12:47 AM, Evan Foss  wrote:
> Hi Pierre,
>
> No worries about the response time. I remember when the features
> matrix was mostly todo's. Clearly you folks have put in a ton of work.
> I would feel bad about trying to shove a developer into my problem and
> I do not have the time right now to join the development team. Besides
> my day job I am currently writing a library to interpret BSDL files
> (JTAG).
>
> I am having a bit of trouble with acpidump which is telling me there
> is no -n option. The acpidump I am running is from a package called
> pmtools. Is that the correct thing? I am in gentoo and used the
> following ebuild to do the install.
>
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-power/pmtools/pmtools-20110323-r1.ebuild?view=markup
> which pulls this source
> https://github.com/anyc/pmtools/
>
> I see your point about using the intel instead of the nVidia GPU.
>
> Many thanks for your help,
> -Evan
>
> On Wed, Mar 11, 2015 at 3:52 PM, Pierre Moreau  wrote:
>> Hi Evan!
>>
>> Sorry for taking so long before answering...
>> Thanks for the greps! It appears you have a newer version of apple_gmux than 
>> I have, so let's see if something also changed in the _DSM method. Could you 
>> please run - as root - `acpidump -b -n DSDT` which will create a file named 
>> dsdt.dat containing the DSDT table, and then run `iasl -d dsdt.dat` and send 
>> me the resulting dsdt.dsl file?
>> That way I will have the uuid, the available functions and their version for 
>> your _DSM method.
>>
>> Regarding bringing the clocks down, you could add a fake performance level 
>> in the vbios but I'm not sure if it would be a good move. You should rather 
>> power off the NVidia card and only use the Intel one - using vgaswitcheroo, 
>> see [1]; once I have that dsdt.dsl file, I should be able to add support for 
>> auto-powering down the NVidia card. Or you could try to motivate some 
>> developers - or if you want to give it a try - to investigate / add support 
>> for power and/or clock gating.
>>
>> Regards,
>>
>> Pierre
>>
>> [1]: 
>> http://nouveau.freedesktop.org/wiki/Optimus/#checkingthecurrentpowerstate
>>
>>
>> - Mail original -
>>> The first grep of dmesg is for the apple info so you know exactly
>>> what
>>> box I have. The second is to show that I am booting in EFI mode and
>>> not some bogus bios compatibility thing. The third is to show the
>>> gmux
>>> version. The fourth is to answer the question you actually asked.
>>>
>>> $ cat /proc/version
>>> Linux version 3.19.0 (root@turingatlarge) (gcc version 4.7.3 (Gentoo
>>> 4.7.3-r1 p1.4, pie-0.5.5) ) #3 SMP Sun Feb 15 01:09:59 EST 2015
>>>
>>> -- $ dmesg|grep Apple
>>> [0.00] efi: EFI v1.10 by Apple
>>> [0.00] DMI: Apple Inc. MacBookPro9,1/Mac-4B7AC7E43945597E,
>>> BIOS MBP91.88Z.00D3.B08.1208081132 08/08/2012
>>> [0.00] ACPI: XSDT 0x8CD8E1C0 B4 (v01 APPLE
>>> Apple00    0113)
>>> [0.00] ACPI: FACP 0x8CD8C000 F4 (v04 APPLE
>>> Apple00   Loki 005F)
>>> [0.00] ACPI: HPET 0x8CD8B000 38 (v01 APPLE
>>> Apple00  0001 Loki 005F)
>>> [0.00] ACPI: APIC 0x8CD8A000 BC (v02 APPLE
>>> Apple00  0001 Loki 005F)
>>> [0.00] ACPI: SBST 0x8CD88000 30 (v01 APPLE
>>> Apple00  0001 Loki 005F)
>>> [0.00] ACPI: ECDT 0x8CD87000 53 (v01 APPLE
>>> Apple00  0001 Loki 005F)
>>> [0.00] ACPI: MCFG 0x8CD89000 3C (v01 APPLE
>>> Apple00  0001 Loki 005F)
>>> [3.091740] usb 3-1.1: Manufacturer: Apple Inc.
>>> [3.410516] usb 4-1.8.1: Manufacturer: Apple Inc.
>>> [3.581141] usb 4-1.8.2: Manufacturer: Apple Computer, Inc.
>>> [3.777265] usb 4-1.8.3: Product: Apple Internal Keyboard /
>>> Trackpad
>>> [3.777267] usb 4-1.8.3: Manufacturer: Apple Inc.
>>> [3.782615] input: Apple Inc. Apple Internal Keyboard / Trackpad
>>> as
>>> /devices/pci:00/:00:1d.0/usb4/4-1/4-1.8/4-1.8.3/4-1.8.3:1.0/0003:05AC:0252.0002/input/input13
>>> [3.833440] apple 0003:05AC:0252.0002: input,hidraw0: USB HID
>>> v1.11
>>> Keyboard [Apple Inc. Apple Internal Keyboard / Trackpad] on
>>> usb-:00:1d.0-1.8.3/input0
>>> [4.091248] apple 0003:05AC:0252.0003: hidraw2: USB HID v1.11
>>> Device [Apple Inc. Apple Internal Keyboard / Trackpad] on
>>> usb-:00:1d.0-1.8.3/input1
>>> [4.319509] usb 4-1.8.1.3: Manufacturer: Apple Inc.
>>> [4.457798] input: Apple Computer, Inc. IR Receiver as
>>> /devices/pci:00/:00:1d.0/usb4/4-1/4-1.8/4-1.8.2/4-1.8.2:1.0/0003:05AC:8242.0001/input/input18
>>> [4.509982] appleir 0003:05AC:8242.0001: input,hiddev0,hidraw4:
>>> USB
>>> HID v1.11 Device [Apple Computer, Inc. IR Receiver] on
>>> usb-:00:1d.0-1.8.2/input0
>>>
>>> -- $ dmesg|grep EFI
>>> [0.0

Re: [Nouveau] Bug or not?

2015-03-11 Thread Evan Foss

Hi Pierre,

No worries about the response time. I remember when the features
matrix was mostly todo's. Clearly you folks have put in a ton of work.
I would feel bad about trying to shove a developer into my problem and
I do not have the time right now to join the development team. Besides
my day job I am currently writing a library to interpret BSDL files
(JTAG).

I am having a bit of trouble with acpidump which is telling me there
is no -n option. The acpidump I am running is from a package called
pmtools. Is that the correct thing? I am in gentoo and used the
following ebuild to do the install.

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-power/pmtools/pmtools-20110323-r1.ebuild?view=markup
which pulls this source
https://github.com/anyc/pmtools/

I see your point about using the intel instead of the nVidia GPU.

Many thanks for your help,
-Evan

On Wed, Mar 11, 2015 at 3:52 PM, Pierre Moreau  wrote:
> Hi Evan!
>
> Sorry for taking so long before answering...
> Thanks for the greps! It appears you have a newer version of apple_gmux than 
> I have, so let's see if something also changed in the _DSM method. Could you 
> please run - as root - `acpidump -b -n DSDT` which will create a file named 
> dsdt.dat containing the DSDT table, and then run `iasl -d dsdt.dat` and send 
> me the resulting dsdt.dsl file?
> That way I will have the uuid, the available functions and their version for 
> your _DSM method.
>
> Regarding bringing the clocks down, you could add a fake performance level in 
> the vbios but I'm not sure if it would be a good move. You should rather 
> power off the NVidia card and only use the Intel one - using vgaswitcheroo, 
> see [1]; once I have that dsdt.dsl file, I should be able to add support for 
> auto-powering down the NVidia card. Or you could try to motivate some 
> developers - or if you want to give it a try - to investigate / add support 
> for power and/or clock gating.
>
> Regards,
>
> Pierre
>
> [1]: http://nouveau.freedesktop.org/wiki/Optimus/#checkingthecurrentpowerstate
>
>
> - Mail original -
>> The first grep of dmesg is for the apple info so you know exactly
>> what
>> box I have. The second is to show that I am booting in EFI mode and
>> not some bogus bios compatibility thing. The third is to show the
>> gmux
>> version. The fourth is to answer the question you actually asked.
>>
>> $ cat /proc/version
>> Linux version 3.19.0 (root@turingatlarge) (gcc version 4.7.3 (Gentoo
>> 4.7.3-r1 p1.4, pie-0.5.5) ) #3 SMP Sun Feb 15 01:09:59 EST 2015
>>
>> -- $ dmesg|grep Apple
>> [0.00] efi: EFI v1.10 by Apple
>> [0.00] DMI: Apple Inc. MacBookPro9,1/Mac-4B7AC7E43945597E,
>> BIOS MBP91.88Z.00D3.B08.1208081132 08/08/2012
>> [0.00] ACPI: XSDT 0x8CD8E1C0 B4 (v01 APPLE
>> Apple00    0113)
>> [0.00] ACPI: FACP 0x8CD8C000 F4 (v04 APPLE
>> Apple00   Loki 005F)
>> [0.00] ACPI: HPET 0x8CD8B000 38 (v01 APPLE
>> Apple00  0001 Loki 005F)
>> [0.00] ACPI: APIC 0x8CD8A000 BC (v02 APPLE
>> Apple00  0001 Loki 005F)
>> [0.00] ACPI: SBST 0x8CD88000 30 (v01 APPLE
>> Apple00  0001 Loki 005F)
>> [0.00] ACPI: ECDT 0x8CD87000 53 (v01 APPLE
>> Apple00  0001 Loki 005F)
>> [0.00] ACPI: MCFG 0x8CD89000 3C (v01 APPLE
>> Apple00  0001 Loki 005F)
>> [3.091740] usb 3-1.1: Manufacturer: Apple Inc.
>> [3.410516] usb 4-1.8.1: Manufacturer: Apple Inc.
>> [3.581141] usb 4-1.8.2: Manufacturer: Apple Computer, Inc.
>> [3.777265] usb 4-1.8.3: Product: Apple Internal Keyboard /
>> Trackpad
>> [3.777267] usb 4-1.8.3: Manufacturer: Apple Inc.
>> [3.782615] input: Apple Inc. Apple Internal Keyboard / Trackpad
>> as
>> /devices/pci:00/:00:1d.0/usb4/4-1/4-1.8/4-1.8.3/4-1.8.3:1.0/0003:05AC:0252.0002/input/input13
>> [3.833440] apple 0003:05AC:0252.0002: input,hidraw0: USB HID
>> v1.11
>> Keyboard [Apple Inc. Apple Internal Keyboard / Trackpad] on
>> usb-:00:1d.0-1.8.3/input0
>> [4.091248] apple 0003:05AC:0252.0003: hidraw2: USB HID v1.11
>> Device [Apple Inc. Apple Internal Keyboard / Trackpad] on
>> usb-:00:1d.0-1.8.3/input1
>> [4.319509] usb 4-1.8.1.3: Manufacturer: Apple Inc.
>> [4.457798] input: Apple Computer, Inc. IR Receiver as
>> /devices/pci:00/:00:1d.0/usb4/4-1/4-1.8/4-1.8.2/4-1.8.2:1.0/0003:05AC:8242.0001/input/input18
>> [4.509982] appleir 0003:05AC:8242.0001: input,hiddev0,hidraw4:
>> USB
>> HID v1.11 Device [Apple Computer, Inc. IR Receiver] on
>> usb-:00:1d.0-1.8.2/input0
>>
>> -- $ dmesg|grep EFI
>> [0.00] efi: EFI v1.10 by Apple
>> [1.220269] fb0: EFI VGA frame buffer device
>> [2.619144] EFI Variables Facility v0.08 2004-May-17
>> [4.205767] fb: switching to nouveaufb from EFI VGA
>>
>> -- $ dmesg|grep gmux
>> [2.739845] apple_gmux: Found gmux version 1.9.35

Re: [Nouveau] [PATCH] pmu/gk20a: PMU boot support.

2015-03-11 Thread Deepak Goyal

Hi Mirkin,

Your observations are quiet correct.
After the boot code is submitted successfully, I will submit the code to 
configure & enable features of PMU.(This will be done by sending cmds to PMU).

Now talking about this patch:
Apart from just the boot code, I have also included some things in this patch 
that I can remove for now(I will include these things in later digestible 
chunks):

- Debugfs support (can be removed for now)
- Debug support for dumping PMU falcon registers(can be removed for now)
- PMU interacts with Kernel via interrupt mechanism.
  For interaction with PMU, we have
  defined command structs, functions to prepare/validate and send commands to 
PMU.
  This infrastructure is basically to send commands to PMU.(right now it can be 
removed though we still require to receive messages from PMU to know if it has 
booted successfully).

But this will be all that I will be able to remove from this patch.
Can I go ahead with removing above suggestions?

Regards,
Deepak G

-Original Message-
From: ibmir...@gmail.com [mailto:ibmir...@gmail.com] On Behalf Of Ilia Mirkin
Sent: Wednesday, March 11, 2015 10:41 PM
To: Deepak Goyal
Cc: Ben Skeggs; Alexandre Courbot; nouveau@lists.freedesktop.org; 
linux-te...@vger.kernel.org
Subject: Re: [Nouveau] [PATCH] pmu/gk20a: PMU boot support.

Hi Deepak,

There's... a lot of stuff going on here. Can you describe the goal of
this patch (which could then be used as the patch commit message)? The
current one basically boils down to "Add support for loading PMU", but
merely loading the fw into a fuc engine is just a handful lines of
code. Also, except in rare cases, it's customary to split up patches
of this size into smaller, more reviewable chunks, which add on bits
of functionality as they go.

From what I can tell, you're adding the kernel-side interface for a
hypothetical (and presumably closed-source) PMU blob that NVIDIA will
supply. In essence, the blob is expected to implement a RTOS which
runs on the PMU's falcon CPU. There are a bunch of API's implemented
by this blob that the host can call, but it also does things on its
own. For the kernel side, each of these API calls should probably be a
separate patch (after an initial "just load it and do nothing" style
patch). Or perhaps have the infrastructure that you add first and then
something that implements the API calls.

Cheers,

  -ilia


On Wed, Mar 11, 2015 at 2:33 AM, Deepak Goyal  wrote:
> It adds PMU boot support.It loads PMU
> firmware into PMU falcon.RM/Kernel driver
> receives INIT ack (through interrupt mechanism)
> from PMU when PMU boots with success.
>
> Signed-off-by: Deepak Goyal 
> ---
>  drm/nouveau/include/nvkm/subdev/pmu.h |   26 +-
>  drm/nouveau/nvkm/subdev/pmu/base.c|  108 ++
>  drm/nouveau/nvkm/subdev/pmu/gk20a.c   | 2131 
> -
>  drm/nouveau/nvkm/subdev/pmu/gk20a.h   |  369 ++
>  drm/nouveau/nvkm/subdev/pmu/priv.h|  264 
>  5 files changed, 2884 insertions(+), 14 deletions(-)
>  create mode 100644 drm/nouveau/nvkm/subdev/pmu/gk20a.h
>
> diff --git a/drm/nouveau/include/nvkm/subdev/pmu.h 
> b/drm/nouveau/include/nvkm/subdev/pmu.h
> index 7b86acc634a0..659b4e0ba02b 100644
> --- a/drm/nouveau/include/nvkm/subdev/pmu.h
> +++ b/drm/nouveau/include/nvkm/subdev/pmu.h
> @@ -1,7 +1,20 @@
>  #ifndef __NVKM_PMU_H__
>  #define __NVKM_PMU_H__
>  #include 
> +#include 
> +#include 
> +#include 
>
> +struct pmu_buf_desc {
> +   struct nvkm_gpuobj *pmubufobj;
> +   struct nvkm_vma pmubufvma;
> +   size_t size;
> +};
> +struct pmu_priv_vm {
> +   struct nvkm_gpuobj *mem;
> +   struct nvkm_gpuobj *pgd;
> +   struct nvkm_vm *vm;
> +};
>  struct nvkm_pmu {
> struct nvkm_subdev base;
>
> @@ -20,9 +33,20 @@ struct nvkm_pmu {
> u32 message;
> u32 data[2];
> } recv;
> -
> +   wait_queue_head_t init_wq;
> +   bool gr_initialised;
> +   struct dentry *debugfs;
> +   struct pmu_buf_desc *pg_buf;
> +   struct pmu_priv_vm *pmuvm;
> int  (*message)(struct nvkm_pmu *, u32[2], u32, u32, u32, u32);
> void (*pgob)(struct nvkm_pmu *, bool);
> +   int (*pmu_mutex_acquire)(struct nvkm_pmu *, u32 id, u32 *token);
> +   int (*pmu_mutex_release)(struct nvkm_pmu *, u32 id, u32 *token);
> +   int (*pmu_load_norm)(struct nvkm_pmu *pmu, u32 *load);
> +   int (*pmu_load_update)(struct nvkm_pmu *pmu);
> +   void (*pmu_reset_load_counters)(struct nvkm_pmu *pmu);
> +   void (*pmu_get_load_counters)(struct nvkm_pmu *pmu, u32 *busy_cycles,
> +   u32 *total_cycles);
>  };
>
>  static inline struct nvkm_pmu *
> diff --git a/drm/nouveau/nvkm/subdev/pmu/base.c 
> b/drm/nouveau/nvkm/subdev/pmu/base.c
> index 054b2d2eec35..6afd389b9764 100644
> --- a/drm/nouveau/nvkm/subdev/pmu/base.c
> +++ b/drm/nouveau/nvkm/subdev/pmu/base.c
> @@ -25,6 +25,114 @@
>
>  #include 
>
> +/* init allocator struct */
> +int nvkm_pmu_allocator_init(struct n

Re: [Nouveau] [PATCH] pmu/gk20a: PMU boot support.

2015-03-11 Thread Ilia Mirkin

Hi Deepak,

There's... a lot of stuff going on here. Can you describe the goal of
this patch (which could then be used as the patch commit message)? The
current one basically boils down to "Add support for loading PMU", but
merely loading the fw into a fuc engine is just a handful lines of
code. Also, except in rare cases, it's customary to split up patches
of this size into smaller, more reviewable chunks, which add on bits
of functionality as they go.

From what I can tell, you're adding the kernel-side interface for a
hypothetical (and presumably closed-source) PMU blob that NVIDIA will
supply. In essence, the blob is expected to implement a RTOS which
runs on the PMU's falcon CPU. There are a bunch of API's implemented
by this blob that the host can call, but it also does things on its
own. For the kernel side, each of these API calls should probably be a
separate patch (after an initial "just load it and do nothing" style
patch). Or perhaps have the infrastructure that you add first and then
something that implements the API calls.

Cheers,

  -ilia


On Wed, Mar 11, 2015 at 2:33 AM, Deepak Goyal  wrote:
> It adds PMU boot support.It loads PMU
> firmware into PMU falcon.RM/Kernel driver
> receives INIT ack (through interrupt mechanism)
> from PMU when PMU boots with success.
>
> Signed-off-by: Deepak Goyal 
> ---
>  drm/nouveau/include/nvkm/subdev/pmu.h |   26 +-
>  drm/nouveau/nvkm/subdev/pmu/base.c|  108 ++
>  drm/nouveau/nvkm/subdev/pmu/gk20a.c   | 2131 
> -
>  drm/nouveau/nvkm/subdev/pmu/gk20a.h   |  369 ++
>  drm/nouveau/nvkm/subdev/pmu/priv.h|  264 
>  5 files changed, 2884 insertions(+), 14 deletions(-)
>  create mode 100644 drm/nouveau/nvkm/subdev/pmu/gk20a.h
>
> diff --git a/drm/nouveau/include/nvkm/subdev/pmu.h 
> b/drm/nouveau/include/nvkm/subdev/pmu.h
> index 7b86acc634a0..659b4e0ba02b 100644
> --- a/drm/nouveau/include/nvkm/subdev/pmu.h
> +++ b/drm/nouveau/include/nvkm/subdev/pmu.h
> @@ -1,7 +1,20 @@
>  #ifndef __NVKM_PMU_H__
>  #define __NVKM_PMU_H__
>  #include 
> +#include 
> +#include 
> +#include 
>
> +struct pmu_buf_desc {
> +   struct nvkm_gpuobj *pmubufobj;
> +   struct nvkm_vma pmubufvma;
> +   size_t size;
> +};
> +struct pmu_priv_vm {
> +   struct nvkm_gpuobj *mem;
> +   struct nvkm_gpuobj *pgd;
> +   struct nvkm_vm *vm;
> +};
>  struct nvkm_pmu {
> struct nvkm_subdev base;
>
> @@ -20,9 +33,20 @@ struct nvkm_pmu {
> u32 message;
> u32 data[2];
> } recv;
> -
> +   wait_queue_head_t init_wq;
> +   bool gr_initialised;
> +   struct dentry *debugfs;
> +   struct pmu_buf_desc *pg_buf;
> +   struct pmu_priv_vm *pmuvm;
> int  (*message)(struct nvkm_pmu *, u32[2], u32, u32, u32, u32);
> void (*pgob)(struct nvkm_pmu *, bool);
> +   int (*pmu_mutex_acquire)(struct nvkm_pmu *, u32 id, u32 *token);
> +   int (*pmu_mutex_release)(struct nvkm_pmu *, u32 id, u32 *token);
> +   int (*pmu_load_norm)(struct nvkm_pmu *pmu, u32 *load);
> +   int (*pmu_load_update)(struct nvkm_pmu *pmu);
> +   void (*pmu_reset_load_counters)(struct nvkm_pmu *pmu);
> +   void (*pmu_get_load_counters)(struct nvkm_pmu *pmu, u32 *busy_cycles,
> +   u32 *total_cycles);
>  };
>
>  static inline struct nvkm_pmu *
> diff --git a/drm/nouveau/nvkm/subdev/pmu/base.c 
> b/drm/nouveau/nvkm/subdev/pmu/base.c
> index 054b2d2eec35..6afd389b9764 100644
> --- a/drm/nouveau/nvkm/subdev/pmu/base.c
> +++ b/drm/nouveau/nvkm/subdev/pmu/base.c
> @@ -25,6 +25,114 @@
>
>  #include 
>
> +/* init allocator struct */
> +int nvkm_pmu_allocator_init(struct nvkm_pmu_allocator *allocator,
> +   const char *name, u32 start, u32 len)
> +{
> +   memset(allocator, 0, sizeof(struct nvkm_pmu_allocator));
> +
> +   strncpy(allocator->name, name, 32);
> +
> +   allocator->base = start;
> +   allocator->limit = start + len - 1;
> +
> +   allocator->bitmap = kcalloc(BITS_TO_LONGS(len), sizeof(long),
> +   GFP_KERNEL);
> +   if (!allocator->bitmap)
> +   return -ENOMEM;
> +
> +   allocator_dbg(allocator, "%s : base %d, limit %d",
> +   allocator->name, allocator->base);
> +
> +   init_rwsem(&allocator->rw_sema);
> +
> +   allocator->alloc = nvkm_pmu_allocator_block_alloc;
> +   allocator->free = nvkm_pmu_allocator_block_free;
> +
> +   return 0;
> +}
> +
> +/* destroy allocator, free all remaining blocks if any */
> +void nvkm_pmu_allocator_destroy(struct nvkm_pmu_allocator *allocator)
> +{
> +   down_write(&allocator->rw_sema);
> +
> +   kfree(allocator->bitmap);
> +
> +   memset(allocator, 0, sizeof(struct nvkm_pmu_allocator));
> +}
> +
> +/*
> + * *addr != ~0 for fixed address allocation. if *addr == 0, base addr is
> + * returned to caller in *addr.
> + *
> + * contiguous allocation, which allocates one block of
> + * contiguous address.
> +*/
> +int nvkm_

[Nouveau] [Bug 88822] X freezes after watching videos

2015-03-11 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=88822

Pierre Moreau  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #10 from Pierre Moreau  ---


*** This bug has been marked as a duplicate of bug 87244 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 87244] [NV94] X hangs, logs show kernel: nouveau E[ PFIFO][0000:01:00.0] still angry after 101 spins, halt followed by an X trace

2015-03-11 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=87244

Pierre Moreau  changed:

   What|Removed |Added

 CC||shuihuzh...@free.fr

--- Comment #19 from Pierre Moreau  ---
*** Bug 88822 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Bug or not?

2015-03-11 Thread Pierre Moreau

Hi Evan!

Sorry for taking so long before answering...
Thanks for the greps! It appears you have a newer version of apple_gmux than I 
have, so let's see if something also changed in the _DSM method. Could you 
please run - as root - `acpidump -b -n DSDT` which will create a file named 
dsdt.dat containing the DSDT table, and then run `iasl -d dsdt.dat` and send me 
the resulting dsdt.dsl file?
That way I will have the uuid, the available functions and their version for 
your _DSM method.

Regarding bringing the clocks down, you could add a fake performance level in 
the vbios but I'm not sure if it would be a good move. You should rather power 
off the NVidia card and only use the Intel one - using vgaswitcheroo, see [1]; 
once I have that dsdt.dsl file, I should be able to add support for 
auto-powering down the NVidia card. Or you could try to motivate some 
developers - or if you want to give it a try - to investigate / add support for 
power and/or clock gating.

Regards,

Pierre

[1]: http://nouveau.freedesktop.org/wiki/Optimus/#checkingthecurrentpowerstate


- Mail original -
> The first grep of dmesg is for the apple info so you know exactly
> what
> box I have. The second is to show that I am booting in EFI mode and
> not some bogus bios compatibility thing. The third is to show the
> gmux
> version. The fourth is to answer the question you actually asked.
> 
> $ cat /proc/version
> Linux version 3.19.0 (root@turingatlarge) (gcc version 4.7.3 (Gentoo
> 4.7.3-r1 p1.4, pie-0.5.5) ) #3 SMP Sun Feb 15 01:09:59 EST 2015
> 
> -- $ dmesg|grep Apple
> [0.00] efi: EFI v1.10 by Apple
> [0.00] DMI: Apple Inc. MacBookPro9,1/Mac-4B7AC7E43945597E,
> BIOS MBP91.88Z.00D3.B08.1208081132 08/08/2012
> [0.00] ACPI: XSDT 0x8CD8E1C0 B4 (v01 APPLE
> Apple00    0113)
> [0.00] ACPI: FACP 0x8CD8C000 F4 (v04 APPLE
> Apple00   Loki 005F)
> [0.00] ACPI: HPET 0x8CD8B000 38 (v01 APPLE
> Apple00  0001 Loki 005F)
> [0.00] ACPI: APIC 0x8CD8A000 BC (v02 APPLE
> Apple00  0001 Loki 005F)
> [0.00] ACPI: SBST 0x8CD88000 30 (v01 APPLE
> Apple00  0001 Loki 005F)
> [0.00] ACPI: ECDT 0x8CD87000 53 (v01 APPLE
> Apple00  0001 Loki 005F)
> [0.00] ACPI: MCFG 0x8CD89000 3C (v01 APPLE
> Apple00  0001 Loki 005F)
> [3.091740] usb 3-1.1: Manufacturer: Apple Inc.
> [3.410516] usb 4-1.8.1: Manufacturer: Apple Inc.
> [3.581141] usb 4-1.8.2: Manufacturer: Apple Computer, Inc.
> [3.777265] usb 4-1.8.3: Product: Apple Internal Keyboard /
> Trackpad
> [3.777267] usb 4-1.8.3: Manufacturer: Apple Inc.
> [3.782615] input: Apple Inc. Apple Internal Keyboard / Trackpad
> as
> /devices/pci:00/:00:1d.0/usb4/4-1/4-1.8/4-1.8.3/4-1.8.3:1.0/0003:05AC:0252.0002/input/input13
> [3.833440] apple 0003:05AC:0252.0002: input,hidraw0: USB HID
> v1.11
> Keyboard [Apple Inc. Apple Internal Keyboard / Trackpad] on
> usb-:00:1d.0-1.8.3/input0
> [4.091248] apple 0003:05AC:0252.0003: hidraw2: USB HID v1.11
> Device [Apple Inc. Apple Internal Keyboard / Trackpad] on
> usb-:00:1d.0-1.8.3/input1
> [4.319509] usb 4-1.8.1.3: Manufacturer: Apple Inc.
> [4.457798] input: Apple Computer, Inc. IR Receiver as
> /devices/pci:00/:00:1d.0/usb4/4-1/4-1.8/4-1.8.2/4-1.8.2:1.0/0003:05AC:8242.0001/input/input18
> [4.509982] appleir 0003:05AC:8242.0001: input,hiddev0,hidraw4:
> USB
> HID v1.11 Device [Apple Computer, Inc. IR Receiver] on
> usb-:00:1d.0-1.8.2/input0
> 
> -- $ dmesg|grep EFI
> [0.00] efi: EFI v1.10 by Apple
> [1.220269] fb0: EFI VGA frame buffer device
> [2.619144] EFI Variables Facility v0.08 2004-May-17
> [4.205767] fb: switching to nouveaufb from EFI VGA
> 
> -- $ dmesg|grep gmux
> [2.739845] apple_gmux: Found gmux version 1.9.35 [classic]
> [ 4299.386843] apple-gmux 00:03: System wakeup disabled by ACPI
> 
> -- ~/Documents $ dmesg|grep DSM
> [4.205710] ACPI Warning: \_SB_.PCI0.IGPU._DSM: Argument #4 type
> mismatch - Found [Buffer], ACPI requires [Package]
> (20141107/nsarguments-95)
> [4.205724] ACPI: \_SB_.PCI0.IGPU: failed to evaluate _DSM
> [4.205739] ACPI Warning: \_SB_.PCI0.P0P2.GFX0._DSM: Argument #4
> type mismatch - Found [Buffer], ACPI requires [Package]
> (20141107/nsarguments-95)
> [4.205749] ACPI: \_SB_.PCI0.P0P2.GFX0: failed to evaluate _DSM
> 
> On Sun, Feb 15, 2015 at 5:13 AM, Pierre Moreau
>  wrote:
> > Does the Nvidia card auto-suspends or do you have to force it? If
> > not, does
> > it report some “failed to parse _DSM” message?
> > I have a mid 2009 MBP who uses a different _DSM handles than the
> > ones
> > Nouveau currently supports, and I wondered if they were related to
> > the Apple
> > Gmux or not. So, as you have a different model with a different
> > Nvidia card
> > but still with an Apple Gmux, I

[Nouveau] [Bug 80901] [NVCF] PWM fan speed too high

2015-03-11 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=80901

--- Comment #41 from poma  ---
(In reply to Lars E Pettersson from comment #39)
...
> 
> Not sure what all these numbers means though... :)


'nvapeek' might be something like "nvidia peek(read)"
and
'nvapoke' might be something like "nvidia poke(write)",
MMIO regs.

Addresses 'e114'&'e118' with their 'values' should fall into this range:
- G80:GF100 MMIO map
  0x00e000 all PNVIO GPIOs, I2C buses, PWM fan control, and other
external devices
OR
- GF100+ MMIO map
  0x00e000 all PNVIO GPIOs, I2C buses, PWM fan control, and other
external devices

How Martin reached the actual addresses and values, he knows better. :)


Ref.
PEEK and POKE
http://en.wikipedia.org/wiki/PEEK_and_POKE

MMIO
http://en.wikipedia.org/wiki/Memory-mapped_I/O

MMIO register ranges
http://envytools.readthedocs.org/en/latest/hw/mmio.html

PNVIO: external device interface
http://envytools.readthedocs.org/en/latest/hw/io/pnvio.html

Pokémon
http://en.wikipedia.org/wiki/Pokémon

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 80901] [NVCF] PWM fan speed too high

2015-03-11 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=80901

--- Comment #40 from poma  ---
(In reply to K.-P. Schrage from comment #38)
...
> I put the two lines
> echo 1 >
> /sys/devices/pci:00/:00:01.0/:01:00.0/hwmon/hwmon1/pwm1_enable
> /usr/local/bin/nvapoke e118 8002
> into /etc/rc.d/rc.local (don't know any other way to make this workaround
> permanent).
> 

$ udevadm info -a -p /sys/class/drm/card0 | grep -m2
'ATTRS{device}\|ATTRS{vendor}'
ATTRS{device}=="0xabcd"
ATTRS{vendor}=="0x1234"

/etc/udev/rules.d/10-unladen-swallow.rules
ACTION=="add", ATTRS{vendor}=="0x1234", ATTRS{device}=="0xabcd", RUN+="/bin/sh
-c '/bin/echo 1 >
/sys/devices/pci:00/:00:01.0/:01:00.0/hwmon/hwmon1/pwm1_enable'",
RUN+="/usr/local/bin/nvapoke e118 8002"

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] instmem/gk20a: fix crash during error path

2015-03-11 Thread Thierry Reding

On Tue, Mar 10, 2015 at 03:46:08PM +0900, Alexandre Courbot wrote:
> If a memory allocation fails when using the DMA allocator,
> gk20a_instobj_dtor_dma() will be called on the failed instmem object.
> At this time, node->handle might not be NULL despite the call to
> dma_alloc_attrs() having failed. node->cpuaddr is the right member to
> check for such a failure, so use it instead.

Indeed. The DMA address handle is in fact the very opposite of 0 in the
failure case (DMA_ERROR_CODE).

Reviewed-by: Thierry Reding 


pgpScuoncZSsV.pgp
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH] pmu/gk20a: PMU boot support.

2015-03-11 Thread Deepak Goyal

It adds PMU boot support.It loads PMU
firmware into PMU falcon.RM/Kernel driver
receives INIT ack (through interrupt mechanism)
from PMU when PMU boots with success.

Signed-off-by: Deepak Goyal 
---
 drm/nouveau/include/nvkm/subdev/pmu.h |   26 +-
 drm/nouveau/nvkm/subdev/pmu/base.c|  108 ++
 drm/nouveau/nvkm/subdev/pmu/gk20a.c   | 2131 -
 drm/nouveau/nvkm/subdev/pmu/gk20a.h   |  369 ++
 drm/nouveau/nvkm/subdev/pmu/priv.h|  264 
 5 files changed, 2884 insertions(+), 14 deletions(-)
 create mode 100644 drm/nouveau/nvkm/subdev/pmu/gk20a.h

diff --git a/drm/nouveau/include/nvkm/subdev/pmu.h 
b/drm/nouveau/include/nvkm/subdev/pmu.h
index 7b86acc634a0..659b4e0ba02b 100644
--- a/drm/nouveau/include/nvkm/subdev/pmu.h
+++ b/drm/nouveau/include/nvkm/subdev/pmu.h
@@ -1,7 +1,20 @@
 #ifndef __NVKM_PMU_H__
 #define __NVKM_PMU_H__
 #include 
+#include 
+#include 
+#include 
 
+struct pmu_buf_desc {
+   struct nvkm_gpuobj *pmubufobj;
+   struct nvkm_vma pmubufvma;
+   size_t size;
+};
+struct pmu_priv_vm {
+   struct nvkm_gpuobj *mem;
+   struct nvkm_gpuobj *pgd;
+   struct nvkm_vm *vm;
+};
 struct nvkm_pmu {
struct nvkm_subdev base;
 
@@ -20,9 +33,20 @@ struct nvkm_pmu {
u32 message;
u32 data[2];
} recv;
-
+   wait_queue_head_t init_wq;
+   bool gr_initialised;
+   struct dentry *debugfs;
+   struct pmu_buf_desc *pg_buf;
+   struct pmu_priv_vm *pmuvm;
int  (*message)(struct nvkm_pmu *, u32[2], u32, u32, u32, u32);
void (*pgob)(struct nvkm_pmu *, bool);
+   int (*pmu_mutex_acquire)(struct nvkm_pmu *, u32 id, u32 *token);
+   int (*pmu_mutex_release)(struct nvkm_pmu *, u32 id, u32 *token);
+   int (*pmu_load_norm)(struct nvkm_pmu *pmu, u32 *load);
+   int (*pmu_load_update)(struct nvkm_pmu *pmu);
+   void (*pmu_reset_load_counters)(struct nvkm_pmu *pmu);
+   void (*pmu_get_load_counters)(struct nvkm_pmu *pmu, u32 *busy_cycles,
+   u32 *total_cycles);
 };
 
 static inline struct nvkm_pmu *
diff --git a/drm/nouveau/nvkm/subdev/pmu/base.c 
b/drm/nouveau/nvkm/subdev/pmu/base.c
index 054b2d2eec35..6afd389b9764 100644
--- a/drm/nouveau/nvkm/subdev/pmu/base.c
+++ b/drm/nouveau/nvkm/subdev/pmu/base.c
@@ -25,6 +25,114 @@
 
 #include 
 
+/* init allocator struct */
+int nvkm_pmu_allocator_init(struct nvkm_pmu_allocator *allocator,
+   const char *name, u32 start, u32 len)
+{
+   memset(allocator, 0, sizeof(struct nvkm_pmu_allocator));
+
+   strncpy(allocator->name, name, 32);
+
+   allocator->base = start;
+   allocator->limit = start + len - 1;
+
+   allocator->bitmap = kcalloc(BITS_TO_LONGS(len), sizeof(long),
+   GFP_KERNEL);
+   if (!allocator->bitmap)
+   return -ENOMEM;
+
+   allocator_dbg(allocator, "%s : base %d, limit %d",
+   allocator->name, allocator->base);
+
+   init_rwsem(&allocator->rw_sema);
+
+   allocator->alloc = nvkm_pmu_allocator_block_alloc;
+   allocator->free = nvkm_pmu_allocator_block_free;
+
+   return 0;
+}
+
+/* destroy allocator, free all remaining blocks if any */
+void nvkm_pmu_allocator_destroy(struct nvkm_pmu_allocator *allocator)
+{
+   down_write(&allocator->rw_sema);
+
+   kfree(allocator->bitmap);
+
+   memset(allocator, 0, sizeof(struct nvkm_pmu_allocator));
+}
+
+/*
+ * *addr != ~0 for fixed address allocation. if *addr == 0, base addr is
+ * returned to caller in *addr.
+ *
+ * contiguous allocation, which allocates one block of
+ * contiguous address.
+*/
+int nvkm_pmu_allocator_block_alloc(struct nvkm_pmu_allocator *allocator,
+   u32 *addr, u32 len, u32 align)
+{
+   unsigned long _addr;
+
+   allocator_dbg(allocator, "[in] addr %d, len %d", *addr, len);
+
+   if ((*addr != 0 && *addr < allocator->base) || /* check addr range */
+   *addr + len > allocator->limit || /* check addr range */
+   *addr & (align - 1) || /* check addr alignment */
+len == 0)/* check len */
+   return -EINVAL;
+
+   len = ALIGN(len, align);
+   if (!len)
+   return -ENOMEM;
+
+   down_write(&allocator->rw_sema);
+
+   _addr = bitmap_find_next_zero_area(allocator->bitmap,
+   allocator->limit - allocator->base + 1,
+   *addr ? (*addr - allocator->base) : 0,
+   len,
+   align - 1);
+   if ((_addr > allocator->limit - allocator->base + 1) ||
+   (*addr && *addr != (_addr + allocator->base))) {
+   up_write(&allocator->rw_sema);
+   return -ENOMEM;
+   }
+
+   bitmap_set(allocator->bitmap, _addr, len);
+   *addr = allocator->base + _addr;
+
+   up_write(&allocator->rw_sema);
+
+   allocator_dbg(allocator, "[out] addr %d, len %d", *addr, len);
+
+   return 0;
+}
+
+

Re: [Nouveau] Bug or not?

Re: [Nouveau] Bug or not?

Re: [Nouveau] Bug or not?

Re: [Nouveau] [PATCH] pmu/gk20a: PMU boot support.

Re: [Nouveau] [PATCH] pmu/gk20a: PMU boot support.

[Nouveau] [Bug 88822] X freezes after watching videos

[Nouveau] [Bug 87244] [NV94] X hangs, logs show kernel: nouveau E[ PFIFO][0000:01:00.0] still angry after 101 spins, halt followed by an X trace

Re: [Nouveau] Bug or not?

[Nouveau] [Bug 80901] [NVCF] PWM fan speed too high

[Nouveau] [Bug 80901] [NVCF] PWM fan speed too high

Re: [Nouveau] [PATCH] instmem/gk20a: fix crash during error path

[Nouveau] [PATCH] pmu/gk20a: PMU boot support.

12 matches

Site Navigation

Mail list logo

Footer information